The Xavisys WordPress Plugin Framework
A few months ago I was chatting with Joost de Valk and he was talking about a new plugin toolkit that he was making. The basic idea was to make a flexible base that he could use to build on for all his plugins. It would handle all the tasks that are common to all his plugins (options page, dashboard widget, etc) and still be easily extended so each plugin could handle more specific tasks as well. Now his plugins (at least some of them) use his toolkit.
It was a great idea, and I finally got around to writing one for my own plugins. I built it as an abstract class (and a tiny CSS file) that I extend for each plugin. Here you’ll get to see a quick tour of what the framework does. Let me know in the comments if you’re interested in seeing a walkthrough of how it was built, and feel free to download Efficient Related Posts to see it in action.
WordPress Core vs Canonical Plugins
There has been intense discussion about what should and shouldn’t go into the core of WordPress and what should be in plugins since way before Matt talked about canonical WordPress plugins in his State of the Word, but that mention has definitely caused some serious buzz. The question is whether WordPress should stay small and fast or grow and be feature rich. Both have their advantages and disadvantages.
The advantages to the “WordPress should stay small” philosophy are not limited to the WordPress download staying small (although that is one advantage). A smaller code base will make it easier to keep WordPress fast, reliable, and easy to test as well. The people that support this side of the argument would argue that WordPress could be extended to still accomplish any of the “missing” features through plugins and custom themes, and having built-in functionality that you don’t use is a waste.
The disadvantages are that many users (remember there are millions of WordPress blogs out there, many ran by people that are not tech savvy) are not comfortable with or even capable of installing plugins to solve their problems. For those people, having the functionality in the core WordPress install is probably the only way they’ll get to use it. Not to mention if 99% of people that install WordPress install a specific plugin, isn’t it obvious that the functionality provided by that plugin should be included in WordPress itself? Unfortunately, what if it’s 95%? 90%? 75? It’s hard to figure out where to draw the line. Additionally, if something is popular but doesn’t make it into core, should the programmers test against it before releasing new versions of WordPress or does that responsibility fall to the plugin author?
Obviously the advantages and disadvantages for the “WordPress should be feature rich” philosophy are the exact opposite. The problem is, both sides have valid arguments, so the real question becomes “is there something better?” I think canonical plugins may very well be the answer to that. The idea of canonical plugins is that WordPress would back a specific plugin as being the “solution” to a specific problem. For example, maybe you want to display related posts and WordPress has decided that “Efficient Related Posts” is the solution for that. They may have a list of commonly asked for features and their solutions on a page somewhere, or they may take it one step further and package the plugins with the official WordPress download.
I think that if they package some plugins with the official WordPress download, they may be very close to a great solution to this tiring debate. The advantages are that the core would stay lean, fast, and reliable. The functionality would be available to all users because it’s just a matter of activating the plugins rather than finding, downloading, and installing them. Also, the plugins that are shipped with WordPress would need to be tested with each new version, which means they’ll be stable as well. The only real disadvantage is that the download size would grow, but we live in the era of broadband. It seems a small price to pay to solve so many other problems.
WordPress Developer Meeting – July 01, 2009
The developers had another IRC meeting today, and we discussed the media overhaul for 2.9 & 3.0. The idea is to do a two step process, laying down a lot of groundwork in 2.9 and finishing up in 3.0. Jane will be adding a post and later a poll to get community feedback on some of the items discussed, but here’s a list (in no particular order) of some of the things that will be considered for 2.9 & 3.0:
- post thumbnails
- media albums
- bulk media import API
- make adding embeds easier (like viper plugin)
- enable most media settings as defaults that can be overridden on a per image/file or per-use basis
- cropping, resizing, and rotation (in 90 degree increments) for image uploads…I’m excited about this one
- Custom Image Sizes. Instead of hardcoded thumb, med, large (manually configuring maximum image sizes for small, thumbnail etc)
- page exclude plus reorder for blog navigation
- media metadata
- uploader feature: ability to choose from most recently used/most often used/marked as favorite files
- more default shortcodes. check top ten from wp.com. slideshare and any place that advertises wp.com shortcodes
- importers (specifics TBD)
- UI header brushup and uploader UI
Plenty of other things were discussed, such as “lightbox by default” for images, but the consensus was that there are good plugins for this. We also discussed post types (examples of post types: book review, recipe, essay, aside), which would let you choose a type for your post and treat it differently based on what you choose (currently posts, pages, and attachments are different “post types”). The idea is to allow users (or plugins) to easily set up different post types. This will be put off until 3.0, but it’s still exciting!
WordPress and the Google Summer of Code
For those that don’t know, Google has been doing something called the Summer of Code since 2005. Google picks open source projects to fund development for. Then they accept applications from college students and then choose about 1000 winners in conjunction with the project mentors. Project mentors are experienced developers that are familiar with the project in question. Each student is paired with a mentor, who will help by giving direction and advise throughout the process. Google pays the students $4,500 each to complete their project over the summer, as part of their contribution to the open source community. The main requirements are that you have to be 18 years old or older and enrolled as a full or part time student as of April 20, 2009.
The process goes something like this. On May 23rd the students begin coding, and receive their first payment of $500. On July 13th they have “Mid Term Evaluations” where the mentor evaluates the student, and the student evaluates both the mentor and the project. At this point, if the student isn’t performing, they will be dismissed, but the vast majority of students will continue and receive their second payment of $2000. On August 17th the students stop coding. On August 26th there is a final evaluation which works just like the mid term evaluations worked. The student now receives their final $2000. On September 3rd, the code must be submitted to Google.
The WordPress has-patch marathon
Xavisys is participating in the WordPress 24 hour has-patch marathon. We’ll update this post as we go, but wanted to encourage others out there to participate as well. Grab a ticket and get started!
- #8014 has been fixed as part of the marathon.
- Now you can use dbDelta() with SQL containing backticks!
- #9507 has been fixed
- You can now localize the “tag” word in the new plugin page
- #9408 has been committed
- WAI-ARIA landmark roles have been added to the default theme to increase accessibility
- #5710 – wp_tag_cloud should echo get_tag_cloud
- For this one, my patch was replaced with a better solution offered by DD32 which added an echo option to the args array for wp_tag_cloud
- #9472 – Fixed
- Now wp_list_pages() applies the “current_page_item/parent/ancestor” classes when browsing image/attachment pages!
- Some new filters were added
- I always like to see new filters. It means that plugins can be more powerful. They added wp_trim_excerpt and admin_footer_text so far.
- #9442 – Login UI
- They added a password recovery link to the login error messages
