It’s been pretty quiet around here lately, mainly because I’ve been working on something but having trouble hammering the last few problems out of it.
As I work on the various plugins I make for WordPress, I find that there are several common bits of code appearing in all of them, and as I improved it in one place I would then have to go through and copy/paste (with modifications here and there) to the other plugins. This is a pain to keep track of, so I figured it would be a good idea to create a set of “core” files that I could simply drop in and have work. I found this had various implications, such as what happens when two plugins are using the same core set — duplicate function names and conflicts suddenly started popping up. How about when two plugins have differing versions of the core files?
So Strider Core was born. Among other things, I’ve created a system wherein different plugins can all run on Strider Core, and if they each have different versions of the core files, it will figure out which one has the highest version and use that for all of those plugins. Thus if Plugin A includes Strider Core 1.0, and Plugin B has Strider Core 1.1, the 1.1 core will be loaded for both plugins. Thus, activating one plugin can actually improve the functionality of other plugins.
Most of what I’m including in the first go are little bits of polish for the Admin — such as settings links from the Manage Plugins page, Menu icons, and the like. One significant addition, however, (and the thing I can’t quite get working right…) is a third party version checking system. Thus, anyone who makes plugins that are not hosted on WP-Extend will be able to have their plugin check for new versions simply by integrating Strider Core and adding a single line to the code.
That’s the plan anyway.
I’m going to try and get things going this weekend (with some luck), but even if I don’t get the version checking going, I will probably do a “beta” release so people can see what’s happening. I know some people have expressed interest in this system, so perhaps better to get it out sooner and get feedback before the “prime time” release.
If you’re interested, keep a lookout for an update to my Log Deprecated Calls plugin, as that is going to be the first plugin to use the new system.
3 Comments
Yes, a public beta is a good ideea.
Although, I already have a question: what happens if you update the core and it isn’t backwards compatible?
Basically, if I know an update is a “back breaker”, I can increment the name of the strider_core class. “strider_core_2″ and so forth….
If handled properly, this should not happen very often. Part of why this has been so long in development (besides lack of long swaths of time to get “into the zone” coding it) is I’m trying to design it in a way that future compatibility will be maintainable.
I’ll try to get this up this weekend.
This sounds like an excellent idea. I’ll definite look for the public beta.