tukutoi / better-wp-plugin-boilerplate Goto Github PK

See #17 (comment)

I've done this in the boilerplate-based plugin https://github.com/TukuToi/tukutoi-cp-directory-integration/blob/f91ec328109c6f4b6948cd9414b4567fc77deed1/includes/class-cp-plgn-drctry-loader.php#L191

Should become standard.

It is easy enough to run wp i18n make-pot <target-dir> in terminal to generate the POT of a plugin, but not many know it.

We should add at least a description to the readme about this (it can also be done with GNU's native gettext utility xgettext --add-comments *.php, but that isn't as nice for Plugins as the WP CLI command is)

More complicated setups can be seen here for example, however that is really not needed given WP CLI exists.

This is just a "catch all" ticket to jot down things that should be added, removed, or changed in the new version.

As folder structure, we are breaking away from the public/admin structure which became pointless (and never really had a point) and instead approach it with the only somewhat globally accepted "standard" in PHP.
This will also allow more freedom in the actual application structure itself.

Full autoloader should be implemented, thus, all classes should likely reside inside one single folder, and access controls should be done on a more granular base and not like in the old approach on a more "global" level

Namespaces should be used

See full list of "no go" here https://github.com/szepeviktor/starter-plugin/blob/wp-63/README.md#what-to-avoid

Potentially it should include more examples for newbies, as it is always easier to remove than to add: so we should add a menu page, shortcode (already there in current version), perhaps some more examples on filters and actions, localised AJAX script, and so on.

Also, a very important point is to NOT abstract the add_action and add_filter (which is currently the case in the plugin boilerplate)
This has not only confused people but also is based on pure "personal opinion" by the original author, and makes no real sense, as it is just adding clutter code and does not really improve anything: filters and actions are not going to change and do not require plugin-side abstraction.

While the concept is a good idea, it is futile in this case and teaches the user nothing useful.
The abstraction can be better brought to example in a admin-side page or menu with settings, or custom /user field implementation

Thinking of which, the plugin should show how to add custom fields of all kinds, custom field tables, taxonomy, post type, settings and options (best exampled on the admin page) as well.

The plugin should and will keep full WPCS compliance, overruling any other PCR rule