Topic Views List Widget

Right now plugin comes with 2 widgets. Search Topics widget ads simple search form to search topics in the forum. Plugin depends on the search view from GD bbPress Tools plugin, so you need that plugin installed and active. Topics views list is expanded from the original bbPress widget and allows you to select views to include in the list. You also have option to disable default views widget.

If you notice any problems, please report them in the comments or in the forum.  More widgets will be added and all suggestions to enhance current widget or to add new ones, are welcome.

Signature for User

All standalone forums support users signatures. Now, signatures are added to bbPress forums also, and you can control what user roles can set signature, and also what user roles can use BBCodes or HTML inside the signature.

bbPress supports adding custom views for topics. Now, you can simply enable extra custom views from new tab. Currently, there are 3 custom views added: Topics with most replies, Latest Topics and Search Results. Last one is very interesting since it will allow searching topics (more on  that soon, when search widget is released). BBCodes are added for: Vimeo video, image, font size and font color. More to come soon.

As for the new bbPress 2.1 that should be released soon, plugin fully supports it. Even if you enable rich WP Editor in bbPress 2.1 (they call it Fancy Editor), plugin will be able to use it. All the other features are tested and work fine. In the same time, quote feature is improved: you can select text of the page, and click quote to quote only selected text. And when you click quote, page will scroll down to the editor area.

One more new feature is the use of the capabilities. As you know, each feature in the plugin can be allowed to users with user roles specified, but if you want finer control, plugin now supports capabilities and each cap is listed for each feature on the settings pages.

If you notice any problems, please report them in the comments or in the forum. All suggestions for new tools are welcome. Also, read more to find out about 2 upcoming plugins for bbPress.

Thumbnails In Line

New option is added for the thumbnails display to allow for in line rendering. From this version on, rendering of images thumbnails and other attachments is separated into two lists to allow for better styling manipulation. Also, styling is improved for better CSS compatibility with different themes.

Plugin is tested with latest development code for bbPress 2.1, and it works fine. Some minor things are changed, but nothing serious. I expect that no more changes are required when bbPress 2.1 final is released. Also, new translation is added for Persian language by Ramin Firooz.

As always, if you notice any problems, please report them in the comments or in the forum. All suggestions are welcome.

Support BBCodes List

Plugin adds support for BBCodes based on phpBB implementation. Right now 26 codes are implemented, but some 10 more will be added in next version. Four of those codes are listed as advanced, and you can decide what user roles can use them. If the role can’t use the code, it will be stripped when saving. Each code allows for same attributes: class, style and raw. If you set raw to 1, content inside the shortcode will not be processed and will not allow for nested BBCodes. Style and class will be applied to the element.

New option is also for quoting topic or reply in your own reply. Plugin can use BBCode for that or standard HTML blockquote. Quote option can be added to links above the topic/reply content, or it can be appended after content.

More new features are coming soon. If you notice any problems, please report them in the comments or in the forum. All suggestions for new tools are welcome.

Plugin Version: 1.7.3, revision: 512060

Patch Fixes:

1. Undefined warnings.
2. Loading of CSS files.

Download:

1. wp-syntaxhighlighter.php_543686

Worst thing about having free plugins, is that you can’t expect that developers will be able to fix things quickly enough. If you are using my Pro plugins, you know that fixes come out in a matter of days, or even quicker. With most free plugins, that can take a lot of time. But, in most cases, I can’t wait that long to get plugin I need to use working, so very often I get involved and fix the plugins myself.

Plugin Example

But now, I will release to public patches for any third party plugin I fix. Each plugin will get own post, and in that post patches will be listed by plugin version and SVN build, with included fixes list and list of files to download. Each patch is in the ZIP archive, and to apply it, you need SVN version of the plugin that can be used to apply patch to. When I can, I will be updating patch information in case the plugin author fix it.

I will always try to contact plugin author and send him the fix, and hopefully they will release proper updated version soon after. First plugin to get a patch is WP SyntaxHighlighter, and patch contains several fixes, some of them quite critical depending on what you need the plugin for.

I hope you will find these patches useful. I hope to have more of them coming soon.

Right now plugin features two tools: toolbar menu integration and

GD bbPress Tools: Settings

GD bbPress Tools: Toolbar

Most tools in the plugin will allow user roles based settings as you can see on the image above. Toolbar menu option will add easy to use menu into WordPress toolbar with links to forums and views. Also, there are links to admin side new and edit links, settings and tools related to bbPress, including links for information.

Other tool included in 1.0.0 is to limit access to admin side menus and editors for forums, topics and replies. This code is based on the code by John James Jacoby from his ‘bbPress – No Admin’ plugin, but my version is more effective to prevent access, not only to hide menu items.

If you notice any problems, please report them in the comments or in the forum. All suggestions for new tools are welcome.

There are small updates to translations and main POT file. And, this time we have new language added: French translation by Marie Bodson. Due to the changes in the last few versions, I call for the translators of existing languages in the plugin to update their translations.

As always, if you notice any problems, please report them in the comments or in the forum. All suggestions are welcome.

Plugin Links:

GD bbPress Attachments Home Page
GD bbPress Attachments on WordPress.org

Creating multi sets is similar to the old plugin. But, now we have popup dialog for convenience with drag’n'drop for the multi set elements.

Mutli Set Editor Popup

As for the plugin Tools, right now Import/Export is completed, and the Maintenance for cleanup and reset.

Maintenance Tools

Most important part is setting rating object, here is fully functional auto insert rules editor.

Rating Object Auto Insert

That’s it for now, stay tuned for more.

Enhanced search result feature is removed due to the conflict with the search in some cases. And, you can use default ‘Exclude from Search’ option each post type has. This option is on Settings tab, Visibility group of settings.

If you notice any problems, please leave comment or report them in the forums.

Many import and export problems are fixed in this version: hierarchical taxonomies (like Categories) failed to import, products updating also failed, exporting empty link field was not done right and cleanup of line breaks before import also failed. Properties editor had small problem with default unit value selection, also fixed in this version.

Plugin now has a Spanish language support, translated by Antonio Romero. There are some more improvements to JavaScript files and the taxonomy interface withe deletion confirmation dialog.

Please report in the forum any other problems or bugs you find. Also, suggest features for future versions, and if you need, tutorials about any subject related to plugin use.

Folders creation process now shows the notices on the admin side stating the reason for the problem, so you can create folders manually or make them writable for the plugin. If you notice any more issues or problems please report them in the forums.

New Settings Panel

This version fixes several reported bugs, including problem with saving templates, loading obsolete files and few other minor problems. Plugin now uses same interface and color styling as all the other Dev4Press plugins.

Other than this, there are no changes in widgets. But, just in case, please check if everything is OK and if you find any problems, report them in the support forum. Also, plugin development continues, plans for it are below.

Subscribe2 is free and excellent plugin for email subscriptions about new entries on the website. Plugin is created by Matthew Robinson and to get more info about it visit the plugin website: Subscribe2 Plugin.

Previous benchmarks I did for this plugin showed that it used too much memory and that all the code was in one PHP file. For benchmark done in January 2012 I was testing Subscribe 7.0.1 released in November 2011. And based on those tests, I gave the plugin lowest grade for the optimization. My grading was not based only on memory usage or SQL queries, most important factor was based on the code review and the potential for optimizing it. There are instances where plugin uses a lot of memory and I still gave it good grade because of the way plugin loads and works. So, benchmarks included both measured data and optimization analysis.

Subscribe2 author Matt joined the discussion and he was defensive of the plugin and its performance. But, the great thing that come from the discussion is that Matt decided to give optimization a try, to see if my instructions on that really work and how he can improve his plugin. And it really did work, and Matt did a great job on optimizing Subscribe2 plugin. Over the last 2-3 months Matt and I talked about the optimization and I did more benchmarks, testing his optimization process that ended up with the release of 8.0 version of the plugin. Matt also provided me with a short text, where he describes his work on optimization.

