37 blogs & 49 users

Posts Tagged ‘WordPress’

WordPress 2.8.1

July 10th, 2009

I’ve upgraded the site to WordPress µ 2.8.1, which contains a number of improvements on the previous 2.7.1 release.

Most of the dashboard pages now have Screen Options with additional options such as number of columns, and widgets now take advantage of object oriented programming — for the end user, widget management is once again drag-and-drop, and you can even deactivate widgets without deleting them.

As part of the upgrade, my Simpler CSS plugin has been enabled site-wide so that you can customize your theme with your own CSS. You’ll find it as “Custom CSS” under the Appearance menu.

Custom CSS

Custom CSS

Important: the old video embedding system has been deactivated for inefficiency, and replaced with a new site-wide installation of Viper’s Video Quicktags, which adds new, simpler-to-use buttons in the Add New Post text editor.

New buttons to embed YouTube, Vimeo and other videos

New buttons to embed YouTube, Vimeo and other videos

Hence, [swf URL width height] style tags are no longer supported, and [YouTube URL] embeds must be replaced with [youtube]YouTube URL[/youtube]. I’ve made an attempt to automatically correct these YouTube embeds in posts through the database.

Take advantage of the faster WordPress µ backend, the easier-to-use video embeds, and the ability to customize the design of your blog with custom CSS!

Hello, 2.7

January 30th, 2009

It’s here.

Upon logging in to your blog’s backend, you will immediately notice the new WordPress 2.7 interface. Play around with it, explore its features, and get used to it.

WordPress µ 2.7 slightly delayed

January 20th, 2009

The release of WordPress µ 2.7 is coming somewhat later than expected, although Trac (the interface to the Subversion repository) shows recent commits, with the latest having been made two hours ago.

Some of the blogs currently running on PersonalLog have a large number of posts and their performance could be optimized by running a single-blog install; anyone who wishes to migrate their blog to a single-blog install (take it out of the PersonalLog system) running WordPress 2.7 or 2.8-bleeding-edge can contact me.

Happy blogging.

Another Demo of 2.7

November 16th, 2008
Please enable Javascript and Flash to view this Flash video.

Here’s yet another video showcasing the significant changes in WordPress 2.7. It highlights some of the best features in 2.7.

Upcoming Upgrade to WordPress 2.7

October 29th, 2008

With the upcoming release of WordPress 2.7 on November 10, you can expect an upgrade of the PersonalLog system to WordPress mu 2.7 by the end of November, whenever the WordPress mu code base is synced.

The new release of WordPress is expected to bring many significant changes, including drastic (but good) changes to the admin interface, among other features.

Here’s a preview of what the Write Post screen may look like:

New Post screen in WordPress 2.7

Sorry, but this means that we’re all going to need to learn the new interface. I do agree that the new interface is significantly more user-friendly, even though it may take some time to get used to.

Read more about the new changes.

The significant changes in this new release mean that the admin menus (drop-down) inside the admin backend will be disabled today, and the admin menus on the frontend might not work with 2.7.

I’m sure that you’ll appreciate the changes.

Edit: this also means that PersonalLog will be skipping the 2.6.3 upgrade.

A major problem fixed

October 11th, 2008

Over the past few days, as I have been increasingly active in “fixing” PersonalLog, I noticed something that’s always been perplexing to me. Our database had been increasing significantly in size, and it was rather odd.

I decided to use phpMyAdmin to take a look. What I found was disturbing. (No screenshots.)

The database had over 4000 records in the options table for many blogs. Looking through some of the records, I quickly ascertained that most of the records were duplicate entries: “kb_robotstxt” and the robots.txt file as the value.

I immediately proceeded to wipe the 4000+ records from the tables, which ended up halving the size of the database after optimization. I then went over to the File Manager for a bit more investigation.

The problem was clearly the “KB Robots.txt” plugin. After checking the plugin’s PHP file, I was shocked to see an ugly piece of code that inserted a database record for the plugin’s options every time it was loaded. Since WordPress plugins are loaded on every page load, this meant that the plugin was inserting a new record into the table for every page load, unnecessarily.

I know I could have changed the plugin so that it only did so upon activation. But I was so disturbed by this piece of bad coding that I proceeded to delete it immediately.

As a result, all blogs depending on the “KB Robots.txt” plugin will no longer have access to it. Instead, I did something that was better; I made a default, search engine optimized robots.txt file identical to what the plugin produced, so all blogs will now benefit from the robots.txt optimization, without the need for an inefficient plugin. :)

Addendum: the database has been further optimized by purging the caches of the various RSS feeds in the dashboard. This means that the first time you log in to your dashboard after these changes, there will be a slight delay (both before and after you load the page) while WordPress fetches the RSS feeds. However, the database is now a fifth of its unoptimized size and will perform significantly more efficiently. :)

Enjoy your blogs on a cleaner, faster database.