default
theme. You are welcome to use it and modify it for your needs, yet if you want to start with a blank page, you can also create a completely new theme.
The following section explains how they are structured and their main concepts. We recommend you to read this if you are creating your own theme, or making extensive changes to the ones we provide.
themes
folder is located in the root of the application and is the directory where each theme folder must be added. If you navigate to path /themes/
you’ll see our default theme which has the following structure:
theme.json
): It uses JSON syntax to define theme metadata (name, version and author) as well as a list of templates that are part of the theme.assets
: It intended for static assets like CSS, JS or images that are used by the theme. All contents from this directory are mounted under the /assets
path in the portal HTTP server.layouts
: The layout is the top level view of your theme.views
: The view is rendered as a part of a layout. Each view can be rendered using a different layout.partials
: Partials provide an easier way to handle snippets of code that are reused across different views or layouts, for example if you want to inject a JS snippet that’s used in different places, you could set this code in a partial and include it anywhere by using the appropriate ‘Go template directive’. In this way you could improve code readability and organize the theme in the most efficient way.default
theme that is located in /themes/default
. The syntax looks as follows:
templates
field establishes a list of available templates. Every template consists of three fields where name
is a user-friendly name that will be seen on the Admin app when creating a page. template
is a reference to the template file itself. layout
is a reference to the layout that will be used to render the previously set template.
To illustrate the current template hierarchy, this is what a typically rendered page would look like. The layout
would be the top level template and base structure of the page:
layouts
and views
but also any combination of them. These combinations are set in your manifest file (theme.json
).
Regarding partials
, even though the illustration above shows two partials embedded on the view
section, partials
are intended for using in any place. You should be able to embed a partial
directly into a layout, or even in multiple layouts.
Content blocks are explored more deeply in the next sections. To summarise, its relationship with the above hierarchy is when rendering a particular page, a layout
, a view
and potentially a combination of partials get loaded from the theme directory. Content blocks are different because their content gets dynamically populated by database content. These contents are created from the Admin section.
To be Concluded:
<!DOCTYPE html>
, <html>
, <head>
, <title>
, and <body>
.template
is what we would inject in a layout and specifically within the <body>
of a layout.partial
can be, for example, the navigation menu so that you can inject it in the layout and it will be visible every time this layout is used.tmpl
file extension, which is the default Go template extension. Go templates work in a similar way to ERB or EJS templates by letting the user mix HTML code with dynamic values. Sample syntax is as follows:
{{ render “top_nav” }}
The code sample above would execute the render
template helper, which is a common function that’s used to inject code from other views
into the current one. You may use this to embed content from other parts of the theme, typically partials
or views
. In this case, it will insert a view
or partial
named top_nav
to the template where it’s used.
The same delimiters {{
and }}
are used for all Go template directives. We’ll explore some of them in the upcoming sections.
See the Go package template documentation for more information.
view
by using a particular template directive in combination with a name or ID to identify the given block. For example, if you check the home
template in the default theme (themes/default/views/home.tmpl
), you will find the following code:
{{ .page.Title }}
. This is the Title
input in the form UI (Screenshot #1){{ .blocks.HeaderDescription.Content }}
. This is the HeaderDescription
input in the form UI (Screenshot #2){{ .blocks.HeaderButtonLink.Content }}
. This is the HeaderDescription
input in the form UI (Screenshot #3){{ .blocks.HeaderButtonLabel.Content }}
. This is the HeaderButtonLabel
input in the form UI (Screenshot #4)PORTAL_MAX_UPLOAD_SIZE
. This parameter is configurable.
main
branch contains code corresponding to the latest stable release. If you wish to check out a specific release (e.g., v1.8.3), you can use tags:
portal-default-theme
repo in github.
portal-default-theme
repo among your remotes before adding it. Execute the following command to check:portal-default-theme
.
portal-default-theme
to the remotes by executing the following command:main
branch. That branch will mirror the latest changes from the portal-default-theme
main. You will be using it to import the latest changes from the portal-default-theme
to your custom theme:main
branch in the portal-default-theme
repo, you can just pull the latest updates:
portal-default-theme-main
:dev-branch
.
portal-default-theme
into the dev-branch
. Please remember to always pull the latest changes from the portal-default-theme-main
branch before merging:
portal-default-theme
repo, you need to create a zip archive with the customized theme and upload it to the portal.
src
folder and not the folder itself. To create a zip archive with the customized theme execute the following:
src
directory to make sure you:src
directory: