The short answer is: premium support remains as it is. As long as your support account is active, you get support for GD Star Rating plugin, regardless if the version is 1.x or 2.x. I know that this is logical status for the support, but I have been getting some questions lately what will happen when GDSR 2.0 is released, and I want to ensure all current premium support users and future ones, support will cover both versions.

When GDSR 2.0 is released, new sub-forum will be added to separate the topics from old and new. Also, sub-forum for transition purposes will be added with advices and help on migrating to new version. New category for tutorials will be added to separate tutorials also.

Since GDSR 1.9 branch is not going to be developed anymore, there will be one more minor revision soon to fix few minor issues and that’s it. Plugin is compatible with WordPress 3.0, and with WordPress 3.1 for the most part, but that’s it. I don’t plan to make changes to make it fully WP 3.1 compatible, especially when you consider major changes in network mode this WP adds.

If you need to know some timeline in GD Star Rating 2.0 development, so that you can make plans in using the plugin, here is the date list that is not set in stone, but I will do my best to keep to it.

• End of February 2011 => GD Star Rating 2.0 Alpha: core functionality, voting control, JavaScript and styling for rating blocks, partial admin interface
• End of March 2011 => GD Star Rating 2.0 Beta: plugin is done, conversion of data, installer, everything ready for final round of testing
• April or May 2011 => GD Star Rating 2.0: plugin is released to public.

There is a lot of work to be done, and not much free time to do it, so it will take some time. But I think that results will be great and that new plugin will cover most of the things requested in the past year or so. If you have additional support related questions, please, feel free to ask.

jQueryUI loading is changed, and divided into more minor parts. So, if you have other jQuery library that depends on jQueryUI widgets, it will not work anymore, since widget library needs to be loaded now. So, check out all plugins that do that and make sure that everything is loaded as it should.

Here is the table of Dev4Press plugins and current minimal version supported. It includes upcoming versions of plugins that will be updated this week to support upcoming WP 3.1:

New versions of GD Custom Posts And Taxonomies Tools and GD Press Tools are coming very soon. Same goes with GD LinkedIn Badge and GD aZon FUSION. I am testing with latest development version of WP 3.1 and I will make imporvements if needed in the coming weeks leading to the final release of 3.1.

More info on new WordPress is coming. Also, expect another benchmark post as soon as final 3.1 is released to compare it to WP 3.0.

Intro

In some cases, it’s best to give on WordPress and make your own CMS that is made for the need you have. Getting some other CMS is most likely not good solution since it will have some other issue that will cause troubles, since all CMS have one fatal problem: they are not made for a single purpose, they are made to cover all sorts of uses, and this type of generalization will always be slower than custom use specific coding. But, I don’t plan just to give up on WordPress for such complex tasks, best is to make changes that will solve the problem.

Main problem and major slowdown on the AppHelp website was getting list of posts belonging to a post tag. One run of the query can take up to 1 minute (yes, one whole minute), and that’s not good. Using cache plugin is partial solution, and I prefer to have something that will solve the issue at the source, not to patch it after.

Solution(s)

Solution to this problem is to change the SQL query WP generates to get posts archive based on tags. The solution I have in mind takes 2 queries instead of 1, and these 2 queries need only 0.2 seconds to run. Compare that to 30 seconds (on average) original query takes for such large database, and you will see that new method is 100 times faster! Minor downside is that mySQL for these 2 queries will use a bit more memory (I managed to measure some 15% increase), and in my book that is a fair trade off for the massive speed improvement we got.

Original WP code gets post tag (term) slug and makes a query that joins posts table with all 3 taxonomies tables. If you want to use multiple terms SQL where clause will try all of them in the same time, and in all cases will search by VARCHAR field. So, there are actually two solutions. First, and simpler one is to use term ID’s in where, instead of slug names. This is actually method WP uses to filter categories and category pages are much faster than post tags because of simple SQL. But, that method is still slow, as it takes up to 10 seconds to run, and we want to get it much, much faster.

My solution is to add one more step. First, get the term ID’s for all terms. Than, make a new SQL query that will join posts table directly to the secondary, nested SQL query that will use term ID’s. Such method is very, very fast.

The Code

