Before we go on, here is the reminder for the article published yesterday about upcoming WordPress:
What will we get with WordPress 3.4?

This list is based on the features requested by WordPress community, and things I consider important. This features are in circulation for over a year now, and still most of them are not even mentioned in the future development plans. Problem with most of these features is that they need much more time to do, and current quick development cycles core team insist on are simply not long enough to make these things happen.

• Replacing outdated and no longer maintained ThickBox with jQueryUI Dialog. This is actually something that was in works, and from what I have seen, it should be ready for the next WP 3.5. ThickBox popups are very complicated to control and they lack many features that jQueryUI Dialog popups can do. Replacing them would be great. But, that will also cause all sorts of problems for plugins developers, because most of the code using ThickBox will not be compatible with new popups. Colorbox is also a good way to go to make popups, but I would prefer jQueryUI approach, considering  how much WP relies on jQueryUI already.
• Custom post types posts relationships. This is very, very important feature that will move WordPress in the field of full-fledged CMS systems. Right now, you can’t connect posts directly and with more and more popularity custom post types gain, this is a very important addition. There are several plugins for this, all implementing this differently, but this is something that must be in the WordPress core. This would need additional database table for bridging posts.
• Meta data for taxonomies terms. There was some talk about this, but it was always dismissed when plans for next WordPress were made. Right now all data types in WordPress have meta fields (users, posts, comments) with the exception of terms. It would be very beneficial to have those. This also would require another database table.
• Improved media library. This can be found on most WordPress wish lists on the Internet. I don’t have too many complaints to Media Library, but there are many things that can be improved, including attaching one image/file to more than one post. Other important improvements would include: user controlled folder structure for storing files (not only dates based as it is now), with improved URL rewriting rules that can hide wp-content from the URL. Also, real galleries implementation would be of great benefit for media library.
• Shared resources between sites in multisite. It would be of great benefit to have central media library with assets and images that all multisites can use (logos for instance). Only super admins get to control that, but any site admin can use those resources. Beyond files, sharing can be done for taxonomy terms, maybe even pages and posts to some extent. This can be useful if you have same Terms And Conditions page that any site in the network can use as its own.
• Improved posts management. Right now, posts lists on the admin side are real pain to use when you have large website with thousands of posts. Changing category for hundreds of posts at the time is impossible. We need better system that would allow simpler and more powerful filtering on that page and operations that go beyond current, flawed bulk operations (if you want to bulk edit 10 or 15 posts, you can wait good minute or two before you can do anything, and some browsers can freeze with bulk edit).
• New Taxonomies Terms management. This current is very bad, and if we get meta data for terms, this current interface must be replaced with something that is actually usable for website with large number of taxonomies and terms.
• Real search. Maybe the worst thing in WordPress is absolutely useless search feature. There is no need to explain how bad it is, and how much we need something useful to search posts. We need full text indexing, some search operators, easy set filters for post type, custom fields or taxonomies terms. There are some plugins for this, but this is a feature that should be in the core.
• Remove Akismet from core distribution. Akismet is a commercial plugin, and for most websites, it must be purchased to use. Bundling it with WordPress core is not fair to all the other commercial plugins developers. Considering that many users prefer solutions that work on site only with no remote servers involvement, there are better solutions that Akismet, and also free solutions.

And what we should not see in future WordPress version (for a while at least):

1. We don’t really need new core themes. TwentyTen is great, and TwentyEleven is awful. I would like to see TwentyTen as HTML5 theme and be done with it. From what I have seen of TwentyTwelve, I am not impressed.
2. No more cosmetic admin side changes. We need real changes to posts lists panel, taxonomies terms pages, leave the rest of WordPress admin as it is. It looks great as it is now.

With few teams working only on these features, I think (based on earlier development cycles) that these would take 9 to 10 months (maybe a year) to implement and test properly. Also, having longer beta testing period for it would be beneficial to convince larger group of users to switch to new version when it gets released. And I am sure that powerful set of features would be the best incentive for adopting new WordPress.

What do you think about these features? Would you prefer to wait longer for a WordPress that comes with most of these things, than to waste time on small updates as we have now? Let me know with a comment.

Plugin Changes

Interface is updated to match our other plugins, context help specific info added, bookmarklet is improved and there are many minor styling improvements. Several bugs are fixed included minor bookmarklet issues and problem with updated of prices procedure.

New database table is added to track each price change. This will be used with next version for charting prices changes over time, monitor prices of specific products and other things. New tools panel for cache cleanup is added also.

