Hi!

Love this boilerplate. Began using it a few days ago on a new plugin project and while it takes some getting used to there's just so much to gain.

I have a question about best practice: The user should be able to call a function from within their theme (think of it as a function that outputs some interactive elements). Where and how would you put this?

My current solution is to have a static public function inside the public class (public/class-plugin-name-public.php) and let them call it by

Plugin_Name_Public::the_public_function();

But it doesn't feel right.. Should I put another file in the public folder which just contains these functions (not in a class) and include it via the load_dependencies() function? By my logic that should mean that they'll be able to call it with just:

the_public_function();

P.S. I do realize the function name has to be very unique in that case

I use this snippet to set actions/filters only when they are needed (no admin actions if we are no there and vice versa):

protected function __construct() {
    $this->_actionsCommon();

    if ( is_admin() ) {
        $this->_actionsAdmin();
    }
    else {
        $this->_actionsFront();
    }
}

Here, in 2.8.0, admin has its own class, which is great. I already asked about is_admin in the previous issue. What about common actions? What about not setting front actions when is_admin?

Thank you!

It would be really handy if you could throw in a plugin slug, plugin name, plugin author etc. etc. and have it automatically spit out a plugin with everything named correctly at http://wppb.io/.

In short: Moved everything to uninstall.php. Imho that file should be renamed to setup.php. Or if someone wants to really, really use that crap, which is called "WordPress Coding Standards", then it should be class-plugin-name-setup.php.

I moved everything - including the callback hooked to the wpmu_new_blog hook - into that file. The file itself contains a class. All the logic that has previously been in place (like looping though blogs/blog IDs and calling single site actions/callbacks) have been moved as well. This makes the main file much more consistent.

In the class-plugin-name.php file, loading the text-domain is pointing to the wrong folder. Since moving the file into a public folder, the relative link being computed is public/languages/.

When WordPress tacks on WP_PLUGIN_DIR the final path is /home/www/wp-content/plugins/public/languages/ instead of /home/www/wp-content/plugins/plugin-name/languages/

I usually privatize the __clone() magic method in singletons I write. Technically, if I understand cloning correctly, PHP will still make the shallow copy of the cloned object in memory, but then when it calls the __clone() method, since it's private, it creates a fatal error.

It's probably overkill, but adding the following to the classes (usually as the last thing in the class to keep it out of the way) isn't so bad:

private function __clone() { }

Thoughts?

I believe when core scans the plugin directory it looks at all PHP files in the root of each subfolder. (citation needed)

It's probably a negligible performance impact, but would there be a benefit to moving these two files to a classes sub-directory, performance or organization-wise? As people add classes it helps to have a separate inc or classes directory to keep everything organized.

class-plugin-name.php
class-plugin-name-admin.php

This would involve modifying the include paths for these files and anything using dirname or basename in the classes.

These PHP files would remain in the root:

plugin-name.php
uninstall.php
index.php

See issue: https://github.com/DevinVinson/WordPress-Plugin-Boilerplate/issues/396

By using native add_action and add_filter functions you're able to use IDE benefits and stick to WordPress conventions, decreasing the learning curve to new plugin developers.

According to the PHP Documentation Standards, the @author tag should not be used in plugins, 'except in the case of maintaining it in external libraries'.

At this point, I'm interested in moving the assets directory above the root of the plugin directory.

This is the follow the new practices of the WordPress Theme repository (as @GaryJ) has pointed out not long ago.

The typical Subversion repository structure is:

• assets
• branches
• tags
• trunk

As far as I'm concerned, plugin-name is analagous to the trunk directory, so this means that assets should be moved up one level; however, this places the directory with the changelog and the README which doesn't make sense.

Instead, it feels almost like we should create a trunk directory of sorts, but I'm looking for some additional input on how to best handle this.

Hey guys, I'm after a little assistance please.

I am writing a plugin to extend the functionality of another, I would like to set up a proper "plugin dependency check within boilerplate but unfortunately lack the knowledge of where to perform such checks as well as what the best practice for performing said checks are.

The plugin I am extending is WooCommerce how would i go about checking that WooCommerce is installed and currently active.

I'm assuming a check would need to be performed when my plugin is activated, other than this would there be any other instances where i would need to perform such a check?

Could I politely ask for some assistance from my fellow, more knowledgeable developers out there! Thanks Lee.

Added Composer so that this project can be based on namespaces and dependencies, enabling more complex solutions. Also, applied the PHP PSR-2 coding standard.

Plugin tested on local environment.

In the installation instructions it clearly states to replace "plugin_name" with "my_plugin_name". However in many example uses of this boilerplate I see $plugin_name not renamed and in fact $plugin_name is usually defined as such "$plugin_name = my_plugin_name". I've seen this as part of the construct when including additional class files, and also in the root of new classes. This is really confusing - what is the proper naming convention and are there are any instances of "plugin_name" that should not be replaced, such as those that are not exact matches and/or begin with special characters ('>', '$', etc.). If so, why is this not documented in the installation instructions?

Currently a hook defined as below would throw an error under Php 8

$this->loader->add_filter( 'woocommerce_single_product_zoom_enabled', null, '__return_false' );

This change let someone set the hook component as null, thus making built in WordPress functions accessible within the plugin using $this->loader->add_action or $this->loader->add_filter methods

I just picked up the code to use it for my plugin. I have this urge to turn some of the core classes to singletons. Before doing so, was wondering why it's not like that already.

Any specific reason?