Hello,
Please see the first question here: https://www.ads-software.com/extend/plugins/easy-admin-color-schemes/faq/
As it says, the new version 4.0 of the plugin requires at least PHP version 5.3. If your server can’t support PHP 5.3 or greater then you can still use the old version of the plugin.
I made the decision to require PHP 5.3 with the new version of the plugin to help promote better future coding standards. It uses PHP namespaces which require at least PHP version 5.3. The only other way around that is to use classes or function prefixes.
Classes shouldn’t really be used for most WordPress plugins because most WordPress plugins are just collections of functions, rather than actual object-oriented programs.
The function prefixing works fine but it does make the code a lot more complex and harder to maintain. For example, the older versions of the plugin have “eacs_” before every function and every function call. This is required to prevent naming collisions with other plugins/themes. Most people have a ton of plugins active at any one time so naming collisions is a very real problem.
So, I decided to go with namespacing. It works perfectly except, of course, if your server doesn’t have at least PHP 5.3.
Most good hosting providers should be using at least PHP 5.3 at this point anyway considering it’s been available for quite some time. Heck, PHP 6 isn’t even that far off. But, I do understand that some hosting providers do not yet support PHP 5.3 or greater, so, for those users the old version of the plugin should still work fine.
I really wanted to be able to provide a more user-friendly way to let users know that the version of PHP their server is running is not compatible with the new version of the plugin, but unfortunately, there’s no real easy way to do that. It’s sorta possible but, requires some quite hacky code to do it.
The way namespacing in PHP works, you can’t really detect if they have the right version of PHP before you go ahead trying to use namespaces. The namespace code has to go right at the top of the PHP file before any other logic, so, you can’t really do any detecting before that point. As a result, if you try to activate the plugin on a server that doesn’t have at least PHP version 5.3, you will get the error you are seeing.
I’m sorry if this causes you (or anyone else) any inconvenience. It probably wasn’t the best way to go in terms of backward-compatibility, but, I think most plugins should be coded similar to this in the future.
If this causes too much of a fuss for everyone I might look into other alternatives (if there are any good ones) soon.
I suppose the entire issue here is up for debate and more of a personal belief, but, it seemed like a good idea at the time. It actually still seems like a good idea. To me anyway. Only time will tell if most people agree/disagree with me though.
I guess overall this is kind of like an experiment. Not that I’m trying to waste anyone’s time with an experiment, but, I think it’s worth it to move coding standards forward.
I’m definitely not out to piss people off or make things harder for anyone. I was just trying to create an example of how things should be done in the future.
Most plugin developers just use classes without even thinking about it. It’s actually not a proper practice. It works, sure, but it’s not how things should be done. Granted, classes might be good for some plugins. But, for the vast majority of plugins, it’s really not the proper solution.
Sorry for the long response. Just kind of wanted to try to explain my reasoning.
Anyway, please feel free to get back to me at any time with your thoughts, opinions, etc. I kind of figured this might cause some problems for some people so, I really am open to any and all feedback.
If you prefer E-Mail, just send it here: mail [AT] jamesdimick [DOT] com
Cheers.