So, how to actually do this? Since we need to change whole query not only parts of it, there is only one way to do it without actually hacking WP_Query class. We need to hook up after the query is created and than make our own query. To do that we need to add filter for ‘posts_request’. This will give as full query made by WP_Query object, and the current instance of WP_Query object. Since, only problem are taxonomy pages (mostly tags in my case) code will check out if we are on the right page.

<?php
add_filter('posts_request', 'dev4press_posts_request', 10, 2);

function dev4press_posts_request($sql, $wpq) {
  if (is_tag() || is_category()) {
    global $wpdb;

  if (is_tag()) {
    $tax = "post_tag";
    $t = get_term_by("slug", $wpq->query["tag"], $tax);
    $terms[] = $t->term_id;
  }
  if (is_category()) {
    $tax = "category";
    $t = get_category_by_path($wpq->query["category_name"], false);
    $terms[] = $t->term_id;
    $terms = array_merge($terms, get_term_children($t->term_id, 'category'));
  }

  $sql = sprintf("SELECT SQL_CALC_FOUND_ROWS %s.* FROM %s INNER JOIN (SELECT DISTINCT tr.object_id as ID FROM %s tr INNER JOIN %s tt ON (tr.term_taxonomy_id = tt.term_taxonomy_id) WHERE tt.taxonomy = '%s' AND tt.term_id in (%s)) t ON %s.ID = t.ID WHERE %s.post_type = 'post' AND %s.post_status = 'publish' ORDER BY %s.post_date DESC LIMIT 0, 10", $wpdb->posts, $wpdb->posts, $wpdb->term_relationships, $wpdb->term_taxonomy, $tax, join(", ", $terms), $wpdb->posts, $wpdb->posts, $wpdb->posts, $wpdb->posts);
  }
  return $sql;
}
?>

This code can be changed for different purposes, this is just an example on how to make this work. Feel free to experiment. You can use $wpq (WP_Query instance) to get preset parameters and with that modify query further.

Speed improvements

First case is one category and all subcategories. Original SQL query took 21 second, modified query took about 1.5 seconds. Query for a single category is second case. Original SQL query took 1 second, modified query took about 0.2 seconds. This is the smallest gain, but everything counts. Last case is the filter by post tag. Original SQL query took 66 seconds, modified query took about 1.2 seconds. And that’s where this query method knocks out WP out of the park.

Conclusion

There are many cases where WP core will be slow and the only solution is to rewrite parts of it. In most cases use of filters will be enough to make changes, but there are some elements where only direct hacking of WP core is the solution. I will try to avoid such things as much as I can. Main WP development rule: don’t change the core files.

This is not something that you will need for every website, but it’ a good idea to have this around if you are working on not so typical WP website where using core code can cause website to be slow. For small websites, such issues will never occur, but for bigger websites many things in WP core are slow.

Major features are already outlined in the roadmap for xScape, but here is the more info on what to expect. The only new theme related feature in next WordPress 3.1 will be post formats support. One of the next couple of versions of xScape will add support for post types, I am not sure exactly when, still waiting to see how that will work in the first place.

Some features I was planning for previous milestone were bumped to this one because I didn’t had time for them, or some other features have been bigger priorities. But, I am not adding anything not already on the list, so all the features on the milestone roadmap will be done while the xScape reaches 1.6.

Also, very important change for next milestone is fading support for WordPress 2.8 and WordPress 2.9. xScape 1.6 will support only WordPress 3 and higher. From xScape 1.5.3 I will start removing code that deals specifically with WP 2.8. Based on WordPress official usage statistics, WP 2.8 has only 10% of websites running on it. WP 2.9 is with 25% of websites, and WP 3.0 on over 50%. xScape 1.5.3 will be released by the end of this year.

That’s it for now, more info on the xScape development progress will follow.

For normal usage, adding terms doesn’t affect WP working much, since you will publish post at a time. But, if you have some automatic publishing procedure that have to publish 100 or more posts at the same time, you have large number of posts, large number of tags and more than 2 default taxonomies, assigning terms can take quite a long time.

Massive website I am working right now on, has 300.000 posts, 40 categories and currently 100.000 tags (for some 30.000 posts only at the moment). To get tags for the rest 270.000 posts using current default WP function wp_set_post_terms() it will take about 2 weeks to complete on a very, very fast VPS server. And that is only adding normal post tags, if you need something like that with hierarchical taxonomy with same number of terms, this can take much longer. Why?

