Cutting with WP would make a lot of sense, to really start becoming something interesting.
WordPress is diverging from what it was before WP 5, and since CP is sticking to pre WP 5, sharing the plugins repository is just a bad idea. And more now that all new plugins are basically Gutenberg blocks.
It will be good for CP to have its own Plugin Directory, separated from WP, since that will allow to set new standards that may allow CP to actually make changes in its core without fearing back-compat issues.
What I think is very important, if CP ends up cutting with the WP plugin repo, is to set clear standards and really stick to them. [Prefer quality plugins over quantity!]
For example:
Never use something that is under PHP 8.
Use namespaces for plugins instead of prefixing everything.
Prohibiting the Singleton Pattern in plugins.
Don’t rely on core jQuery!
Provide a modern and clear Plugin Development Handbook.
Setting minimum quality standards that are actually not hard to implement (like using namespaces) will result in ClassicPress being a top notch quality CMS that will attract all those developers who run away from WP because of its old way of doing things.
Not doing so will just end up filling the new plugin repository with unevitable technical debt.
Of course, it may also push away users who want to contribute but don’t want to follow harsh rules. Gotta find some balance.
Using jQuery for specific things that can be achieved easily with VanillaJS or with the modern Web API is just lazy. And lazy software is bad software.
While I do namespace my own code, using prefixes does not add technical debt. This is because no matter how much PHP changes, it’s not going to break code simply because it was prefixed. I would daresay that prefixed code is actually even more protected from PHP changes than namespaced code, namely because, while namespace behavior may change over time in PHP, the behavior of prefixed code will not change at all. The only real benefit of using namespaces (over prefixes) is that you’re typing less characters, but, since virtually everything in an IDE is autocompleted anyway, it doesn’t really amount to much benefit.
Using jQuery (which is loaded whether you use it or not) is perfectly fine.
I admit that this makes a lot of sense, but I didn’t just mean namespaces. The original idea was to set up a list of standards, to bring code quality to the top. Maybe the specific point with namespaces is irrelevant.
The point is: the less jQuery is used, the easier it will be in the future to remove it or just don’t load it by default. jQuery is an old thing that helped while Javascript was not as mature as it is today. But there are now more efficient ways of doing things.
If we stick to load the whole jQuery library for things like $('#element').hide() instead of just doing it in a way that the browser already knows without having to download a library, then CP will never be able to say goodbye to jQuery.
In the end, I’m just talking about trying to promote best practices.
Thanks for clarifying. I wouldn’t mind seeing jQuery removed (or, at the very least, updated); I just think that ship may have already sailed. jQuery is everywhere in the *Press space and if CP wants to attract WP devs, it will need to offer the same tools so they can hit the ground running. I could be wrong, but, it seems unlikely that devs will be willing to learn vanilla JS simply to adhere to a CP recommendation unless the userbase becomes large enough to support a monetized effort.
The problem is with old tutorials showing how to create a WordPress plugin. If there is a modern step by step guide with good recommendations, I’m sure developers will at least consider those recommendations.
I will put in the effort to create such a guide in the following days.
I would keep this topic open so that others can state what they think would be a good list of recommendations. If not called standards or requirements, at least call them recommendations and have them visible.
Updating from my previous list:
Never use something that is under PHP 7.2.
Consider using namespaces for plugins instead of prefixing everything.
Consider not using the Singleton Pattern in plugins just for the sake of globalizing stuff.
Completely agree about old tutorials – the space is riddled with outdated (and sometimes just plain bad) advice. In a lot of cases (at least for me) rather than seeing a step by step guide for a new process, it can be helpful to see a contrast of smaller parts of the process. For example: “here’s how we’ve traditionally done x in jQuery [insert example code here] and here’s how it’s done in vanilla JS [insert example here]” to break it down into more manageable/consumable bits.
Now, this is how to get your ideas implemented!
…and I like your updated list much more than your original.
Here’s my list of better practices (used in my own plugins)…maybe one or two items might be good for your list.
Everyone has good points in this discussion. Instead of making these into requirements, we should create a document with recommended coding standards. Maybe starting with @anon71687268’s list and expanding on it as needed.
ClassicPress Initiative, the non-profit managing ClassicPress, is classified as an educational organization (I believe). So this actually gives us an opportunity to educate developers by providing tutorials and guides on improving their PHP skills.
For example, if we recommend the use of namespaces then we can provide examples and explanations why it’s a better option than prefixes. Plus, provide an example of how an existing code using prefixes can be refactored using namespaces.
We could also do this for jQuery and vanilla JavaScript. Provide examples for most common jQuery functions using vanilla JavaScript.
This would help educate developers on the modern best practices while driving traffic to ClassicPress properties and exposing developers to ClassicPress (help with awareness).
Rather dogmatic links that don’t convince me in the slightest. There are multiple scenarios where it makes sense, for example a registry class of transient data used by a codebase, or access to a single resource.
Those are just examples; my point is that edicts about coding style will simply alienate developers and stop the directory growing. Suggestions, sure, but imperatives? Not a good idea.
As something of a modern-day heretic, I actually have no problem with flat, C-style PHP code that uses a common prefix for each function to avoid collisions with other code, for simple and small projects.
I find that small pieces of code written in this way are much easier to fit inside one’s head. And since plugins should be kept simple, fulfilling a single purpose… this often works out pretty well.
In fact if we are going to promote specific development practices then my first choice would be just that: keep your plugin code as small as possible. Our community already tends to think this way, and I would like for the ClassicPress plugin directory to include some metrics around line counts and/or sizes for this very reason: to continue to nudge people towards creating and using smaller, simpler plugins.
As far as architectural practices, I suggest learning to write automated tests. With good automated tests in place, the architecture of the code matters less, because you have more flexibility to improve and reorganize things as needed and be pretty sure you won’t be breaking anything. Writing code in a way that allows automated testing of one small piece at a time also tends to encourage better architecture all by itself. This might take the form of classes that don’t mutate global state or composable functions that have as few side effects as possible, either way, the result is cleaner.
It’s also important to keep in mind that plugin code doesn’t operate in a vacuum. It has to interface with ClassicPress itself and that code is a mess with a lot of history and mistakes behind it, many of which can’t really be fixed at this point because they would break the ecosystem that depends on the current behavior. The “best practices” for writing a CP plugin therefore probably shouldn’t be the same “best practices” as starting a new, modern PHP project from scratch.
There are at least as many opinions about best practices as there are developers. We can nudge things in a certain direction but I don’t think dictating specific architectural choices is the right path.
My thoughts exactly. I can only like your post once though!
Every time I think of what PHP is designed for, which is to be a filter for static content that you can easily insert dynamic things into, I am flabbergasted at the megabytes of code that is loaded just to create a web page. Keep it simple is so important.
PHP8 with strict_types=1 helped me much.
it makes the codes easily to read and track, while I dont have to remember all of the var/param names and its content
I learn a lot from WP codes, especially the naming conventions.
Add that with PHP8 with strict_types=1, its like using jetpack while coding.
