The following will try to explain the logic of our CMS.
We use our WordPress theme as base for content management so please read the theme docs first.
Content management logic is built into our WordPress theme and it helps developers create Advanced Custom Fields PRO fields seamlessly.
We use field and module classes to create customizable fields. All available core fields are located in gotoAndCore/Fields
folder and all modules in gotoAndPlay/Modules
folder.
Fields and modules will be sent to twig as classes meaning all public variables and methods can be accessed directly.
At the moment fields can be added under all classes that extend one of the following classes:
gotoAndCore\Models\Post
gotoAndCore\Models\Page
gotoAndCore\Models\Term
gotoAndCore\Models\User
gotoAndCore\Models\NavMenu
gotoAndCore\Models\NavMenuItem
gotoAndCore\Models\OptionsPage
gotoAndCore\Models\Module
gotoAndCore\Models\Layout
To add fields, define public static function getFields
method. The method must return an array where keys are the names for fields and values are the field classes.
For example if we want to define a title and a content field we could do the following:
public static function getFields() {
return [
'title' => new Text(),
'content' => new Wysiwyg(),
];
}
In the defined class we will be able to access the values for these fields with they same key they are defined. For example if we want to modify the title we could do this:
public function getMainTitle() {
return sprintf('<h1>%s</h1>', $this->title);
}
Keep in mind that all the keys that are defined under the public static function getFields
method will be added under the class as variables.
If we do not define a variable under the class we assume the variable to be public
.
This means that if we wanted to register the field as title and modify the value before it is passed to twig we must define it as protected
and create a public function getTitle
.
protected $title;
public function getTitle() {
return sprintf('<h1>%s</h1>', $this->title);
}
You can define global fields for a post type under its abstract class. At the moment we support global fields for Post, Page, User and Term classes.
abstract class Page extends CorePage {
public static function getFields() {
return [
'hero' => new Hero(),
];
}
}
It is also possible to overwrite the global fields in the parent class.
class NoHero extends Page {
protected function getView() {
return '@view-no-hero';
}
public static function getFields() {
return [
'hero' => false,
];
}
}
PS: Also remember that that the field variables can never be defined as private
only protected
or public
are allowed.
Registering field group settings can be done by adding public static function getFieldGroupSettings
. There you can specify ACF settings that are regularly defined on a field group.
For example, hiding the default content editor and changing the menu order for the template:
public static function getFieldGroupSettings() {
return [
'hide_on_screen' => [
'the_content',
],
'menu_order' => 2,
];
}
A single field can be separated as its own field group by adding the group_settings
property to its settings. Inside group_settings
you can define ACF settings that are regularly defined on a field group, just as you would inside public static function getFieldGroupSettings
. If we want to give the group a custom name and/or add multiple fields inside the named group we can define group_name
in field settings which will group all the fields with the same name together.
For example, positioning a field such that it displays in the side menu:
public static function getFields() {
return [
'text' => new Text([
'group_name' => 'Pre title',
'group_settings' => [
'position' => 'side'
]
]),
'icon' => new Icon([
'group_name' => 'Pre title',
]),
];
}
Take a look at some of the usage examples here.