Matt:
About two months ago as I type a user of my plugin drew my attention to a benchmarking assessment done at Dev4Press.com that had assessed and benchmarked a substantial number of WordPress plugins. This site noted that Subscribe2 had “Bad optimization results, must be improved”. Now I visited the site and noted that Subscribe2, in comparison to other more highly rated plugins, loaded pretty quickly, did not use much resource and used minimal SQL queries. I started to question the author of the review article, Milan Petrovic, about exactly how he had arrived at his conclusion that Subscribe2 was badly optimized in light of these comparatively good optimizations.

If you want to read the full discussion we had back in January through comments, you can revisit original plugins benchmark article here: Measuring impact of plugins on WordPress loading.

Matt:
It became apparent that Milan was not only taking into account the raw data gleaned from his analysis of the execution of the plugin code but also reviewing how the code was written and thus optimized. He recommended that I break Subscribe2 down from essentially a single file into several classes and subfiles. Now, I have to say the prospect of doing this did not fill me with excitement. I am not a coder or programmer in my day job, I see Subscribe2 as a hobby. It’s code I use on my sites and I make it available to the wider WordPress community as it seems that a few of you find it useful too. Since I have no real formal education in coding I’ve learned everything I know from simple trial and error and through reading lots of documentation about PHP and WordPress functions. I find it much easier to have all the code in one place – one file.

Great thing about WordPress is that making a plugin is very easy. And you can always start from simple examples, from documentation and you don’t need to know too much about PHP. In my experience, starting with simple plugin you can put all the code in one file. Start adding more code, and that file grows. And if you end up with the file that has 200KB of code, PHP will need a lot of memory to load file and to interpret it into operation code that is than executed. That code can take a lot more memory in the end.

Matt:
That said I thought I would test out Milan’s assertion that breaking the code up would make a difference. I’m a scientist really and I love to challenge theories, in this case I was skeptical at the start. So, I set about breaking Subscribe2 into 5 files, a loader, a core class and then 3 extender classes for the front end, the admin side and a special case for multisite installs. Once I’d finished this I emailed the code to Milan and he happily tested it for me. I was very surprised to see that the RAM usage and loading time on the front end had been halved by the changes. The admin side was pretty much unchanged.

Milan then made one last suggestion; he recommended that I break my code for the 4 administration side screens that Subscribe2 makes available into separate files too and load these only when the page was visited. So, again I set about making these changes and emailed the code to Milan once completed. Again, to my surprise the administration side RAM usage had dropped to less than half what it had been before, even on the largest of the Subscribes pages. Additional changes also saw RAM usage drop to about a quarter of what it had been previously.

Matt did great job in splitting plugin into smaller files and making good folders structure to organize files based on their use and context. And main plugin file dropped in size from 200 KB to less than 3 KB. This loader file was than used to load only other plugin files based on the need for them.

Matt:
So, in summary, the review by Milan and the recommendations he made have left me with a faster and less resource intensive plugin. That can only be a good thing. On the downside it has caused me to split my plugin into lots of smaller files which I will find harder to manage and will therefore slow development down – but I consider that Subscribe2 is pretty feature complete now and I try to avoid adding new features unless they are adding value to the plugin to as large a number of users as possible, so perhaps that isn’t too bad a thing either!

Now to the numbers. How much memory is saved with the optimization Matt did? Table below shows test results for old 7.0.1 and latest one 8.2.0 versions.

As you can see, on the admin side plugin uses 70% less memory and on front end side 77% less memory after optimization. That is a huge gain. On the admin side, depending on the plugin admin page loaded this memory usage varies, but it doesn’t go over 0.6MB, on all other pages it is 0.4MB. As for the loading time, this is measured on my test server. Depending on the server speed, plugin can load faster. This number here shows a slight gain in loading time also. In that regards, there is not much space to improve that further, considering that even the smallest plugin on my test server needs about 0.008 seconds to load. Subscribe2 is great in this area also.

From my experience, having more files for a plugin can help you down the road when you get to adding more features. You can make better and more logical code organization, and you can start thinking about how new code will affect loading and how you can help to decrease memory footprint. In the end, end users of your plugin will be glad to have better optimized plugin and that they don’t need to switch to more powerful server every time new WordPress is released.

Imagine now if every WordPress developer did the same thing as Matt did with Subscribe2? I don’t think that each plugin can see such gains in performance, but most optimizations can save 30-70% of memory. If you used 20 plugins that were not optimized, you can end up needing 70-90MB of PHP memory, and most shared hosting would have problems with that. If you have 20 optimized plugins, this number can drop to 45-55MB and that is another story, your server can handle more requests and will be faster.

I know of many developers that have used my optimization suggestions to make their plugins better, and in this case I am grateful that Matt decided to try optimization despite his skepticism of the process. And not only try, but get great results after. If you want to see if you can do better with your plugin performance, here is my tutorial on the subject: How to optimize plugin loading.

jQuery libraries qTip2 and Timepicker are updated to their latest versions, and gdr2 is updated to latest 2.7.2 version. Some minor things are changed in various plugin files. Other than that, bugs fixed in this version include: broken DropBox backups upload, problems with beta/nightly updates options, loading gdr_p print function on the front end and problem with displayed date time for the next scheduled jobs (backup and sitemap) on the plugin main admin page.

Plugin toolbar menu now shows plugin icon. And, display of dates on the plugin main admin page are formated using WordPress default date and time format. As always, please report in the forums any bugs you find, and I will get on fixing them.

Each rating object has 3 rating types and 4 rating methods. Basic panel bellow shows settings for each rating type (mind some typos).

GDSR 2.0: Rating, Basic Settings

Second tab shows rules for the voting and revoting for rating type/method combinations.

GDSR 2.0: Rating, Voting Rules

That’s it for now, one more preview is coming soon, and once the admin panels are usable, public alpha will follow. Current testing is going well, and I can’t wait to share the plugin with all users soon.

If you notice any problems, please leave comment or report them in the forums.

Post Types Panel

Image above shows the new layout for the post type editor panel. And, as you can see, it shows information a bit differently with options grouped logically. Taxonomies and meta boxes are listed now with name and label. Similar thing is done with the taxonomies panel.

Tooltip

To help understanding options, tooltips are added for all the links on the panel, like on the image on the right. From the same image here, panel has a new option for templates in the theme for the post type. For now, this shows what templates are needed for this post type, so you will know what file you need to make and customize.

Another new thing is new custom field type for resolution. When in the meta box, it will show X and Y values to enter. More custom fields are coming in future versions.

If you notice any problems, please leave comment or report them in the forums.

Before we go on, here is the previous article on rewriting:
How WordPress URL rewriting works?

Date based archives by default, work only with the default posts post types, and they look like this:

Year archive: http://www.example.com/2011/
Month archive: http://www.example.com/2010/10/
Day archive: http://www.example.com/2012/02/22/
Month archive, feed: http://www.example.com/2010/10/feed/
Year archive, page 2: http://www.example.com/2012/page/2/

But, to get similar URL’s for the custom post types, will not work. Also, each of theses URL’s supports pages and feeds as you can see on the last two examples.

If we have post type names ‘movie’, and for the post type archive slug we have set ‘movies’, you expect to get these date based archives for it:

Year archive: http://www.example.com/movies/2011/
Month archive: http://www.example.com/movies/2010/10/
Day archive, feed: http://www.example.com/movies/2012/02/22/feed/
Year archive, page 5: http://www.example.com/movies/2011/page/5/

