WordPress.org

Ready to get started?Download WordPress

Forums

[closed] How about patches? (22 posts)

  1. reven
    Member
    Posted 9 years ago #

    If only 4 files are changed between two releases, why force everyone to reinstall the whole thing? Why not a patch or just a zip of the affected files? This is a must! I know upgrades are reasonably fast, but it's just not logic to download the whole package every single time (about every two weeks...), and have to manually delete a folder, decompress, etc.

    Point two: I hope the next major release is tested a lot more! WordPress is loosing credit due to all these minor updates and bugs. I've recently read this in a blog's comment: "Even Microsoft doesn't release a new OS each time they find a bug that is fixable with a simple patch". I'd be worried if an open source project I worked on is compared to Windows.

    Point three: What's all that "(...)but an important security issue was brought to our attention which required an update for our users. The problem is not yet public but you should update your blog as soon as possible..." This is amazing! I thought open source meant open mind. You just can't give something to your users and tell them to install it without telling them why. I deserve to know what I am installing, what has changed and more important: why! I thought only commercial software companies did Security Through Obscurity. Come on, the WordPress team can do better. We've seen you do better!

    Besides all the above, I know that WordPress is a community effort and I appreciate the time each member dedicates to make WordPress the best CMS ever. This shouldn't be taken as a rant against WordPress developers, just as a little "hey, let's not forget that we know how to do things better", ok?

  2. Ryan Duff
    Member
    Posted 9 years ago #

    Point one: I've seen a few projects that release all the files for an update. If its only one file, I agree that should be made available, in the case of 1.5.1.3, it was 3 or 4 files that had changed all in different directories.

    Point two: Your point one and two are the same. Service Pack 1 for Windows 2003 was ~350MB, that practically IS an operating system.

    Point three: Disclosing the full extent of a vulnerability as soon as you release an update still allows people to exploit those who have not yet updated. People don't update within 5 minutes of the update being released. Some don't for weeks after. Believe it or not, there are still people running 1.2

  3. iand
    Member
    Posted 9 years ago #

    [self edited as same as above] - I just type slower :)

  4. libcat
    Member
    Posted 9 years ago #

    Ok, so they may be in different directories, but it's still a hell of a lot easier to replace four files than the backup and reinstall the whole damn system. It should be possible to create a zip with the relevant number of directories with the files in them, so that when one uploads the set of directories, the FTP sees that they exist and says, "hey, there's already a file here with this name, want to replace it or keep it? this directory already exists and. . . has a file with this name, want to replace it or keep it, or make a new directory?" and so on. Most FTP clients I've used are smart enough for that. . . . And failing that, most users who have enough technical knowledge to have installed the damn system in the first place are knowledgeable enough to upload four files.

    So again, why isn't it possible to just replace the four affected files?

  5. Ryan Duff
    Member
    Posted 9 years ago #

    Another reason might be so that when somebody downloads the latest version to install, they dont' need to download the main archive and 3 patch archives ie. 1.5 (full) -> 1.5.1 (patches) -> 1.5.1.2 (patches) -> 1.5.1.3 (patches)

  6. RazorSA
    Member
    Posted 9 years ago #

    How about next time, you release a full package, and an upgrade only package with details as to which files you need to replace...

    That would make me happy!!!

  7. Ryan Duff
    Member
    Posted 9 years ago #

    RazorSA:

    For that there is this http://codex.wordpress.org/Changelog

  8. reven
    Member
    Posted 9 years ago #

    I agree with libcat: the number of files or directories is not a point. Just compare to the upgrade instructions in the codex: you have to delete two folders, delete all files in the root directory except the config file, then download and extract new version to the suitable directories...

    And this is easier than replacing 4 files in different directories?

  9. reven
    Member
    Posted 9 years ago #

    Oh, come on ryanduff. How about a 'latest' package and then the update packs? Shouldn't be too hard.

  10. Michael Bishop

    Posted 9 years ago #

    I will say with hispeed connection, it's relatively a short process to upgrade the entire structure. However, I'm now working with 3 wp installs, and would like to think that I will find more uses for WP, and in that case, doing multiple full upgrades can be tedious. However, with the forum, and discussions like this, the resources ARE there to learn what files have been changed.

  11. Ryan Duff
    Member
    Posted 9 years ago #

    That is execssive and was meant for major version upgrades where files have changed, moved, been removed and not for minor upgrades where only a few files need to be replaced. It can still be packaged as a full release (only somebody on a 14.4Kb dialup account will notice slowness when downloading a 290kb file.)

    Maybe the docs team as well as matt/ryan need to look at updating release notes to say upload xxx file(s) to /blah/ and you will be patched.

  12. reven
    Member
    Posted 9 years ago #

    No, I meant that you could be given the option to download either the latest full version or the update packs from the version you have. That isn't too hard to do. The download page could be left as is and a 'patches' link could be added to the sidebar.

    The patches page can contain all the patches since the latest major release, for example: 1.5 -> 1.5.1.3, 1.5.1 -> 1.5.1.3, etc.

  13. amory
    Member
    Posted 9 years ago #

    If it seems so difficult, then why upgrade? No one is "forcing everyone to reinstall the whole thing." And while I agree that it would be nice to have a zip of the changed files available, downloading the whole thing and extracting the changed files is not even time consuming on dialup.

  14. mumkin
    Member
    Posted 9 years ago #

    I would very much like there to be explicit instructions re: upgrading from recent releases, so that I don't have to feel as though I must delete and re-up everything outside of wp-content. Other people feel similarly, and references to the changelog in the codex really aren't sufficient from a user-friendliness perspective. If the canonical download's readme says "to upgrade, delete everything except stuff that you've changed and then replace it with this new stuff"... well, that's not really speaking to the masses.

    Case in point: this most recent time I accidentally overwrote my custom smilies. There was no reason to overwrite wp-images for a 1.5.1.2 -> 1.5.1.3 upgrade, but I forgot about my smilies at the time and just blew them away. Had the changelog been included in the readme, and been phrased as instructions and not developer-centric information, it would have been a boon.

    Given the current size of the WP download -- a 360K zip -- downloading the whole thing just for upgrade purposes isn't a problem. What is a problem, however, is the confusion that comes from having all those unnecessary files. An official 1.5.1.2 -> 1.5.1.3 upgrade, like angusman's, which didn't contain unnecessary files, all would have been groovy.

    I'm not complaining so much for my own sake ... I'm more concerned for the sake of those whom I introduce to WordPress. People who don't read support regularly or even see new release announcements. It's one thing for me (/we/the media/etc) to give our WP-using friends a "heads-up!" when we see that security updates are available; it's a completely different kettle of fish if, duly alerted, said people are unable or are too intimidated to successfully update for themselves.

  15. jemmie19
    Member
    Posted 9 years ago #

    I would rather download a new version, delete the old files and upload the new version as soon as a security issue is found than wait the length of time Microsoft wait before releasing "patches".

  16. skippy
    Member
    Posted 9 years ago #

    The simple fact is that we're not going to make all people happy. We can try, and fail miserably; or we can set an acceptable baseline and stick to it.

    Everyone here -- everyone -- is a volunteer. We often have things we'd much rather do than build a zip file of just the changed files.

    Think of it this way: by having only one official ugprade process, we are making it easy for new users to know --and remember -- what to do. "Oh, this is just like installing it from scratch!" We need manage only one download location; we need point users to only one location; and we need maintain only one set of instructions -- that is a committment to user friendliness. Now, the contents of said instructions could use some attention. Feel free to contribute or discuss ways to improve it.

    If we start providing patch level downloads, we'll complicate the download page. For every person we make happy with patch downloads, we'll confuse a new user. We literally cannot win this argument. Accept that a decision has been made, and that it is unlikely to change.

    This is the fourth or fifth thread on this issue. If you feel strongly enough about patch downloads, please construct them, make MD5 sums of the individual files, as as well MD5 sums of the zip files, and send them to me. Post the MD5 sums of the individual files and the archive file somewhere so that I can compare your posted results with my calculated results. It would be extra helpful if you could send the files to me in a GPG-signed email, so that we have a full audit trail. Please indicate in your email whether I can expect additional patches from you every time a new release occurs, or if this is a one-time project for you.

    I'll see what I can do to get them posted for download. I make no promise that any such patches will be posted, since I don't control this website. I can only promise to try.

    Note that people who really want patches can and should investigate the Trac and Subversion instructions.

  17. angsuman
    Member
    Posted 9 years ago #

    <ego>
    For the love of God, would people stop calling me Angusman!
    It is Angsuman folks!
    </ego>

    And yes a patch from WP 1.5.1.2 to WP 1.5.1.3 is available.

    Yes, I too would like it to be made available by Matt's merry bunch (takes load off me) but that's open source. The credo of OSS AFAIU is either you make the changes yourself, like I did, or STFU because everyone is "volunteer", so no responsibility or obligations. In commercial software on the other hand you can literally force the company to provide you with patches.

    The way things are going I may not even upgrade WordPress anymore (unless they are security upgrades). I think WP is pretty much where it can go with its architecture. After this you will start seeing more look-and-feel stuff like Ajaxian goodness, draggable menus and other niceties instead of real improvement. Already 1.6 charter reads that way.

  18. angsuman
    Member
    Posted 9 years ago #

    @jemmie

    If everyone goes your way then all of us have to think about reinstalling Windows after deleting all the directories where Windows put its stuff (replace it with a four letter word of your choice) and install a new copy everytime they fix a security defect, in the process deleting all your settings and customizations.

    Fortunately they issue "patches".

  19. skippy
    Member
    Posted 9 years ago #

    Angsuman: please feel free to participate in the discussion as to what "real improvements" you think are necessary.

    I think removing 400 lines of duplicated code in post.php is a real improvement.
    I think more plugin hooks are a real improvement.
    I think a robust user capabilities system is a real improvement over arbitrary user levels.

  20. angsuman
    Member
    Posted 9 years ago #

    @Skippy
    > please feel free to participate in the discussion as to what "real improvements" you think are necessary.

    I am not sure if this is the right place but here it goes.

    > I think removing 400 lines of duplicated code in post.php is a real improvement.

    That is really refactoring. It doesn't help the client directly in the short term. It makes future modifications easier. As with others it also should be prioritized. Do you have unit/acceptance tests which will ensure that something will not break while doing this refactoring?

    > I think more plugin hooks are a real improvement.

    Is there a real strong requirement for them? Or just someone feels they are nice? You can always add tons of hook everywhere. However they also, however imperceptibly slow down rendering of the page. I think hooks should only be added to address a strong requirement. They don't take much time to add but we shouldn't indiscriminately go down that path.

    BTW: Don't talk caching for speed here as caching comes with its own set of problems. It renders many real-time plugins useless.

    > I think a robust user capabilities system is a real improvement over arbitrary user levels.

    Define robust user capabilities. What is the plan/architecture for this new system? Fundamentally what are we getting with this?

    One thing I noticed is that in several places wp template tags or functions dictate visual layout. They should be separated in all places. It makes for better template creation and maintenance.

    Many important functions are not documented in codex, which I often find in the code.

    Several people are using WordPress around the world. Whenever there is an upgrade it affects them. Many have personalized WordPress. Any new release should keep these users in mind. Between 1.2 and 1.5 the whole templating system changed. It was a big change for many and hence many haven't upgraded even today as you can see in the forums. And they are hence open to security vulnerabilities. A patch for their releases would have gone a long way in helping these users.

    I have seen plugins break with even minor releases like 1.5 to 1.5.1. Sufficient care needs to be taken in this respect for backward compatibility.

    WordPress is moving into big league. Think Big. Look at Microsoft. They test new releases with popular software of their platform before releasing them. WP developers should similarly test popular plugins (need not be perfect list and yes mistakes can happen) with every new release. Much of it is grunt work but that's software development. It is not always about doing the coolest thing.

    Themes break everywhere with new releases. Why? We need to find out.

    Part of the problem is that there is no official guidelines which says what to do and what not to do in theme development. You should think about compliance checking.

    WordPress developer community should focus on perfecting existing functionality more than adding new goodies. People are still facing issues with pingbacks and trackbacks. I know them, fixed them in my blog, couldn't find time yet to release them as plugins. Another reason is that they shouldn't be plugins in the first place but part of core code.

    WordPress needs to publish its architecture. Serious re-factoring needs to be done in places.

    WP community should issue patches, especially for security upgrades. Despite the strength of plugin architecture, expect people to modify code. The community should reasonable accomodate them and not just provide blanket statements like it will be tougher for those who modify etc.

    I think the above should have higher priority over ajaxian niceties and draggable menus.

  21. skippy
    Member
    Posted 9 years ago #

    > I think removing 400 lines of duplicated code in post.php is a real improvement.

    That is really refactoring. It doesn't help the client directly. It makes future modifications easier. As with others it also should be prioritized. Do you have unit/acceptance tests which will ensure that something will not break while doing this refactoring?

    Removing duplicated code does help the client directly, in several ways. It slims down the single download archive a bit. It makes posting and editing use the same code, and therefore provides a unified workflow, as opposed to the previous bifurcated one for posting versus editing.

    I have no unit or acceptance tests. If you have some, please submit them.

    > I think more plugin hooks are a real improvement.

    Is there a real strong requirement for them? Or just someone feels they are nice? You can always add tons of hook everywhere. However they also, however imperceptibly slow down rendering of the page. I think hooks should only be added to address a strong requirement. They don't take much time to add but we shouldn't indiscriminately go down that path.

    Yes, there is an identified need for new plugin hooks. People are looking to do more and more with WordPress, including some (weird) integration with other systems. Plugin hooks facilitate these integrations without requiring users to modify core code.

    Further, the core WordPress developers have repeatedly stated that the WordPress core should be kept as slim as possible, focusing on core functionality. Non-core features should be implemented in plugins. So far, this has worked well.

    Plugin hooks are being added for plugin (de-)activation, user creation and deletion, and more.

    BTW: Don't talk caching for speed here as caching comes with its own set of problems. It renders many real-time plugins useless.

    I said nothing about caching.

    > I think a robust user capabilities system is a real improvement over arbitrary user levels.

    Define robust user capabilities. What is the plan/architecture for this new system? Fundamentally what are we getting with this?

    I invite you to subscribe to the hackers mailing list, where you can monitor -- and participate in -- the discussions surrounding the user capabilites system.

    One thing I noticed is that in several places wp template tags or functions dictate visual layout. They should be separated in all places. It makes for better template creation and maintenance.

    Many important functions are not documented codex, which I often find in the code.

    Please submit patches for these items. If you have improvements, please share them, instead of complaining that the two core WordPress developers didn't code things the way you would have.

    Several people are using WordPress around the world. Whenever there is an upgrade it affects them. Many have personalized WordPress. Any new release should keep these users in mind. Between 1.2 and 1.5 the whole templating system changed. It was a big change for many and hence many haven't upgraded even today as you can see in the forums.

    Anyone who edits (or "personalizes") core WordPress files is taking it upon themselves to maintain their revisions across upgrades. This is true in any Open Source system in which a user makes changes. The core system cannot be made to accomodate all users' modifications. This is entirely up to the user.

    I have seen plugins break with even minor releases like 1.5 to 1.5.1. Sufficient care needs to be taken.

    Please address your concerns to the plugin authors. The core WordPress developers cannot be held responsible for plugin breakage.

    WordPress is moving into big league. Think Big. Look at Microsoft. They test new releases with popular software of their platform before releasing them. WP developers should similarly test popular plugins (need not be perfect list and yes mistakes can happen) with every new release.

    Plugin developers need to test their own plugins. It is unreasonable to expect the core WordPress developers to test even a smattering of the available plugins, many of which the core developers do not use.

    Themes break everywhere with new releases. Why? We need to find out.

    Part of the problem is that there is no official guidelines which says what to do and what not to do in theme development. You should think about compliance checking.

    Please help us write the documentation necessary. Please spend time with us in #wordpress-docs, agonizing over how best to articulate complex concepts to new users without insulting advanced users.

    WordPress developer community should focus on perfecting existing functionality more than adding new goodies. People are still facing issues with pingbacks and trackbacks. I know them, fixed them in by blog, couldn't find time yet to release them as plugins. Another reason is that they shouldn't be plugins but part of core code.

    Instead of writing plugins to solve these problems, please submit patches to the core application.

    WordPress needs to publish its architecture. Serious re-factoring needs to be done.

    Please submit patches to help expidite your refactoring suggestions.

    WP community should issue patches, specially for security upgrades.

    Thank you for your volunteer effort in this regard so far. I encourage you to continue to satisfy this need for others.

    Despite the strength of plugin architecture, expect people to modify code. The community should reasonable accomodate them and not just provide blaket statements like it will be tougher etc.

    How do you propose we support poeple who make changes to the core files? If you're customizing core files, then you should keep track of what you've changed, and why. Before upgrading, you can compare the last-modified versions of your files to the available source code. Or, if you're handy with diff, use that.

    WordPress, as a project, does a lot to make the code available to the people who want it. We, the support volunteers, have done our best to support as many people as we can. If you make modifications to core files, or if you use an unstable un-released development version of WordPress, you should expect challenges. That's just the way it's going to be.

    I think the above should have higher priority over ajaxian niceties and draggable menus.

    I happen to agree with you, but not everyone does.

    This is Free Software. The two core developers do this because they want to. It is entirely their perogatvie to focus on the development aspects that give them the most pleasure.

    I made a modest effort to propose something other than the draggable interface. I invite you to do the same.

  22. Matt Mullenweg
    Troublemaker
    Posted 9 years ago #

    Thanks for your comments. For the vast majority of releases many files change, things are moved around, things are removed, and generally it would be a waste of our time and yours to provide an archive of just the changed files. People using such an archive would be more prone to make mistakes when upgrading. It is highly unusual that a release only has 4 changed files, and that's because of the extraordinary circumstances surrounding it. In the future if we have another highly unusual release when almost nothing changes, we may provide an archive file like you suggest, but in general we like to keep things consistent from release to release.

Topic Closed

This topic has been closed to new replies.

About this Topic