One of concrete5's greatest strengths is the way that its pages support in-context editing. This mode is not an afterthought or a bolted-on feature; it is the way that concrete5 has always worked. Site administrators need only visit a particular page, put the page in edit mode, and click and edit to make changes to a page. Changes are made instantaneously. No administrative panel needs to be understood out of the gate.

However, there are times when this approach is not the best way to manage content. For example, when adding pages concrete5 presents itself much like a blank canvas. While this freedom is powerful, certain applications require a bit more structure, and concrete5's approach may take longer than necessary. The solution isn't to ignore concrete5's built-in objects like pages, attributes or page types, but instead to craft a custom interface for creating these pages in a more efficient manner. This tutorial will show you how to do just that.

Required Version

While this tutorial uses screenshots from concrete 5.4.0.5, its approach should work on concrete 5.3.3.1 and above.

Download Code

If you want to skip the tutorial and download the code, you can do so from here.

Components

I'm going to show you how to build a simple FAQ system for your website. Here are the components of it:

Multiple FAQ Sections

Using a custom attribute, administrators can specify different sections of their site as possible FAQ Entry holders.

Dashboard Add/Edit Interface

Administrators will be able to use a simplified dashboard interface to add FAQ Entries beneath these categories.

These FAQ Entries can be pages of any type, leaving their presentation very flexible. Since they are pages, they can be returned in search results and have additional blocks attached to them.

Dashboard List/Filter Interface

The dashboard single page interface lists all FAQ entries added to the site, and allows filtering by section:

Custom Page List

A custom page list template allows administrators to display these pages in an attractive, FAQ-esque way.

Specifying FAQ Sections

The Example FAQ code detailed here uses a custom attribute to determine where FAQs can be added to a particular website. You'll need to create this attribute, then set it to true at one or more pages in your site. Then, those pages will show up as places where FAQ entries may be added.

Create and Assign Required Custom Attributes