Third Party Libraries

Main phpSDK Cloudfusion library for accessing Amazon is updated to 1.3 (with caching temporarily disabled due to some bugs in library cache class), Dev4Press gdr2 Library is now updated to 2.2.5, jQuery UI to 1.8.11 and several other jQuery plugins are updated also.

Promo coupon

If you decide to purchase plugin now, while still in Beta phase, a coupon is available that will give you 25% discount. This coupon is: AZONFBETA. To purchase plugin, visit the plugin editions page.

Demo Website

Demo website is in works and uses our lightScape theme, will use custom taxonomies and custom post types using our GD Custom Posts and Taxonomies Tools Pro. You can see it now, but expect updates as I update all the plugins used on the website. Website contains products (books, dvd, blu-ray, music) I purchased from Amazon.com and Amazon.co.uk over the years.

myCollection: Amazon Products:
http://my.gdragon.info/

Plugin Info

GD aZon Fusion, Plugin Information:
http://dv4p.com/10e
GD aZon Fusion, Editions & Purchase:
http://dv4p.com/10g
GD aZon Fusion, Screenshots:
http://dv4p.com/10j

Intro

Many parts of the page don’t change often, but require many SQL queries to be executed. If you have complex menu that combines categories, pages or posts and it can take more than 20 or even 50 SQL queries to make. For instance, all 3 menus on Dev4Press take about 30 SQL queries to get URL’s or structure. Similar situation is with widgets that don’t change every day, but can take a lot of SQL queries.

Cache method that I want to describe uses database to manually store rendered HTML into the wp_options table using transient records that can have expiry time, allowing you to set how long the cached data will be valid. In multisite mode, for rendering that is related to all websites you can use wp_sitemeta table with transient records. I will note the different functions for this later.

Cache Functions

We need 2 functions, one to store and other to get data from cache. You can store: objects, arrays, rendered HTML, anything really.

function dev4press_get_cached_data($name) {
  return get_transient($name);
}
function dev4press_set_cached_data($name, $value, $ttl = 43200) {
 set_transient($name, $value, $ttl);
}

• $name: name for cached object, this needs to be max 45 characters in length due to the limit of database table structure.
• $value: object/array/string to store.
• $ttl: time-to-live, how long the cached value will be valid, in seconds

$name must be unique for the element you are storing. After the $ttl time expires, stored element will be invalidated. Also, functions up there are very basic, but they allow you to expand with calculating stats about the hits or misses, or whatever you might need.

Best way to use this cache is for caching complex operations that require more than couple of SQL queries or uses one or more very complex SQL queries. Transient cache requires 2 simple SELECT queries that are very fast. You can always measure operations to determine if the cache will give you performance boost or not.

Example: WP Menu Cache

Here is the example how to use this cache method for WordPress menu. WP theme to display menu is wp_nav_menu(). So, if you have menu named “my_menu”, it’s usually added to theme like this:

wp_nav_menu(array("menu" => "my_menu"));

To use cache, code will change to this:

$menu = dev4press_get_cached_data("cached_my_menu");
if ($menu === false) {
  $menu = wp_nav_menu(array("echo" => false,"menu" => "my_menu"));
  dev4press_set_cached_data("cached_my_menu", $menu, 86400);
}
echo $menu;

Line 1 attempts to get stored menu from transient cache by key “cached_my_menu”. If the result is false, than we build the menu as before (using echo parameter set to false, so that menu is not displayed) on line 3. And when the menu is built, we need to store rendered HTML to transient cache using same ”cached_my_menu” key on line 4. And than display menu on last line.

First time the menu needs to be displayed, cache will be empty, and lines 3 and 4 will execute making menu and caching it. Next time, line 1 will get the menu from cache skipping rebuild part. After 24 hours (86400), menu will be invalidated, and first line will again return false, and menu will be rebuilt again.

Same principle can be used to handle any type of data to cache.

gdr2 Library

My gdr2 Library used in all my premium plugins and themes has own Cache class that is based on this method. Cache class supports statistics, unique name building and other things. It’s used to cache widgets in plugins and to cache widgets and menus in xScape themes. On Dev4Press website, powered by lightScape theme, widgets are cached and also main menu and the footer links map. Top menu items depend on the user, so it’s not the same for everyone, and caching it is not good idea.

Conclusion

I will search further for more things you can do to optimize websites, so more posts like this will be added. If you have some more suggestions on WordPress speed improving, please leave a comment.