After upgrading automatically, my site became a completely blank screen. The favicon was still visible. I had to rename the plugin folder to restore the site.
Please see the first question here: http://wordpress.org/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
Most of users can’t upgrade PHP selfishly because of using rental server.
I’m one of them and got blank that take time to pin down what cause it and restore blog.
If you’re author of this plugin don’t provide incompatible version as upgrade one.
You must provide it as new one and note “incompatible with under PHP 5.3”
Well, I do have several notes in the readme and a couple attempts at warning the user in the plugin. But, unfortunately, there isn’t any good way to warn the user when they try to activate the plugin. Because of the way the namespace functionality in PHP 5.3 works, you can’t really detect if the current PHP setup supports namespaces before you try to use them. Not without some hacky code anyway. So, there really isn’t any way around the error besides just trying to warn people ahead of time.
If you have any ideas on how I could make the warning more effective, I’m definitely open to suggestions.
WordPress recommend to upgrade itself,plugin,theme..etc at short interval that let people do upgrade without read any cautions.
My idea is simple.
Stop upgrade this,and release “Admin Color Scheme 2 (compatible upper PHP5.3 only!)”.
The name warn people,moreover when upgrading plugin people don’t read caution,but install new one most of them heed it.
I’ve just uploaded the 4.1 release. I went back to function name prefixes for now so the plugin should now work with older versions of PHP. But, hopefully, we can go back to namespaces once PHP 5.3+ has more penetration.
So, please update. Also, please update your vote of Works/Broken on the plugin page accordingly.
Sorry again for the trouble this has caused…
- The topic ‘[Plugin: Easy Admin Color Schemes] 4.0 Upgrade left my site Blank’ is closed to new replies.