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?

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 stuffjunsuijinany – ideas for handling that type of thing tho azaozz?azaozz – at the moment the simplest way is to start a forum thread about itjunsuijin – i mean short of scanning any and all plugin submissions for base64 and making it illegal in wp or somethingjunsuijin – 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 versionswesti – junsuijin: automatic scanning like that will likely just trigger false-positivesscribu – junsuijin: exactly, there are legitimate uses for evalazaozz – 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.

How To Participate:

If you want to suggest a topic to be discussed at the next meeting, you can by visiting the WordPress development updates blog. If you would like to participate in the chat next week, install IRC or an IRC compatible client and connect to the following IRC server.

chat.freenode.net or any random server on the Freenode network and then join this channel at 5PM Eastern time or 9PM UTC Thursdays. The meeting day was changed to accommodate European users.#wordpress-dev.

Who is Jeff Chandler

Jeff Chandler is a WordPress guy in the buckeye state. Contributing writer for WPTavern. Have been writing about WordPress since 2007. Host of the WordPress Weekly Podcast.

Share this:

Like this:

Related

4 Comments

I have write many plugins and i use the base64-function for inlude images, not as a file, only for include with php; better performance; little bid faster. I dont like your idea for scan the plugin-directory for the base64 function.

One idea I had for a site as a service to the WP community was a Google Custom search for plugins and better categorization than tags provide. At 6500 plugins, most of what I find is a waste. They need an advanced search by category, rating, etc. I’m sure they have bigger fish to fry, but anyone (hint, hint) could throw up a Google custom search with labels and filters to get current year, and keyword categories. I find that I need to do that myself to be sure I’ve found everything out there without looking through the many abandoned projects.

Auto upgrade replaces all the files, and likely will continue to do so. It’s good practice, as it is the best way of ensuring that you have a clean, complete WP install.

The “changed/added files only zip” can be downloaded manually from Trac by people who cannot use the auto-upgrade, and who don’t want to manually upload an entire WP install when only some of the files have changed. It’s not going to be a canonical upgrade method — it’s just a handy shortcut for a small group of people.