Such URL’s will filter posts by post type and date, returning date based archives for a post type. But, it is not that hard to do this. What’s more, there are two ways you can do it: using a plugin and doing it your self with custom coding.

Using GD Custom Posts and Taxonomies Tools Pro

If you prefer to do things from the comfort of the admin interface, and if you need to do this for many post types, my GD CPT Tools Pro plugin is a best solution. You can add and manage any number of custom post types and you get long list of extra features plugin implements, including custom rewriting that includes date based archives.

GD CPTTools Pro: Enable Date Based Archives

For each custom post type, plugin includes many more rewrite options. On the rewrite tab, you can set up permalink structure for single posts, and you can control archives for post type. Simply enable the Date based archives checkbox (like on the image on the right), save post type, and plugin will generate rules for these archives.

If you want to check the rest of this plugin features, you can do it from here:

Do it yourself with example code

If you prefer to do this yourself, here is the code that GD CPT Tools Pro uses for the date based archives. For the year, month and date archives you need one extra rewrite rule. And, if you want to have feeds and pages for them, you need 3 more rules for each one. So, in total there are 12 new rules for each post type for the date based archives. For this to work, we need to hook into action ‘ generate_rewrite_rules ‘:

add_action('generate_rewrite_rules', 'my_datearchives_rewrite_rules');

function my_datearchives_rewrite_rules($wp_rewrite) {
  $rules = my_generate_date_archives('movie', $wp_rewrite);
  $wp_rewrite->rules = $rules + $wp_rewrite->rules;
  return $wp_rewrite;
}

This code attached  ‘my_datearchives_rewrite_rules’ function to ‘generate_rewrite_rules’ action. On line 3, we call another function that will generate rules for a post type ‘movie’. We than add those rules to existing WP rules, and return rewrite object. Now we need the function that generates rules for specified post type.

function my_generate_date_archives($cpt, $wp_rewrite) {
  $rules = array();

  $post_type = get_post_type_object($cpt);
  $slug_archive = $post_type->has_archive;
  if ($slug_archive === false) return $rules;
  if ($slug_archive === true) {
    $slug_archive = $post_type->name;
  }

  $dates = array(
            array(
              'rule' => "([0-9]{4})/([0-9]{1,2})/([0-9]{1,2})",
              'vars' => array('year', 'monthnum', 'day')),
            array(
              'rule' => "([0-9]{4})/([0-9]{1,2})",
              'vars' => array('year', 'monthnum')),
            array(
              'rule' => "([0-9]{4})",
              'vars' => array('year'))
        );

  foreach ($dates as $data) {
    $query = 'index.php?post_type='.$cpt;
    $rule = $slug_archive.'/'.$data['rule'];

    $i = 1;
    foreach ($data['vars'] as $var) {
      $query.= '&'.$var.'='.$wp_rewrite->preg_index($i);
      $i++;
    }

    $rules[$rule."/?$"] = $query;
    $rules[$rule."/feed/(feed|rdf|rss|rss2|atom)/?$"] = $query."&feed=".$wp_rewrite->preg_index($i);
    $rules[$rule."/(feed|rdf|rss|rss2|atom)/?$"] = $query."&feed=".$wp_rewrite->preg_index($i);
    $rules[$rule."/page/([0-9]{1,})/?$"] = $query."&paged=".$wp_rewrite->preg_index($i);
  }

  return $rules;
}

To fully understand this code, you need to understand PHP regular expressions, but if you just want to use it, no worries, it is all here and this function doesn’t need to change. Let’s see what is going on in this function. Function is called with two arguments: name of the post type ($cpt) and the WP rewrite object ($wp_rewrite).

First, we need to find out what is the slug for the archives URL for this post type ($slug_archive). If you have disabled archives for post type, this function will exit on line 6. If the archives are set to use custom slug, function will use that, or it will use post type name (lines 7-9). Lines 11 to 21 are used to set up day, month and year based regular expressions rules and variables to be used in the query. First one is for day and it needs year, month and day, month based needs year and month, and year based only year. After that, we go through these 3 archives types and we generate rules for them. In the rule part we use regular expressions, and it uses ( and ) to separate capture groups. Each capture group provides a value for us to use, and each of these values need query variable in the query part of the rewrite rule.

Line 24 sets up the base for the query using post type name and on 25 we set up base for the rewrite rule using post type archives slug and the rule for the archive. Now, we need to add to the query all the variables needed for the rule (27 to 31). This builds the basic rewrite rule and rewrite query rule point to. Lines 33 to 36 are setting up rules for basic archive rule, feeds and pages. Feeds and pages need extra bits for the regular expression to detect feed or page, and extra query variable for feed or page. If you don’t want to have feeds for these date based archives, you can remove lines 34 and 35. Line 33 adds basic rewrite rule, and line 36 adds pages for archives, and you need to leave these two in place. After all the rules are generated, they are returned back to the rules in ‘ my_datearchives_rewrite_rules’ function, merged with WP rules and ready to use.

Whenever you make changes to rewrite rules, you need to instruct WordPress to rebuild the cached rules. To do this, it is enough to open Permalinks panel on the WordPress admin side under Settings. If you use GD CPT Tools Pro and its rewrite features, this plugin will flush rules on its own when needed.

Conclusion

Adding extra rewrite rules is not that complicated as you can see from this practical example. Depending on what you need, you need to learn (at least basics) PHP regular expressions and to make sure that query for the rule has sufficient number of variables to correspond to the number of capture groups in the regular expression. If you don’t want to lose time over this, and you need these extra rules, get yourself GD Custom Posts And Taxonomies Tools Pro and add new features with just a few clicks.

Some plugins settings panels are updated a bit, new option for always embedding JS and CSS added to the same block of settings with information about it. Plugin will still require plugin version of bbPress 2.0, and it can’t work with BuddyPress built in bbPress forum. These two versions of bbPress are not compatible. Plugin FAQ and requirements are updated.

As always, if you notice any problems, please report them in the comments or in the forum. All suggestions are welcome.

Plugin Links:

GD bbPress Attachments Home Page
GD bbPress Attachments on WordPress.org

If you still have problem adding images for products, clear the cache in the browser to make sure that latest version of the JavaScript is loaded. Please report in the forum any other problems or bugs you find. Also, suggest features for future versions, and if you need, tutorials about any subject related to plugin use.

New GD CPT Tools Website Front

GD Custom Posts and Taxonomies Tools has got his own dedicated website. Similar to GD Products Center, website uses Xposed theme (with xScape Theme Framework), contains plugin information, pricing & purchase options, blog, support information and much more.

New website has blog that will be used to announce special deals, new versions or anything else important related to the plugin. Plugin pricing and purchase page is also available, with several more plugin information pages (support information, system requirements…). Also, several pages with features overview are prepared. Contact form is also there. And, if you want to see plugin in action, small demo is set up for that. If you want to try plugin before buying you can request demo website through contact form here also and through contact form on GD Custom Posts and Taxonomies Tools website.

Plugin support and download access is provided on Dev4Press even if the purchase is made on the plugin own website.

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.

newsScape is improved and GD Products Center Pro styling added for custom colors styling too. Both airScape and lightScape includes several fixes and styling improvements and also improved maintenance mode template for GD Press Tools Pro. xScape Core and Framework include number of improvements and fixes, including updated gdr2 shared library. Some deprecated functions are replaced, banner display improved and some missing translation strings added.

WP 3.4: Theme Customizer

Theme Customizer

Old theme preview feature is now gone, and it is replaced by customizer. It will open a theme for preview (new window/tab in browser) and it will show the sidebar frame where you can change few things. This works with any theme, but if your theme doesn’t have direct support for features supported by customizer, you will see only options to change front page and site title. Themes like Twenty Ten and Twenty Eleven will allow changing background, header and navigation.

