As my webhost is down; I’m writing my status report here directly this week, And will post to my blog later.
API: Working locally, Still need to figure out how to use the Plugins tracker code to get a useable plugin zip location (From memory: I couldnt work out the input requirements for the function, The fact i have no useable data other than the core plugin and which meta keys the usual data is stored in isnt helping, But getting access to working test data isnt allways the fastest when people have a life to lead :))
Plugin Install in WordPress:
Interfacing with API: Pretty much working
Searching, Browsing, Etc works
Installing plugins Works too, Some code has been duplicated from the upgrader, And some code moves from the update main files to a generic common center location (misc.php / file.php)
Install Confirmation dialogue hasnt been started, I’m waiting on getting the API working before proceeding there.
So far i’ve been coding behind closed doors, Simply because I prefer to release code which works, So far this has just been delayed more as 90% of
the code relies upon the API to be operational. I personally do not mind re-coding large chunks of work, So with that in mind, I’d appreciate it
people were to read over the current code, While you’ll not have much luck in using it yet (I’ll get around to working in some test data if the API
doesnt come good this week), Some comments on the code flow would be appreciated.
First of all, I’ve got to start writing the Weekly reports at the start of the week and filling in the details as it happens.. Remembering whats happened the last week is a PITA.
Seeked feedback on the UI’s, Mixed response, But a good few responses
Installed bbPress and started writing up an API
Btw: Whats faster?
A Query to get the bbPress topics, and then a query to load the first post of each(to get the post_text)
A single query with a join to grab the post_text along with the topics?
EXPLAIN SELECT… doesnt show any significant difference. And looking at the ms times with my *really* small data set (11 posts) there does not appear to be much of a difference at all. *EDIT*: 2 Queries are taking ~ 0.0015s (Told you it was a small result set..), A join query is taking 0.0036s usually, However keeps spiking up to 0.0080s, My guess is that 2 queries are going to scale better.
Some backend work done on some installer code
Experimented with the layouts of the Plugin listing (search results mainly)
Once again, I’ve been selected to take part in the Google Summer of Code. This year my aim is to complete the work on the Trac Ticket #6015. In short: Allow plugin installations directly from the WordPress administration interface
As usual, I’ve allready started working on the coding previous to this week, and as such, do have some code to show for my efforts, However, My personal aim is to get an API off the ground for the WordPress Plugin Respositories before releasing any code which could utilise it.
Work so far:
API: So far i’ve drafted up a first scratch at designing a flexible API which returns the details needed for the search, as well as details for other projects which wish to access the data. It’d be run over a serialized post request the same as the current API’s, My iniial thoughts of objects can be found here: http://dd32.id.au/files/soc2008/pi_api_test2.html i’d appreciate input from others on that, What is missing, Whats needed, etc.
UI: I’ve not released any code for the UI yet, I’d prefer to get the API implemented and returning useable information ASAP before any UI feedback comes in, This is initially to allow the UI to have access to the data that it needs. (RSS can only provide limited details). A Quick mockup of the UI which relies on RSS details is shown below:
So, List of items achieved this week:
Basic UI design
Rather large chunk of work on the WP_Filesystem abstraction to fit in with recent changed to trunk
Looked at a change in UI for the plugins table to fit in better with being able to install a large number of plugins, A Delete/Uninstall option might be needed on the plugins page, As well as seperating it into 2 tables, “Currently Active plugins” and “Available Plugins”. 2 tables does not make much sense in the 2.5 world with people usually only having plugins installed which they need, But with the ability to search and install plugins, a larger number of people may end up with a list of 20 or so plugins which they have available, yet do not use, which could fill the active plugins table up..
If you have any input on anything mentioned here within, Or anything mentioned in this Google Groups post, please do leave a comment with your thoughts :)