The Summer of Code is now underway, infact, last week was Week 1. I’ve been working on my project for the past ~2 months in some spare time, So up until now i’ve had very little peer review of the code, testing, and real log of what i’ve done (except for the SVN commit comments).
Instead of talking about what i’ve done in the past week (Which honestly, is absolutely nothing — Uni assessments come first!), I’m using this initial Blog entry as a overview of the past 2 months of development i’ve done.
What has been accomplished so far.
Lets see now..
- Plugin Update Checking: Although this is so far not very advanced, it still works amazingly well.
- Theme Searching: Yep, You can now search for themes directly from within the WordPress Administration panel.
- Theme Installation: It works.. However definitely needs some more work done on it.
The Plugin update checking currently relies on a 3 step method..
Step 1: Check plugin file for a “Update URI:” meta-item, If it is set, then thats the URL where the plugin information is pulled from.
Step 2: Do a search on wordpress.org/extend/plugins/ for a Plugin matching the same name as the Plugin being checked, If ones found, the plugin information is taken directly from the wordpress.org page for the plugin.
Step 3: Pull all the information from the URL specified and make decisions based on whats provided, If theres a newer version available, then display it to the user. At the same time, the plugin also checks the requirements of the plugin if they’re supported, Eg. “Plugin only tested up to WordPress 2.1”
Theme searching is pretty standard, the interface is very similar to themes.wordpress.net, infact at present borrows some code from that very page.
Theme Installation is pretty basic as well, This was only put together in a few hours week before last while hiding away from Uni Assessments. I’m writing up some wrapper classes around the Filesystem functions and FTP functions which i’m calling WP_Filesystem, What i aim to do with this is allow a single API for the plugin to use(And potentially others) which can modify/access files either directly via the filesystem, or by FTP(php_ftp ext; php sockets; php streams; etc). At Present i’ve got a basic model for Direct Filesystem modification working, which will most likely be fleshed out a bit once more work is put into it as well. theres some basic PHP_Ftp Extension class work in some messy code too from a previous project.
What are your plans for the upcoming week.
heh, This part reminds me of a Simpsons quote… “Krusty: *reading from auto-queue* Now its time for my favourite part of the show! *groan* Speaking to the audience!” ok, chances are, that quote is probably right off track.. but simpsons fans will probably know the scene i’m refering to :)
Items that i’d like to work on this week include improving the security of the plugin (i’m mainly thinking of nonces..) and working on WP_Filesystem a bit more, however due to the way i’ve tended to code, i’ll most likely also improve the Theme Installation and re-code some of my older code which no longer makes sense.
Problems/Chalenges so far
The first thing that comes to mind is the lack of a data-interface to the wordpress.org/extend/plugin and theme.wordpress.net setups, Now some people might suggest that this should’ve been the first thing that i looked at getting done, however i have so far been putting it off for one simple reason: I dont want to mark any access methods in stone before i’m fully sure of the data i’m going to want in the plugin. But i’ve been thinking about this as well for the past month, theres several possible methods, RSS feed, XML File, PHP Serialised Array, Plain text, etc, Personally i’m leaning towards a PHP Serialised Array, quite possibly simply because of the effort involved in parsing the XML File compared to it, And that i honestly dont know much about a RSS feed layout and how WordPress’s include RSS parser would handle multiple fields in it.. Thats something i’ll have to look into in time.
The next item that comes to mind is the lack of documentation available for certain things, Or quite possibly, The lack of knowldge on my part to know how to find what i want. namely the i8n functions, _e() and __(), How do you use them correctly? AFAIK best practive is to wrap all text blocks in a _e() call, But what else do i do with it exactly? What about when i want to put a few variables into the string, do i use sprintf(), do i concat things with __().. etc.
On that note.. the WordPress Object Cache was another hurdle that i hit, For some reason cache objects were exireing before my custom cache timeout value.Turns out, the custom expiration value is completely ignored at present. I created a patch for this using the modification time of the file created.. As of yet, there hasnt been much interest in it, It needs an updated patch to be uploaded to keep it in line with the current SVN though.
Back to the Plugin update notifications, One problem i’ve found there is that the plugin name thats shown within WordPress isnt necesarily the same name that the Plugin exists within the wordpress.org world, This is causing some anoyances with the current method of searching for plugins.. as it means not all plugins can be found, which subsequently means some plugins may have updates available which i cant find automatically. I think the best way will be for all Plugins to include a link to the update location, either be that a WordPress.org slug, or URI to its update location.
Well, this post has become more of a essay rather than a short update, but i guess thats what you get for having 2 months worth of status sitting in your mind. Hopefully future posts will be much shorter.
For all those who want to check out some screen shots of the current work, Have a look at my previous blog entry on the topic: http://dd32.id.au/2007/04/17/google-summer-of-code-wp-update/ If anyone would like to look at the source code at present, you can do a SVN Checkout on my current dev. build here: http://wordpress-soc-2007.googlecode.com/svn/trunk/dd32.crazyman/trunk/