This is interesting feature that is few years too late. All good WordPress theme (all premium and most of the free ones), already have their own frameworks, their own settings and customization panels. They all have so many customization power that using the Customizer is really pointless.

Theme searching is improved (again), making a very useless option a bit better for some reason. It can get themes from WordPress.org only, and that’s it. For most users it is completely useless. How many times users really change their themes? So much time is spend on making things in WordPress Core that will be used very, very rarely. Most WordPress websites use custom themes, or premium themes anyway.

Improved Localization

Translation files are split differently than before to allow for better flexibility and to have performance improvements when loading translations. There are many small improvements to localization, and all that is aiming to make WordPress easier to translate. Detection of RTL languages is improved also.

Themes API & Other minor improvements

Old set of functions working with themes is now completely replaced with new API to deal with themes. All old functions are now deprecated. New API relies on class that are now easier to use and most importantly aim to improve WordPress overall performance. Problem with all this is that if you use old functions in your plugins, you need to continue to use them for compatibility with old WordPress versions, making new API pretty much useless as long as plugins must be backward compatible.

There are some multi site improvements added with installation and searching, images captions support HTML now, XML-RPC is improved and comments management works from the post editor. But best features in this version is the click on empty part of toolbar, that scrolls screen back to the top.

How does WP 3.4 Beta 1 feel?

One of the things announced for this version is speed improvements and lower memory usage. But, with this current beta 1 that is not the case. I did some preliminary testing, and WordPress 3.4 Beta 1 uses 2-4% more memory than WordPress 3.3 did and 3-7% more than WordPress 3.2. As for the speed, situation is similar and WordPress 3.4 Beta 1 is slower than earlier versions of WordPress. Right now, I am hopping that this is only because we have just entered beta stage, and that in the next month leading to release of stable WordPress 3.4 this will improve. If things stay the same as they are now, it is not looking good from performance standpoint.

Other than this, WordPress 3.4 is in normal use, the same as previous WP 3.3. If you don’t get to change your theme you will not even see the only new feature in this version. I bet that only thing you will use all the time is click on the toolbar.

Conclusion

If the development of WordPress Core was done right, 50% of the features in this version would never been made at all, and the other 50% would be only a small part of much better release that would take a year or so to make, and not be rushed in couple of months. But, as it looks right now, we will continue to get new WordPress every 4-5 months with features that are rarely used. Right now I only hope that WP 3.5 will get at least some changes to media manager, I have lost hope on seeing some really important things any time soon.

Have you tried Beta 1 yet? Leave the comment with your experience with it.

Built In Select Type Functions

Right now, 3 functions are added to fill the data for the select type custom fields: Countries, Continents and Months. You can see this on the image on the right, with the select type field method set to function.

There was a problem with templates location for custom post types in some cases, and this is now also fixed.

If you notice any more problems, please leave comment or report them in the forums.

Over the past few years, Google has developed a way to improve SERP display with additional information through rich snippets. GD Star Rating already uses snippets for ratings, and I have already announced that products snippets will be added to GD Products Center. First part of this implementation is now available, and activated by default. Snippets will be used only on main product page and plugin can use markup specific to Google or to Scheme.org implementation used by Bing and Yahoo too. Right now, product name and image are marked in the snippet. Next few versions will include: description, categories, brand and few more things.

New specification property is added: Link, for email or web URL. It has default settings (main plugin settings) for target and rel attributes, and in product editor you can specify link/email, title to use (if empty, it will use link value) and rel attribute. To improve usability of Select controls, plugin now can load and use Chosen.js library. And, a new shortcode is added to generate comparison page link: gdpc_link_compare.

jQueryUI, gdr2 and gdT3 libraries are updated to latest versions, some obsolete JavaScript code removed, and link shortcode expanded with REL attribute. Bugs fixed: problems with some of the rendering functions, broken preview of images in the product editor and broken compare URL’s for the GD Press Tools Pro sitemaps generator.

Please report in the forum any problems or bugs you find. Also, suggest features for future versions, and if you need, tutorials about any subject related to plugin use.

Taxonomies terms filtering can be done only for taxonomies that are registered as public, and have set query variable. Query variable is the same as taxonomy name by default, but it can be registered to be anything as long as it is clean and URL safe (query variables are used in URL, so they can’t contain empty spaces or special characters). For instance, default WP taxonomies – category and post tags have query variables - category_name and tag.

URL Query

Taxonomies query variables can be used in URL like this:

// archive for category with name 'news' //

http://www.example.com/?category_name=news

// archive for category with name 'news' and post tag with name 'latest' //

http://www.example.com/?category_name=news&tag=latest

You can use more taxonomies in the URL like this, and you can even specify multiple terms separated by comma. But, the more terms you try to filter, number of posts will be smaller, and if you specify filter that gives no results, you will be redirected to 404 page (or to empty archive with no posts message).

Override the WP Query

It is useful to be able to override already prepared query and add filters for terms. This way you can modify query for archives by adding additional conditions. To do this, you need to use ‘pre_get_posts’ action, and to modify query arguments with function attached to that hook. Here is the example.

add_action('pre_get_posts', 'example_pre_get_posts_simple'));
function example_pre_get_posts_simple($query) {
  $query->set('tag', 'latest,wordpress,video');
  $query->set('category_name', 'news');
}

This example will expand query with filters for 3 terms belonging to post tags (comma separated strings: latest, wordpress and video) and one term belonging to category. Based on this Query class will generate tax_query object that contains elements that will be used to filter posts by taxonomies you have set and taxonomies that were already in the Query object before you hooked into it with pre_get_posts action. You can even modify tax_query with this hook, but that is not recommended because parsing taxonomies will be done once again after pre_get_posts. Still, it can be done, but you need to make sure you preserve old tax_query variable before adding your own. Tax_query elements are much more complicated than the example above, and you can specify relations for the terms and you can specify terms with ID’s or name, not only slug. Third method bellow shows how to get posts using custom tax_query array.

Using get_posts function

This function has many different ways to filter using terms. Function get_posts has an array of arguments, and there is a long list of parameters you can use with it, so you can specify posts count, post type, tags, categories, post ID’s and much more. First few examples are simple ways to specify terms:

//use category ID:
$posts = get_posts(array('category' => 1));

//use category slug with category query variable:
$posts = get_posts(array('category_name' => 'news'));

//use category slug and post tags slugs for 3 terms:
$posts = get_posts(array('category_name' => 'news', 'tag' => 'latest,wordpress,video'));

You can add more things here including custom taxonomies, using query variables for those custom taxonomies. Full list of parameters you can use can be found here: WP Query Parameters.

Another thing you can do is to specify terms using tax_query array. This allows more flexibility in specifying terms. Tax query is actually array of arrays. Each array is to specify the taxonomy terms and it is in form of array that has few parameters of its own. Each tax_query array can have 5 parameters:

• taxonomy: name of the taxonomy, actual name, not query variable
• field: it can be slug or ID, and it is used to define what is used to specify terms
• terms: single ID or slug, or array with slugs or ID’s based on field parameter
• include_children: should the children of terms be included, only for hierarchical taxonomies, and by default is set to true
• operator: what operator to use in SQL query to link the specified terms: ‘IN’, ‘NOT IN’, ‘AND’

So, here is the example with two taxonomies:

$args = array(
  'tax_query' => array(
    array(
      'taxonomy' => 'post_tag',
      'field' => 'slug',
      'terms' => 'latest,wordpress,video'
    ),
    array(
     'taxonomy' => 'category',
     'field' => 'id',
     'terms' => 1
    )
  )
);
$posts = get_posts($args);

This will filter posts using 3 terms for post tags, specified by slugs, and by one category specified by ID.

There are a lot of possibilities to filter posts by multiple taxonomies and multiple terms. You need to choose method which works best for you, depending on what you need to do and how to filter posts, and be careful with listing multiple terms: more terms in the filter, the less posts you will get, or you will get no posts due to number of filter rules, and you can get to 404 page with no results.

So far, plugin core is ready, and the goal now is to work on the user interface for next Alpha #2 that will be released to public during this month. Once the Alpha stage is done, plugin will go to final release soon after with maybe one Beta and 2-3 release candidate versions. I can’t talk dates now, but once the Alpha #2 is released I will have precise release date for the plugin.

Current tests show that plugin needs only about 1.0 to 1.5 MB of memory (current 1.9.16 needs up to 5 MB), and it is very fast. CSS and JS files are very clean and simplified allowing great flexibility and CDN compatibility (current 1.9 branch wasn’t CDN ready due to complex CSS file). Code is modular and will allow for great expanding possibilities starting with modules that will be built in (bbPress and BuddyPress), or commercial modules later.

During this month, I plan also to build new website and to retire old one under a subdomain installation for archive purposes. New website will be dedicated to 2.0 version only. So, stay tuned for more news and soon several screenshots. Great thing now is that plugin is nearing the release and this internal testing period will provide me with valuable information to make next Alpha a public release.

Permalinks Examples

To make permalinks settings easier, plugin includes 5 examples you can use with one click (similar to WP Permalinks panel). This can help you to create the permalinks you like for custom post types. To further improve archives intersections, plugin now has option for partial advanced rules. If you set advanced structure to use 4 taxonomies, partial option will generate additional rules for 1, 2 and 3 taxonomies also. This option can generate a lot of additional rules, so be careful with it, it can generate conflicts.

As for the custom fields, new one is added to handle email or web URL. When displayed in front end it will be turned into link. Shortcode and plugin field function have additional settings for it. 3 existing select custom fields are merged into 1 with additional options to make using it easier. To make select custom fields easier to use, plugin can load and use chosen.js library. You need to enable both inclusion of the library and using it for different select versions from the plugin newly added Settings/Meta Boxes tab.

If you notice any more problems, please leave comment or report them in the forums.

Plugin code is optimized for better memory usage on both admin side and front end. Plugin now uses half the memory it needed with previous version. Fixes in this version include the problem with logging multiple upload errors with same error type and many issues with displaying upload errors. Also, new option to allow forum moderators to see logged upload errors is added.

Options to delete attachments

But, most important new feature is set of options to delete attachments from topics or replies. You can delete or detach (leave it in media library, but no longer with the topic or reply) attachment, and you have options to control what can administrator, moderator or topic/reply author do to delete attachments.

Beside that, few more filters are added for better control of the plugin operations (soon available in documentation). If you notice any problems, please report them in the comments or in the forum. All suggestions are welcome.

Plugin Links:

GD bbPress Attachments Home Page
GD bbPress Attachments on WordPress.org

On my part, I have expanded some of the rendering functions with additional arguments to allow for more flexibility in rendering control. I have also expanded a bit on some of the changes submitted by Galen. Everything else is contributed by him, and that includes many fixes and improvements: Several new actions and filters for AJAX and rendering functions, static directive added to functions in some classes (as always, plugin requires PHP5), conditional loading of debug version of plugin JavaScript rating file. Several potential undefined warnings are fixed, deprecated wp_specialchars function replaced with esc_attr and esc_html and replaced deprecated fetch_rss function with new fetch_feed function.

Most of these changes are here to minimize number of warnings that are usually issued in debug mode due to use of old functions or undefined variables and to improve few of the plugin features. No new features or major changes are added for a while now, and with soon to be released GD Star Rating 2.0, goal is to keep old plugin version up to date until that happens.

Once again, big thanks for the contribution goes to Galen Wright-Watson: sublimitywebdesign.com.

For a full, current roadmap you can check it here. The list is not complete, and things tend to change, and I am sure that each version will have more features than planned. As for the upcoming 3.6 version, it will include several new features:

1. Custom Field Select will be updated and different select fields replaced with one. Plugin will add chose.js jQuery library for easier selection of values.
2. Custom Field URL will be added. When added with shortcode, it will allow additional options for styling and linking without need to add A tag.
3. Custom Post Type rewrite rules will get a list of default values to get started with custom permalinks faster, similar to default post Permalinks in WordPress.
4. Intersection archives rewrite rules will be improved to have additional terms combinations for additional links flexibility.

Few other minor things will be included. If you have any suggestions for simpler changes, please leave comment. But, goal is to have this release out quickly, so anything too complex will be pushed to next release cycle. Version 3.6 will be released by the end of this month.

This article explains what happens when WordPress resolves URL request that uses pretty permalinks. This article doesn’t include examples with creating custom permalinks structures. I am planning to have additional articles to cover that.

By default, pretty permalinks are disabled in WordPress. Reason for that is that in some cases they can’t be activated without user intervention. For pretty permalinks to work, WordPress needs access to .htaccess file (if on Apache server) where it needs to add few lines that are base for the rewrite engine in WordPress. And that also requires Apache mod_rewrite module. This module is part of Apache installations and it is very rare that it is missing. Code added into htaccess file basically redirects all URL’s to WordPress index.php and that allows WordPress to break URL into parts and using regular expressions detect what content to display.

WordPress supports also PATHINFO permalinks that don’t require mod_rewrite module, but permalinks in that case must start with index.php. More info on this you can find on the WordPress Codex Permalinks page (links are at the end of this article). There are some setup differences in using permalinks for Apache, IIS or other servers, but they can work with any of the currently available servers for Windows, Linux or MacOS.

So, basic thing to activate rewrite engine in WordPress is to enable permalinks from WordPress Settings/Permalinks panel. If it is set to Default, permalinks are disabled, any other value they are active.

Why do you need these permalinks?

Well, there are many reasons, and most important reasons are SEO and that they look much nicer and user-friendly than long query strings in URL. Especially if you have complex website structure. Search Engine Optimizations benefits from permalinks, because they contain more relevant information about the content, and most search engines have a use for that when indexing websites.

Older versions of WordPress were known to work slower because of some permalinks structures that required additional SQL queries, but since WordPress 3.3 most critical permalinks structures are optimized and there is no performance penalty if you use post name only in the URL. Even with older WordPress versions performance was affected with only some structures and with large number of posts.

Permalinks are a must in a website, and very few WordPress websites don’t use it (mostly default installations, left with permalinks disabled). What to choose for permalinks is another matter.

Default permalinks settings

To quick start using the permalinks, you can select one of the predefined rules from Permalinks panel. Also, you can see Custom Structure field where you can create structure you want. What this panel doesn’t say is that those rules are only for posts (default post type: post). WordPress allows you to customize only this post type rewrite rules, nothing else! Pages in WordPress always use same rewrite structure: only sanitized version of the page name. And, that is the rule you can’t change. For archives, Permalinks panel offers only two settings: what to use as a base for category and tags archives.

Beside this, there are plenty more rewrite rules that WordPress will not allow you to change (well, not directly anyway). These rules include: archives for authors, date base archives, attachments, feeds, custom post types, custom taxonomies and generic archives.

When you create rules on the Permalinks panel, you don’t need to handle regular expressions, but you can use special tags to form the URL. By default, WordPress uses several structure tags (full list in the Codex, check the link at the bottom). If you use these tags in the URL they will be replaced with actual data. If element in the URL is not recognized, it will be left like that as a part of URL. This way you can add static parts of the URL.

Most things in WordPress use more than one rewrite rule. To resolve year based archive, WP needs separate rules to match: basic year archive URL, URL with page numbers and feed URL. Some things need more than 3 rules, for a post you need 5 rules.

Resolving rewrite rules

To resolve URL, WordPress uses a list of rewrite rules. Rules are based on regular expressions, and each regular expression in the list points to a query based URL. For instance, here is the rule to resolve author archive feed:

Regular Expression: author/([^/]+)/feed/(feed|rdf|rss|rss2|atom)/?$
WP Resolved Query: index.php?author_name=$matches[1]&feed=$matches[2]

I am not going to go into how regular expressions work, but URL is matched against all regular expressions in the rules list, until we get a match. When URL is matched against expression, query for that expression is than used to resolve requested URL to a query based URL. In the query in example above you see $matches[1] and $matches[2]. These are values detected by regular expression from requested URL. These values are URL parts marked with ‘(‘ and ‘)’ in the regular expression. So, if your URL is this:

http://www.example.com/author/admin/feed/rss/

Website URL part is removed, and we get the request:

author/admin/feed/rss/

This is what WordPress than matches against the rewrite rules, it will match it against our example expression above. Words ‘admin’ and ‘rss’ are matched/extracted from regular expression, they are replacing $matches[1] and $matches[2] and resolved query based URL is now this:

index.php?author_name=admin&feed=rss

And this is something WordPress can use to prepare page, load template and data for it. This final query is used to create WP Query object that is ultimately used to get posts for that request.

If all rewrite rules fail, the last rule will always resolve. This base rule resolves any request to a page request. If that page is not found, you get 404 error. If the URL is resolved by some rewrite rule, and the WordPress Query doesn’t find any results to match, again you will get 404 error.

Custom rewrite rules

If you need to customize URL for posts, you can use Settings Permalinks panel and do it from there. But, anything else you must do it through code. WordPress 3.0 added support for custom post types, and there is one very important thing missing: custom rewrite rules for them. All custom post types by default have same URL structure that includes name for the post type and name for the post. Same thing goes for the archives for the post types, or date base archives. Nothing can be customized without custom coding.

But, there is even more important use for custom permalinks. Each URL is resolved to a query that WordPress uses to get posts. So, date based query and URL filter posts by the date. If you request this:

http://www.example.com/2012/03/

You will get all posts published in the year 2012, in March. And if you want to get all posts belonging to custom post type movie, you can use this:

http://www.example.com/movie/

But, what to do if you want to get all posts for custom post type movie for 2012? You would like it to be this:

http://www.example.com/movie/2012/03/

But, there is no rule for that in WordPress and this will not work, so instead this elegant link you must use only this:

http://www.example.com/movie/?year=2012&monthnum=3

Anything that is part of the URL: resolved by WordPress or added like here with direct query element is used in WordPress Query engine to get posts. There are many examples where additional rewrite rules can make a big difference in getting cleaner links.

Most important thing is filtering posts by post type and taxonomy. Normally, you have URL that filters posts by post type or by taxonomy term. If you want to mix those, you need to use query elements. So, if your movie custom post type has taxonomies category and genre, to filter by both with URL you need to use something like this:

http://www.example.com/movie/?cat=short&genre=animated

But, what if you can do it like this:

http://www.example.com/movie/short/animated/

That would be great, and if you have more taxonomies you can have more terms listed like this, one term for each taxonomy. But, again, this can’t be done without using custom coding to implement additional rewrite rules and you can’t use such links…

GD Custom Posts and Taxonomies Tools Pro

…Oh wait, you can!

Ever since custom post types are added to WordPress, I used them for many things, and I always hated limitations with permalinks. So, I started adding customized rewrite rules with my GD Custom Posts and Taxonomies Tools Pro plugin. Plugin now allows fully customized single post permalinks for custom post types (just like for default posts), date based archives for custom post types and archives with intersection of custom post types and taxonomies. All that without any additional coding, just by setting rules for each custom post type you add through this plugin.

Check out this tutorial with examples to see what can be done with this plugin and custom post types. All this is used on Dev4Press for Central Documentation and Feature of Day sections to filter posts by terms. I have few more ideas for additional rewrite rules and more customizable links structure.

Canonical Redirect

This is very interesting and useful (usually) feature. Sometimes, WordPress can partially match the URL depending on the rule. Than, it will find what URL should resolve to, and than generate proper URL for it, and redirect to it. So, you request one URL, and that gets replaced with some other URL. If you use category taxonomy in the URL, with hierarchy ending with post name like this:

http://www.example/parent-category/child-category/post-name/

If you make this request:

http://www.example/parent-category/post-name/

WordPress will find the post it needs, and than will determine that URL is not canonical as the rewrite rules require it to be, it will than generate full URL and redirect to it. But, if you don’t want this to happen, or you have additional rewrite rules for the post, canonical redirect will ignore all that and will redirect to URL it decides is correct. In that case, you must disable canonical redirect. To do that, you can use this PHP code:

remove_filter('template_redirect', 'redirect_canonical');

Conclusion

Handling custom rewrite rules is not easy, and very often you will run into conflicts. If you try to use same regular expression for your rule, you will remove default rule that was using same expression, and that will most likely break something. When working with rules, it is useful to have list of all rules in the system. You can see this list with GD Press Tools Pro debugger, or you can use few functions (check the debug rewrite rules tutorial, link at the bottom).

WordPress rewriter is very powerful, but by default it uses only a fraction of what it can do, since only basic rules are implemented, and if you need more, you must write code for that. The goal was to keep things simple in the core, and to allow freedom to customize things if needed. Not everyone will need so complex rewrite rules, and basic ones are enough. If you need more, you need to dig deeper or to use specialized plugins to achieve that.

Single Product Discuss Page

Single product now has another page called Discussion. Right now you can integrate topic from bbPress 2.0 powered forum, but you can override default function and integrate some other forum or something else. Two templates are added for this page type.

When generating product pages links, plugin can remove links for related or discussion pages if there are no related products set or discussion topic ID set. There are options for this on the plugin settings panel. When you want to delete product type, you will now get confirmation dialog first.

XML Sitemaps Settings

Plugin also adds basic support for XML sitemaps expansion. Right now plugin starts with support for GD Press Tools Pro plugin and adding of special pages and compare links. This will take some time to finish, and in the next couple of versions it will be expanded further. Be careful with the compare depth, it will significantly increase number of links in the sitamap, for 1000 products, depth of 3 will give you 500.000 links. If you choose compare from database only, this will include links to compare pages visitors actually compared. Major change is introduced into specification property types. All different select types are merged into one Select type with additional settings to select selection type and values method that now has associated arrays.

Please report in the forum any problems or bugs you find. Also, suggest features for future versions, and if you need, tutorials about any subject related to plugin use.

During this whole month, we have a very special deal: Buy GD Products Center Pro and get another of Dev4Press plugins for free. Also, for first purchase each day, a bonus theme will given completely free. More information is available on this page:

Buy GD Products Center Pro and get another plugin for free

During April 2012, plugin official website will go through changes. Current website will be moved to a sub-domain for archive purposes. New website will be created during the plugin development, after Alpha phase is done. As it was announced before, new plugin will not be compatible with old one. New plugin will feature conversion tools to copy data to new format. Old functions will have equivalents in the new plugin.

Main plugin features

This is the list of the features that will be part of the plugin. This is not definitive list, things can change quickly during development and new things can be added to this list.

1. Four built in rating methods: standard stars and thumbs, multi stars and thumbs. Multi thumbs is new rating method, similar to multi stars. All four methods can be used for rating posts, comments, users and any other rating object. Plugin will allow for adding of new rating methods.
2. Rating objects are main part of the plugin. Built in main objects are: post, comment, user and free. Secondary expanded objects are page and attachment. Plugins and themes can register additional rating objects for all kinds of purposes. Each object can be based on one of the main objects, or you can write a whole new objects to use. Modules will be available to add rating objects for bbPress and BuddyPress plugins.
3. Each rating object has following properties: vote, revote, insert, limit, restrict, moderate. Each of these can contain multiple set of rules for each rating method. This will allow for very fine tuned ratings display and control.
4. There are three rating classes: rating, author review and user review. Rating is open to everyone, author review can be set only by the post author (this rating class is available only for rating objects that have author) and user reviews can be used with comments system to provide user comments with rating for a review based websites. User reviews are not class of ratings, and in previous 1.x versions this was handled by normal ratings.
5. Changing saved votes/ratings. This will be available only to logged in users (no way to make certain determination of non logged visitors).
6. Improved Google Rich Snippets integration with snippet code added into rendering templates. Tis integration method will be much closer to what Google recommends.
7. New templates gdT3 system. This system is already in use for GD Products Center Pro plugin and is allowing a lot more flexibility including use of PHP inside the templates. Templates will be stored in files and will allow overriding and adding new templates.
8. GD Custom Posts and Taxonomies Tools Pro integration. Easy to use option to include registration of custom post types as independent rating objects.
9. GD Products Center Pro integration. Each product will get own rating object, and plugin will add what is needed into templates for ratings for products and reviews.

Database Structure

Plugin will use completely new database structure with only 6 tables (current 1.x plugin needed 12 tables). Plugin data structure will not be compatible with the old plugin.

1. One table is used to log all rating activities, regardless of the rating method or object.
2. Standard stars and thumbs ratings will be stored in two tables. One of these tables will be main table for individual rating elements, and the other one is for meta data about ratings.
3. Multi stars and thumbs will need 3 tables. One is main, one is for elements values and one is for meta data about ratings.

Modules

Modules will be available as part of the plugin that can be enabled if you need it, or as external plugin that GDSR 2.0 can use. External modules that will be published by Dev4Press will be commercial. If you have Premium Support license, some of these modules will be available as a part of that Premium package. If you don’t have premium package, purchase of a module includes support for that module, and access to module updates.

Internal Free Modules

1. bbPress. Simple module that will register rating objects for forums, topics and replies with some options about placing the rating elements and allowed types of ratings. This module will be free and part of the main plugin package.
2. BuddyPress. Another simple module to add rating objects for the different BuddyPressfeatures. This module will be free and part of the main plugin package.

External Commercial Modules

1. Badge. First module will be developed in the same time as the plugin will be for rating image badge. This will allow you to create image with rating that can be embedded on third party websites. Module will support customized base images, caching of images, rewrite rules for badge paths… This module will be available to users with premium support license.
2. Trends. Additional functionality to calculate rating trends and include them with different rating results, will be part of this modules. This module will be released at a later date and it will be available to users with premium support license.
3. Rating API. This module will be released later (hopefully by the end of this year), and it will not be available as a part of the Premium Support License. With this module you can publish ratings through API using XML or JSON formats. API can be configured to use authentication, what data to make available…

Graphics packs

Main plugin will contain one stars and one thumbs graphics set. Anyone can create additional sets. But, to make things easier, sets can be purchased. If you have Premium Support license, all graphics packs will be available as a part of that Premium package. With the help of few designers we will try to offer high quality graphics packs, and first such pack will be available by the time plugin gets stable release.

Several changes are made to the way external URL’s are added, and also, empty sitemap files are automatically removed. Fixes include: external build sitemaps now are executed properly, last modification date parameter missing from URL’s, saving and updating sitemaps content settings broken, sitemaps builder ignoring inactive content elements and several warnings during the build process.

To make sure all is OK, recheck and save all sitemaps settings. As always, please report in the forums any bugs you find, and I will get on fixing it.

New jQueryUI library should be fixing some issues with latest versions of Google Chrome browsers. As always, please report in the forums any bugs you find, and I will get on fixing it.

One of the main objections with old plugin, was a large memory footprint. Old plugin structure was written and updated over the period of two years, with many elements added on top of other elements, and that was causing higher memory usage. Old plugin started very simple and it grew from there. This time, GDSR 2.0 is starting very differently, and it has powerful core that can be expanded for any rating purpose.

New Multiset Editor

Base of the plugin is created using gdr2 shared library that handles main plugin classes, settings and settings forms rendering. This is already proven concept from GD Products Center Pro, and all future Dev4Press plugins will use similar approach. To render on frontend, gdT3 library is used (same as for GD Products Center Pro). On top of the plugin base code, there is rating core. Core is very modular, with base classes containing most of the code. Individual rating types are extending base classes to add additional features they might require. On admin side, plugin will use between 1.0MB up to 1.5MB. On front end, this should be about the same, depending on how many rating elements are displayed on the page. That is about 4 times less than with old plugin. Plugin needs only 6 database tables to store all the data. Plugin will use meta approach to store data, and that will help to accommodate different needs for different rating types.

First Alpha version will include following rating methods: Free (you can rate anything as long as you provide unique ID), comments, users, posts and pages. But, before Alpha is released, GD Custom Posts and Taxonomies Tools Pro will have support to register rating objects for each custom post type added by the plugin. Similar support will be added to GD Products Center Pro for registered product types.

That is all at this moment, I will have more information soon. Current target date for GDSR 2.0 Alpha is March 29 2012.

newsScape Specific Styling

Xposed and R8 are updated with some changes to color styling for GD Products Center Pro plugin. newsScape has new styling added for the GD Products Center Pro plugin. There are no other changes in these versions, and more themes soon will get similar styling changes.

I am a bit behind with adding GD Products Center Pro specific styling, but more themes will be updated soon.

Updated Settings Panel

To improve the comparison widget, there are many changes introduced. Option is added to allow display products in the widget with links to product pages, better control for the options in the widget (hide compare widget for one product in the widget only), showing product titles. Functions to generate URL for product now can properly detect if the product has alternative URL set. Also, a filter is added for this function to allow further modification for the URL. Main settings panel is changed a bit, with one more tab for options added. Also, a potential bug is fixed (caused only with some versions of jQuery library): tooltip JavaScript handling code was added before qTip2 is loaded, and now that is changed.

Please report in the forum any problems or bugs you find. Also, suggest features for future versions, and if you need, tutorials about any subject related to plugin use.

During this whole month, we have a very special deal: Buy GD Products Center Pro and get another of Dev4Press plugins for free. Also, for first purchase each day, a bonus theme will given completely free. More information is available on this page:

Buy GD Products Center Pro and get another plugin for free

During this month, we offer you a very special deal: Buy GD Products Center Pro plugin and get another premium Dev4Press plugin for free. And, to first purchase every day we will give one xScape Theme Framework powered theme for free.

If you buy GD Products Center Pro during this month, you can get completely free one of these plugins:

1. GD Press Tools Pro | plugin info
2. GD Custom Posts and Taxonomies Tools Pro | plugin info
3. GD Affiliate Center Pro | plugin info
4. GD aZon FUSION Pro | plugin info
5. GD Simple Widgets Pro | plugin info

And, to first purchase of GD Products Center Pro plugin every day, as a bonus we will give completely free one theme based on xScape Theme Framework. Start of the day will be considered to be midnight in the CET time zone (UTC+1).  Bonus will be available only if you made a purchase without using any discount codes! If you have a valid discount code, and you prefer to get discount, use the code, but you will not get bonus plugin (and theme).

So, if you buy GD Products Center Pro Standard Lifetime license, bonus plugin will be also with Lifetime license. If you buy one of the annual recurring payments licenses, same license will be used for bonus plugin. Bonus plugin license will remain active as long as your GD Products Center Pro license is active. So, if you get recurring license, and you stop payments after first year, both plugins licenses will be deactivated.

How to get bonus plugin (and theme) for free?

It is very simple, and here are step by step instructions:

1. Buy GD Products Center Pro. You can initiate purchase from this or official plugin website. Make sure NOT to use discount code during the purchase.
2. Once the purchase is processed, you will get normal email confirmation from Dev4Press.com. Get Purchase ID from this notification.
3. Go to Dev4Press contact form page (set Feedback Type to Promotion) and send us the message using email you used for purchase, include Purchase ID and name of the plugin you want to get from the list on the top. To get the plugin, you must do this during this month, while the deal is active.
4. Chosen plugin license will be added within 24 hours since you send the message through the contact form.

That’s it. We will add new plugin (and theme if your purchase was first for the day) to your account on Dev4Press. Please, follow the rules listed here, we will not give plugin if the rules are not met and that especially goes to use of discount coupons. If you use coupon, you can’t get extra plugin for free.

Last day to get this deal is March 31 2012.

For a while there was one minor issue that was getting rather annoying in debug mode: plugin was using old user levels system to display menus and do few other things, generating warnings. Now, I have finally switched that to using user roles and capabilities, and all those deprecated warnings are gone. There was a problem in the main plugin CSS file that is now fixed, thanks to Emil Sirbu for noticing and sending fix.

New panel is added called GDSR 2.0. This panel will be used to give information about upcoming GDSR 2.0 and changes required for everything to work. So far only a small notice is displayed, with more information coming soon.

GDSR 2.0 Alpha #1 is coming in late March 2012. Plugin will be available for download only on Dev4Press and official GD Star Rating websites. Plugin will be added for update to WordPress.org Repository once it reaches Stable stage, and that will take another month or two depending on how tests go.

1. Improvements to backup and restore. New set of backup features will include adding sites from backup into multisite network, and will allow you to export site from network into a standalone website. Restore script will be improved, and parts of it will be added into main plugin code to allow for adding sites into multisite network.
2. More HTACCESS tweaks. There are number of new tweaks and options related to HTACCESS that will be added to help with the website security. The list of these tweaks is not yet finalized.
3. Expanded comment SPAM features. This is still not finalized, but I have several ideas on how to improve security with improvements to SPAM detection. Few methods will be available and they should be as automated as possible to reduce the need for moderation.
4. Logging actions into database. Set of features that logs the users activity on the website will include a wide range of interactions like profile changes, activities defined by plugins through filters and functions use.
5. Full set of SEO features. Powerful SEO module is coming, with options to control titles, meta tags and descriptions for all sorts of pages on your website.
6. Dynamic XML Sitemaps. Right now sitemaps are generated as static XML files. But, in multisite environment, this is not a good method to use considering how many files you will need to keep. New method will allow to generate sitemaps through WordPress with method similar to feeds.

As I said, this is preliminary list, and more minor features will be added to 4.5. If you have any suggestions, please let me know through comments here or in the support forum. GD Press Tools Pro 4.5 will go into development in late March, and is expected in May or June 2012.

One of the problems with the deleting of replies was that attachments for deleted replies were automatically moved to topics (WordPress does that for all hierarchical post types). Now, there are options to control this, and you can have attachments deleted also, you can leave attachments in the library, but they will be no longer attached to topics or you can leave things as they are now. New option is added to hide attachments for visitors. They will not see attachments until they are log in, and they will see such message only. This option can be overridden for individual forums.

Also, detection of bbPress pages (forum, topic or reply) is improved and additional JavaScript and CSS should be added on all these. Automatic adding for these works only on pages generated by plugin, if you use shortcodes or functions to embed forum elements into unrelated pages, this will not work. But, there is a filter that you can use from the code to change this (filter name is: d4p_bbpressattchment_is_bbpress). Filter parameter is a boolean: true if the page is detected as bbPress page. To make CSS and JS embedding work, this check is executed in WordPress wp_head() hook.

As for the bugs, only one was reported and fixed: meta settings for forums were visible to all users. This is now changed, and only admins can see and change those settings. POT file is also updated, so all translators should update translations, and they will be included in next minor revision of the plugin.

If you notice any problems, please report them in the comments or in the forum. All suggestions are welcome.

Plugin Links:

GD bbPress Attachments Home Page
GD bbPress Attachments on WordPress.org

There are two major features in this version. First on is for alternative URL. If you use plugin rendering to embed products specifications into the posts outside those controlled by the plugin, problem is that products URL’s will still point to actual products, not your posts. But, that is not changed, and you can specify alternative URL where plugin will link the product. This alternative can be actual full URL or post ID. You can specify it for each product on its edit page in the meta box for product settings.

Tooltip Example with qTip2

Second major improvement are tooltips for properties. Before this version each property had description that was displayed in the product edit page to instruct about creating specification. Tooltips are displayed on front end. To make things look good, plugin includes qTip2 for jQuery to render nice looking tooltips. Tooltips are explanation of product specification properties, and you can see how this looks on the image on the right. If you don’t want to use extra qTip2 library, it can be disabled and plugin can show simple browser based tooltip only. Or you can add your own JavaScript and handling functions to change how tooltip is displayed. Tutorial on the customization for tooltip will be published tonight.

New Product Type from Templates

I get many questions about things you can do with this plugin. You can use to to manage and compare any product types that you can describe through properties specification. To make this easier to set up, another 4 product types templates are added: one is for WordPress themes, and the rest are for hosting plans (shared and VPS) and cell phone plans. These can serve as a good example and starting point on how to set up your own product types.

Three bugs are fixed in this version: checking settings for JavaScript and CSS inclusion and problem with saving some of the plugin settings and some minor issues with few rendering tags are taken care of.

Please report in the forum any problems or bugs you find. Also, suggest features for future versions, and if you need, tutorials about any subject related to plugin use. So far, 12 tutorials are published and another 2 or 3 are coming this week.

XML sitemaps generator has been improved to generate archives links differently and eliminate links to non existing date archives pages. Also, broken filters execution for extra URL’s in sitemap is fixed. This will help to add a new features in GD Products Center and GD Custom Posts and Taxonomies Tools plugins to expand the sitemaps.

Adminbar/Toolbar toggler is improved, and now it can be used to hide toolbar even in WordPress 3.3 by setting toggler position to negative value. This will only hide toolbar, it will be still part of the page only invisible. New gdr2 library is included.

As always, please report in the forums any bugs you find, and I will get on fixing it.

In Development: GD Press Tools 4.5

List of features that will go into next major 4.5 version are almost done, and I will announce it officially next week. Current 4.3 version is now in a branch for bug fixes while 4.5 is in development.

Links and Resources

To see the list of plugin features, overview and to buy the plugin, visit these pages:

GD Press Tools Overview
GD Press Tools Main Page
GD Press Tools Frequently Asked Questions
Buy GD Press Tools Pro

New hierarchical tags are listed on plugin options page to be used in the title and description for various page types. Be careful using them with deep hierarchies, since they will generate additional SQL queries to get all ancestors in the hierarchy. New tags are added for pages, category and custom taxonomies.

Updated Toolbar Menu

Toolbar plugin is updated to include settings for notifications displayed in the menu item, and now also can display notifications about Gravity Forms updates. Some of the toolbar menu items are changed and link to Gravity Forms Toolbar plugin settings panel added.

Both David and I added many new things to the plugin, and there are a lot of interesting changes in this release. Notifications is expanded to include information about Gravity Forms update. Settings are also added to enable or disable notifications. Some of the toolbar menu items are renamed and updated with new items, including support for new Gravity Forms add-ons.

Plugin also uses the groups in the menu added in WordPress 3.3, updates to all screenshots, read me file and few other things. Serbian translation is added.

Plugin Links:

Plugin Official Home Page
Plugin Home on Dev4Press