Content Architecture
Posts
Currently we don't treat posts any different than if we would in a monolithic WordPress site. Occasionally they may have custom fields, but typically are kept basic with the one content field and featured image.
Pages & Page Templates
While we have flexible content to keep our pages dynamic and flexible for designs, lots of times we'll want more fine grain control. Some examples may include:
- Contact page where a form is used
- About page where there is a grid of people
If you're going to create a new Page Template (can be done from the admin), be sure that the layout can't already be solved with Flexible Content. If you believe it can, but the current flexible content block doesn't have the layout you need, file an issue on the wordpress-headless-childtheme repo and leave a link to the site you need it on. Yes, it's possible to extend the flexible content on a per-site basis, but we also tie these flexible layouts into our react-components
If the design doesn't really need flexible content, feel free to create a page template for each page and then make your custom fields available on a per-template, not a per-page basis. The reason we do this is because clients will have access to these pages and my occasionally change the page slug. Because of this, we target page templates, not slugs within React Static.
Custom Post Types & Taxonomies
The Custom Post Type UI plugin is available to create, edit, and manage custom post types and taxonomies. Use this plugin opposed to adding to the functions so that we have consistency accross projects and that all* configuration is done within the admin.
Be sure that for each custom post type and taxonomy that you create that you have the True option selected for Show in REST API.
Should this be a CPT or an ACF Repeater?
The argument could be made that you could simply use an ACF repeater in many cases that you'd use a CPT. However, it is recommended to use a CPT more liberally in a static site because it helps us to organize content better by not tightly coupling it with other content.
Think about it this way. The content and the static site are independent from one another. As such, they can mature and develop independently. For example...
Say in Version 1 of a site we have a grid of employees on the About page and that's the only place we ever use those people. In Version 2 of the site however, it's decided that each person is going to have their own page. If you created the people grid in V1 from a repeater field on the About page, you'll have to completely rework your content for V2. Whereas if you used a CPT, that data is already independent from the about page and can still be used within the about page, or in any other way we need it.
Custom Fields
The main thing here is to be consistent, and to tie field groups to Options Pages (Brand), a CPT, or a Page Template. You really shouldn't have any per-page fields (read the Pages & Page Templates section above for an explanation).
General rules for consistency
If the Field Group is for a CPT or Page Template, check the Hide on screen option for Content Editor. This way it keeps all our content nested within ACF (makes developing the frontend easier).
Naming Convention: Just use a name that's descriptive and is self-explanitory. For example, if I'm going to create a Field Group for my Contact Template, I would call my Field Group "Contact Template Content".
To prevent naming collisions in the WP database, always make sure your top-level field is a group. If you just need a repeater or flexible content, you can use those as well. The idea here is that you only have to namespace that top field, opposed to all fields within the Field Group.
Going back to our Contact Template example... I would name the Field Name "contact_template_content" (the Field Label can be anything that is descriptive for the SMS Client). A nested field may be a form's title. The Field Name can then be something simple and non-namespaced like "form_title".
Brand Options
These fields are global content used throughout the site. Common usecases here are logos, contact info, social icons, or anything used within the header or footer (outside of main navigation).
Default fields are already in place. These can change on a per-site basis based on what is required by the design.
Menus
Menus management works just like it would in a monolithic WP setup. We've already extended the WP REST API to access any menu at /wp-json/sms/v1/menu/MENU_NAME
.
*Items that aren't managed within the WP admin include: Custom TinyMCE Button, Menu Registration (Header and Footer menus are registered by default), custom options pages (Brand is registered by default), and REST API customizations.