Extending Object Types

All of the Object Types supported by ACF Engine such as Post Types, Taxonomies and Options Pages are implemented using abstract classes. The ACF Engine core system loads instances of these objects created using the UX and registers them by using a "custom object type class" such as PostTypeCustom, which extends PostType.

Because post types are used for providing the UX registration of other objects there are many examples under the /src directory of using the PostType abstract class. You'll find that with both PostType and Taxonomy, the minimal data required to create a new object is only a few lines of code. All options are available to set and/or override. If you ever find a setting from WP core registrations that are not implemented, report this to us and we'll fix it.

Here is a full list of object types that you can extend programmatically by using the abstract classes available.

  1. \AcfEngine\PostType - used to register custom post types
  2. \AcfEngine\Taxonomy - used to register custom taxonomies
  3. \AcfEngine\OptionsPage - used to register an ACF options page or subpage.
  4. \AcfEngine\BlockType - used to register an ACF Gutenberg block.
  5. \AcfEngine\Template - used to register a Gutenberg template that can be used either as a single post template, a loop template, or any other form of block-based template supported by ACF Engine.

Use Cases for Extending Object Types #

While the main purpose and typical use of ACF Engine is to provide a UX for registration of ACF-based solutions, there are times when being able to create your own class-based solutions will be beneficial and possibly preferable. This might include creation of an ACF Engine extension plugin.

Before you jump into extending base objects solely because you want to be able to reuse and transport your objects from one site to another, consider that the ACF Engine UX automatically stores all objects created as JSON files. These JSON files can be easily migrated to any other site with ACF Engine installed. So generally, do not create file-based definitions solely for the purpose of migration, because the JSON representations of ACF Engine objects is already completely transferable and has the advantage of also enabling use of the UX to make changes.

In fact one use case for using a code-based definition of your objects would be to ensure nobody else edits them. The JSON versions can always be loaded into and edited in the UX, whereas what you put into code will stay the same until you make a new version of your file. For some applications, that stability may be preferred.

Powered by BetterDocs

Leave a Reply