How WP adds and assigns terms?

If you use wp_set_post_terms() function, there are several things WP needs to do to ensure that terms added are not duplicates, that are not assigned already. In case of hierarchical taxonomies things are more complicated, because WP needs to check the whole hierarchy. To add new term WP can execute between 10 and 16 queries , and even 20 for hierarchical taxonomy. With large database these queries can take long time to execute. For the website I am working on now, typically one post gets 15 tags, and running all that can take even 4 seconds per post, and that is about 2 weeks needed to process! And, for what we need that is simply unacceptable.

How to solve this problem and speed process up?

Well, it all depends on what you need and what kind of flexibility you search for. For the project I am working now, I have written functions to replace default WP wp_set_post_terms() function. New functions are for post_tags only, and they are removing several steps that are not needed in the specific case we have here. New set of functions is some 6 times faster than default function and it takes 3 to 5 SQL queries per term. Also, new SQL queries are simpler and with that faster. But, they will work only with non hierarchical taxonomies and they will always work in append mode, adding terms to posts.

Here is the source code for functions needed, feel free to use them. Last function in the source is one you need to add terms to posts (or any other object).

<?php
function dev4press_insert_term($name, $taxonomy = 'post_tag') {
 global $wpdb;
 $args = array('name' => $term, 'taxonomy' => $taxonomy, 'alias_of' => '', 'description' => '', 'parent' => 0, 'term_group' => 0);
 $args = sanitize_term($args, $taxonomy, 'db');
 extract($args, EXTR_SKIP);

 $name = stripslashes($name);
 $slug = wp_unique_term_slug(sanitize_title($name), (object)$args);
 $wpdb->insert($wpdb->terms, compact('name', 'slug', 'term_group'));
 $term_id = (int)$wpdb->insert_id;

 $wpdb->insert($wpdb->term_taxonomy, compact('term_id', 'taxonomy', 'description', 'parent') + array('count' => 1));
 $tt_id = (int)$wpdb->insert_id;

 return array('term_id' => $term_id, 'term_taxonomy_id' => $tt_id);
}

function dev4press_term_exists($term, $taxonomy = 'post_tag') {
 global $wpdb;

 $sql = sprintf("select t.term_id, tt.term_taxonomy_id from %s tt inner join %s t on t.term_id = tt.term_id where t.name = '%s'", $wpdb->term_taxonomy, $wpdb->terms, $term);
 return $wpdb->get_row($sql, ARRAY_A);
}

function dev4press_add_tax_terms($object_id, $terms, $taxonomy = 'post_tag') {
 global $wpdb;

 foreach ($terms as $term) {
 if (!strlen(trim($term))) continue;
 $term_info = dev4press_term_exists($term, $taxonomy);
 if (is_null($term_info)) {
 $term_info = dev4press_insert_term($term, $taxonomy);
 }
 $tt_id = $term_info['term_taxonomy_id'];
 $wpdb->insert($wpdb->term_relationships, array('object_id' => $object_id, 'term_taxonomy_id' => $tt_id));
 wp_update_term_count(array($tt_id), $taxonomy);
 }
}
?>

Conclusion

This is not something that you will need for every website, but it’ a good idea to have this around if you are working on not so typical WP website where using core code can cause website to be slow.

Interface for custom post type and custom taxonomy editor is improved and looks the same for both. Custom post type have option to deactivate post type (for testing or something like that). And custom taxonomies got special features (only in Pro version, similar to custom post types). Currently there is only one special feature: to add custom taxonomy as a column on post edit grid.

If you have any more problems, please report them in the forum or in comments.

GD Custom Posts And Taxonomies Tools:
http://dv4p.com/gdtt

Dev4Press compatibility

First, all our plugins and all themes are fully compatible with new WordPress. There will be minor updates over the next few days if the errors are found in any of them, so please, report any problems if you find them.

Upgrading

I have auto updated most of my WordPress driven websites to WP 3.0, without any problems. But this is only on systems with PHP memory limit set higher than 32MB. I tried two older blogs running with 32MB running WP 2.8, and on both upgrade failed due to lack of memory caused by average number of plugins these websites were using. I think that many users will have to perform manual upgrade if they run in the problems with the memory and auto upgrade.

