OOPS-WP Structures and Utilities

Structures introduced in 0.2.0

Plugin

A Plugin object is one that represents the primary class of a WordPress plugin.

In future releases, the Plugin abstract may be updated to include additional functionality that is specific to plugin registration, such as methods for retrieving methods from the plugin bootstrap file, default activation or deactivation routines, etc. In version 0.2.0, the Plugin abstract class was introduced primarily for lexical reasons. It extends the ServiceRegistrar class, because the primary responsibility of the main plugin class is to instantiate the various services which the plugin itself provides.

Taxonomy

The Taxonomy class is an object that can be extended to quickly register a new custom taxonomy. It provides an extremely limited set of default arguments necessary to hook the taxonomy into WordPress (that is, the labels that you are required to define), and will throw exceptions if any values are missing, such as the taxonomy slug or object types to which it's associated (e.g., post, attachment).

ContentType

The ContentType class was introduced to define an abstract structure for objects that are responsible for registering content with WordPress in a unified way. Specifically, the PostType and Taxonomy classes each extend this class, because both post types and taxonomies require that you define a slug, an array of arguments, and an array of labels to register them with WordPress.

It is possible that there may be other uses for this class in the future, both within OOPS-WP or within your own projects which use it. Any object that requires a slug, an array of arguments and an array of labels would be a candidate to extend this class.

Shortcode

The Shortcode class was introduced to facilitate registration of custom shortcodes within WordPress. Objects extending this class must define both a register and render method, the latter of which is required because all shortcodes must output something to the display. The Shortcode class implements the ShortcodeInterface interface.

Utilities introduced in 0.2.0

Renderable

The Renderable interface was introduced to allow implementing classes to uniformly declare how their data is output to a display. It requires a single method, render. The body of this method in implementing classes should contain logic which echoes or prints data to the screen, either via the use of a PHP echo statement, or by requiring templates which are subsequently output.

In the 0.2.0 release, the Shortcode class is one such structure which implements Renderable.

Structure interfaces

Some structure-specific interfaces were introduced in 0.2.0 to allow for some additional flexibility for engineers when scaffolding projects. These include:

• PluginInterface
• ContentTypeInterface
• ShortcodeInterface
• EditorBlockInterface

The aforementioned S.O.L.I.D. principles dictate that we must rely on abstractions, not concretions, and that it's advisable to write code against an interface. Some of these interfaces may seem redundant, particularly in cases where they're nearly interchangeable with the abstract classes which implement them, such as Plugin. The rationale for this decision, however, is that a primary goal of this library is to allow engineers who use it decide what approach they want to take. It is certainly possible that one may want their concrete classes to implement the interfaces that OOPS-WP provides without necessarily extending the abstracts. Making these interfaces available provides them that flexibility.

Structures introduced in 0.1.0

Structures are abstract classes that can be extended during plugin and theme development, the result of which will become some kind of "thing" in WordPress - a post type, a shortcode, a widget, etc.

Service

A Service in OOPS-WP represents a functional component in WordPress.

For instance, as a developer who is building a custom plugin for a client, you might be tasked with extending WordPress to provide some additional post types and taxonomies. You could create a ContentRegistrationService object that contains references to each individual post type and taxonomy, each of which would be represented by their own class file. The job of the service is to create each of those objects and to fire its hooks at runtime.

ServiceRegistrar

A ServiceRegistrar is an object that registers a collection of Services.

Continuing with the ContentRegistrationService example above, let's say that your client's plugin also required some custom REST API routes, some WP-CLI commands, and a few custom settings pages.

Instead of putting all of the logic for those different pieces of functionality into a single class or functions file, you could split the responsibility of each feature set into its own Service class: an ApiService, a CliService, and a SettingsService. The role of the ServiceRegistrar is to contain references to those individual services, creating their objects and triggering their WordPress hooks at runtime.

PostType

The PostType class is an object that can be extended to quickly register a new custom post type. It provides a small set of arguments needed to hook the post type with WordPress, and requires that you define a slug and an array of labels that WordPress will need to load it.

EditorBlock

The EditorBlock class can be used when registering a new Gutenberg block with WordPress. It defines a set of abstract methods that your child class will define in order to give your blocks a type and paths to its assets.

Utilities introduced in 0.1.0

Utilities are interfaces and traits that your own classes can implement and use, ensuring that your objects define the methods that are needed at runtime. Generally, these interfaces are small, and importantly, they promote the L in SOLID - letting you switch out one kind of object for another in the future, so long as that new object still abides by the same interface.

Hookable

The Hookable interface requires a single method, register_hooks, which should be implemented by objects that need to hook into WordPress. The register_hooks method helps keep all of those hooks in one place within a class file.

Registerable

The Registerable interface can be used by classes that require some kind of "registration" with WordPress. Generally, these are objects that subsequently call some type of WordPress registration function, such as register_post_type, register_taxonomy, add_shortcode, etc.

Runnable

The Runnable interface requires a single method, run, which can be implemented by objects that need to trigger some kind of process after instantiation. This might be something like a plugin or Service object, which first gets initialized, then subsequently needs to be run.

The run method helps support unit testing by classes that implement it, because boot-up logic that requires interaction with the WordPress APIs can be stored in here, allowing us to create new objects without tons of additional setup when writing tests.

FilePathDependent

The FilePathDependent trait can be used by objects that require some kind of reference to a file path. One such example is the EditorBlock class, which leverage this trait to indicate where the class is relative to its JavaScript and CSS assets.

AssetsLocator

The AssetsLocator interface can be implemented by objects that require some kind of URL reference to a file path. It differs from the FilePathDependent trait because the location of assets required by an object may not be within the file server and thus, is required by an object to define its method body.