Content - Page templates
Page types
When you first add the content plugin, only a single page type will be available to you: page
. Usually you’ll need more. 🙂
Much like Custom Post Types
in WordPress, ContentPage types in OFW content plugin allow you to define specific design and functionality to a page. So you may have a page which displays a list of articles, you may have a page which displays the article itself, and you may also have a separate front page design.
In OFW content plugin each page type will have the following:
- a type id and a list of available
ContentPageSection
types defined in the conf - name and icon defined in the lang
- an HTML view template that defines what the page looks like
- an optional controller to load any additional data
So let’s look at these one by one.
Page type configuration
Say we want to add a new page type, article
. To add a new page type you’ll need to modify content.conf.ini
and the contentpage.lang.*.ini
lang file.
Let’s modify content.conf.ini
first. Take the existing content plugin version and move it to the app level at /app/conf/content.conf.ini
. Next, update contentpage_types
and also add a new contentpagesection_article
section. The resulting file should look something like this:
[contentpage] # This is a comma-separated list of available page types. contentpage_types = page,article # .... [contentpagesection_article] contentpagesection_panels = 1 contentpagesection_types = header,textarea,gallery contentpage_is_singular = false
For more info on contentpagesection_types
see the docs on this topic.
When you set the contentpage_is_singular
property to true then only one page of this type will be created. This is useful for site main pages where you don’t need multiple instances of the page type.
Page type name and icon
Now create an app-level contentpage.lang.*.ini file. This should be for your admin locale, so whatever $zajconf['locale_admin']
is set to. Note that you do not need to create this for all site locales – just admin ones!
The important part is the [menu]
section – here we need to add the new type’s name and icon:
[menu] menu_contentpage_article = Articles icon_contentpage_article = file-o
Note that icons should use font-awesome id’s, but without the fa- prefix!
Page template
All page types require a page template. A page template will define the design and display all the ContentPageSection
objects on this page (see docs on creating section types). The naming is important here – you need to add it to /app/view/contentpage/*.html
so in the case of our article type example the file would go in /app/view/contentpage/article.html
.
A very simple page template would look like this:
Of course, you can and should use the same template inheritance features that are provided by the OFW template system.
Page controller
Some pages may require additional data to be loaded before the template is shown. In this case you can optionally add a page template controller. Again, the naming is important here – you need to add it to /app/controller/contentpage/*.ctl.php
so in the case of our article example the file would go in /app/controller/contentpage/article.ctl.php
.
Page controllers will follow this format:
…and the __before()
method will be called magically before the page template is loaded.
Multiple panels / columns
All content page types can support one or more panels. Panels can be anything from various design areas on the page or they can be multiple columns. To support multiple panels, simply update contentpagesection_panels
in your content.conf.ini
for the given page type. Next, when you design your template, update it so that contentpagesections are displayed for a given column only:
Panel-specific settings
In certain cases you may want to set up panel-specific settings for a page. There are three settings you can modify: the name, the types (or contentpagesection types it accepts), and whether the panel is locked.
contentpagesection_panel1_name = Top area contentpagesection_panel1_types = header,textarea contentpagesection_panel1_locked = true
In this case the first panel will be named “Top area” (instead of the default “Column 1”), it will accept only contentpagesections of type header and textarea, and it will be locked.
Locking panels
When a design requires completely fixed sections you can lock the given panel.
You can lock panels by setting their contentpagesection_panelX_locked
property to true (see full example above). When locked, only users with full admin
rights will be presented with the option to unlock and modify the page.
Specific layouts
You should try to use multi-panel layout as much as possible to provide an ideal balance between the admin’s flexibility and the design contstraints of the page.
But sometimes the layout is so specific that you need to display a given section in a given div due to design constraints. In this case you can use the contentpagesections tag like so:
For these specific layout pages it is useful to set up Layout templates – see below. You should also lock the panel or the entire page for these layouts so that admins cannot mess it up by rearranging or adding new sections.
Layout templates
Once you have completed your ContentPageSection settings (type, name, template, etc.) you can set up layout templates for admins so that they do not have to memorize which section goes where and with what settings.
To do this simply create a new contentpage item in the chosen type, then when you save it choose “Layout template” from the dropdown where you set the content’s visibility:
Displaying breadcrumbs
If pages have hierarchy then you can display breadcrumbs using the ContentPage’s parents
property.