Another problem is compatibility. All existing themes should be working fine, but with plugins there will be problems. Most plugins that use JavaScript to improve and modify WP will simply fail and cause many problems. I hope that plugin developers will fix the problems soon, because even number of popular plugins are affected by problems.

Big problem with WP 3.0, as it was with previous versions is that uses more memory. This is unavoidable, and 32MB is simply not enough to run website with WP if you plan to use 5-6 or more plugins. Compared with WordPress 2.9.2, this website memory usage grew by 20% when upgraded to WP 3.0. Similar is with my other websites. And with 20 plugins I use on this website, admin pages use from 42MB to 50MB depending on the page.

Features

I am not going to go into details about what this version added, the list is very long. You can check the full list on official website using links at the bottom. Bu,t most important addition are fully implemented custom post types, improved custom taxonomies, custom navigation and much, much more. I think that custom post types will prove to be the most important addition to WordPress added in the last 2 years to make WP even more competitive in the CMS market offering high degree of flexibility.

Merging with WordPressMU and changes that lead to new networks mode is also very important change. Installation of the multi site / network mode is not very complicated, and upgrading from WPMU goes smoothly.

Theme 2010

Well, I said it before and I will say it again: I don’t like the new default theme. It was the time for WordPress to get theme to replace good old Kubrick, but new theme is just not as good as I expected. But, I never run website with default theme anyway, so I don’t really care about that. But, for the overall image of WordPress, better theme was needed.

And in the end

There will be much more talk over the next few weeks, but right now this is hands down the best WordPress release in years. From all my testing in the past 4 months and the tests of the final WP 3.0, I can tell you that it’s very stable and reliable like no other major WordPress release I have tried since WP 2.3. I am sure that bugs will surface soon enough but that’s nothing new, important thing is that you can safely upgrade and benefit from new features. Also, make sure that plugins you use are up to date with WP 3.0 to avoid problems.

Finally, all the developers working on WordPress 3.0 deserve a big thanks from the whole WordPress community, because they did a great job on making this latest release. You can check out the list of all developers and contributors on the official WP website. I am honored to be mentioned among contributors even so I only reported several bugs and fixed one.

And to celebrate

To celebrate release of new WordPress I have decided to offer a 30% discount for all our plugins licenses. Discount coupon is WORDPRESS30. It has limited number of uses, so hurry up and use it for individual plugins or bundle pack.

Links:

WordPress 3.0 “Thelonious” Release Post
WordPress 3.0 List of Features and Changes

There are days that I get over 200 spam blogs registered over at xScape demo website. And I get the IP used for registration, and I add it to .HTACCESS file. And than I need to removed all those blogs. And that takes time, and always it’s very frustrating. And to be honest, the only method that have some effect is banning IP’s. But, there is nothing to prevent these spam bots to use another IP.

I searched, and I searched, and there is not a single plugin that offers any kind of protection from this. And everybody seems to be fine with that. Website administrators are patiently block IP’s, delete spam and nothing is changed. Well, I am not fine with that. So, last night I started work on a new feature for GD Press Tools Pro that will fight spam registrations. At this point it’s all done, and it works with both regular websites running WP and multi sites. There are several methods plugin implements right now, and they will be expanded over time:

• Prevent using keywords in the username (old feature)
• Limit length of username with minimum and maximum length value (old feature)
• Perform regular expression filtering of username and email. If they fail with at least one expression, they are considered invalid.
• Log registration requests into DB, and mark them with filter that they failed.
• Auto ban IP, email or username automatically if they fail filter tests.
• Redirect visits to whole website or wp-login.php/wp-signup.php based on the banned IP.

Starting tonight I will test the plugin on xScape.info and make sure that everything works before rolling out GD Press Tools 3.6 Pro next week. This will be another Pro exclusive feature and over time will be expanded with more options and more filter tests. If you have suggestion what else can be included, please leave a comment or send me an email. I will be happy to improve this as much as possible and help all plugin users by saving them some time and a lot of frustration from cleaning the website from spam registrations. And with increasing number of WPMU and WP 3.0 Multisites, I am sure that spam problem will only increase. And with already implemented prune users feature GD Press Tools is very powerful tool that will make your blog clean and secure.

