Home > WordPress > Upgrading WordPress sucks.

Upgrading WordPress sucks.

October 30th, 2007 Leave a comment Go to comments

It is almost perfect - just tar xvfz latest.tar.gz and let it overwrite the files in the wordpress/ dir... but life isn't easy like that.

A bunch of files have been deprecated from various releases and just sit around getting stale. Currently the installation instructions are to just "remove all files" in various places. I would rather just get a list of files that are safe to remove, and be able to blindly copy the archive using tar (or remotely using FTP, etc.)

That shouldn't be too hard.

Right now I have my WP installs for work and home in Subversion, and I can't just move the files because the SVN metadata and directories get lost. I'd prefer to just get a list and I can manually just "svn del" the files myself. So please, for future WP releases, would someone publish the list of files so I don't have to do all this manual work each time? How about a quick and dirty cheat sheet like so:

List of files deprecated by this release:

  • foo.php
  • bar.php

Database upgrade required: Yes/No

Functions changed or deprecated:

  • wp_insert_post() now does this instead of that...
  • etc...

This might also make it easy for [us] plugin authors to look at the function deprecation list and easily know if something we're doing could be in trouble 🙂

Categories: WordPress
  1. Carlo
    October 31st, 2007 at 13:05 | #1
    Reply | Quote

    I use something like this
    http://perassi.org/2007/02/21/updating-wordpress-with-subversion-and-sitecopy/
    (I also create and use a patch file when I want to be fast)

  2. mike
    October 31st, 2007 at 13:12 | #2
    Reply | Quote

    Thanks. I saw something related to this, but it still probably winds up being the same amount of effort.

    Just being notified of which files are deprecated would be a start. Perhaps in the upgrade.php script for each upgrade - regardless of database updates. It could check for files that are in the base install against the base install directories (wp-content/*, wp-config.php, .htaccess, wp-includes/languages/* would be ignored for example)

    I still think the directory structure could be setup a little bit better. Having the language information mixed in to wp-includes, having wp-config.php in the same directory as core code, etc... that mixes things up. It would be nice to have a totally "3rd party" area and a core code area that is completely separate 🙂

  1. No trackbacks yet.
You must be logged in to post a comment.