[wp-hackers] Upgrade sanity checks
peter.westwood at ftwr.co.uk
Wed Feb 27 21:18:22 GMT 2008
On 27 Feb 2008, at 21:06, Matt Mullenweg wrote:
> Otto wrote:
>> One way would be to have it load some other file which is a list of
>> all the WordPress files, then check (and potentially hash) them
>> all to
>> ensure that they are unchanged. Every time a new release occurred,
>> that file would need to be generated as part of the release process.
>> Of course, you would want a failure to not *stop* the upgrade, but to
>> get confirmation. The best user experience would be to put up a
>> warning message saying "These WordPress files don't appear to be the
>> correct versions: (list of files here). Proceed with upgrade anyway?
>> WARNING: Proceeding may cause unexpected results! Do not proceed
>> without knowing what you're doing. (Proceed / For the love of god
> I think that's a great idea.
I discussed the idea of exposing the hashs with matt last year.
When I looked into implementing something to be deployed on wp.org I
found to my delight that svn gives us everything we need already!
peter at epia (wireless:S.4) trunk 0 0.21 s $ svn info wp-blog-header.php
peter at epia (wireless:S.4) trunk 0 0.16 s $ curl http://
svn.automattic.com/wordpress/trunk/wp-blog-header.php --request PROPFIND
<?xml version="1.0" encoding="utf-8"?>
peter at epia (wireless:S.4) trunk 0 0.19 s $ md5sum wp-blog-header.php
So if we want to expose the info it is very easy to get at.
Anyone fancy writing something which uses the last one to validate an
install based on the svn tag?
http://blog.ftwr.co.uk | http://westi.wordpress.com
C53C F8FC 8796 8508 88D6 C950 54F4 5DCD A834 01C5
More information about the wp-hackers