So stay tuned, new GD Press Tools will get his spam fighting powers soon.

I must say that I am impressed with the the upgrade in WP 3.0. xScape demo website has some 20 blogs right now, but I guess that even with large WPMU website everything should be fine. I also posted a tutorial on the upgrade procedure and exactly what I did during the xScape upgrade. You can check it out:

Migrate from WPMU 2.9.2 to WP 3.0 MultiSite

New xScape.info now works faster than before, uses less memory and benefits from all new features in WP 3.0. If you have WPMU websites I recommend that you try upgrading to new WP.

To try xScape themes and Dev4Press plugins go to xScape and get your own 48 hours free blog:

xScape Demo

If you follow the discussions on the current WP 3.0 progress, you surely know that major problems remaining right now are Menus and custom post types. And while the custom post types are working good as far as I can tell (with few problems still), the same can’t be said for Menus.

Custom post types and taxonomies

Even though custom post types were implemented in WP 2.9, it was very basic implementation, and you couldn’t do much with them. But now, custom post types are on the same level with the posts and pages. And while there are some bugs still remaining, I am confident that it will be sorted out before the official release. This website uses custom post types for the central documentation, and right now the only thing I couldn’t implement is having comments with posts in documentation.

Custom taxonomies are much improved with additional hierarchy support. You can try my GD Custom Posts And Taxonomies Tools plugin to see how all that works right now.

Menus

As of yesterday, I managed to create first menu and to actually see the editor working properly and display nesting of the menu items. But, menus editor in my opinion is not good (not to use stronger word). I have several problems with the way the menus are implemented. They are forced into a taxonomy, even thou, menu has nothing to do with taxonomy. Menus need much complex data model to be able to allow much wider range of items and taxonomies are not good for that. Editor will be a pain to use if you need to create big menus that have hierarchies of pages or categories with no settings on how to handle page item that already has sub pages or categories with sub categories. In my xScape theme I have built menu designer that has much more options and more control over the menu items and how they are displayed including different way to render items. Also, all menus in xScape are saved into the WP options table as serialized objects, and that I find more logical than approach in with WP native menus. Also, it’s easy to expand such structure. But, deed is done, and I don’t believe that anything with menus implementation will be changed in the next 2-3 weeks. We will see who the menus will perform and how much problems will cause in the long run. Good idea, average implementation.

WPMU to Multi Sites

As for the merge with WPMU, I still have to test how the conversion of WPMU website will go to WP 3.0, but from what I have seen over the Internet, that should go without problems. As for standalone multi site installation I tested, there are many inconsistencies with WPMU and I think that there will be problems with migration of plugins and themes specifically written for WPMU. I will write more on the migration next week when I do that with xScape.info website.

Speed

Speed. WP 3.0 is much faster in all operations. This is not just subjective view, but I actually measured that speed improved by 15% and memory usage is now lower by 10%. Many changes made to meta boxes on post edit page are great and improve speed and usability, but they will break many plugins that relied on JavaScript to modify default meta boxes. But, I guess that with so many changes one can expect that problems with plugins can’t be avoided.

For the past month I have been improving all my plugins to work with WP 3.0, and so far everything works great. Same goes for xScape themes, and everything works in both normal and multi site installations. More on WP 3.0 coming soon, I will make more tests with menus after Tuesday when Beta 2 is announced. Migration from WPMU will follow next weekend.

WordPress doesn’t change much the already established interface created with WP 2.7 and WP 2.8. But, there are number of features that you might find very useful. But, first and most important is that there are many fixes in this release over 2.8 so, the upgrade is at least worthy of that. Here are some of the new features:

• Trash: instead of direct deletion of posts, they are marked as trash. So if you delete something by accident you can restore it.
• Theme templates: for categories, pages and tags based on slugs.
• Image editor: basic operations allowing resize, rotate of uploaded images and more.
• New libraries: updated SimplePie and TinyMCE.
• Embed: direct embedding of different media types in posts and options to expand them using oEmbed.

There are many more things, and you can check full list here.

As for the compatibility of Dev4Press plugin, I can confirm that they are all fully WP 2.9 compatible, and you can safely upgrade your blog, none of our plugins will brake.