Sugget use PHP autoloder

[cherifGsoul]

The plugin loader is great feature in WP plugin boilerplate but we can make it better by using the php autoload feature http://php.net/manual/fr/function.spl-autoload-register.php I started making something like this https://github.com/cherifGsoul/plugin-framework/blob/master/includes/framework/class-core.php but not have much time to accomplish this, would be great if the user can register his own autoloaders for third-party classes (for mustache template egine for example) :) hope this could help

[ryanhellyer]

I'm having trouble understanding how this would be beneficial to a plugin.

[tommcfarlin]

At this point, I'm not interested in using an autoloader because it's a feature that's not supported by the base version of PHP that WordPress supports.

Once those are in-sync, we'll revisit it :).

[afragen]

Tom, spl_autoload_register requires PHP version >= 5.1.2 and WordPress requires PHP version >= 5.2.4

I'm currently using it in GitHub Updater.

[tommcfarlin]

Then I stand corrected :). Shame on my for not paying closer attention.

With that said, I'm definitely up for re-opening this ticket for discussion. @afragen have you found benefits in usual autoloading in the Updater prior to using it before?

[afragen]

I found the benefits were a single location for loading classes instead of having require_once littered (figuratively of course) throughout the code. Any place the class is instantiated results in a check to see if the class is loaded and if not, loads it. It really does help modularize the code and should assist in maintainability. Give me a sec and I'll point to my autoload method, but I liberally copied from @yoast in WordPress SEO.

https://github.com/afragen/github-updater/blob/develop/includes/class-github-updater.php#L61

[afragen]

Essentially eliminates