Now, create a select element with the handle faq_tags. (Note: this attribute isn't used in any of our custom views - it is simply here to detail how you can include custom attribute forms in your single pages.)

Finally, assign the FAQ Section attribute to at least one page in your site.

Creating the Single Page

Our dashboard interface for listing and editing FAQ entries will be found at

http://www.yoursite.com/index.php/dashboard/example_faq/

The first thing we'll want to do is register this URL with concrete5. To do so, first we create code files for the single page's view layer, and its controller. These files can be empty at first – they just need to exist.

Create the View Layer

Within your site's single_pages/ directory, create a folder named "dashboard," then a folder named "example_faq", and within it, place an empty view.php file.

Create the Controller

Within your site's controllers/ directory, create the same structure, but instead of creating a file named view.php, name it controller.php

Add Controller Code to Your Controller

Some code needs to be added to your controller file before we can proceed with the installation of your new single page. Add this code to your empty controller file:

<?php
class DashboardExampleFaqController extends Controller {
}

This code simply tells concrete5 the name of the controller class. It must be named and capitalized this way! (Note: capitalization is important.) Simply take the path of the directories you're using, replace any underscores with additional punctuation, and add Controller on the end of the class. Make sure it your class extends the Controller class.

Install the Single Page

Now that the code files are in their proper place, you need to register the single page with concrete5 before it shows up in the dashboard. This is done in the Dashboard > Pages & Themes > Single Pages area of your dashboard. Simply scroll to the bottom and enter the path to your new single page in the form field:

Submit the form, and your page should show up in the dashboard in the left menu. Click on it, and you should have a blank page in the dashboard available to you.

Controller Code

Now it's time to populate the DashboardExampleFaqController class with real code.

Setup

Now that you have blank controller and view files, it's time to add code to them, so that they can do things like retrieve pages, list pages, and add pages. Add the following methods to the controller.php file:

public $helpers = array('html','form');

This declaration loads the Html and Form helpers found in concrete/helpers/, and sets them in the view.php file. This means that helper objects named $html and $form, respectively, will be available. (This is simply a shorthand way of specifying which helpers are available in a controller's associated view.)

The on_start() method fires automatically every time the associated controller is run. (Note: this is slightly different than the __construct() method - on_start() will only ever be run when the page is actually rendered as a view. Here we load the PageList class, and setup ValidationErrorHelper object within our controller.

The first two methods we include in our controller are responsible for loading data within the view layer. The Controller::view() method is automatically run when a particular single page is viewed. That means the moment we come to index.php/dashboard/example_faq/, our view() method is run. First, it runs the loadFAQSections() method, which sets a $sections array filled with all pages that have been marked as FAQ Sections (using the faq_section attribute detailed earlier.) Then, it creates a new PageList object that retrieves all pages within any of these sections, and sets up paging on it. Finally, the list of pages and the PageList object itself are set within the view using Controller::set(), so those variables will be accessible within view.php

Edit

The edit() function will be fired when we edit a particular FAQ entry using this single page interface (e.g. http://www.yoursite.com/index.php/dashboard/example_faq/edit/200)

First, we run setupForm(), which takes care of loading available FAQ sections, as well as getting an array of all page types installed on a site, and adding our rich text editor JavaScript. Then, we get information about the requested FAQ Entry, validate that it appears in the proper location, and set the $faq object in the view layer.

Add/Update

The add() function is fired when the add interface is displayed and/or submitted (e.g. http://www.yoursite.com/index.php/dashboard/example_faq/add/).

First, we setup the form. If we're not posting the form, then no further action is required. If the form is a post, however, that means we're submitting a new FAQ Entry into our system. That means we need to validate it using the validate() function (which will be shown later.) If the validate function passes, that means we're posting valid information, so we grab the parent page specified, grab the page type specified, and add a page of the specific type. Then we call a custom saveData() method (shown later) which takes care of setting up custom attributes like tags, and body content. Then we redirect the user to http://www.yoursite.com/index.php/dashboard/example_faq/faq_added/

The update() function is run when an existing FAQ Entry is updated. It is very similar to add() but takes an existing page ID:

First we run the edit function on the posted faqID variable, then we run validate. If there are no errors, we update the page, move it if necessary, and handle redirection.

Validation

protected function validate() {
$vt = Loader::helper('validation/strings');
$vn = Loader::Helper('validation/numbers');
$dt = Loader::helper("form/date_time");
if (!$vn->integer($this->post('cParentID'))) {
$this->error->add(t('You must choose a parent page for this FAQ entry.'));
}
if (!$vn->integer($this->post('ctID'))) {
$this->error->add(t('You must choose a page type for this FAQ entry.'));
}
if (!$vt->notempty($this->post('faqTitle'))) {
$this->error->add(t('Title is required'));
}
if (!$this->error->has()) {
Loader::model('collection_types');
$ct = CollectionType::getByID($this->post('ctID'));
$parent = Page::getByID($this->post('cParentID'));
$parentPermissions = new Permissions($parent);
if (!$parentPermissions->canAddSubCollection($ct)) {
$this->error->add(
t('You do not have permission to add a page of that type to that area of the site.')
);
}
}
}

The validate function is run by both add() and update(), and checks the post array to ensure that the FAQ entry in question has valid properties. First, we check to ensure that a parent ID is passed through post, a valid page type ID is passed, a valid title, and then we check permissions to ensure that the user has the ability to add to the particular location. If any of these fail, we add a text error to the $this->error object we instantiated in on_start() above (more on this below.)

saveData($p)

This function is run by both add() and update(), and is responsible for saving body content, and setting custom attributes on the page in question. It is passed the page object.

The first bit of code is responsible for clearing out any existing blocks in the Main area. The second saves a block of type content into the Main area array, and the third is responsible for grabbing the submitting 'faq_tags' attribute form, and saving it against the page.

Error and Success Display

The following methods are those that display success and error messages to the end user.

The faq_added() and faq_updated() methods are automatically run when the user is redirect to http://www.yoursite.com/index.php/dashboard/example_faq/faq_added or http://www.yoursite.com/index.php/dashboard/example_faq/faq_updated/, respectively. They simply set the $message variable in the view layer, which is automatically displayed in a nice fashion by our dashboard theme. Beyond setting this variable, no further action is required. Finally, the on_before_render() function will be called immediately prior to exiting the controller and rendering the view. It sets the $error variable in the Dashboard theme. If this error object has any errors – such as those tripped by the validate() function above – they will be displayed in a nice list automatically.

View Code

The following code goes into view.php. It directly interacts with any variables set within the controller.

Create view vs. add/update sections

The same view.php file will be displayed whether a user is listing all FAQs or add/updating one. That means we need to create a single outer loop which displays certain content depending on the current task.

The top half of the if statement will show in add/edit/update mode, and the bottom half will show in all other cases. We place the adding/editing form in the first section, and the listing form in the second.

Add/Edit/Update Form

This code should be pasted within the first section of the loop above.

This code is responsible for creating the add/update interface. It is unified for both add and update, meaning that if a valid $faq object is present, the fields will be loaded in, otherwise they will be blank. This code provides good examples of using our form helper to create textarea and text elements, loading the rich text editor, and rendering the form view for a custom attribute. While we include just the FAQ Tags custom attribute, any number and any type of custom attribute can be included in a single page interface. The code provided here will display any of the attribute types, and save them properly against the page automatically.

Finally, we load the concrete interface helper to present submit and cancel buttons to the user in the concrete5 style.

View List

The second bit of code in view.php is responsible for listing all existing FAQs. Paste this code within the second half of the loop created above.

This is simply a repurposed view.php from the existing core Page List block. Instead of showing the description, we keep the description hidden and create a custom JavaScript method that fires when clicking on the FAQ question.

Add a Page List and Apply the Custom Template

Add the Page List block on your various FAQ Section pages, configure them to show their child pages, and then assign this custom template to them.

And that's it!

Conclusion

At this point you should see how easy it is for a developer to create a fully interactive, full-featured editing interface for pages, using the concrete5 single page approach. Your administrative users will be able to add and edit FAQ entries without interacting with the front-end interface at all. Pages are still created, meaning that they can be moved, updated, tweaked and customized using existing concrete5 editing interfaces, themes and add-ons.