WordPress Dev Chat For 9-10-09

This weeks meeting consisted of an agenda that was light to non existent. However, we still managed to find some things to talk about such as the addition of changed files that are linked to in a release post, quite a few issues dealing with the plugin repository and more.

So far, two people have volunteered to help make the administration area of WordPress more accessible. Jane is giving it till Monday and then she’ll try to get a group together to figure out the best approach.

the question of downloading single file vs full upgrade process

Thanks to Mark Jaquith who dived around in Trac, it looks like it is possible to show a link in the backend of WordPress during an upgrade which will contain a zipfile of just the changed files for that version. This link and zip file will also be shown in future release posts.

One interesting question I had regarding this new upgrading option is whether uploading just the changed files counted as a full upgrade? Ever since I have used WordPress, upgrades have always been a matter of overwriting the previous package. Mark Jaquith told me it should be the same, if the zip file of changed/added files is accurate. This is good news because I wanted there to be an option in-between the auto upgrade not working and uploading the entire package of WordPress. Auto upgrade should be the primary upgrade method with uploading only the changed files coming in second. Last would be replacing all of the files.

If we find any issues related to the new site wide profiles site, who do we report them to? Andy Peatling or what?

Jane told me we should report issues within this forum thread.

Has anyone heard anything at all about 2.8.4 being affected by the latest attacks? I have not.

MarkJaquith – jeffr0: what’s likely happening, if you hear about that, is that they didn’t clean up, and someone has continuing access, even though their install is clean.

Most of the discussion from this point on deals with plugins, the repository, removing bad plugins, reporting compatibility, etc. I’ll just provide a few tidbits of the conversation as nothing much was decided, just a bunch of ideas discussed.

azaozz – there’s another thing about plugins too. Some submit nicer code to get in the repository and then start to add base64_decode stuff
junsuijinany – ideas for handling that type of thing tho azaozz?
azaozz – at the moment the simplest way is to start a forum thread about it
junsuijin – i mean short of scanning any and all plugin submissions for base64 and making it illegal in wp or something
junsuijin – azaozz: would it be worthwhile to have some kind of cron script running over the entire plugins/themes repos, scanning (preg_match) for predefined ‘illegal’ functions like base64, eval, etc. and temporarily disabling any plugins/themes that have uploaded files containing such functions? could also push status messages to end-users that may have gotten the filthy versions
westi – junsuijin: automatic scanning like that will likely just trigger false-positives
scribu – junsuijin: exactly, there are legitimate uses for eval
azaozz – it can only flag some plugins, they will have to be checked by hand..
junsuijin – true westi, it could, but i don’t know any other easy way to make sure that kind of stuff doesn’t happen, and it would be quite possible to make exceptions for any authors that need eval or whatnot

If you’re interested in reading the rest of the conversation, visit the log file and start at Sep 10 21:39:01 2009. If you’re interested in the conversation related to reporting plugin compatibility, start here and work your way up.