The other day, Kym Huynh sent another gem of a WordPress rap into my inbox. This rap is hilarious and just as good if not better than the first one. This rap is based on an episode of WordCast where the group covered people who they believed were famous in the WordPress community. Now, they have a rap dedicated to them! Take a listen and let me know what you think. Just right click on the MP3 file and save it to your desktop.
P.S. I am not secretly in love with Kym.
Just wanted to pass a note along that my review of the new WordPress HelpCenter has been published on WPCandy.com. In this review, I share my opinions as well as my experience I had when I decided to give them a call and ask an easy question to see if I could get an answer within three minutes.
Also, we have an ongoing thread on the forum discussing this new service which you can contribute to if you desire.
Today I wanted to talk about a problem which Justin Tadlock will be covering in more detail at some point in the future and that is, plugins which contain a CSS file to edit their style. Don’t get me wrong, Lester Chen is a great plugin author, but I find it increasingly annoying that after I make the necessary styling changes to his WP-PageNavi plugin so that it blends in with my theme, I overwrite those changes once I upgrade his plugin.
Based on what I’ve been told, it’s fairly easy to add a plugins stylesheet to your themes CSS file so that this sort of thing doesn’t happen. But, I wanted to raise the question if whether or not plugins should come with their own CSS file for editing or just store the styling information in the database so that end users don’t have to worry about messing around with the CSS in the first place? I’m pretty sure this is how Lester’s WP-Polls plugin works as I can define from within the plugin options page which colors the voting bars should be via hexadecimal color codes.
What are the drawbacks to storing plugin style information in the database versus a CSS file? On the surface, seems like adding the style information right into the plugins options table in the database is A OK to do.
Jane Wells has announced on the WordPress.org development blog that the 24 hour has-patch marathon is now underway. The reason it’s called has-patch is because in trac, when someone submits a patch, the tags ‘has-patch‘ is added to the keyword field making it easier to sort through those tickets which actually have a patch.
During the next 24 hours, the core developers will be evaluating patches that have been tested and committing those that are up to par.
Grab yourself a copy of the nightly build to make sure you’re using the right version, then head over to Trac and start looking at the has-patch* tickets. Pick a ticket, download the diff, test it out on the browsers/platforms you have available, and write a comment about the results in the ticket’s comment thread. Move on to the next ticket. Do as many as you can over the next 24 hours.
Next Monday, Jane will publish the results of the marathon and in her message to the testers mailing list, she upped the incentive on contributing to this event:
When I put up the results of the marathon on the dev blog on Monday, I’ll also link to the top 5 testers from the 24-hour marathon period (measured by number of patches tested/commented in trac treads).
Hopefully, all goes well and if I can find the time, I’ll see if I can do a bit of testing on a patch or two. Last but not least, WordPress 2.8 is now feature frozen.
Sarah over at BloggingTips.com has published a short and sweet article explaining how to setup WordPress out of the box to work like a CMS. She also gives a listing of recommended plugins to accomplish the task.
Upon upgrading my development site for testing to the latest nightly build of WordPress, I discovered that the first bits and pieces of the Widget management system were added. Just as I had hoped for, the system works like a cross between 2.3 and 2.5 leaning more towards 2.3. On the left, you have a listing of available widgets. On the right, you have sidebars available where you drag widgets from the left, to the right, just like it worked in WordPress 2.3. However, there are a few differences.
Instead of a drop down list of sidebars available, all of them in your theme show up on the right hand side. Also, the sidebar titles are shown on the right so if a theme author has given the widgetized areas of their theme common sense placement names, it should be rather simple to place widgets in the desired location the first time around. Also, multi-widgets works as expected.
At the bottom of the page is a container for inactive Widgets. At this stage of the game, I am a bit confused with why there is an inactive widgets container and a container filled with widgets you can use. They are all widgets and if they are there, then they are all usable. But this system is still very early in development. It’s obvious that a few styling issues need to be addressed but more importantly, some UI enhancements need to take place which I’m sure will happen in the coming days.
But I can honestly say, I like what I’m seeing and I’d rather just drag stuff around rather than clicking around and selecting drop downs from multiple sidebars.
For those who didn’t get a chance to listen to episode 50 of the WordCast Podcast, you missed Kym Huynh’s awesome WordPress Rap. So, he’s been a trooper and sent me the mp3 file which you can download and take a listen to. It definitely fits the bill for being a ‘rap‘. Right click and save the file to your desktop.
How long has it been since we started talking about the media management system in WordPress receiving a major overhaul? Based on what I’ve read, the plan is to revamp the media system in WordPress 2.9 instead of WordPress 2.8. Shane who operates Bugssite.org has released his proposed wireframes for media management in WordPress aimed at version 2.9.
You can download the PDF file containing the wireframes here.
Here is the proposed workflow for how the new media system would work.
Reading over the PDF document, here is what I’ve been able to figure out.
Groups Inside Of Media Items – The new system would allow you to create groups inside of media items. For example, lets say you went on a trip to both Florida and Georgia and you wanted to showcase your photos. Currently using the Gallery shortcode, you would end up showing all of the images. The new way would enable the ability to do something like this [gallery_florida] [gallery_georgia] or something similar to that affect.
Better Media Organization – The new media system will incorporate a way for you to categorize and tag media elements as they are uploaded. This will be done without having to go through a seperate screen during uploading making it a speedier process.
Much Better TinyMCE Integration – TinyMCE will have much better control with the images. You won’t be able to drag images from one section into TinyMCE but this gives the developers a chance to control how TinyMCE will deal with those issues. The new system will try to take TinyMCE image previews up a notch by going for the full gallery.group preview to show you exactly what it will look like based on the settings you have chosen instead of having to do a full post preview.
The development around the new media management system will be conducted in three stages on a seperate branch of WordPress so as not to mess up trunk for 2.9.
The first stage will revolve around cleaning out all of the media related functions to start from scratch. Development of the upload process will take place first along with the library, categories and tagging system. Shane makes a great point within the wireframe document that they will need to make sure the 2.8.x inline format is developed so that the millions of blogs running on WordPress do not lose file associates or deletes.
The second stage will consists of development around the media system post box inside the post/page screen. This will also contain the upgrade to TinyMCE.
The third and final stage will be all about usability. Remember all of the testing that was involved with the redesign of the backend of WordPress 2.7? That is the kind of testing that the media system will undergo once they reach stage three. This testing will determine things such as where tags, categories, and comments are listed, how to preview images, how to deal with a large number of images that are unassociated, etc.
I remember when Shane put together some code that would enable multiple gallery support in WordPress. Since then, he has grabbed the bull by the horns and as you can see via his wireframe proposal for the media management system, he may be the one largely responsible for how we manage our media in WordPress 2.9. I want to thank Shane for stepping up and getting knee deep with revamping the media management system which definitely needs to be done, one way or another. File/image associations alone would be cool.
The proposal states that the goal is to have an Alpha at the end of July or earlier with a beta aimed at the end of September and finally, a release in October 2009. I highly encourage you to read through his proposal and then, provide him with your feedback either through the WP-Hackers mailing list, the WordPress Developers IRC Channel or via the comment form on his blog.
Ever wish you could search for WordPress functions, template tags, function sources, user notes, etc all from one place? That is exactly what WPSeek.com allows you to do as it acts as a very slick WordPress centric search engine.
WPSeek was originally used to be a gateway page for the WordPress Helper FireFox extension but the site has expanded into something much more. For example, take a look at what this search engine offers:
One of the cool things you should notice right away is the Auto suggest feature. Helpful for those who only remember the first or second bit of a function. For this review, I used wp_list_pages.
The search results produce a link to the official page on the Codex related to the function, Code Snippets, top Google search results, and WordPress.org forum posts discussing the function and user notes. The Codex Documentation when searched provides a way to see related documentation for that function. The list of recent forum topics also provides a link to create a forum thread within the correct location on the forum to talk about the function. Last but not least, User Notes function like a commenting system on a blog. So far, I haven’t seen any spam so it looks like moderation has been keeping up.
All in all, WPSeek reeks of pure awesome. It provides most of what you need in a very tidy, neatly designed page without having to see all of that OTHER stuff that is typically on a CODEX page. Taking a peek at the coming soon link located at the top of the page, localization, RSS feeds for results page and the addition of conditional tags in search and auto-suggest are on the horizon for the search engine.
If you would like to access WPSeek.com without actually browsing the website, add the search engine to your browser. If you’re using FireFox, look for the search bar located somewhere above your Address bar. Click on the drop down arrow and select ADD WPSeek.com.
First off, Lyceum is the answer to the trivia question I presented in episode 49 of WordPress Weekly. More importantly, Lyceum is the name of the open-source software project developed by ibiblio. Its development is synchronous with WordPress although as it stands, development has pretty much been at a standstill as the last version to be released was a bugfix back in June of 2008 which is based off of the 2.0.x WordPress code branch. However, Lyceum and WordPress MU are very similar in functionality but there is a big difference between the two. That being, Lyceum stores all of its information in a set number of database tables (it has a normalized schema). WordPress MU, on the other hand, adds new tables for each weblog added (it has a sharded schema). This difference in database schemas is what gives Lyceum its bread and butter. According to the developer:
Lyceum’s schema is normalized, MU’s is, roughly speaking, sharded. For massive installations such as WordPress.com, a sharded schema is preferable. A normalized schema is preferable for everyone else. A normalized schema offers advantages in performance, ease of upgrades and administration, and vast opportunities for developing plugins and features which can access the entire set of data in the installation.
“Show me the last 10 posts across all blogs” is impossible in MU without maintaining and accessing a separate, redundant index table at the application layer. In Lyceum, it is trivial and fast, even for thousands of blogs.
In February, a discussion was started on the Lyceum users mailing list about the future of the project. In this discussion, someone mentioned that John, who is the lead developer of the project should think about getting hired by Automattic to maintain a Normalized version of WPMU. Here is what John had to say.
Hmm, an intriguing idea :) I’ve actually pondered various flavors of this on and off over the years. I think if I decide to continue Lyceum development, I will get in touch with them to explore if there are possibly points of collaboration.
Last but not least, the topic in the Lyceum IRC channel is ‘Lyceum Lives‘ which to me sounds like the project will continue. But, I have sent an email to John to get his take on the matter.
I know I have a few WPMU users in the audience so I have a few questions for you. would you like to see this project continue? Does the difference in database schemas mean anything to you? Have you given this project a try?