if ( ! class_exists( 'My_Class' ) {
   require_once my-class.php;
}

[leewillis77]

Small[1] note of caution, but although SPL is available < 5.3.0, and is compiled by default, it's optional, so it's possible for PHP 5.2.4 to not have the SPL functions available [Source: http://php.net/manual/en/spl.installation.php]

[1] Small because I can't see why anyone would do that, or indeed if anyone really does

[afragen]

Thanks @leewillis77 but as we say here at the hospital, "You can't cure stupid."

[cherifGsoul]

@ryanhellyer if WordPress lack of using some great features of PHP (for historical reasons) as autoloading dosent mean that plugin developers should be it's benefical to avoid using require include and require_once that result bad code (for maintenance) and with autoloading, classes will be lazy loded which mean the file is not loaded if is not needed the plugin will have better performance, @tommcfarlin yes I understand your concerns about the supported PHP version in WP I just talk about the autoloading in PHP (since 5.1) not PSR0 or PSR1 and composer stuffs, maybe a POC will be great for better understanding.

[mAAdhaTTah]

@cherifGsoul Generally, if you're developing for WordPress, you should try and conform to its requirements. Obviously, this isn't always feasible, nor even strictly necessary, but if Tom is aiming to build a general-use boilerplate for plugin development, I have to guess that his goal is to be completely compatible with WordPress, which a 5.3+ autoloading scheme wouldn't be. I don't think the 5.2 compat version includes lazy loading, though it would solve the "require_once everywhere!" problem.

[cherifGsoul]

@mAAdhaTTah I dont talk about 5.3+ features, Im aware of WP requirements and coding standards, I use a php framework that require PHP 5.1+ and supports Lazy loading, after all, WordPress API uses PHP and we can use some best practices whitout changing any of WP workflow, requirements or standards.

[renoirb]

+1 In 2014, with PHP 5.6 out and PSR coding conventions out and running for a few years already.

A project that says promoting coding best practices but doesn’t teach or helps use of spl_autoload and other package managements such as Composer (e.g. http://wpackagist.org/) should reconsider its positioning as "best practice friendly". Include in every file is how we were doing w/ PHP <= 5.2.

Granted that one given plugin boilerplate, such as this very project, cannot be responsible of WordPress core. It still shouldn’t say code best-practice without making PSR part of the boilerplate.

[markhowellsmead]

+1 for namespace implementation.

[cherifGsoul]

@renoirb @mhmli WP Plugin boilerplate should follow WordPress coding standards and minimum requirements, namespaces and composer are out of this for now, but with some tweaks can be open for extension :)

[markhowellsmead]

Searching the core, there is one solitary call to spl_autoload_registerin wp-includes/class-simplepie.php. So perhaps that's a start ;)

[ryanhellyer]

A project that says promoting coding best practices but doesn’t teach or helps use of spl_autoload and other package managements such as Composer (e.g. http://wpackagist.org/) should reconsider its positioning as "best practice friendly". Include in every file is how we were doing w/ PHP <= 5.2.

It's promoting best WordPress coding practices, which would include maintaining support for whatever setups WordPress core also supports.

[markhowellsmead]

I'd welcome the switch to namespaces and spl_autoload, but as it's only supported in newer versions of PHP, I can understand the reticence before making such a change. It's on a par to dropping support for IE8; desirable, but exclusionary for many, many thousands of users around to world who depend on this software and who have no possibility of upgrading.

[renoirb]

I’m sorry for my previous (troll-ish) post. You guys are right, its worthless to make a boilerplate extension using PSR recommendation if the core doesn’t support it officially yet. PSR autoloader is a good thing if the main entry point (i.e. WordPress front controller, index.php) uses the autoloader. Otherwise it creates collision.

I would recommend to document how to install a full WordPress using http://wpackagist.org/ and that a plugin using this boilerplate project to be loaded in that fashion. While may people are using this technique along with how to deploy by submodules (that’s what I did here) Its still experimental and not supported by core. Its up to you guys.

[mAAdhaTTah]

Tom has said he's not planning on implementing namespacing, composer, gulp, etc. in this version of the Boilerplate, but I've built a fork off Tom's work that implements some of these things. I'd love some feedback from you guys if you're interested.

[tommcfarlin]

Hey guys,

First off, all of this discussion is important to me.

@renoirb don't worry about your previous post. I know what you meant, Trust me, I want to include things that are more up to date with PSR standards, composer, etc. This is something that's definitely on my radar.

Right now, I'm having to strike a balance between what the minimum requirements for WordPress core require, and then come up with a strategy for implementing more advanced functionality.

The biggest priority on deck right now is building out a documentation site. That's going to be what helps a lot of people with many of the questions they have.

After that, I want to move into specific forks or versions of the Boilerplate that cater to specific needs like custom poster types, meta boxes, etc., as well as streamlining development with things like composer, etc.

These are all things that are on my radar, but I'm having to be more pragmatic about it. :)

[danieliser]

My thought here is not every plugin warrants it.

If you have a plugin with 5-10 then includes should be sufficient. When you have so many that your include page looks like a wall of text, then autoloader may be efficient to manage them better.

Definitely seems like overkill to include it by default though.

[jaspervalero]

Code that tries to be everything to everyone fails 100% of the time. Boilerplates better serve the community when they are opinionated things. They help the community grow and learn by introducing best practices through their implementations.

It should be a teacher to those just starting out. It should be a sigh of relief to those already implementing best practices. It should be a challenge to those not yet there.

WPPB must support the building of plugins that function within WordPress, that is fact. Developers should use best practices whenever possible, another fact. So the key is to identify low hanging fruit. Find ways to raise the bar while not breaking functionality.

A perfect example is what you've discussed here. If PSR-4 autoloaders are not supported, yet:

• Determine timeline for support, sync the WPPB roadmap with that timing.
• Determine if WordPress supports spl_autoload_register, if so put it in place. If not, determine timeline for support and sync WPPB roadmap.

Be vigilant in these types of conversations. It is easy to go down the wrong path based on assumptions when not all facts are present. A few suggestions that will help:

• Identify the best practice resources the project will use as a guideline, E.g. http://www.phptherightway.com/
• Determine version support vs date timelines and develop a roadmap. This will make tasks seem much more surmountable.
• Be agile. Remember the WordPress today is not the one of tomorrow. If you can't do something now, don't rule it out permanently. Come back to it at a later date. The previous bullet can help with that.
• Use what you learn in conversations about feature requests and best practices that raise concerns about support.

Lastly @danieliser, the idea that some plugins might not need best practices (autoloaders in this case) because they're smaller is dangerous. That type of thinking is a breeding ground for technical debt. It suggests that there is some magic threshold that exists. The reality is even the smallest of projects should implement best practices. One class is good enough reason to implement an autoloader as a project with 100 classes. It isn't long before it pays for itself and actually cuts down on code required in the project.

[danieliser]

As a developer who has been working with WordPress since v2.0 and seen an explosive amount of growth I will both agree and disagree with you.

You points about the boilerplate are on par. But the fact is that WP already has support for auto loaders and uses them in 1-2 places. So that is a non issue altogether as WP has already made the decision to use it.

As for the last part. I completely disagree. I can find you dozens of plugins that simply wouldn't warrant it at all.

Examples would be:

1 Line plugins. 1 function / 1 action plugins 1 widget /single file plugins

Your assumption is that all plugins have enough code to maintain that setting up a large set of files and folders to manage it is warranted.

Lets convert that to another industry. I mean when you pay a contractor to build a house, does he order steel girders and a crane to build it? No because wood and nails will do the trick.

Sometimes the extra code will not only take longer to build but also require more maintenance than the functionality itself. This shows a clear sign of "Not Warranted".

I will say that most of my plugins are not that small and I do use OOP to keep it clean and I do use autoloaders ( comes from my 4 years experience with MVC OOP application development with Kohana & Codeigniter ).

But even with that said, there are projects simply to small to warrant even firing up Kohana install. Sometimes there is such thing as overkill. And an autoloader for a 1-5 file plugin is overkill generally speaking.

[danieliser]

PS Best practice almost always starts with Keep It Simple which includes de-duplicating work, writing code using the most efficient functions for the job IE for over foreach etc, and reducing impact on performance & the host systems ( WP, Servers etc ).

I know PHP & WP best practices and constantly find myself still checking them and docs to be sure I have the most up to date info. And with that I will say that there is no best practice when it comes to using an autoloader. The reason is purely sometimes it adds more than the plugin itself.

[mAAdhaTTah]

As for the last part. I completely disagree. I can find you dozens of plugins that simply wouldn't warrant it at all.

...

Your assumption is that all plugins have enough code to maintain that setting up a large set of files and folders to manage it is warranted.

While this may be true generally, I would suggest that those small plugin aren't going to fire up the full Boilerplate anyway. As you say, keep it simple, and some if the divisions laid out aren't necessary for those small plug-ins. I think, if you believe your plugin is going to be big enough to warrant the full Boilerplate treatment, it's probably big enough to use an autoloader.

[danieliser]

And I would agree. I believe that the proven usage of auto loaders in WP core is enough to warrant setting it up here anyways. OOP is just cleaner with an Auto Loader setup.

[jaspervalero]

@danieliser,

There is a reason I said, "One class is good enough reason to implement an autoloader as a project with 100 classes." Obviously, you don't use an autoloader if there are not any classes involved. There are always exceptions and that is a prime example. I understand the point you're trying to make and don't disagree. The point I was trying to make is to be careful when walking that line. :)

[omarabid]

@danieliser I think you make a good point. Having 50 files just to create a simple wordpress plugin is an overkill.

Between, I'm building/maintaining a different boilerplate: https://github.com/omarabid/WordPress-Plugin-Boilerplate

The decided approach will be using Composer and adding packages on your will.

Example 1: You want to make a 15 lines plugin. You simply download the boilerplate with no requirements. This will give you a single PHP file which has the boilerplate main class.

Example 2: You want to build a giant WP Plugin. You simply download the boilerplate and then using composer you download other packages. (Templating, Options Framework, Debugging, Logging, MVC Framework...)

In a nutshell, the boilerplate is simply one file. And everything else is a package. Package are maintained separately. They have their own tests and they can be used in other plugins as well.

If you have application specific logic, it should be implemented in the "Helpers" folder of the MVC app package. If it's not just a function, then maybe it's a package.

I also want to streamline the development and deployment process using Docker.

If anyone is interested in discussing it, they can email me. You may want to check the issues: https://github.com/omarabid/WordPress-Plugin-Boilerplate/issues or the milestones of the project: https://github.com/omarabid/WordPress-Plugin-Boilerplate/milestones

[cherifGsoul]

Now minimum WP requirements is PHP >= 5.6 I suggest to start with a class map autloader.

[DevinVinson]

Technically no, the requirements are still 5.2.4+. The recommended specs have been bumped to 5.6+.

That said, I'm planning on adding an autoloader and redoing the organization of the plugin a bit fairly soon. There is just no reason to not be using it at this point.

[cherifGsoul]

@DevinVinson Im confused here!! the wordpress.org requirements page said:

to run WordPress we recommend your host supports: PHP version 5.6 or greater MySQL version 5.6 or greater

[AlchemyUnited]

Moi? And to @DevinVinson's point...

The boilerplate should be directed at the customer (read: developers) who are most likely to use it. Using a One Size Fit All mentality is inefficient when there are known section of the market for which the product (i.e., boilerplate) just ain't gonna fit.

If the majority of that buying market (e.g., developers following this repo) are in favor of leaning forward (e.g., autoloader, composer, etc.) then it would make sense to steer the product in that direction. A slight lean forward in this boilerplate standard, that allows for stuff to be removed, makes more sense then leaving stuff out, having multiple wheels reinvented similtaneously, only to have to standardize those some time soon (6 to 12 months?).

"If ya wanna make omletes ya gotta break some eggs."

Perhaps forward compatipility (i.e., growth and general direction) should be just as important - of not more so - as backward compatibility (i.e., static and dying)?

[DevinVinson]

Recommend does not mean Required. Not going to argue over semantics since I agree with the main point about using an autoloader.

[gvanto]

Has spl autoloading been implemented in this plugin boilerplate? I downloaded from wppb.io but couldn't see anything autoload-y in the downloaded project ...

[ralphonz]

Still no namespaces and autoload yet? Is this coming to the boilerplate? Seems a little overdue now possibly as this discussion was started over 2 1/2 years ago.

[DevinVinson]

WordPress still supports PHP 5.2.4 which does not support Namespaces. If the boilerplate is to implement them it will be a strategic step in breaking with standards.

This isn't an official core project by any means but if those features are a necessity for you then fork the repo and add them.

With that said, I keep this and the other really good conversations for some of these features open as issues (and even PRs) because I want anyone looking to fork to see the resources available.

[garretmh]

WordPress may still run on PHP 5.2.4 but PHP itself considers versions up to PHP 5.5 unsupported and unsafe. Is support-by-default really necessary for new projects using this boilerplate?

[AlchemyUnited]

As a user of traits - which I believe started with 5.4 - I'd say "No sleep til (at least) 5.4." :)

Off the record, what WP Core does for the sake of bragging rights (i.e., market share) is not a good enough reason for the rest of us to follow. If this boilerplate is about progress then it seems silly to have its collective decisions tied to Core's ego.

[otakupahp]

Guys, this is an old post and the whole plugin development seems to be stuck.

Now WP requires PHP 5.6 so I think is safe the resurrect this old request.

@DevinVinson , what do you think about it?

[otakupahp]

Furthermore @karannagupta forked this years ago to let autoload https://github.com/karannagupta/WordPress-Plugin-Boilerplate

Maybe is time to rebranch it?

[DevinVinson]

I'm working on a rewrite that uses psr-4 autoloading now that base support is there for it. I'll end up closing any open issues on the current version and forks once I move it to this repo. For now the issues, discussions, and PRs are all still available for working with the current version.

[simplenotezy]

Would love a composer autoloader..

[BrianHenryIE]

I've a fork with namespacing, autoloading and prefixed composer libraries: https://github.com/BrianHenryIE/WordPress-Plugin-Boilerplate/

[adamradocz]

Same here, plus Settings template: https://github.com/adamradocz/WordPress-Plugin-Boilerplate