Call me lazy (I dare you), but would it be possible for somebody to post all the changed code from 1.2.2 that has changed since 1.2.1 or at least more detailed instructions than "you can do a normal update"? I have hacked up my WP quite a bit.
Thanks in advance!
Stu Schaff
Devsyn Development Studio
1.2.1 -> 1.2.2 Diffs (25 posts)
-
stubie
Posted 7 years ago # -
Anonymous
Posted 7 years ago #This is a Big Deal. When the 1.2.1 security upgrade came out with similar instrux (roughly, "Upload the changed files. Don't overwrite anything you need.") I thought it was just because the devs were in a real hurry to get the fix out, and that the next upgrade would have proper instructions. I was too optimistic by half -- this sort of upgrade instruction is unacceptable.
At a bare minimum, you need to include, IN THE INSTRUCTIONS, a changelog that indicates what files were changed. I can scan that list to see if it has files I've modified, and from there I can figure out for myself what I have to do to merge my changes back in. As it is, I need to check this version in to source control and have it diff the files for me in order for me to find the problems.
I'll check it in anyway, cuz I have system and process for that. But most users don't, and you're doing them no favors by throwing out a new release and telling them simply to replace their existing app with it. That may be barely tolerable for a product in beta, when communicating with beta testers who are supposed to be working on the stock, uncustomized product. It is completely unacceptable for a minor upgrade of a general-release application, to users who have systems in production.
While I appreciate all the hard work that's going in to the product, this is a major flaw in your development process. I'm starting to think twice about betting a bunch of sites on this app. The refactoring you're doing may minimize the impact of this approach in the future, as most of my mods may be restricted to templates, but today it just blows.
</rant> -
Read the changes for yourselves, here: http://cvs.sourceforge.net/viewcvs.py/cafelog/wordpress/?only_with_tag=WordPress-Ver-1_2-Branch#dirlist Just look for the files that have been updated recently, and click on them to see the changes made.
-
Ryan Boren
Posted 7 years ago #Diff your tree against 1.2.1. Apply that as a patch against 1.2.2. Resolve conflicts. Done.
If you need such a detailed changelog, you should be doing your own diffs. -
Posted 7 years ago #i applied patches from this forum to fix trackbacks and make the default status of posts 'publish'. i don't know how to do diffs. i am not confident of my ability to re-find the hacks in the general mass of posts. i don't know whether upgrading will wipe these fixes or whether they've been applied to the new version.
what do you suggest i do? -
Posted 7 years ago #Ryan, read it again. I DO my own diffs. Most people can't or don't . If you think that the only people who modify the WordPress presentation layer, which is full of code that you might change to fix bugs, are also people who use CVS or Subversion and know how to diff and merge, you're sorely mistaken.
I don't need "such a detailed changelog"; as you point out, I can and do generate one myself. I need a basic idea of what changed. If you fixed security bugs in a handful of functions, in a couple of files, and dind't touch the presentation parts, I feel good about just updating those files, rather than blowing away my entire installation and painstakingly re-implementing all my customizations -- which is what your installation instrux tell users to do.
Since I know what I'm doing, I can ignore your crappy instrux and do the right thing. I'm asking you to give useful instructions for people who DON'T already know how to do the right thing, but who have found that they can hack the PHP, just as they used to do with HTML, and make some cool changes. Telling them to just blow away their site and install the new code is just wrong.
Macman's comment was actually helpful -- thank you, I can see some changes made in the last few hours, and some made months ago, so that gives me a good starting place to browse. Consider putting those instrux in the upgrade instrux. -
Posted 7 years ago #Ryan:
Thank you very much. I bet that this page will be fairly linked to shortly as people being to hear about the upgrade.
Another satisfied customer,
Stu Schaff
Devsyn Development Studio -
Posted 7 years ago #Glad to be helpful. :-) I still recommend that anyone making non-trivial changes to WP files learn how to use diff and patch (or their equivalents). Porting changes forward by hand is tedious and error prone, especially when you forget what you've changed.
-
Which is why I like the changes a comin' in 1.3 ;-)
-
Hey, guys, let's get serious for a moment. For the average WP user this whole thread is almost impossible to understand; except there is something missing in the upgrade instructions. And if the number of WP users is getting close to 30,000 (it was around 25,000 about two months ago!) everybody should keep in mind that the silent majority is NOT the geek type. Don't be misled by this very small but very loud group of users, who are very active on this forum - creating an impression that all the WP users are born coders, linux/unix users etc.
So, don't bother to post all kind of fancy geek-terminology and stuff that is totally useless for the majority. On the other hand keep always in mind that the increasing popularity (read: numbers) is due to those people who are almost afraid to post here anything because of this attitude.
Let me describe the average user of any kind of blogging tool. S/he got a computer with the obligatory windoz, then got caught by the world wide blogging mania, so learned somehow to download, to use a FTP client (not always, LOL), and is struggling with the basic HTML tags, not to mention CSS. Actually they are a bunch of very grateful people for this software, just don't alienate them saying they have to do all kind of wierd "diff" and "patch" things to be able to upgrade. And don't tell me either 'tis a free stuff, write yourself the docs'... I use many free software that has instructions written in normal human language.
The other option is: put on the main page "ONLY FOR GEEKS - non-coders, non-hackers are not welcome". -
Posted 7 years ago #The silent majority isn't hacking their core files. Most don't even change the default theme, they just upload when a new version comes out... if they get an announcement email.
-
Posted 7 years ago #Indeed, this whole thread is predicated on someone hacking files. The upgrade instructions are not targeted at those who change core WP files. I again suggest that someone help develop a document targeted at those who do. That document could describe managing and porting changesets with the appropriate tools. Those who don't change files can ignore that document as well as this entire thread.
-
Posted 7 years ago #The dev blog does point to this documentation page, which is pretty nice:
http://codex.wordpress.org/Upgrading
Of course if you don't like it you can always edit it. -
Posted 7 years ago #rboren, if you can't write a document explaining diffs and such to people like me who have made minor changes to php files, what makes you think anyone else will be capable of doing so? aren't most of the docs writers non-coders? and macmanx's suggestion is no good as i can't remember precisely which files i've modified.
at the moment i have two choices:
1. upgrade to 1.2.2, possibly breaking trackbacks and defaulting all my posts back to draft mode, and definitely losing a couple of cosmetic changes i made to the post page.
2. stick with 1.2 (having already held off installing 1.2.1 for precisely this reason) and upgrade when 1.3, since i don't mind the hassle of redoing stuff if there's new features on offer.
2. is looking like the best option at the moment, but i appreciate everyone's help on this. -
Posted 7 years ago #There are many people who have the knowledge. We just need to find some with the time and energy to write a document.
If you have specific changes you need help rolling forward, by all means solicit help on the forums. If you want to learn how to use diff, let's get the discussion going. The discussion may result in a document. I can offer help on using the GNU diff tools in a POSIX environment. Diff tools specific to non-Unix platforms are outside my experience and are of no interest to me. Others in the community will have to help document those tools. -
"and macmanx's suggestion is no good as i can't remember precisely which files i've modified."
Which is exactly why smart individuals keep a log of what they modified.
"upgrade to 1.2.2, possibly breaking trackbacks and defaulting all my posts back to draft mode"
I honestly can't think of any possible reasons why this would happen, not even with any of the known hacks. Trackbacks and post status are both controlled by WordPress. That's almost akin to saying, "I don't want to upgrade to Windows XP SP2, because I'll lose my Start menu." -
Posted 7 years ago #yes, of course i am aware now i should have kept a record of all my changes, but crowing after the fact is not all that helpful to me.
the draft issue is here (tracking that down has solved at least part of my problem). i write all my posts offline so when i enter a post, i want to publish it without messing with the post status settings every single time.I can offer help on using the GNU diff tools in a POSIX environment.
i'm afraid since that sentence meant absolutely nothing to me diffs are going to be way beyond my expertise. i am going to look for the trackback patch now :)
-
Matt Mullenweg
Posted 7 years ago #Clicking the "publish" button doesn't publish a post for you?
-
Posted 7 years ago #if that's all you need to do to change the post status, why would there be a radio button for 'publish'? i always assumed that for the post to publish the status would have to be 'publish' as well.
-
Mark (podz)
Posted 7 years ago #Re the original posts in this thread:
I've used WP for almost a year now, and have upgraded dozens of times when using nightly, alpha and beta builds. It used to take me ages to rebuild all the changes, esp before the advent of plugins, and I learnt two things the hard way:
1 - To keep a list, a written list, of all the files I had messed with.
2 - That the amount of 'customising' I did directly related to the amount of work I had done.
If you have invested time and energy in creating a site, then upgrading deserves as much diligence.
As for diffs.. what if through an oversight one diff was not included ? And that due to that something happened to your site ? You'd be coming back here not very happy I guess - but I really would not see that as the fault of either the devs or anyone else involved in preparing the code. If it's code that will operate on your site, then you have to accept that and any risks. That applies whether its WordPress or any other server side code.
If you can generate diffs - do so.
If you cannot generate diffs - follow a full upgrade procedure
If you insist on only ever using files that you see have been changed, then - and no doubt someone will call me on this - you are increasing your chance of hitting an error. An error which could have been avoided by you.
And if anyone thinks that the WP devs can release code which can be downloaded, unzipped, uploaded to a server and then be involved in upgrading an existing WP install in such a way that requires no user intervention but which preserves all prior user changes, then they are living in cloudcuckoo land - it ain't going to happen. 25,000 WP install as a minimum - do you honestly expect code to behave in a way other than generic ? -
Posted 7 years ago #Anonymous, all you need to do is click the Publish button. The interface is not the clearest and I can understand your confusion, but don't worry this is being improved in 1.3.
Also note that there's a list of changed files on the wiki:
http://codex.wordpress.org/Changelog/1.2#Version_1.2.2 -
Posted 7 years ago #And if anyone thinks that the WP devs can release code which can be downloaded, unzipped, uploaded to a server and then be involved in upgrading an existing WP install in such a way that requires no user intervention but which preserves all prior user changes, then they are living in cloudcuckoo land - it ain't going to happen.
i really didn't see any posts suggesting that, but then i'm not very good at reading between the lines. i do think it's probably more efficient for the devs to tell people what files have been changed than for every single hacker to generate their own diff between 1.2.1 and 1.2.2. i expect they are quite prepared to take the risk of generating errors, rather than wiping all their customisations every time there is a minor release.
anyway, my own issues are solved now -- i have a copy of the trackback patch in case it wasn't applied to the 1.2 branch, as well as the patch to fix the default status of posts. and i will be sure to record any other changes i make before 1.3. -
Posted 7 years ago #i do think it's probably more efficient for the devs to tell people what files have been changed than for every single hacker to generate their own diff between 1.2.1 and 1.2.2.
Which was my exact point from the beginning and why I wrote this post.
Thank you again,
Stu Schaff
Devsyn Development Studio -
I'll toss my 2 cents in - I only do minor modifications to WordPress, you know, to fix trackbacks and prevent spam, that sort of thing. I have no idea where you get this "diff" program, but the list of changed files above is immensely helpful.
-
On edit, self-deleted.
allusion, in the post above, already posted the address to the changelog. Sorry I missed it on the first quick read..
Topic Closed
This topic has been closed to new replies.
