Once I realized what was going on (actually mikelu pointed it out to me), it really wasn’t a lot of work to convert the hacks and plugins and it is to a benefit. I once had a Model A, thank goodness we no longer have to hand crank our cars. Now the word is out so by the time of 1.3 it won’t be a surprise as it was with me when I first “updated” to 1.3-alpha.
Thank you for comparing my suggestion on helping for a smoother upgrade to Model A’s and hand cranking.
True, I do have over 20 years of experience rolling out applications, which must make my suggestions seem old and outdated. Interesting, but the concept of deprecation is honored in most other open source applications — I guess they’re all Model As like myself.
Sorry you seem to be offended. The Model A had both a hand crank and an ignition. Anyhoo, my point is we should be preparing for the change now, not after it comes out. I’m of the mind I’d rather we do it now than in 1.4, why wait? It took me all of 30 seconds to do a global search and replace on the hacks and plugins that were affected. Besides, this is not a feature deprecation but a renaming. Again, sorry if I offended.
Codergurl, I misread, or Beel misread? Sorry, but when Model A is interjected without any other association, I have to assume its interjected in response to my suggestion.
But Beel did misread my underlying concerns when I talked about the problems this will cause. If the application comes out and these variables have been dropped, but people are using plugins that haven’t been updated, what will happen as soon as the people upgrade to 1.3?
There’s a massive assumption here that the plugin developers and others providing hacks are going to keep up with these releases. They most likely will — but they may not keep up to the speed that users download the 1.3 alpha, and then beta.
Look in the bug reports for 1.2. One of the significant ones has to do with supposedly deprecated functions that people are using.
The deprecation process traditionally, and I know that’s an ugly word, is to deprecate the object for one release, possibly two, while you also provide support for the new variable/function. Then you pull the old. The overlap provides for a smooth upgrade, regardless of who has updated their code. Then people can take their time about making the change.
What is the harm in doing it this way? A simple mapping to ensure smooth upgrades.
Yes, I saw that and updated my message just as you were coming in. As I said, that’s something.
But which branch is feeding the nightly builds? The 1.3 alpha? Which branch feeds the nightly build should be distinguished. All it takes in one rumor of an important fix in the ‘nightly’ build, and the build is 1.3a, to have a mess.
The nightlies there would be 1.3. I don’t know where the 1.2 updated nightly will be located but I am sure one of the devs will now let us know.
I’m sorry if I’m messing something, but what’s to stop someone to make a hack which simply does something like this:
$GLOBALS['tableposts'] = $wpdb->posts; [etc...]
That way anybody still running a WP less than version 1.3 can use 1.3 hacks. So I don’t see a big problem for the end user.
As far as source-management on the development end… oy vey!
That’s what I’ve been suggesting–that the WP development map between the two for 1.3, rather than just pull the old names without backwards compatibility, and without overlap.
Unless the structure of the objects change, this mapping shouldn’t be a problem for the development team.
And if the structure of the objects change, then this is more than just changing the variable names, and there needs to be some discussion on this now, too.
And Beel, the nightly is a 1.2.x.
Hmm, we must be getting our nightlies from two different places 🙂
wordpress-2004-05-28.zip has this:
<?php
// This just holds the version number, in a separate file so we can bump it without cluttering the CVS
$wp_version = ‘1.3-pre-alpha’;
?>
Would love to know where you found a 1.2.x nightly.
I see your point now, thanks for the insight.
You’re right, it was a mistake to do this without any thought towards these issues. However I seriously don’t see a problem. We have a complete list of changes. Someone make a plug-in (maybe even an include or good ‘ol inline code) that does translations. Eventually word will get around that the plug-in is needed for backwards support. Who knows, it might even make it to the developers end of the code… In the end everything will work out I think.
Maybe the developers are aiming for leaner code and cleaner namespaces. Maybe they saw this as a community problem to solve (plug-ins are a community feature). But I honestly believe that this won’t be anything to worry with. Worst case scenario is people will simply say “older plug-ins/hacks require So-and-So’s plug-in.” A little frustration for those not in the loop but things will work out.
As a side note, maybe WP 1.3+ could have a warning label for older plug-ins. “Danger: This plugi-in has not been tested with the current WP system. Use at your own risk.” 😉
The version in the nightlies is labeled 1.3 pre alpha. Not even alpha! That means things are going to break on a daily basis. Any change is going to meet resistance. In 1.0 almost every file was renamed or moved. People said this would break every existing hack and no one would write for WordPress anymore. The old $table* variables will probably be in 1.3 for compatability, but having them in there while we’re testing everything is changed over would be a pain. Thank goodness this is an open project and you can see the code being changed (not wait for a beta you might or might now be chosen for), read about it on the dev blog, read the documentation I wrote specfically for this issue, and have the ear of the developers.
Can I make a suggestion? Have the old variables setup/active off of some master flag, which can be set in the 1.3 >releases< to keep things stable, but can be disabled easily for testing that the new variable schema is working. That way there’s no ‘accidental death’ of older code, yet people can work on forward-compliance by disabling the flag and seeing what breaks then.
Just a thought. From someone with a number of ‘hacks’ still yet to become ‘plugins’, and a site still on the 1.0 base due to the amount of hackery needed to do certain things back then… 😉
-d
Good idea. “They” were just now stuck back in with this comment:
// We’re going to need to keep this around for a few months even though we’re not using it internally
$tableposts = $wpdb->posts;
etc.
Anonymous
There are a few other potential ways of minimizing the headaches:
1. Plugin authors can code in version controls:
if (wp_version = 1.3) {
print “go to this URL to see if you need an update.”
}
else
{
1.2 plugin code
}
2. It’s should be fairly easy to come up with a “1.3ifyer” where you post the plugin code into a text box, PHP does some nifty str_replace’s, and voila, users have brand new 1.3 compatible code.
–Stewart
