- Ensure you have the latest WP-CLI (version 2.0 or higher)
wp package installÂ /gitlab.com/ComposePress/cli.git
- Then runÂ
wp composepress create-project "my plugin"
So first thing you might notice is it looks like I just installed WordPress :P. May as well be true. Will likely get a half decent look in the future.
Anyways, the reason you are here. right..
TL; DR:Â This is a fast, modern, modular, extendable OOP framework to get you up and running fast with ideally best PHP practices while still sticking to WordPress principles. See the Getting Started page and see what its all about!
Compose Press is intended to be a very minimal plugin framework at the core. Unlike all the “MVC” frameworks over the past 5+ years, it does not try to act as some imitation, of Code igniter, CakePHP, or Larvel. Instead its goal is to give a foundation to use that uses modern PHP design principles and idioms that apply to even other languages as well. Because lets face it, I am willing to bet if not you, at-least a few of your friends or colleagues learned PHP by hacking on WordPress. I personally did not, and that makers a huge difference in MANY cases. Its not really a bad thing, but it does keep the quality standards of PHP “WordPress” code way behind compared the rest of the “PHP” world.
This framework has had a version of it in use by the community for over a year via my own community plugins, so it has had some real world usage.
Ideally you can pick up the basics of it within an hour. So ill consider this an hour of your time as an investment, as we are all usually too busy for anything more! right?
Goals of the framework include:
- Using composer for auto-loading and dependency management
- The one large problem in complex plugins that is JUST now starting to be given more attention is loading 50+ classes in every request to add hooks whenÂ half of it is NEVER ran. And doing a ton of conditionals is really not ideal in my opinion for importing classes.
- We also do not need to fork popular libraries likeÂ /github.com/A5hleyRich/wp-background-processing in every plugin with custom “prefixes” unless absolutely required.
- Using namespaces
- Because lets face it, if WordPress had namespaces in the core, we would be looking at the start of a very DIFFERENT WordPress (and for the better I think). The need to support 5.2 really holds it all back when that is older than dial-up internet!
- Using dependency injection/service containers
- Here are some links for explaining to those who don’t know about this. This is very useful for “unit testing” as well as better code design.
- Be highly modular. Everything is based on a component class which in turn has a baseobject class for low level actions and magic access. These are also classes that just use traits :).
- If you don’t know about traits, seeÂ /www.sitepoint.com/using-traits-in-php-5-4/
- Does NOT use $GLOBALS!
- This is a very bad practice that I see encouraged out of ignorance. Instead it uses a “functional singleton” as I call it in which is a static variable inside a function that manages the dependency container which in turn controls the plugin instance and anything else defined.
- Is light weight and very minimal. Excluding the exception classes and interface, the core is a mere 6 files. It also uses some memory/array caching for a few lookups when needed
- It does not intend to be everything possible. However future supporting libraries may come in the future, like models, settings/options library and others. But you only need the core for things to work! ð
If any of this confused you too much, just head over to the Getting Started page and see what its all about!
I encourage any/all feedback and improvements for this system. I also hope this can help making better WordPress developers as well.