A page template can consist of multiple segmented areas of content. Some could be small blocks of meta data, the source path to the pages hero image, or a large body of text editable by a WYSIWYG editor.
Humblee comes pre-installed with few existing content block types
This is the default main-body content for a page.
SEO & Meta Tabs
This helpful content type has multiple fields for entering the page title and description (used by search engines) as well as additional open graph meta tags for social sharing.
Extra Head Code
<head> of the page at load time.
Note that for the above block and all custom blocks, it is up to the developer to ensure that the templates have an area with a PHP snippet that echo's out each of the content blocks. See the "drawing content" section of the templates documentation.
Users with the "designer" or "developer" role can use the "Manage Content Blocks" tool to register new content blocks within the CMS.
The "Object Key" field defines how this block will be referenced in the
$content array passed to the templates.
The "Input Parameters" is the code that will be injected into the CMS editor with the UI necessary for users to edit the content. There are multiple pre-set snippets that can be used by selecting them from the "Input Type" field.
Make sure you also use the "Manage Templates" tool to add the new block to existing page templates that may require it and update the given template's PHP view file.
In addition to the predefined "Input Types" a more complex content block may require a customized UI. This is especially neccessary if the content block has multiple normalized fields. To create a custom widget for editing a content block, select "Custom PHP Form" from the "Input Types" field. Then enter the path from the
~/humblee/views/ folder to the new file you will create.
You may want to look at the pre-built "SEO & Meta Tags" widget in
~/humblee/views/admin/contentWidgets/seo to get a good feel for how to generate a editor widget.
Custom editor widgets assume that the content will have multiple fields, so it stores them as a serialized JSON array in the database. The editor widget must include a hidden form field named
serialize_fields with a value that lists all of the
<input> fields within the widget that will have content to be stored. This will be used on POST to store all the fields and their values in a single array in the database.
When the editor widget is loaded, the view is passed the array,
$content_array which contains all of the decoded fields previously saved in the database so they can be echoed back into the form.
Here is an example of a simple editor widget that loads a form with three input fields, including one that lets you pick an image from the Media Manager: