RS Base Plugin – a really simple class based plugin framework<\/p>\n\n\n\n
On its own this plugin does nothing.<\/p>\n\n\n\n
The class Filters, actions and shortcodes are defined in derived classes simply by making appropriately named class methods. The Additional functionality is defined as PHP traits, which can be used in any combination with the base class.<\/p>\n\n\n\n This class is for making KISS plugins, really simple to program and use, but not flashy. Simplicity is the goal, not looks.<\/p>\n\n\n\n A minimal plugin looks like this:<\/p>\n\n\n\n The class is defined within the All derived plugin classes must set the property The The last line in the example above could therefore also be written as:<\/p>\n\n\n\n Most plugins interact with the WordPress core through action and filter hooks.<\/p>\n\n\n\n Actions and filters are defined in derived classes simply by making appropriately named class methods.<\/p>\n\n\n\n Hooks for actions and filters are simply correctly named class methods:<\/p>\n\n\n\n This cannot work in all cases, as WordPress in some cases uses hook names which do not translate to legal PHP identifiers.<\/p>\n\n\n\n In such cases the correct name of the hook can be defined by a protected class property named The common case of having the plugin basename in name of a hook can be handled by putting the string The priority of an action or filter hook is set by a protected class property named Shortcodes are likewise defined in derived classes simply by making appropriately named class methods.<\/p>\n\n\n\n To be done: AJAX call backs<\/p>\n\n\n\n Each plugin object has at least these three options\/settings related properties:<\/p>\n\n\n\n The method The method The trait A link to the Settings page is added automatically to the plugin’s entry on the Plugin admin page.<\/p>\n\n\n\n The derived class muse use the trait above to activate the settings functionality of base plugin.<\/p>\n\n\n\n The derived class must define a hook for the A settings page is usually made of one or more sections, each containing one or more related fields. Each section and field has some explanatory text.<\/p>\n\n\n\n If the derived class has a A section is defined with The return value is needed for adding fields to the section.<\/p>\n\n\n\n A field is created and added to a section by The The field is rendered by plugin method, in the example above indicated as The Single line text input<\/strong> fields can use Multiline text input<\/strong>, or textareas, can use Checkboxes<\/strong> can use Menus<\/strong> with single or multiple selection can use The cases of creating multiple selection menus for post types or taxonomies have some extra helpers.<\/p>\n\n\n\n Here \\ReneSeindal\\PluginBase<\/code> is meant as a base class for plugin classes. It is a kind of very simple plugin framework, in reality little more than a class constructor and a handful of helper methods to avoid repetitive coding.<\/p>\n\n\n\nPluginBase<\/code> class then automatically adds all the filters, actions and shortcodes.<\/p>\n\n\n\nSetup<\/h3>\n\n\n\n
add_action( 'plugins_loaded', function() {\n class PluginTemplate extends PluginBase {\n protected $plugin_file = __FILE__;\n\n \/\/ use PluginBaseSettings;\n\n \/\/ Methods galore\n }\n\n new PluginTemplate();\n} );<\/code><\/pre>\n\n\n\nplugins_loaded<\/code> hook to make sure the PluginBase<\/code> class is loaded.<\/p>\n\n\n\nplugin_file<\/code> to __FILE__<\/code>, which is needed for several parts of the base plugin.<\/p>\n\n\n\nSingleton interface<\/h4>\n\n\n\n
PluginBase<\/code> class also implements a static method instance()<\/code> which creates a singleton interface. This is useful if the plugin object is needed elsewhere, e.g., for a WP-CLI interface.<\/p>\n\n\n\nPluginTemplate::instance();<\/code><\/pre>\n\n\n\nActions and filters<\/h3>\n\n\n\n
Hooks<\/h4>\n\n\n\n
\n
do_ACTION<\/em>_action()<\/code>‘ defines a hook for ACTION<\/em>;<\/li>\n\n\n\ndo_ACTION<\/em>_action_EXTRA<\/em>()<\/code>‘ defines the same hook for ACTION<\/em> as above. The EXTRA<\/em> part can be descriptive or allow several callbacks for the same ACTION<\/em>, which can make sense to keep related code together and readable;<\/li>\n\n\n\ndo_FILTER<\/em>_filter()<\/code> defines a hook for FILTER<\/em><\/em>;<\/li>\n\n\n\ndo_FILTER<\/em>_filter_EXTRA<\/em>()<\/code>‘ is the same hook for FILTER<\/em>, just as for actions above.<\/li>\n<\/ul>\n\n\n\n$ACTION<\/em>_callback_hook<\/code> or $FILTER<\/em>_callback_hook<\/code>.<\/p>\n\n\n\n__PLUGIN_BASENAME__<\/code> in its place, which the base plugin will substitute automatically. Please note that this often leads to three underscores in a row in a method name.<\/p>\n\n\n\nPriority<\/h4>\n\n\n\n
$ACTION_EXTRA<\/em>_callback_priority<\/code> or $FILTER_EXTRA<\/em>_callback_priority<\/code>. If not defined the WordPress default of 10 is used.<\/p>\n\n\n\nShortcodes<\/h3>\n\n\n\n
\n
do_SHORTCODE<\/em>_shortcode()<\/code>‘ defines a shortcode named SHORTCODE<\/em>.<\/li>\n<\/ul>\n\n\n\nAjax end-points<\/h3>\n\n\n\n
Options<\/h3>\n\n\n\n
\n
options_page<\/code> — if not set, it is set to the base-name of $plugin_file<\/code> with the extension .php<\/code> removed. This is the default option page URL. See section Settings below.<\/li>\n\n\n\noptions_base<\/code> — if not set, it is set to $options_page with all hyphens changed to underscores.<\/li>\n\n\n\noptions_name<\/code> — if not set, it is set to $options_base<\/code> with _options<\/code> added.<\/li>\n<\/ul>\n\n\n\nget_options()<\/code> will retrieve option $option_name<\/code> which is usually an array of all the plugin’s options.<\/p>\n\n\n\nget_option( $name, $default = NULL )<\/code> will retrieve the named option from the array of plugin options.<\/p>\n\n\n\nSettings<\/h3>\n\n\n\n
PluginBaseSettings<\/code> defines a set of methods for making simple option pages.<\/p>\n\n\n\nPlugin requirements<\/h4>\n\n\n\n
use PluginBaseSettings<\/code><\/code><\/pre>\n\n\n\nAdding the settings page to the menu<\/h4>\n\n\n\n
admin_menu<\/code> action to generate a menu link to the settings page. In most cases the method settings_add_menu()<\/code> will be sufficient:<\/p>\n\n\n\nfunction do_admin_menu_action() {\n $this->settings_add_menu(\n __( 'Settings page title', 'text-domain' ),\n __( 'Menu heading', 'text-domain' )\n );\n}<\/code><\/pre>\n\n\n\nGenerating the settings page<\/h4>\n\n\n\n
settings_define_sections_and_fields()<\/code> method, that is called automatically to define, wait for it, sections and fields.<\/p>\n\n\n\nPluginBase::settions_add_section()<\/code>:<\/p>\n\n\n\n$section = $this->settings_add_section(\n 'section_id',\n __( 'Display name', 'text-domain' ),\n __( 'Explanatory text', 'text-domain' )\n);\n<\/code><\/pre>\n\n\n\nPluginBase::settings_add_field()<\/code>, in this way:<\/p>\n\n\n\n$this->settings_add_field(\n 'field_id', $section,\n __( 'Field name', 'text-domain' ),\n 'settings_field_XXX_html',\n $args\n);<\/code><\/pre>\n\n\n\nfield_id<\/code> is a unique identifier for the field — which can be used with PluginBase::get_option()<\/code> to retrieve the value — and the translated string is for display.<\/p>\n\n\n\nsettings_field_XXX_html<\/code> with additional arguments $args<\/code>, an associative array.<\/p>\n\n\n\nField types<\/h4>\n\n\n\n
PluginBase<\/code> class defines field renderer methods for the most common input types.<\/p>\n\n\n\nsettings_field_input_html<\/code> which takes these arguments:<\/p>\n\n\n\n\n
settings_field_textarea_html<\/code>:<\/p>\n\n\n\n\n
settings_field_checkbox_html<\/code>:<\/p>\n\n\n\n\n
settings_field_select_html<\/code>:<\/p>\n\n\n\n\n
Post types and taxonomy menus<\/h4>\n\n\n\n
$this->settings_build_post_types_menu(\n $field, $section, $label,\n $query, $default, $hooks\n);<\/code><\/pre>\n\n\n\n$query<\/code>\u00a0is the argument to get_post_types()<\/code> \ud83d\udd17, while $default<\/code> is the defaults selection. The last $hooks<\/code> (string|array) are filters through which the list of post types to display is run before rendering the menu.<\/p>\n\n\n\n