Full menu options example

Gravity Forms Toolbar is created by David Decker for adding WordPress toolbar menu with Gravity Forms specific links and options. This can include help links, listing of registered forms and more. From version 1.2 I have contributed code for additional settings and features.

If you use Gravity Forms plugin, with this toolbar add-on you can add quick access links to various plugin pages, help, official and third-party add-ons/plugins and get list of registered forms with edit forms quick access, view entries quick access and notification for unread entries with the counter.

Plugin has panel with settings to control what elements in the menu will be visible, so you can make lighter menu if you don’t need everything in it.

I have contributed code for this plugin (settings and settings panel, listing of forms and count notification), and it is added to 1.2 version. From now on I will be co-developer and both David and me will work on it. You can use support forum on WordPress.org or on Dev4Press to get help, report bugs and suggest features.

David Decker is the author of multiple WordPress plugins and you can check out his website for more information about his plugins.

Plugin Links:

Plugin Official Home Page
Plugin Home on Dev4Press

Warning: Plugin is not yet completed, and it is not recommended to use it on the live websites. Right now, from all the planned features for 1.0.0 release, plugin is 98% done. If you have problems with missing templates or broken pages, please run Cleanup operations from the plugin Tools -> Maintenance.

Release: With all the new added features that were not previously planned, plugin 1.0 release is delayed a bit. Current target date is February 9 2012. Until than, one or two RC versions will be released to fix bugs. No new features will be added until than. If the number of bugs requires, plugin release date can be delayed for couple of days to make sure that plugin is released as stable as possible.

Importing and updating products from CSV file is completed, and export updated to include images, video links and links. Plugin can import images from given URL into the WordPress (there are exceptions and will not work with websites that use hotlinking protection). To make change for rendering templates easier, plugin now supports settings for the templates globally (for the whole plugin and all product types) and you can set this individually for each product type. You can still set it in the theme, and xScape Themes Framework will still use own method of setting these rendering templates. Also, one more theme got direct support: Mystique. This is for the full version of this theme that works with auto child theme.

In the next week video tutorials will be released: Import/Export with CSV file, Quick features overview, In depth plugin use, Themes support, xScape Themes Integration. Please report any bugs found, I am sure that some more are still in the plugin. Future plans for the plugin are updated and listed for the next 5 milestone versions. Other features can also be added, depending on what is most needed by the users.

Plugin Test Drive

If you want to try out the plugin before deciding on buying, use the contact form to request demo website set up for test drive. There you can try out all our plugins and themes.

Promo Coupon

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

Resources

Theme Templates Integration:
http://www.dev4press.com/2011/tutorials/plugins/gd-products-center/theme-templates-integration/
Product Type Editor:
http://www.dev4press.com/2011/tutorials/plugins/gd-products-center/product-type-editor/

Plugin Info

Planned Features:
http://www.dev4press.com/2011/blog/development/planned-features-for-gd-products-center/
Plugin Information:
http://www.dev4press.com/plugins/gd-products-center/
Editions & Purchase:
http://www.dev4press.com/plugins/gd-products-center/buy/

When you get to the checkout page on ShareIt, you will get the list of our other products with the same license type you can buy. Depending on the license type, you will see different discounts. For plugins with annual standard or developer licenses, discount is 15% for same license for other products, 10% for GD Star Rating Support License and 25% for xScape Themes Club Membership. For lifetime licenses, discount is higher by 5%. And if you are buying Dev4Press plugins pack or xScape Theme Club Membership you can get up to 30% discount.

Cross-selling Example

Lets say you want to buy GD Press Tools Annual Standard License. Price for that one is $89.00. But, on the checkout, you will see other plugins and themes with 10% to 25% discount. Image on the right shows this, and price for other products with same license type with you can add to the cart and get additional plugins or themes cheaper.

Discount depends on the first products added that got you to checkout page. Also, discount coupons you might have will not have effect on the price of cross-selling products.

Comments SPAM Control

New panel is on the image on the right and it is quite simple. You have a list of IP addresses and option to control action against them: prevent comments only or deny website access. To make adding of IP’s easier, you can enable control for it and new options are added to all comments on the admin side: Spam IP (and if it is already in the list Unspam IP). With this option you can go through spam or moderation list and mark IP’s used for some comments as spam, and they will be added to the list. Later, if you need to remove IP from this list, simply delete the row with the IP.

Spam IP option (if enabled) will be visible on the main comments admin panel and the dashboard widget with latest comments. If you decide to ban access to the website to spam IP’s, you need to enable HTACCESS deny IP option first, and all IP’s from spam list will be included also in HTACCESS file.

New Maintenance Mode Template

Other changes are for the maintenance mode, and this time there are more things that can be set and 2 more templates included (both named Simple, one Gray and other Red). A bug in the page title is fixed and more strings added to the settings for the maintenance (to control “we’ll be back” message).

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 in the next 2 weeks. Current 4.3 version will go into own branch for bug fixes while 4.5 is in development. Focus in 4.5 will be on: improved backup and restore, more security improvements, SEO features and actions logging.

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

There are no major changes this time. New context help and improved performance with several cosmetic changes. Also, starting today, old ‘classic’ themes versions will not be offered for install or update. xScape Core theme that is needed for all other themes will remain in themes box for install or update, all other themes will be listed under Core only. Fixed bugs include: problem with themes upgrade (no files saved when xScape upgrade backup was used), menu was not added properly for the network admin menu and some of the updates strings were missing.

As usually, this plugin is available to all users with any plugin or themes license. If you notice any more problems, please report them in the forum.

Download Updater:
http://www.dev4press.com/user/updater/

Support Forum:
http://www.dev4press.com/forums/forum/plugins/dev4press-updater/

Xposed with GD Products Center

Xposed and R8 are updated with color styling for GD Products Center Pro plugin (requires latest 0.9.7 Beta version of the plugin) and changes to GD Press Tools Pro maintenance mode template. Xposed includes several more fixes to the styling and missing RSS feed image.

All the other themes will be updated with GD Products Center Pro specific styling until the release of the stable version of the plugin. Maintenance mode template for all themes is also getting updated.

Demo Site:
http://xscape.info/

Warning: Plugin is not yet completed, and it is not recommended to use it on the live websites. Right now, from all the planned features for 1.0.0 release, plugin is 98% done. If you have problems with missing templates or broken pages, please run Cleanup operations from the plugin Tools -> Maintenance.

Release: With all the new added features that were not previously planned, plugin 1.0 release is delayed a bit. Current target date is February 9 2012. Until than, two more beta is coming early next week with import implemented and one or two RC versions.

New simple widget is added for searching products. You can fix product type to fix, or you can allow visitors to select the product type. For all products related pages, plugin is setting additional CSS classes so you can use for your own styling. New shortcode is added to generate link to products home page, archive pages and single products. Previous shortcode for embedding products is expanded to include class and style for the product added. Shortcodes are in the documentation.

Frontend rendering is improved further with new styling. Also, main rendering style file has all colors separated, and because of that you can use built in styling, and only change colors. All xScape themes will get color schemes stying for the plugin soon. And any other theme can use this to make styling easier. Updated Xposed and R8 themes will be released tonight with this new styling added.

As for the bugs, new version fixed the problem with missing theme templates controls, eStore theme integration templates are also fixed. Additional product pages linking was broken due to canonical rewriting problems. When plugin is updated, rewrite rules were flushed, but that was not working fine, this is fixed now. Many styling problems are fixed.

Please report any bugs found, I am sure that some more are still in the plugin.

Plugin Test Drive

If you want to try out the plugin before deciding on buying, use the contact form to request demo website set up for test drive. There you can try out all our plugins and themes.

Promo Coupon

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

Resources

Theme Templates Integration:
http://www.dev4press.com/2011/tutorials/plugins/gd-products-center/theme-templates-integration/
Product Type Editor:
http://www.dev4press.com/2011/tutorials/plugins/gd-products-center/product-type-editor/

Plugin Info

Planned Features:
http://www.dev4press.com/2011/blog/development/planned-features-for-gd-products-center/
Plugin Information:
http://www.dev4press.com/plugins/gd-products-center/
Editions & Purchase:
http://www.dev4press.com/plugins/gd-products-center/buy/

New Import / Export

New export tool allows you partial export with selection of custom post types and custom taxonomies you want to export. And, if you want to import the data, you can control it much better and select what to import. For custom post types, custom taxonomies and meta boxes you can append definitions to existing ones allowing you to merge object types from different websites.

Some small changes are also included and fixes to the widgets. New gdr2 library is included with few more changes and fixes to the shared code.

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

GD Custom Posts And Taxonomies Tools Pro Overview:
http://www.dev4press.com/gd-custom-posts-and-taxonomies-tools/
GD Custom Posts And Taxonomies Tools Pro Home Page:
http://www.dev4press.com/plugins/gd-taxonomies-tools/

So, if you have permalinks structure for posts set to /%year%/%postname%/, and you try to reach post by it’s id with URL query argument, WordPress will resolve the request, and than redirect to permalinks based URL. So, if you have post with ID 10, and permalinks URL for it is something like this:

http://www.example.com/2012/my-post-is-here/

And you try to load the page with this:

http://www.example.com/?p=10

You will see that URL is redirected in browser to main permalinks based URL.

And this is really great feature. Even when you make a small mistake in the URL, there is a chance that canonical redirect will deal with it and show you what you were looking for. Good thing about this is that you will have only one valid URL to a page or a post, so search engines will not index same page with different URL. And nowadays, you can get penalty from search engines with duplicated content. So, canonical redirect is a very good thing to have.

But, there are cases where this is actually a bad thing, and you don’t want URL to be modified by WordPress like this. Some website owner run some third-party plugins that deal with canonical URL’s, or they simply don’t want it on. And, as with so many WordPress features you simply don’t have an option to turn it off. There is a simple one line code you can add to your theme functions.php or some other place to disable canonical redirect from loading:

remove_filter('template_redirect', 'redirect_canonical');

But, what if you want canonical redirect working, but not for every URL? Well, you can do that also, and it is not that complicated to do. What can be the reason for this? While developing GD Products Center plugin, I needed a very important feature: each post needed to have 5 pages, and I didn’t want numerical values for them, I wanted each page to have own URL. So, if the main post URL was something like this:

http://www.example.com/products/phone/samsung-galaxy-s2/

My added URL’s for it look like this:

http://www.example.com/products/phone/samsung-galaxy-s2/media/

http://www.example.com/products/phone/samsung-galaxy-s2/review/

http://www.example.com/products/phone/samsung-galaxy-s2/related/

Plugin was made to handle this extra element of the URL, and display proper content. But, canonical URL was not letting such URL through and it was always redirecting back to basic post URL. The only way to handle this, without disabling canonical redirect, is to attach a filter into that redirect function and prevent change in some cases. Filter you need for this is redirect_canonical.

So, the example for this would be:

add_filter('redirect_canonical', 'my_redirect_canonical', 10, 2);
function my_redirect_canonical($redirect_url, $requested_url) {
  if (is_singular('phone') {
    return $requested_url;
  } else {
    return $redirect_url;
  }
}

Filter parameter $redirect_url is canonical URL created by the canonical redirect function and $requested_url is originally requested URL. Within my_redirect_canonical function we need to decide if we want canonical URL or if we want to leave the original URL intact. This example here shows that we are checking if the post type for the request is for ‘phone’ custom post type. If it is, it will use original URL, if not it will redirect to canonical. You can change this to use different methods to check what URL to use.

So these are two methods to use to fully or partly disable canonical redirects. In most cases you need to leave this redirect method active, but it is good to know how to handle it if you need it gone, or at least partly disabled.

Fixing small bugs for all themes continues, and the rest of the themes are getting updated this week. And next week, new xScape Theme Framework with xScape Core theme is coming.

Demo Site:
http://xscape.info/

Securtiy HTACCESS tab has a new options to enable adding of the rules to deny access to list of IP addresses. With this you can prevent users from any IP to access the website. Also, there is a new option to add user agents rules from PerishablePress 5G Firewall, and updated request strings for the same Firewall. Please, check and test all these new security options to make sure you don’t break something. Any settings that deal with HTACCESS can be potentially dangerous.

Maintenance mode has new settings to change title used for the maintenance page, and also to set heading (by default it was about maintenance, now you can set it as landing page). Default template has new actions to expand rendering for the page. In the next plugin version, new template will be added that uses animated counter and few other things.

There are few fixes and changes in the debugger and maintenance mode modules. As always, please report in the forums any bugs you find, and I will get on fixing it.

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

Xposed will get at least one more maintenance release next week to improve few more things and to improve styling. As for the other themes, they will be all updated next week with some fixed bugs and other minor improvements.

Demo Site:
http://xscape.info/

Warning: Plugin is not yet completed, and it is not recommended to use it on the live websites. Right now, from all the planned features for 1.0.0 release, admin side is 100% done, and front end is 95% done. If you have problems with missing templates or broken pages, please run Cleanup operations from the plugin Tools -> Maintenance.

New main template for product types list page is done, and it can list registered product types with images set for them (new option added in the product type editor). Currently one template for it is included, with 2 more coming next week. xScape and other themes support include new theme template for this page type.

Compare and product types list pages have new settings for page titles. This code and settings can work with normal theme title functions, and they can tie into xScape Theme Framework and WordPress SEO by Yoast plugin. Conditional functions for page types are added, and main WordPress Query object modified with them also. And new default product type template data is added for Television. Default plugin styling is improved for better look across browsers and themes. The bugs are fixed: products info is missing if the sorting order is changed, properties editor was setting wrong item types, some minor layout bugs are also fixed. Central Documentation on Dev4Press is updated with latest functions.

Please report any bugs found, I am sure that some more are still in the plugin.

Plugin Test Drive

If you want to try out the plugin before deciding on buying, use the contact form to request demo website set up for test drive. There you can try out all our plugins and themes.

Promo Coupon

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

Resources

Theme Templates Integration:
http://www.dev4press.com/2011/tutorials/plugins/gd-products-center/theme-templates-integration/
Product Type Editor:
http://www.dev4press.com/2011/tutorials/plugins/gd-products-center/product-type-editor/

Plugin Info

Planned Features:
http://www.dev4press.com/2011/blog/development/planned-features-for-gd-products-center/
Plugin Information:
http://www.dev4press.com/plugins/gd-products-center/
Editions & Purchase:
http://www.dev4press.com/plugins/gd-products-center/buy/

Warning: Plugin is not yet completed, and it is not recommended to use it on the live websites. Right now, from all the planned features for 1.0.0 release, admin side is 95% done, and front end is 95% done. If you have problems with missing templates or broken pages, please run Cleanup operations from the plugin Tools -> Maintenance.

Data Import / Export

First new feature is new tool for importing and exporting products data. Right now, export is functional (import will be soon) and includes: product name, taxonomies terms and all properties values. Media values will be added later. Tutorial on this will be published later tonight.

New page type is added and it is used to display list of all product types. This new page type has an empty template right now, but it will be functional very soon. More on this in a day or two.  New template for it is added for all supported themes. If you use xScape themes, you need to update to latest xScape Core 1.8.1.1.

List of themes directly supported by the plugin has increased to include: Canvas and Wootique (from Woothemes), eStore (from ElegantThemes) and Socrates. These themes have theme templates prepared and included. Most of the ElegantThemes themes are similar in strucutre to eStore, so you can use it for other themes from theme (maybe with small modifications). Same goes for Woothemes. More themes will be directly supported, giving a wider choice of theme templates to use for themes that are not directly supported.

Default styling for rendered products, archives and compare pages is improved and several visual problems fixed, so rendering should look good with most themes. You can always make your own styling and disable default styling. I can’t make styling that will be for specific themes, you must make changes you need. Other fixes in this version include: filtering issues with some plugin templates and broken rewrite rules for archives. To make sure that this is working for you, please clear all rewrite rules, and plugin will generate new rules that will be now OK.

In the next couple of weeks I will have some important information regarding integration with several third-party plugins. Also, new plugin and demo website will be up during this week. Please report any bugs found, I am sure that some more are still in the plugin.

Plugin Test Drive

If you want to try out the plugin before deciding on buying, use the contact form to request demo website set up for test drive. There you can try out all our plugins and themes.

Promo coupon

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

Resources

Theme Templates Integration:
http://www.dev4press.com/2011/tutorials/plugins/gd-products-center/theme-templates-integration/
Product Type Editor:
http://www.dev4press.com/2011/tutorials/plugins/gd-products-center/product-type-editor/

Plugin Info

Planned Features:
http://www.dev4press.com/2011/blog/development/planned-features-for-gd-products-center/
Plugin Information:
http://www.dev4press.com/plugins/gd-products-center/
Editions & Purchase:
http://www.dev4press.com/plugins/gd-products-center/editions/

Standard Archive Layout

Xposed is new xScape Theme Framework based theme, made with use of HTML5. Theme can be used for blogs, or showcase theme that can use static pages content in page blocks. Theme also uses featured posts slider using Nivo jQuery slider and comes with 8 color styles.

Xposed is simple and clean theme, that has 4 color schemes and total of 8 color styles (with and without background patter imges). Nivo slider is used for features slider block with similar settings as with previous R8 and Serenity theme. Single page block is added and can be used to create a product showcase website or pages on the website.

To see intro to setting this theme, check out the video on the theme homepage. Next week, this theme will be used on the new website for upcoming GD Products Center plugin for both showcase and demo.

Xposed  Info:
http://www.dev4press.com/themes/xposed/

To see the theme and framework in action, visit the WordPress MultiSite powered demo website and get your own blog to see who the framework back-end works:

Demo Site:
http://xscape.info/
Xposed:
http://xscape.info/load/?theme=xposed

Google Web Fonts module got another 80 fonts, and it supports total of 245. Recent posts widget got a new post excerpt tag to use to display posts. And networks widget got a new option to select icons size used. bbPress module has a new option to disable on all page secondary forum navigation. On the theme settings page, you can see information about Blueprint grid used for the active theme. New filters are added, and some improved. Global settings got two more options: add page load debug info on top of page head tag and to load additional buttons.css file with styling used for links turned to buttons.

Buttons Styles Examples

I am not really liking the idea of having theme handling the shortcodes, but I know it can be very useful. So, to start, I have added few shortcodes, and you can open documentation to see the specification for all of them. Visually, link shortcodes look really nice (there is a new button.css loaded by the framework and that can overridden by individual themes to change button styles), and you can see them on the image on the right. Each default styling has hover state.

As for other changes, additional documentation is added to some of functions and classes, and side scroller module had been gone through some changes also. Bugs fixed in this version include: minor styling issues with WordPress 3.3, broken saving of settings when images are uploaded and minor issue loading core theme custom templates. GD Products Center template for compare page in xScape Core is also fixed, and default typography styling for xScape Core improved.

If you find any more  problems or bugs, please report them in the forum. I will also publish couple tutorials over the weekend on using the shortcodes. And expect new Xposed theme tomorrow.

Latest NetBeans IDE from January 2012

Intro to NetBeans IDE

Years ago, NetBeans started as Java development tool, but it grow much over the years. Now, NetBeans IDE support: Java, C/C++, Groovy and PHP with many more available through plugins. Depending on your development needs, you can download partial installation, and one of them is NetBeans IDE for PHP. Major elements of the IDE for PHP are: powerful code editor, projects, frameworks support, debugging, remote and local development, unit testing, phpDocumentator support, namespace support, mySQL integration, code coverage… Beside that, NetBeans IDE has complete support for: HTML, CSS, CSS3, JavaScript, AJAX and integration with popular toolkits (jQuery, Prototype…).

So, for WordPress development, you have everything you need in one powerful IDE. It is important to know that NetBeans IDE works on Windows, Linux and MacOS, and it requires Java JRE installed. Unlike the Eclipse that is also Java based, NetBeans is very fast and not resource hungry as you might expect from Java software, especially under Windows.

Setting up WordPress project

For local development you need, and most likely already have, local server setup where you keep your development websites. To use NetBeans you can use any such local server setup: DesktopServer, XAMPP… To make the best of the developing for WordPress, best thing is to add each your website as a separate project. That will include all WordPress files including wp-content with plugins and themes folder, so you can work on anything you need. Best thing about adding whole project like this is that NetBeans will scan the project and index WordPress function, classes and other elements. This scanning can take a couple of minutes for each project, and each time you start NetBeans, it will take a bit more time to check all projects for changes.

To add new project, open File menu, and click on New Project. Dialog likes this:

New Project

As you can see, you can start empty application, application from sources or remote server. Select one from existing sources and click next. New dialog appears. And you need to select where is your project. Browse for it, and select root folder where the WordPress installation is. It should look like the image:

Select source folder

Click open, and now you need to select PHP version and to give project a name. It is recommended to use PHP 5.1/5.2 for this.

Final project creation step

Projects List

Click Finish, and you are done. NetBeans will need one more minute to scan source for the project, and you will be ready to work. Your new project will be added to Projects list on the left (you can rearrange it). It is recommended to have each website as separate project.

Favorites Panel

If you work on plugins or themes in one WordPress installation, you can make it easier, and add each plugin or theme you need into Favorites panel. This will help you find your work easier without going through whole projects list. To do this, simply right-click on the folder in the projects panel, and select from Tools menu option Add to Favorites. Favorites look with the Navigator is on the image on the right.

Navigator shows all identifiable elements in the now open file for easier navigation through the code.

Powerful editor

Once you have set up the projects you want to use, you can first of all, use autocomplete. If you are in PHP context editing, you will get info on all found functions (both default PHP and found in the code). If you are in JavaScript or CSS editing context, it will work the same way. Image here shows what happens if you start typing ‘wp_admin_c’. You will get list of possible functions and all function versions in regard to arguments, and above you will see documentation for selected function.

Autocomplete and suggestions

If you need to navigate through code by following functions, you can use context menu and option Navigate, or you can use hover over the function, class or variable name with CTRL key pressed, and you will get item documentation. If you click, you will be taken to declaration. Code folding works great with any type of code and will help you working with large files. Also, there are plenty of options available through top and context menus.

Code navigation and quick help

NetBeans support phpDocumentator specification, and to add it, position cursor in the line before function or class declaration starts, start the line with /** hit enter, and you will get all comment containing parameters, globals and return found in the function or class.

If you need to work with CSS, JavaScript and HTML in your files, you can do everything (or almost) with NetBeans. CSS editor is very powerful, and I have stopped using any other external editor for that, and from 7.1 version, it supports CSS3.

File Version History

Support for SVN, GIT, Mercurial

If you are using some versioning  system (Subversion or Git for instance), NetBeans will allow you to work with repositories directly and to show you changes to files, to make updates or send changes to server.

Color coded changes in editor

All changes made are color coded in the editor, but you also have History look that will show how the code looked before and after modification with access to all historical changes data for both local and versioning system changes.

Editor uses colors to mark deleted (red), new (green) and edited (blue) lines of code. Navigation can be done directly by clicking on the position on the right side of the editor. There are many useful things to help with navigation including markers, all found on the editor toolbar.

Debug whole WordPress website

Yes, you can do that. I will not go into details on how to set up your environment for debugging, there is a in detail article on NetBeans website about this: How to configure XDebug. Anything you expect from debugger you can find here. You can start debug of the whole project, and that is what you must do when developing for WordPress (regardless if you make theme or plugin), because WordPress needs to load the way it usually does, so always use Debug Project option for this. In debug mode, you will get additional panels tracking the process and you can use break points also (simply click on the line number to add red debug point).

What’s next?

This is only introduction in using NetBeans IDE for WordPress development, just to get you started. It can take you few days to take everything in and to discover what can be done with this great program, but it will be worth it. You can easily replace all your other editors with this one and make your development process more streamlined and confined within one program.

Download NetBeans IDE:
http://netbeans.org/downloads/

Header and contend detail

First xScape based theme in 2012 will be called Xposed. This will be HTML5 theme, it will have 4+4 built in color styles, one sidebar widgets area, one footer widgets area, static page showcase block, Nivo powered featured posts slider. This is portfolio, showcase and blog theme.

Theme will be completed and available during next week, and also, it will be used on the website for GD Products Center Pro plugin. Until that time, here is a little more information and few preview images.

Widgets and footer detail

Xposed uses 18 column Blueprint grid layout with 950px in width. Normally works as a blog based theme, but with the help of two useful layout block it can be used as portfolio or showcase theme. These blocks are for a single page, and featured posts slider. As with several previous themes, this one will use Nivo jQuery slider.

Pager and widgets detail

There will be 4 color schemes, and each will have two styles: one with the textured/pattern images for background and one with plain colors. This will make theme very lightweight and effective. Since it will be HTML5 theme, to retain compatibility with older browsers, Modernizr JavaScript will be used if needed.

Along with the new theme, xScape Theme Framework 1.8.1 will be released with new Google fonts and many improvements and fixes.

Intro

If you don’t use permalinks structure for URL’s, you can skip this article. All this matters only when permalinks structure is on. And since most websites use them, it is useful to know how the pretty URL is resolved. When URL is parsed by WordPress, a long list of rewrite rules is used to match the URL (using regular expressions) to a query that WordPress can than understand and use to load and display data. If two rules are conflicted, the one with higher priority is used. If no rule is matched, WordPress will load 404 page. If the rule is matched, but the query returns no results, again 404 page will be displayed, this means that URL request was invalid.

If you have complex data structure with many post types, if you use even custom rewrite rules, you can end up with the 404 pages very often, if the rewrite rules are not resolved properly. In most cases, every URL request will resolve as a page if all other rewrite rules fail.

Get the list of all rewrite rules

You can always display list of all rewrite rules registered in WordPress. There is a simple function that can display all the rules in the table form:

function dev4press_debug_rewrite_rules() {
  global $wp_rewrite;
  echo '<div>';
  if (!empty($wp_rewrite->rules)) {
    echo '<h5>Rewrite Rules</h5>';
    echo '<table><thead><tr>';
    echo '<td>Rule</td><td>Rewrite</td>';
    echo '</tr></thead><tbody>';
    foreach ($wp_rewrite->rules as $name => $value) {
      echo '<tr><td>'.$name.'</td><td>'.$value.'</td></tr>';
    }
    echo '</tbody></table>';
  } else {
    echo 'No rules defined.';
  }
  echo '</div>';
}

Add the function to your code, and call it inside any theme template to print the list of all rewrite rules. Order of rules are also the priority, top rules are with highest priority. Reading the list can be confusing if you don’t understand how the URL rewrite in WordPress works, and it is more useful to developers for debugging.

Display resolved rewrite rule and loaded template

Now, we can use another function to show us how WordPress resolved the URL request and why the template is loaded:

function dev4press_debug_page_request() {
  global $wp, $template;
  define("D4P_EOL", "\r\n");

  echo '<!-- Request: ';
  echo empty($wp->request) ? "None" : esc_html($wp->request);
  echo ' -->'.D4P_EOL;
  echo '<!-- Matched Rewrite Rule: ';
  echo empty($wp->matched_rule) ? None : esc_html($wp->matched_rule);
  echo ' -->'.D4P_EOL;
  echo '<!-- Matched Rewrite Query: ';
  echo empty($wp->matched_query) ? "None" : esc_html($wp->matched_query);
  echo ' -->'.D4P_EOL;
  echo '<!-- Loaded Template: ';
  echo basename($template);
  echo ' -->'.D4P_EOL;
}

Debug Rewrite Rules in header

Best way to use this is to add the function into your code (functions.php in the theme), and to call it in the theme header.php template, best to do it on top, right after HEAD tag. Look at the image on the right for the example.

When you do that, whenever you load new page in the browser, the debug info about rewrite rule matched will be embedded as a comment on top of the header. And if you end up on 404 page, you can see why, what happened to resolved rule to do that.

Images bellow shows example output for this debug info. Request is always displayed without the domain name. First example is success matching of a request to a post, and loading of single.php template. First line is request, second line matched rule (regular expression), and when the rule is matched, request is transformed to a query (line 3). This query is something WordPress can interpret and load via proper template. Based on the query, WordPress creates a query object that is used to get the data and determine template to load (last line).

Matching Hello World single post

Next image is a custom rewrite rule for my GD Products Center plugin archive page that mixes both custom post type and taxonomy.

Matching archive for custom rewrite rule

Third example is for the URL that can’t be resolved properly. When all rules in WP fail, last one remaining is a single page rule. And this example has triggered that, and practically the whole request is matched as name for the page. And since such page doesn’t exists in the system, 404 template is loaded.

Matching ended up as a page that don't exits giving 404

If you use Dev4Press plugins this is already built-in some

If you use GD Press Tools Pro, you have a debugger module built-in that can display all the data we discussed here and more. If you use GD Custom Posts and Taxonomies Tools Pro (these functions: gdtt_debug_page_request_comment, gdtt_debug_rewrite_rules, gdtt_debug_page_request) or GD Products Center (these functions:  gdpc_debug_page_request_comment, gdpc_debug_rewrite_rules, gdpc_debug_page_request), so check the documentation for more details. And it will be added to xScape framework soon, and it will be easy to turn on or off.

Conclusion

So, now you can easily find out why WordPress loaded a page for every of the URL requests and find out likely cause to end up on the 404 page. This is also important when working with custom rewrite rules that can be in conflict and can cause 404 page to load.

Warning: Plugin is not yet completed, and it is not recommended to use it on the live websites. Right now, from all the planned features for 1.0.0 release, admin side is 90% done, and front end is 90% done.

Products Types Grid

On image above you can see improved products types grid. Both this one and taxonomies grid are updated. Templates panel now lists in more detail all available templates. Each type of template is displayed as a tab. For future 1.1.0 release I plan to add editor for each template from this panel.

New widget is added for rendering list of products. You can limit and filter products to display, similar to single product widget from before. Also, if you need to embed product info into your blog posts or some other unrelated pages, you can use new shortcode: gdpc_product, details and use are in the documentation.

As for other changes, there are number of small improvements, several bugs fixed (deleting taxonomy and product types selection in the widget), updated gdr2 and gdT3 libraries. Also, code handling custom rewrite rules is improved further. I have added functions that can be used to debug WordPress rewrite rules resolving and list of registered rewrite rules. These functions are in the Central Documentation.

There will be one more beta (0.9.5) before final, and that one will be used to finalize all templates and fix bugs. This major beta is expected in about 7 to 10 days, final should be out before the end of this month. Please report any bugs found, I am sure that more are there. I am testing plugin with different themes, but I might be missing things.

Plugin Test Drive

If you want to try out the plugin before deciding on buying, use the contact form to request demo website set up for test drive. There you can try out all our plugins and themes.

Promo coupon

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

Resources

Theme Templates Integration:
http://www.dev4press.com/2011/tutorials/plugins/gd-products-center/theme-templates-integration/
Product Type Editor:
http://www.dev4press.com/2011/tutorials/plugins/gd-products-center/product-type-editor/

Plugin Info

Planned Features:
http://www.dev4press.com/2011/blog/development/planned-features-for-gd-products-center/
Plugin Information:
http://www.dev4press.com/plugins/gd-products-center/
Editions & Purchase:
http://www.dev4press.com/plugins/gd-products-center/editions/

Sorting order for widgets was broken on some servers due to the changes in PHP, so the sorting functions were not created as they should be. When showing results from custom fields, in some cases data is not displayed properly: empty date was producing odd date displayed, boolean was only displayed if true.

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

GD Custom Posts And Taxonomies Tools Pro Overview:
http://www.dev4press.com/gd-custom-posts-and-taxonomies-tools/
GD Custom Posts And Taxonomies Tools Pro Home Page:
http://www.dev4press.com/plugins/gd-taxonomies-tools/

Plan was to have more, but this first monthly measurement will have 30 instead of 50 plugins. But, this list will change over time, and new plugins will be added to the mix, and some of previously tested will be removed. But, from next month I will have publicly available table with all historical data for all tested versions.

All the data displayed here may vary depending on server configuration and other factors. Data here doesn’t say anything about quality of the plugins or their usability, it is only a test of resource usage. Also, some of the plugin can use different amount of resources depending on the plugin configuration, and all tests here are done with default plugin configurations. There is no way to test complex implication of different settings or method of work for a test like this.

Measurement Process

For this first monthly test I have tested 30 plugins. All tests are done with a single installation, and WordPress 3.3 was used. Tests are done on the local server with PHP 5.3.8. All measurements are done using GD Press Tools Pro 4.3.2 plugin. Plugin has a tracker class that can be loaded from wp-config.php file to accurately capture snapshots of different loading stages (among other things). To allow capturing plugins snapshots, I made small change to WordPress core files: added snapshot call into loop that loads plugins.

To get as accurate resource usage I spent some time testing each plugin individually to measure used memory during loading and after all plugins are loaded. Some plugins load most of its files hooked to WordPress action, and not during loading of the plugin. Again, this number is not 100% accurate, but it is very close. As these tests are improved over the next few months, the numbers can vary a bit.

Plugin Grading

Each plugin is graded on a scale from 1 (worst loading optimization) to 5 (best loading optimization). This grade is not only connected to used resources, but to actual method of loading plugin uses. Plugins that got grade 1 have no loading optimization and they always load everything (or almost everything) and that uses precious server resources always, even if the plugin doesn’t need all things loaded. There is no perfect loading method, because it would be very complicated to do. But grade 5 goes to plugins that use loading optimization, that care about what WordPress is executing, and how much resources are used actually. Change column for this first test is empty (well it is set to =), and it will change with next test depending on the progress plugin developers do with their plugins.

To give plugin a grade, I have analyzed plugin loading process and I have taken into account how much resources plugin takes due to loading method it uses. Best loading optimized plugin I know is my own GD Press Tools Pro. If this plugin is to load all its parts always it would use twice as much memory and it would need much more time to load. Even with all that, I always work on further changing how the plugin loads trying to make it better. Plugins close or better to the level of optimization in GD Press Tools Pro will be graded 5 also. If the plugin uses different amount of memory on front and back end it doesn’t mean that the grade will be higher because of that.

Before we go on to the testing, read the original article from last month regarding the plugin loading process that will give the reasons for such testing and why it is important to make sure that plugin loads parts it needs only for admin side and front end: Measuring impact of plugins on WordPress loading.

Tested plugins basic information

30 tested plugins are listed in the table below. Beside basic data in first 5 columns, you can see if plugin adds own JavaScript, how many AJAX handlers uses, how many cron jobs can be registered by this plugin (it doesn’t mean that all will be registered always) and how many widgets plugin can add.

All tested plugins, but one, used the internal WordPress AJAX handling. Contact Form 7 uses own handler and that is not something I can recommend. Using WP handler is best solution considering that it is already written with security concerns in mind and it is very easy to use, making plugin fit better with WP development concepts.

Resource Usage Test Results

Here is the list of all plugins in this test, and the results.

So, let’s start with the good. My GD Press Tools Pro is very fine tuned to load different plugin parts when needed, and it is always evolving and improving. GD Unit Converter on the original test was badly graded, but with latest version I have changed it all, and it graded 5.  W3 Total Cache has very good optimization of resource usage, and loads a lot of things when needed only. Loader maybe a too complicated for my taste, but it is effective. WordPress SEO by Yoast is a great example of well written and optimized plugin.

Plugins with potential to be better are many, and all grade 3 and 4 plugins fit into this group. NextGEN Gallery is almost there, and with a bit more work, it can go to grade 5. I plan to improve my own plugins further, and work on that is in progress for some of them, so I expect them to be improved in the next tests.

Grade 2 plugins have only some elements of optimization, but they are close to grade 1. Adminimize plugin shouldn’t even load on the front end except for some elements, and that needs to be optimized. Gravity Forms is a great plugin, that needs a long way to go but at least has some sort of loading control.

As for the grade 1 plugins, the results may be surprising considering how popular some of this plugins are. WooCommerce started from JigoShop, but almost nothing is done to change awful loader JigoShop has, so they are both graded 1. Mike Jolley from WooThemes told me that they are working on improving WooCommerce so, I am looking forward to that. bbPress also has no optimization at all, and even from latest sources for 2.1 I don’t see any improvements there, and that is not a good sign.

Why is this all important?

WordPress loads plugins on both admin side and front end. But, most plugins don’t need to behave same way in both cases. Many plugins are needed only on one side. So, a plugin can be used on admin side only, and has no use on the admin side. If the plugin is not optimize to load files only when needed, it will take same resources on front end also, even so it is not needed or used, and that is a waste of server memory and time to load. Most plugins have two parts, one to be used on admin side to set the plugin, and other that works on the front end. No need to load everything on both sides, load only what the plugin needs, and it will use least amount of memory and it will work faster.

Should you care? No. And yes. If you run few plugins, than amount of memory used is not that relevant. If you run your website on VPS or dedicated server, you have much more memory available, but if you are on the shared hosting, every MB can be critical (especially if the hosting company limits it). This test is not about plugin quality. If you prefer using All In One SEO, don’t let the lower grade be a big concern because WordPress SEO plugin got higher grade. This tests show how the plugin handle resources nothing more.

Improving results

I am sure that many developers will say that these results are not important, but considering that most of the WordPress users are on shared hosting with limited memory and resources available to them, this is most important thing to have plugins they need and still have server running fine. Same thing goes for themes also. Dev4Press website uses 20-21 plugins for the last year, but with theme (my xScape Theme Framework based) and my plugins optimizations, I managed to lower memory usage from 60M last January to 40M today.

I recommend to all plugin developers to read my tutorial: How to optimize plugin loading. Most of the things from it can be applied to all plugins, and all users will benefit from developers investing extra time to optimize own plugins.

Edit 2012.01.05. – Updated grade information.
Edit 2012.01.06. – Added few more explanations and link to original loading impact article.

Development of plugins, themes and theme framework will continue this year, and I have plans on improving Dev4Press website, and launching at least 3 new websites related to my work and WordPress. The list that follows will include dates if possible, all items in the list are listed in no particular order.

Dev4Press

1. Newsletters. First major update to website is coming in February with powerful newsletter system. I can’t give more detailes at this moment, but there is a plan to have it released as commercial plugin later this year.
2. Support Forum. There will be many improvements to support forums, starting with changes to posting topics that are coming in the next couple of weeks. More things will be introduced to improve the forums.
3. Plugins Informations. All plugins information will be updated over the next 2 months. Existing information will be improved and kept current as often as possible.

Plugins

1. GD Simple Widgets 3.0 Pro. This plugin was neglected for the last year, but that will change. Plan is to give it new gdT3 templates system library and to add at least 4 new widgets to it. I hope to get working on this new version in the next two months.
2. GD Products Center 1.0 Pro. Plugin is in the final beta phase now, and final 1.0 is expected in January. This is not even close to the end of the development for this new plugin, it will include a lot of new features that are in the roadmap.
3. GD aZon FUSION 1.0 Pro. Plugin is nearing completion, and 1.0 will be released in February or March. I am also preparing the list of features to be added after that. There are some plans in that regard already.
4. GD Star Rating 2.0. This plugin is delayed several times, but now it should be getting back on track. Public beta versions (or further) will be released by the end of March. More info on the progress on this plugin will be available next month.
5. GD Custom Posts and Taxonomies Tools 4.0 Pro. Roadmap for this plugin is pretty much planned out. Before we go to 4.0, there will be at least on major release (3.6 most likely in February).
6. GD Press Tools 5.0 Pro. Plans for this major version are not yet formulated, but it will be released in the second half of 2012. Leading to this release, plugin will get more SEO features, more content related tools and few other things. Development for 4.4 will start this week and it will add new features to modify WordPress 3.3 toolbar and other things.
7. Lite & Free Plugins. The development of all free plugins will proceed as before, Pro plugins will have priority but free plugins will not be neglected. As for the lite versions of Pro plugins, they will get regular compatibility updates as usual.

Themes

1. xScape Theme Framework 1.9/2.0. Work on the post 1.8 version will begin soon, and I will have detailed roadmap soon. Current roadmap already includes new features, and it will be expanded with few more interesting things.
2. Themes. Right now, plan is to have 5 to 8 themes released in 2012, depending on available time and available designs. I have 2 themes already planned, one is in the works. Also, all future themes will be HTML5.

Libraries

1. gdT3. This library is in development, and it is used to power GD aZon FUSION and GD Products Center rendering right now. GD Star Rating 2.0 and GD Simple Widgets 3.0 Pro will use it as well.
2. gdR2. This powerful library will be expanded further this year. Plan is to have more core functions added, to have improved loading and support for APC for caching library. All Pro plugins and xScape are using it already.

Websites

1. GD Products Center Pro, GD aZon FUSION Pro and GD Simple Widgets Pro will get own websites that will be used as demos and basic landing pages with information about each plugin and its features.
2. A website related to WordPress is in works and I expect it complete in the first half of this year. I will not give any details about the website content or plans for it, but it will be interesting.

That’s it for now, plans will change depending on the needs, but I will try to keep to the list. All suggestions for the development are welcome, and you can leave them in comments or in the forum.

I wish you all happy new year!

Development

GD Press Tools Pro has gone through a lot of changes and it is most popular plugin on Dev4Press. GD Custom Posts and Taxonomies Tools Pro has become very popular solution for working with custom content and because of that, a lot of useful features were added, including the integration with bbPress plugin. GD Products Center in the new plugin that will soon get stable 1.0 release. Only thing I regret in this year in regard to development are delays for GD Star Rating 2.0, hopefully that will be resolved soon.

As for the themes, xScape Theme Framework has gone a long way, and reached 1.8 recently. Themes are now all working as child themes to basic xScape Core theme. All the work done on that unfortunately limited number of released themes, but that number will improve next year.

Development of free plugins was great this year, and that includes one new plugin for bbPress 2.0 (GD bbPress Attachments), resurrected GD Pages Navigator, new plugin GD Unit Converter and active updates for Lite plugins.

A bit of statistics

In the past 12 months, there were 350 updates and releases available for all plugins and themes. That is almost one each day, confirming how lively and intense the development was on Dev4Press. This have generated over 250.000 downloads during 2011 with little over 300 GB of bandwidth. And most importantly, number of Pro users has increased 92% during this year.

Dev4Press website have seen 95% increase in number of visitors, 115% increase in number of page views and 135% in number of total time visitors spend on the website. Firefox was most popular browser among visitors (45%), Chrome followed (32%) with Internet Explorer and Safari (both with 8%) and Opera (4%).

Website updates

Dev4Press website have gone through many changes in both design and content in 2011. One of the most important changes was upgrade of support forums to bbPress 2.0 plugin version. New element of the website is ‘Feature of the Day’ section, ‘Documentation’ is updated and now contain over 300 functions and hooks for different products and website now uses shopping cart to make purchase of multiple products easy. Also, all prices are displayed in Euros, British Pounds and US Dollars.

Next week I will write about plans for 2012, and there are some great things in plans. For now, I am very happy with the growth Dev4Press has gone through this year, and I am very grateful to all of you for support, and I wish you all a happy new year.

For each of the listed feature, you will see the plugin version number when the feature is added, and post will be updated over time to reflect the changes made to the plugin. All features in red are completed in the latest available version. Features in green are close to completion.

1. Product Type editor: main editor for the product type used to set name, labels, rewrite rules, images, videos and product specification properties. Product types are implemented through custom post types, but most of the parameters are generated by the plugin, user don’t need to set everything in detail. (0.7 Alpha , 100% done)
2. Product Type data: each product is a post for a custom post type. When creating or editing product, you will use standard WordPress post editor. But, this editor will be expanded with meta boxes generated by the plugin based on the settings for product type. So, you will get Product Properties meta box with all properties you have set for product type and you will get Product Media and Links that will allow you to add images, videos and external links to the product. All 3 can be limited in number on the product type editor. Images can be external or handled by Media Library. Videos can be external link for websites that support eEmbed: YouTube, Vimeo and many more. (0.7 Alpha, 100% done)
3. Product Type pages: each product will get several pages in the front end of the website. Right now plugin support 5 page types: specification, author review, user reviews, related products and media. Author review can have more than one page allowing for long reviews. User reviews is basically comments thread and media page is a gallery of all product images and videos. (0.8 Beta, 100% done)
4. Built-in product types: to make things easier to get started with the plugin, adding new product type will have templates. If you choose one of the offered template, plugin will create new product type from selected template will all predefined properties and settings. You can change things if you want and you will get working product type very quickly. Number of product types will be expanded, and first 0.7 Alpha has 4 of them. (0.9.7 Beta, 100% done)
5. Built-in taxonomies: one more convenient feature is creation of taxonomies. This is also simplified version for those that don’t use our GD Custom Posts and Taxonomies Tools plugin. Also, creating new taxonomy here will give you choice of predefined templates for some useful taxonomies, similar to predefined product types. (0.7 Alpha, 100% done)
6. Custom permalinks rewrite rules: plugin has many customization options to create products permalinks and you can control the rules added with custom slugs for different page types, compare or products pages and more. (0.7.5 Alpha, 100% done)
7. gdT3 Templates System: for all rendering plugin uses Dev4Press own gdT3 templates system. Templates are stored into files, support mixing of HTML and PHP with special tags used for plugin specific features. Plugin has several types of templates: single product, archives, widgets, compare page. Themes and other plugins can replace default templates or add own templates. (0.9 Beta, 100% done)
8. Compare Products: template and rewrite rules for products comparison. Plugin allows comparing 2 or more products in the same time. Default styling for the plugin can support many products compared to make it easier to see wide lists. (0.8 Beta – 100% done)
9. Simple archive filtering: simple filtering of products will be done using taxonomies only with the basic sorting options. There are 2 different templates built in for this displaying products in grid or list. (0.7 Alpha, 100% done)
10. Archive filter Template: complex filter that allows use of product properties and taxonomies, filtering by date, sorting by different criteria. (0.9.7 Beta, 100% done)
11. Full xScape Theme Framework support: all themes have templates built in for this plugin. And, plugin will be able to create and preset templates automatically in one of the next versions. (0.8 Beta – 100% done)
12. Support for any theme: for default WP themes plugin comes with example templates you can use to make it work. Similar method will work with any other theme. Also, plan is to have plugin copy the templates over into theme folders. (0.7.5 Alpha, 100% done)
13. Widget for Comparing: to add products to compare you can use widgets. From many page, you can add products to the widget and than run comparison from it, leading to compare page. You can have more than one compare widget in the same time, and one compare widget can be used for only one product type, because you can’t compare products from different types. Compare widget can have limit of the most products to compare. (0.7 Alpha – 100% done)
14. Widget for Single/Random Product: show one product in the widget using own template to display product specification and image. Widget will allow options for filtering the product to display. (0.8.8 Beta – 100% done)
15. Widget for Products List: template based rendering for the products with basic filtering options. One list widget can display products from one product type only. (0.9 Beta – 100% done)
16. Widget for Products Search: add simple widget to allow searching for the products only with selectable product type. (0.9.7 Beta, 100% done)
17. Maintenance tools: to make the process of cleanup easier, and to have a way of clearing cached data, Tools panel has a tool that allows you to remove cached templates, registration data and rewrite rules. (0.7 Alpha, 100% done)
18. Import and Export: once you create product types and taxonomies, it will be useful to export that data from one website and have that imported on another website. These tools will make that very easy. (0.7.5 Alpha, 100% done)
19. Shortcodes and Functions: Shortcodes and functions that can be used to embed products into different posts. They will allow using products on any page on the website. (0.9.5 Beta, 100% done).
20. Export to file and Import Data from File: bulk export and import formatted data for multiple products using plain text CSV file that include full specifications for products. (0.9.8 Beta, 100% done).

This is current features list, and I expect few things to be added during development. As for the features beyond 1.0.0 version, this is yet not set, but here is the current preliminary list:

1. Integration with bbPress: assign topic to a product and display discussion on the product as a page incorporated with the plugin. (planned for 1.1.0)
2. Expanding Sitemaps: support for different XML sitemaps plugins to add products pages, comparisons and other new links and archives. (plnned for 1.1.0)
3. Additional product pages: for each product/product_type you can define extra pages that will be included in the pages list for the product navigation. (planned for 1.1.0)
4. Archive URL variations: specify different archive templates use based on the URL for the archive. This will allow special archive pages for different uses. (planned for 1.1.0)
5. Advanced search template: new template to include different page layout for searching products based all multiple multi value criteria. (planned for 1.2.0)
6. GD Star Rating 2.0: once the GDSR 2.0 is released, GD Products Center will fully support it and templates will be modified for direct integration. (planned for 1.5.0)
7. GD aZon FUSION Integration: get products data from Amazon via this plugin. Amazon auto added as the Seller with adding links to products in the system. (planned for 1.4.0)
8. Product Editions: one product can have variations like color, more or less memory… Instead having duplicate products, set up versions of same product. (planned for 1.2.0)
9. Vendors/Selers/Stores: setting up vendors and assign product types and products to them for pricing control for different product versions. (planned for 1.2.0)
10. Statistics Display: panel to show visits statistics for different product types and products. (planned for 1.3.0)

Debugger and tracker got many updates. Tracker with each snapshot can count hooks attached, and list of default snapshot points is expanded to include few more important hooks. Debugger got two new panels: one to display all enqueued scripts and styles, and the other one with extra info moved from other panels (sessions, cookies and cache status). Also, you have more control over displaying some of the panels you might not need always. Some panels are updated and some debugger bugs are fixed.

Some parts of the plugin are optimized further. RSS feed items expanding now support special tags to add some of the post and site info easier. Plugin tools got option to reset all security related settings. For the SEO verification meta tags, new one has added for the Alexa site ownership confirmation.

As for the bugs, quite a few of them are fixed now: saving security settings was failing in some cases, some input elements were generated as invalid, problem with creating the plugin folders when wp-content is not writable, post revisions setting might not always work and some debugger problems. If you have problems with security settings missing due to saving problem, you can reset security settings to defaults from the Plugin Tools panel.

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

Links and Resources

Comparing GD Press Tools Pro versus BackupBuddy:

GD Press Tools Pro versus BackupBuddy

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

Special thanks goes to Ryan Skoblenick who created the video explaining all problems with overriding default taxonomies settings. So, the changes and fixes in this version: default taxonomies and post types overrides are now always set to no by default, fixed problem with meta box for taxonomy override when hierarchy settings are changed (category was a big problem), fixed override for taxonomies not unregistering them for post types, fixed problem saving simple overrides always resets full overrides settings,  default taxonomies and post types overrides by default always set hierarchy to false.

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

GD Custom Posts And Taxonomies Tools Pro Overview:
http://www.dev4press.com/gd-custom-posts-and-taxonomies-tools/
GD Custom Posts And Taxonomies Tools Pro Home Page:
http://www.dev4press.com/plugins/gd-taxonomies-tools/

Notice: This tutorial is primarily for plugin developers, but it can be useful reading for anyone working with WordPress to better understand how plugins load and what can be done to improve it.

Intro

Before we go on, I recommend you to take a look at the article with test results. I know that many readers were surprised by the results, considering how some high-profile plugins scored very low and ended up in the bad optimized plugins category. Optimization will take these plugins one step further, showing that author cares about used resources (most WordPress websites are on shared hosting, and resources can be very limited), and that author understands that optimization is as important as adding features and making plugin look pretty.

So, what plugin authors can do to make their plugins better, how to optimize their loading, resource usage and with that speed? Before I list recommendations for this, here is a small analysis of how plugins are loaded.

Plugins Loading

One of the early steps in the WordPress loading is to load plugins. WordPress will get the list of all active plugins and it simply use PHP include function to load main plugin file. That main plugin file can contain the plugin (for smaller plugins or widgets), or it can be used as plugin loader to initialize plugin, or it can be the mix of the two. WordPress will do this for every single page, it will always include active plugins.

Even if the plugin is small, this can be an issue. For instance, my GD Unit Converter plugin was used in the benchmark article. This plugin adds a widget on the admin dashboard, and that’s it. But, if you look at test results it was using 0.5MB on admin side and 0.4MB on the front end side. And it was doing nothing on front end side! So, I changed the main plugin file to act as a loader only. It will check if we are on admin side, and it will load another file that actually contains plugin. If we are on front end side, it will do nothing. After this optimization, on front end side plugin uses now 20KB, that is 95% memory saved. That is amazing gain, but you can’t expect such results for every plugin.

If you look at the test results again, even smallest plugins will use 0.4MB to 0.5MB. Imagine that you have 20 such plugins, and if all 20 of them save just 0.2MB, that will lower memory usage by 4MB, and will improve speed a bit. That might not look like a lot, but trust me, it will make a difference, especially for shared hosting websites.

Most plugins have a specific usage, and that requires plugin to be loaded only on some pages. In some cases you will need parts of the plugin functionalities loaded on every page. It can be very complicated to decide the need for plugin on each admin or front end page. But, you need to recognize what parts of the plugin are always needed, and what parts will be specific to some of the pages. That basic analysis will help you to decide what pieces of code go into separate files. If your plugin is only for the administration, it doesn’t need to be loaded on the front end. It is very simple to check this in the loader file and to prevent loading of the rest of the plugin.

If your plugin ads administration side pages or forms, you will need to load CSS styles or JavaScript files. Too many plugins these days are making a very big mistake of loading these files on every administration page without checking if the page belongs to the plugin. That will most likely break other plugins or change the styling for other plugins, or even WordPress. This is one of the things that must be optimized and done properly.

Files and folders organization

One of the most important things with any plugin, is organization of files and folders with code, CSS, images, JavaScript. When you make right structure for files and folders, you will make it easier to make future changes and perform maintenance.

1. Code should be split into files according to functionalities. Many plugins don’t have that strict code separation, and they end up with large files with functions and classes thrown in. This makes later changes and maintenance harder, because code has no logical structure or order. Also, big files will use more memory, even if most of its functionality will not be used at all.
   

   Code Folders

2. HTML forms should be separated from files with code. These forms will be loaded only on some pages, and they will contain mostly HTML markup code (they can contain PHP code, and usually do, but only used to fill HTML elements with data), and they should be kept outside of the main plugin code.
3. Create few folders for different files types for your plugin. Main plugin code should go in one folder, files with HTML forms should go into another folder, CSS styles and JavaScript should go in own folder and images should go in own folders. On the image on the right you can see a folder structure for one of my plugins. I like adding extra sub folders for ‘code’ and ‘forms’ depending on how many forms there are or how much code. In ‘code’ folder it is recommended to have another level of folders if you have a lot of files.
4. If you have a lot of JavaScript or CSS files, it is good to have source versions for them as well as minified versions. This way they will be lighter on load, and you will have source versions for debugging and development.

Preparing for Optimization

To make the most of the loading process, you need to know what page are you on. Based on that you can perform different operation and load different files. Make sure you set a variable with the page file name or some other identification. On admin side, WordPress pages are identified by the file name loaded. Your own plugin pages can be identified by the ‘page’ variable from the URL request . To get the name of the file, name of the page and more, you can use this code:

$_current_file = end(explode("/", $_SERVER["PHP_SELF"]));
$_current_page = isset($_GET["page"]) ?  $_GET["page"] : "";
$_doing_ajax = defined("DOING_AJAX") && DOING_AJAX;
$_doing_cron = defined("DOING_CRON") && DOING_CRON;

Based on this values you can pretty much know exactly which page is loaded, and what you need from your plugin to load. This can be executed in the main/loader plugin file. I have added two more variables to determine if the page is loaded for AJAX handling or while doing Cron job.

Optimization Recommendations

Here are some of the important recommendations you should follow:

1. Analyze your plugin code, and decide what you need loaded on admin side, what on front end, and what on both. When you do that, you can go further and decide what you need loaded on all admin pages, and what on some of them (your plugin panels). Based on that, you will end up with many smaller files. Make some convenient naming scheme so that you can easily find files and use them in loader.
2. Always use main plugin file as loader. Even for simple plugins, this is best solution because you will have easier time later to expand the plugin. Don’t keep any code that is used by the plugin there, only decide what parts of the plugin you need to load.
3. Try to use classes as much as you can. Also, try to have only one class in a file, or at least put classes that depend on each other in one file. Use some logical naming convention for files, so that name gives you quick association to the class inside. PHP can help you with auto loading of files based on the required class, and you can find more info on that at the end of this tutorial.
4. Separate all AJAX handling code into own file. When your plugin on the server-side needs to handle AJAX requests, don’t add all that into file that is always loaded. It is easy to decide if the WordPress is loading to handle AJAX request, and only then load AJAX handling file. This goes only if the AJAX is handled by the WordPress admin-ajax.php file.
5. Always handle all AJAX calls through WordPress admin-ajax.php. This will save you a lot of headaches, and it can be used for both front end and admin side. Making your own handler file for AJAX is never good idea. If you need help with using admin-ajax.php, here is a good post in the WordPress.org Codex on using AJAX in plugins.
6. Separate all Cron jobs handling code into own file. Similar to AJAX handling, Cron jobs executions are run in own page/thread call, and you can always determine if that is the case. If you have cron jobs in your plugin, move all its handling functions and classes into files that will be loaded only when Cron job is executed.
7. Any other code elements that are needed for some panels only, or in some specific cases, keep in own file(s) and load them only when needed. This can be code that handles individual panels, AJAX handling, CRON handling, saving data… The better you identify what you need and make smaller files to load when needed, you will get better optimized files.
8. Handle all plugin settings through WordPress options database table through get_option/update_option functions (or get_site_option/update_site_option for multisite network wide settings). Never save individual settings as separate options, this can create a mess and will be hard to update and maintain. Put all your settings in one or more array’s (depending on the scope of settings you have). These settings are all loaded with a single SQL query when WordPress loads, and you have them ready when your plugin loads.

PHP Auto Loading

PHP has several methods to trigger automatic loading of files, based on the required code. If you split your code into classes, you can set up autoload functions that will do loading of files based on the class name. This can be very good solution for a plugin that has many classes used as modules, or used only in some cases. It is recommended to have one class in one file. More info about this you can find here: Autoloading Classes on PHP.net. Comments on that page have some really great examples on how the auto loading works.

GD Press Tools Pro Debugger: Snapshots

Measuring the optimization

My GD Press Tools Pro plugin can be used to debug and track WordPress loading. Tracker in this plugin has functions you can use to create snapshots that will contain used memory, hooks, SQL queries and time. You can use these functions in your code to measure how much resources some are used during different stages in the loading process. Plugin has a lot of other things to help you debug the code, find errors, track loading, track WordPress query, enqueued scripts and styles and much more.

There are some other plugins you can use to debug WordPress, but no other plugin allows tracking of the loading and the level of detail as GD Press Tools has.

Conclusion

There are many things you can do to optimize your plugin to use less memory and to load faster, and to have less impact on overall loading of WordPress. This article doesn’t cover everything and you will not be able to use all the recommendations for every plugin. But, good analysis, good code splitting and loading and tracking your optimization progress will always give you good results. Better optimized plugin is later easier to support and expand.

Plugin is tested with WordPress 3.3, and no problems were found. Some minor issues are fixed (warnings, nothing important). Plugin is split in two, so that the admin side code is loaded only when needed. This will improve overall loading speed of, already, lightweight plugin core. For WordPress 3.3, plugin uses new context help area to add important links and information.

As always, check out the Pro version of the plugin and many more features that are built into it.

GD Custom Posts And Taxonomies Tools Pro:
http://www.dev4press.com/plugins/gd-taxonomies-tools/

New Year 2012 coupon for 25% discount is NEWYEAR2012. Coupon is valid starting now until Sunday, January 8 2012. All our products are eligible for this deal, and all prices on the website show the discounted price. For the next 3 days you can get all our plugins pack with lifetime (one payment only) license for only $300,00. And you can get GD Press Tools Pro lifetime license for only $126,50. GD Custom Posts And Taxonomies Tools Pro lifetime license is also only $126,50.

Since a lot of admin side operations done by the theme are done through AJAX, all those operations are now separated into own file that is loaded only if the WordPress is processing AJAX calls. Because of this a lot of code is moved from main settings and admin classes into new AJAX class. Main admin and theme classes are optimized and all the code needed only for the theme panels are moved into separate GUI class that will handle all panels rendering.

With all these changes, theme now allocates about 20% less memory than before. Memory usage can be even lower if you disable some of the modules or widgets if you don’t use. Depending on what xScape modules and widgets you have active, theme can use even less memory. All modules and widgets make up for 20% of total resource usage for xScape. Used memory can now go from 4MB to 7MB depending on active modules and widgets. Most memory is used on the xScape panels due to the loading of panles GUI, on other areas, xScape uses much less memory and same goes for the front end. This is very conservative use compared to other theme frameworks available on the market.

Work on the framework and new themes will resume by the end of January. Until them, if you notice any problems with new framework, please report them as soon as possible in the comments or in the forums.

bbPress 2.0 Embeding: Advanced Controls

This new version continues with more optimization for plugin loading, and now we have another 10%-15% less memory used on admin side. Some minor optimization is done on the front-end to load plugin parts more selectively.  As for the bugs this version includes reported bugs fixed: saving and switching between full and simple edit modes for default post types and taxonomies, minor problems with hiding taxonomies meta boxes, minor styling issues with plugin editors and some issues with import and export of plugin settings.

For bbPress 2.0 plugin integration, you can specify the location in the forms where yo embed the selected metabox. Also, plugin can include CSS and JS for advanced controls for bbPress integration: color picker, date picker and number. Subforums can now inherit meta boxes set by parent forums. Integration works with the edit forms also, so all saved meta values can be edited.

Notice: Please, test all the changes and all the existing features to make sure that optimization done in this version didn’t broke anything. I have tested this version for couple of days, but with so many changes you never know what might be broken.

As announced before, next major 3.6 version will include several important new features, and work on it will begin in late January.

GD Custom Posts And Taxonomies Tools Pro Overview:
http://www.dev4press.com/gd-custom-posts-and-taxonomies-tools/
GD Custom Posts And Taxonomies Tools Pro Home Page:
http://www.dev4press.com/plugins/gd-taxonomies-tools/

If you are new on Dev4Press, Core theme is basically a child theme. Parent or main theme is called xScape Core. We are currently converting all our themes to new Core/Child theme versions. lightScape is next on the list, and is now available in this format. Old, standard theme version is no longer updated. Here is the info about Core conversion: http://www.dev4press.com/2011/tutorials/xscape-framework/xscape-core-themes/. It can happen that after update, some theme template layouts can’t be edited. In that case, you need to reset the layouts for the theme. This is very, very rare and I only have seen it once during tests, and it might not happen at all. If you notice any problems with templates for the theme, or bugs in display, please leave the comment here or in the forums.

xScape Theme Framework 1.8 will be released on Monday bringing massive optimization for the framework loading and few other changes. There will be no new features, just a cleanup and optimization to start with further development in 2012.

This year Christmas coupon for 40% discount is XMAS2011. Coupon is valid starting now until Christmas: December 22, 23 and 24. All products are eligible for this deal, and all prices on the website show the discounted price. For the next 3 days you can get all our plugins pack with lifetime (one payment only) license for only $240,00. And you can get GD Press Tools Pro lifetime license for only $101,40.

Don’t miss this great opportunity. Merry Christmas!

With REL change, you can set REL attribute like this: lightbox[%ID%]. ID will be replaced by ID for the current topic or reply. Other tag to use is %TOPIC% that will be replaced by current topic ID.

Next major version (most likely 1.6) will include the error log admin panel to review all logs and to allow deletion of the logged errors and other features. 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

Last week I have published a benchmark of all 4 latest major versions in the 3.x line. I am sorry to say, this is first WordPress major version in 3.x line that is a step back in terms of performance and resource usage. WordPress 3.2.1 remains fastest WordPress among all 3.x.x releases. In some areas, WordPress 3.3.0 is even slower than, year old, WordPress 3.1.4. Over the past week many users after upgrading to WordPress 3.3 noticed slower admin side on their websites. You can find discussions threads on WordPress.org forums, on Twitter and on many websites with some users had trouble upgrading and ended up with broken websites.

Upgrading WordPress problems and slightly lower speed on admin side are not related. This performance drop is not a problem, it is not a caused by a buggy release of WordPress, it is caused by changes made this time, and those changes are mostly UI related. But, before passing final judgment on new WordPress, lets see all the changes and improvements.

Flyout menus

Flyout menus

First thing you will notice when on admin panel, is that menu is not the same. WordPress now uses flyout menus. All top level menus are always collapsed, except for the currently active one. To see contents for collapsed menus, you need to hover over the menu item. So far, community is divided on the new menu design. For me, this is one of the features that was added just of the sake of having new UI feature.

Old menus were working great, this is more a regression considering also accessibility problems for disabled users or users with touch screen devices. Not to mention that you will need more time to get to the panel you need. In any case, it will take some time to get used to it, but in the end, you have to get used to flyouts, I doubt that they will be removed in next version.

Reportedly, new menus work fine on iPad, but they don’t work at all on any mobile phone browser I tried on the phone with Android. Last time I checked, Android has more mobile devices than iOS, but no one bothered to test new menus there. Now, if you use touch device than is not iPad, you will need multiple clicks and waiting for pages to load needlessly to get to the menu you need.

As with any visual improvement, it comes down to personal preference, and I am sure than many users will hate, and many users will love these new flyouts. Too bad that there is no way now to have both new and old and let users choose.

Context Help

As much as I dislike the flyout menus, I really like new context help tab. It opens into a configurable tabbed navigation panel with sidebar area that is really a nice touch. WordPress has all its context help areas converted, and I have done the same to convert context help for my Pro plugins. Hopefully, more plugins will adopt the new help system and use it. For now, here is the screenshot for the context help in GD Press Tools Pro:

Context Help

Admin Bar is now Toolbar

New adminbar has much more functions than before, it can’t be disabled on the admin side at all, and it is called Toolbar. Toolbar is smaller and darker and it integrates all previous header elements and old admin bar. From developers point of view, there are some new things added to the toolbar, like groups in menus and few more functions for better control and better menu items organization.

Still, after using it for a several weeks now while in beta and stable, I would prefer to have old layout back. WordPress logo button and drop-down are not really useful at all to be always on, stupid Howdy is always there (more on that later) and the fact that it is always on and that it can’t be disabled. Right now, only thing that keeps toolbar needed is user menu with log-out option, everything else is not important. I can confirm that I will be adding new tools to GD Press Tools Pro to deal with at least some of the toolbar annoyances. There are few plugins in the WordPress.org repository to handle new toolbar and move things around. Also, users of Ozh’ Admin Drop Down Menu will be frustrated to find out that this plugin is broken in new WP due to the toolbar changes. I expect update soon for that, but having always 2 toolbars on, is not good solution.

New toolbar duplicates needlessly too many things from the menu on the left, and if you remove duplicated options, and options that are useless, you will end up with empty toolbar. That’s why it ended on both my pros and cons list for new WordPress.

New Uploader

Uploader and Media Library

WordPress 3.3 brings new uploader that supports drag-n-drop and is not depending on Flash anymore. New uploader is powered by Plupload library (from creators of TinyMCE). drag-n-drop is supported by Firefox, Safari and Chrome browsers and  Opera to get support with next major version. There are some improvements to the handling of media in this version and all these changes are great addition to WordPress, making adding of files more straightforward, since now all files are handled in the same way. On the editor toolbar, only one button is there to open media library.

Of all new features, drag-n-drop uploader is the one worth switching to new WordPress. If you deal with a lot of images, it will be faster to just drag them to the uploader when working on posts or in the library. Creating galleries will be faster, and more natural.

Core changes

While the most of the visual changes I find lacking, I like core changes. Permalinks are improved to allow proper use of slug only in the post links, and this new permalink format now doesn’t have any speed issues (before it required more SQL queries and depending on number of posts you have could cause problems). Now, the new post name only permalink is even recommended for links structure.

WP_Screen API is also improved to make creating admin panels/pages easier and more WordPress like. Best thing is rewritten editor API that allows for more than one rich text editor instance with no hacks to make it work, and it can be used on front end also. New jQuery 1.7.1 is included, as well as full jQueryUI 1.8.16. Post formats are now more prominent than before and they are available in quick edit mode also. I am not a big fan of formats, but I am sure that all users that use formats will welcome this change, it makes the process of changing post formats much easier.

There are more minor changes to functions, filters and actions, JavaScript used, but they are mostly low-level stuff and you can find all that in the changelog (link at the bottom of this review).

Pointers

Pointers, Welcome and About pages

To improve new users experience, WordPress got some interesting features: pointers, welcome and about pages.

Pointer should help with introduction of changes and features. While they look nice, after few days and several test installations, I find them extremely annoying. I expect that when plugins start using pointers it will make a mess on the page after upgrade. And I expect that we will soon get plugins to  always disable pointers.

About page looks really nice. You can see overview of new features, credits and freedoms tabs. Similar to this, new Welcome message displayed on the dashboard after installing WordPress 3.3 is a nice touch as well:

Welcome Message

There are many minor improvements that I like and that will maybe go unnoticed since they have a natural way about them and they blend into the interface. New toolbar icons and options are really great, new hidden-behind-icon search form on toolbar also. If you are using Tumblr, WordPress has new importer that can transfer data from your Tumblr website to your WP website.

Go away ‘Howdy’!

Removing stupid Howdy greeting from every single page should happened years ago. And yet, it is still here. And, you can’t change it. There are no filters that allow changing this word to something else. There are some complicated methods of replacing whole user item in the admin bar, but I expect that would break something else down the road. A lot of WordPress users hate that little word. It is time to get rid of it. Well, it is too late now, we need to wait yet another major revision for that. Was it that hard to add simple filter that envelops that word? I know it’s not, but some people decided against it. Problem is that now this is forced on front end too, because it is moved to new toolbar and that makes this much worse. Having a serious website on WordPress, with toolbar active, and stupid Howdy greeting your users, it is just wrong.

Plugins compatibility

While we go some new interesting core changes, too bad that they will remain unused for some time. Plugins need to be updated to take advantage of new editor, or new context help and other things. Considering how slow most plugins were updated before, this will take a lot of time. I expect that some plugins will be broken by new jQuery, and some will be broken with new editor. First plugins problems were already surfacing, and I expect more will be found. Good thing is that many developers are releasing updated plugin versions.

My Pros and cons list for WordPress 3.3

Should you upgrade to WordPress 3.3?

Yes, but:

1. Test on the sandbox to make sure that you will have no issues due to plugins or theme
2. Make a backup of whole website, files and database, so you can revert back if things go wrong
3. Try new WordPress locally to see how great new uploader is and to test all the changes
4. Clear the cache in your browser after upgrade
5. Clear the cache on website if you are using cache plugin(s)

I expect that current problems with new WP will be resolved, and I think that we will see 3.3.1 soon. It is important that only small number of users had problems upgrading, there are many factors that can be a problem, and not everything is direct fault of new WordPress. Upgrade problems existed with earlier versions, and will be here with future versions.

More important question is do you need to upgrade at all? Well, that comes to personal preference. There are no security fixes in this version that are discovered from WP 3.2.1 until now, there are no groundbreaking features you must have (except for uploader, but not everyone will need that), so test it and decide for yourself if you need new WP or not.

Useful Links:

• Detailed changelog on WordPress.org: codex.wordpress about Version_3.3
• Support forum on WordPress.org: wordpress.org Support
• WordPress Benchmark – 3.0 vs 3.1 vs 3.2 vs 3.3: dev4press.com Benchmark

Conclusion

My major complaint with new version are UI changes. What was wrong with 3.2 visually? Don’t mention the ‘vertical space’, because it is just a lame excuse. I understand the need to have design changed from 3.0 to get better looking menu with no space on the left, but this version I don’t get. I liked the header we had in 3.2.1, it was small and functional, I liked the fact that admin bar could be disabled. Now, we lost both only to get toolbar with 70% of useless options on it. All the great work done on optimizing WordPress 3.2.1 is undone with this new WordPress and unnecessary UI changes. I would prefer that WP 3.3 had: editor API changes, new context help, uploader and most important core changes.

There are several new things in WordPress 3.3, and many improvements that will be very interesting mainly to developers. Overall, I think that this is an average release, I have updated all my websites to WP 3.3 and I expected that all developers and users closely involved with WordPress will upgrade. But, the fact remains, this is once again mostly design-centric release that makes WordPress a bit different looking without many changes that will make a lot of difference for most people. Major problem with this version is that it lacks wide appeal, and I am afraid that most users will decide against updating. I have written about slow adoption rate of recent WordPress versions couple of weeks ago, and this new version will have same problem as WP 3.1 and WP 3.2 had (at least WP 3.2 was very fast, and even that didn’t help to get widely adopted).

Hopefully, users with WordPress 3.0 or older versions, will decide that it is time to upgrade after skipping some earlier versions. If that doesn’t happen, by the time WordPress 3.4 is released, we will have big fragmentation of WordPress versions on the market, and that is not good from plugins development and support point of view.

What we need in WordPress 3.4?

To stop needless UI changes. To get posts relations. To get usable posts and taxonomies management. To get improved user management. No more UI changes. Seriously, leave UI alone.

What are your experiences with new WordPress? What things you like and what you don’t like? Leave the comment and spread the word about this review.

YOURLS system and plugin are developed by Ozh Richard based on the idea by Lester Chan. I will not go into details about it, it is easy to set up and use, and you can find the link to get it at the end of this review. Main thing here is the other part for this system, plugin to bring the URL shortening to WordPress.

Yourls Service Settings

Plugin is very easy to set up. Install it as any other plugin, and open its settings panel. There are 3 different things you need to set up, and options are well documented. You first need to set the shortening service. You can use public services: bit.ly, tinyURL and is.gd. And you can use your own YOURLS installation. Once you do that, you need to set up the Twitter account. This is also well documented, and it requires setting up the Twitter Application that will be used to sent tweets through. After that, you need to set up the template for tweet message and options to generated short URL’s for different post types. You can set for each post type if the plugin should sent tweet automatically.

Tweet template support number of tags that will be replaced to generate tweet: author (name and all other user data), custom meta fields, category, tags, taxonomies and post elements. When the plugin is active for selected post types, you will get a meta box on the post editor panel where you can see the generated short URL, you can request new short URL and you can see the generated message, and send it manually to Twitter.

Over the past several months I have contributed to the plugin code with support for custom taxonomies, several bugs fixed (including AJAX powered themes like P2 auto tweet problem), made changes in generating hashtags from terms and few other things. Also, GD Custom Posts and Taxonomies Tools Pro has integration support for this plugin, and you can set for each post type different tweet message and control options for generating short URL and sending tweet message.

This plugin is a great solution for generating short URL’s regardless if you use your own installation for YOURLS shortening service, and to send messages to Twitter with control over templates and auto tweeting. I use this plugin on all my websites, I use my own shortening service and I highly recommend you try the plugin for yourself and see how easy it is to use, and how much it will save you time to get short URL’s and to send tweets.

Useful Links

Ozh Richard Home Page: planetozh.com
YOURLS Home Page: yourls.org
Plugin on WordPress.org: wordpress.org
GD Custom Posts and Taxonomies Tools Pro: dev4press.com

If you are new on Dev4Press, Core theme is basically a child theme. Parent or main theme is called xScape Core. We are currently converting all our themes to new Core/Child theme versions. lightScape is next on the list, and is now available in this format. Old, standard theme version is no longer updated. Here is the info about Core conversion: http://www.dev4press.com/2011/tutorials/xscape-framework/xscape-core-themes/. It can happen that after update, some theme template layouts can’t be edited. In that case, you need to reset the layouts for the theme. This is very, very rare and I only have seen it once during tests, and it might not happen at all. If you notice any problems with templates for the theme, or bugs in display, please leave the comment here or in the forums.

In the next week, 3 remaining themes will be converted to Core versions, and with that there will be no more updates for old themes, only core editions will be updated and all new themes will be only core editions. But, more importantly, xScape Theme Framework 1.8 will be released by the end of this month bringing massive optimization for the framework loading and few other changes. There will be no new features, just a cleanup and optimization to start with further development in 2012.

Login Form in WordPress 3.3

With release of WordPress 3.3, some things changed (once again)  with the login form. Because of that, xScape Theme Framework login form support is partially working. New minor revision is fixing the issue, and all themes have updated styling to take the changes into account.

Other than changes in the login page styling, there are several minor problems fixed, new gdr2 library included and added one interesting option to bbPress module. New bbPress option can enable display of lead topic. When the full topic thread is displayed, by default main topic is merged with replies. New options allows you to display them separately.

xScape Core is released, and all themes will get update to support changes in login form. Updated themes will be rolling out in the next 2-3 days. If you notice any more problems caused by WordPress 3.3, please report them in the forums.

You can check out the original tests article to see first tests results here. I got many requests to expand the list of plugins, so in the first test in 2012 (it will be out on January 4 2012) will include 50 plugins. But, the data displayed will be expanded. For each plugin I will include basic data unrelated to tests:

1. Version and release date
2. Developer and website URL
3. Size and number of files
4. Use of JavaScript
5. Use of AJAX
6. Use of Cron Scheduler

As for the tests, we will test everything as before including few new things. Here is the preliminary list of tests for the January test:

1. Memory usage on Dashboard and Home page
2. Loading time on Dashboard and Home page
3. Number of SQL queries on Dashboard and Home page
4. Number of hooks on Dashboard and Home page
5. Number of AJAX handlers counted in code
6. Number of Cron jobs counted in code
7. Number of widgets registered

As for the plugins tested, I will include both free and commercial plugins. If I can’t get to a latest version of some commercial plugins, they will be dropped from the test, I will not test old versions. I will contact some of the developers with commercial plugins to ask for the plugin for test. If anyone can help with commercial plugins, I will be happy to include them in the test. Number of tested plugins will expand each month, and as I said, first month I will test 50 plugins.

I also plan to have similar test for themes, but that will depend on my free time. I will try to have themes tested in March or April.

Leave your suggestions for plugins to include in the first test. If you have test suggestion, please describe the test and the method to conduct the test. Tests will be published each month on the first Wednesday.

It is often needed to know what is happening with rewrite rules and how the current page is resolved and what template loaded. This can be done with GD Press Tools Pro and its advanced debugger. But if you don’t have that plugin, these new functions will help. These new functions are in the documentation now: gdtt_debug_rewrite_rules() and gdtt_debug_page_request(). You can use these functions anywhere in the theme templates and you will get printed data.

If you create post type that has archives turned off (basic plugin feature rewrite setting set to NO), plugin was still adding rules for archives intersections and dates. That is no longer the case, and plugin will check if the post type has archives allowed before generating extra rules. So, check all data for post types to make sure that you didn’t incidentally disabled archives and lost other settings.

Since previous major release, plugin supports direct integration with YOURLS: WordPress to Twitter plugin. To take advantage of some new tags, you can’t do it with official YOURLS plugin version. I have submitted patch with changes, but until that is included in official release, here is the modded version of latest 1.5.3 plugin version with support for taxonomies in twit URL and few more fixes:

YOURLS: WordPress to Twitter 1.5.3 MOD

With new WordPress editor API one bug surfaced causing the content for rich editor custom field to be rendered incorrectly. This is now fixed and control will work fine in new WordPress. If yo notice any more problems with WordPress 3.3, please report them in forum or comments.

GD Custom Posts And Taxonomies Tools Pro Overview:
http://www.dev4press.com/gd-custom-posts-and-taxonomies-tools/
GD Custom Posts And Taxonomies Tools Pro Home Page:
http://www.dev4press.com/plugins/gd-taxonomies-tools/

WordPress Release Stats

Before we get to test results, first thing is to see how this 4 version compare when it comes to size, number of files, hooks, requirements and few other things. Latest version is the version we used to test here.

Test Environment

For tests I have used WordPress 3.0.4, WordPress 3.1.4, WordPress 3.2.1 and WordPress 3.3. Test machine is CentOS powered VPS server with PHP 5.3.3 and mySQL 5.5.14, with PHP memory limit set to 256MB. PHP runs with eAccelerator enabled. All WP installations used only GD Press Tools 4.3.1 Pro plugin, and all had exactly the same content. GD Press Tools Pro had all its security related features activated, and they add about 3 SQL queries per page, and these queries are counted in the results below. Since I run GD Press Tools Pro as a part of all my WordPress installations, I think of it as logical and essential expansion of WordPress.

Each test for each WP version is repeated 10 times, highest and lowest results are removed, and the average is calculated from the rest of the measured values. Same method is used for server and client (browser) side. For client side measurements I have used Firefox 8.0, and before each measurement, all cached data was emptied. I use my faithful Lenovo IdeaPad Y560 with Intel Core i5 and 8GB RAM. Testing is done on 4 most used pages in WordPress: dashboard, posts list, post editor and comments list. Other pages are similar to these 4, and they will not show much difference in overall results.

If you compare results in this benchmark with previous one comparing 3.0 vs 3.1 vs 3.2, you will see that results for these 3 versions are now different. Difference comes from using latest versions of each WordPress, using differently configured server, and new browser. It is interesting to see how much faster is Firefox 8.0 over 5.0 used for old benchmark.

Server Side Execution

For client side I have measured 4 elements: used PHP memory to generate the page, number of SQL queries executed, time server needed to generate the page and number of hooks (both actions and filters) registered for execution. As with any version of WordPress, each new version uses more memory than previous one. But, while first 3 tested versions had number of executed SQL queries in decline, new WordPress 3.3 uses 4 to 9 queries per page more. Number of queries in the test includes 3-4 SQL queries executed by GD Press Tools Pro for security purposes, and it is the same for all 4 tested versions.

With all this, execution time on server-side for WordPress 3.3 is about 10%-15% higher than in earlier version. Number of hooks is expected to rise, just like the used memory. But again, there is a big jump with new WordPress. You can see all data on the charts below.

Server Side: Used PHP Memory

Server Side: Number of SQL Queries

Server Side: Execution Time

Server Side: Attached Hooks

What this mean? In terms of server performance WordPress 3.3 is a big step backward from WordPress 3.2. I am not going into analysis why this happened, or if it was really needed, but the fact is that new WordPress doesn’t add any feature that warrants such change on the server-side.

Client Side Execution

Pages generated by new WordPress are only a bit larger than before, and the same goes for JavaScript used. Interesting thing is that on post edit page new WordPress adds less JavaScript, all thanks to new editor and quick tags code. Hopefully, we will see more JavaScript improvements like this in next versions. But, execution time is another story, and overall, this new version is slower even than WordPress 3.1 in some cases. Similar results are with cached execution, and new WordPress on average is slowest in the 3.x line.

As before, Firefox even with latest stable version 8.0 is still slower than Opera 11.6 or Chrome 16/17. It is not as drastic difference as before, but with Opera or Chrome, pages are loading some 20%-30% faster.

Client Side: Page Size

Client Side: JavaScript Size

Client Side: Execution Time

Client Side: Execution Time - Cached

What these results mean for end-user page loading? The difference is not big, we are talking about half a second slower execution. That is hardly noticeable, but it proves the conclusion from the server-side benchmark: new WordPress is slower than previous one, while in the same time you will not see why that is needed, what new features are so important to justify this performance drop.

Overall performance index

Last chart shows two interesting, overall comparison indexes. First one is for server-side performance, and other for client side. They take into account individual results for each test and each page. WordPress 3.0.6 is referent version for this test and results for it are normalized to 1.0 for all pages and tests. Lower value is better.

Server Side: Speed Index

Client Side: Speed Index

As you can see, speed index for each of the pages shows that WordPress 3.2.1 remains superior to new WordPress 3.3 in terms of performance. If we want to compare overall for client and server-side, look at the last chart bellow. Overall, WordPress 3.3.0 managed to cling to second place thanks to some of the improvements, like WP Editor API and some other JavaScript changes, but it is very close to WordPress 3.1.4 performance. WordPress 3.3 is some 7% on server-side, and (too) big 14% on the client side off from WP 3.2.1.

Overall Speed Index

Website front-end

I didn’t test new WordPress on the front-end. From using it in the past few weeks while in Beta and RC, I didn’t noticed any changes. I imagine that using some of the permalinks structures will improve speed due to permalinks changes, but other than that all 4 WordPress versions in 3.x line have very similar performance on the front end.

Conclusion

I can’t end this benchmark on a positive note as I did back in July for WordPress 3.2. I can understand that WordPress is evolving and that new features can need more resources. But, in WordPress 3.2 six months ago, features and changes were followed by considerable optimization, and that resulted in faster WordPress. This time, we got no significant new features or improvements, apart from cosmetic ones (and some of them are questionable at best) and some changes that affected only some features (uploader and editor), and yet new WordPress is gone back a full year in terms of performance, and it is comparable to WP 3.1 or even WP 3.0 in some cases.

I am sure that some developers will say that these results are not important. I agree that half a second is not much in terms of speed and that most users will not even notice the difference, but it shows that current development of WordPress is not done right. Adding new features and sacrificing speed and resource usage is not a good way to go. Big part of the blame is on development cycle, that is targeting 2 major versions each year (well, we got whole 3 major versions this year alone). Because of that, testing and optimization is not high on priorities list, developers don’t have enough time for everything. Even now, 3.3 is about one month late from projected development roadmap.

I really hope that this new WordPress performance is a ‘glitch’ in the development, and that next WordPress 3.4 will get it back on track. I also wish that WP 3.4 takes more time, and not to be rushed by May or June just for sake of having new WordPress. Lets have 9 to 12 months development cycles, and I am sure that released product will be better and more appealing to end users to get with faster upgrades.

For now, WordPress 3.2.1 is clear winner in terms of performance and resource usage between all 4 major releases in 3.x line.

Edit:

Server side Memory and Hooks charts replaced with new ones where Y axis starts from 0.

Warning: Plugin is not yet completed, and it is not recommended to use it on the live websites. Right now, from all the planned features for 1.0.0 release, admin side is 90% done, and front end is 90% done.

As the bugs go, there were few minor issues with the templates, and problem with saving currency unit properties. Beside that, there are couple of new features added. There is a working widget to display single product (you can specify product type, filtering and template) with only one specific template right now (more to come soon). Archive templates are improved to support page navigation, and there is a simple and advanced. Simple is only next/previous links, while advanced shows numbered pages. All archive templates use advanced navigation right now.

By the end of next week 0.9 Beta will be out with more filter/search improvements and few more new minor features. Please report any issue you might have with this latest version.

Important: If you had problems with theme templates created with previous plugin versions, you need to create them again. Plugin has a theme template option to overwrite old templates with fixed ones.

Plugin Test Drive

If you want to try out the plugin before deciding on buying, use the contact form to request demo website set up for test drive. There you can try out all our plugins and themes.

Promo coupon

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

Resources

Theme Templates Integration:
http://www.dev4press.com/2011/tutorials/plugins/gd-products-center/theme-templates-integration/
Product Type Editor:
http://www.dev4press.com/2011/tutorials/plugins/gd-products-center/product-type-editor/

Plugin Info

Planned Features:
http://www.dev4press.com/2011/blog/development/planned-features-for-gd-products-center/
Plugin Information:
http://www.dev4press.com/plugins/gd-products-center/
Editions & Purchase:
http://www.dev4press.com/plugins/gd-products-center/editions/

Options for this are found on the Settings panel, on the Administration tab. Find Sender settings (as on the image bellow), and set the email and name you want to use. Now, all the emails sent through WordPress and your website will use these settings. You can set only name and email will be auto generated.

Change email from

This is simple to set. Open Global Settings, and on Users tab, find Authorization block. Enable checkbox and set number of days you want. All login cookies after that will use new number of days for expiration.

Cookie Expiration

Plugin now supports 16 different units, and more will come. But, in this version, plugin is only gone through optimization based on the plugin impact on WordPress benchmark I did last week. So, now plugin is only loading on admin side.

You can download plugin for free from Dev4Press website, or from WordPress.org plugins repository.

Dev4Press Home: http://www.dev4press.com/plugins/gd-unit-converter/
WordPress.org: http://wordpress.org/extend/plugins/gd-unit-converter/

Warning: Plugin is not yet completed, and it is not recommended to use it on the live websites. Right now, from all the planned features for 1.0.0 release, admin side is 90% done, and front end is 90% done.

Bugs fixed in this version include: you can change product type name (this is fixed, and name can be changed only if no products are added for the product type), product type name wasn’t cleaned up properly and it could have empty spaces left in, built in default theme templates for TwentyTen and TwentyEleven themes had some problems causing product pages to appear empty (new templates are added) and some of the integration functions had minor issues that are now also fixed.

Plugin front page info

Plugin front page is beginning to take shape, and on the right you can see detail screenshot of that page showing registered product types with basic information.

When adding templates to the theme, you can now use overwrite option, to create templates again and revert them to default state (useful to fix issues with previous version broken templates). Also, after you edit product type, you will get direct option to create theme templates. Each product now has a simple meta box to display pages statistics and how many times each of the product pages has been displayed.

Compare pages got own tracking now, and each time a compare page is displayed, plugin will save information about products compared, user ID (if logged in), user IP and time.

Important: If you had problems with theme templates created with previous plugin version, you need to create them again. Plugin has a theme template option to overwrite old templates with fixed ones.

Plugin Test Drive

If you want to try out the plugin before deciding on buying, use the contact form to request demo website set up for test drive. There you can try out all our plugins and themes.

Promo coupon

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

Resources

Theme Templates Integration:
http://www.dev4press.com/2011/tutorials/plugins/gd-products-center/theme-templates-integration/
Product Type Editor:
http://www.dev4press.com/2011/tutorials/plugins/gd-products-center/product-type-editor/

Plugin Info

Planned Features:
http://www.dev4press.com/2011/blog/development/planned-features-for-gd-products-center/
Plugin Information:
http://www.dev4press.com/plugins/gd-products-center/
Editions & Purchase:
http://www.dev4press.com/plugins/gd-products-center/editions/

In the past couple of months Amazon made many changes to their AWS services and they added support for China, Italy ad Spain local Amazons. With this, some of the products groups have changes and all that is updated for all Amazon locales. To use new Amazon locales, you need to add associates ID’s for them. There are links to register for all of them from the plugin settings panel.

Promo coupon

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

Demo Website

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

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

Plugin Info

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

Measurement Process

For this article I have tested 35 plugins. This includes both free and commercial plugins, big and small plugins and all of them are tested on the admin side and on the website frontend. All tests are done with a single installation, and WordPress 3.3 RC1 was used. Tests are done on the local server with PHP 5.3.8.

Testing exact impact of plugins on WordPress is not easy, since there are two things that happen during the loading process. First part is WordPress loading the plugin (using PHP include function). Second part is done through actions and filters added by plugin to WordPress during loading stage. First part is not to complicated to measure and that is what you have in the table below. Second part is very complicated to measure because it would need tracking of each action or filter executed. This second part is even more complex if you take into account that different actions and filters are executed only on some of the pages or panels.

All measurements are done using GD Press Tools Pro 4.3.1 plugin. Plugin has a tracker class that can be loaded from wp-config.php file to accurately capture snapshots of different loading stages (among other things). To allow capturing plugins snapshots, I made small change to WordPress core files: added snapshot call into loop that loads plugins.

Measurement Results

35 tested plugins are listed in the table below. You can see how much memory each plugin needs during loading, how many SQL queries are run and how many hooks attached to WordPress, as well as the total time needed for this loading stage. All this is done on the admin side (dashboard) and on the frontend (home page).

This data can change depending on the page used to do the testing since plugins can loading different things based on the page. But, these numbers are good reference point to see how the loading of plugins affect the WordPress. Also, you can see on average (and total) how much each plugin adds to the WordPress loading. What each row color means:

I have mentioned the second part of loading that happens after all plugins are loaded, and WordPress runs actions and filters after that. Table below shows the difference between the WordPress with 35 plugins and WordPress with no plugins. Before plugins loader results are same for clean WordPress and WordPress with plugins.

Interesting thing is that you can have all 35 plugins active, and I had some WordPress setups with more than 70 active plugins. But, be ready for the WordPress using much more resources. The more plugins you have active, the more server power is needed. Plugins will have negative impact on website speed. To fix that you must use a caching plugin (W3 Total Cache for caching pages and minify the JS and CSS files) and some sort of server based optimization (eAccelerate or similar extension for PHP).

Clean WordPress will work with 32MB set for PHP to use. You can have less, but some internal operations might need a bit more, so 32MB is safe minimal value. If you have a couple of plugins, 32MB should be enough. If you have more than 10 plugins, at least 64MB is needed. As you can see from this test, for 35 plugins I had here, you need more, and 96MB or 128MB is safe value. Some shared hosting companies will not let you have more than 64MB or 80MB, so you might have issues with many plugins if you are on some restrictive hosting companies. Consult hosting support to make sure you will get enough resources. You can use average values above to get some orientation value for memory needed.

Optimization Analysis

As you can see in the plugins table on the top, some plugins results are in different colors. Green colors are for plugins with good optimization, red colors are for plugins with bad optimization. Badly optimized plugins are always loading everything on front-end and on admin side and they take a lot of memory. Smaller plugins with less than 0.8MB of memory used are not a big problem and they usually can’t be much optimized considering number of plugin files.

Since most plugins are behaving different on admin side and front-end, they should be taking care of what will be loaded in both cases. Only files that are actually needed should be loaded. This is not always possible, but with little extra work, code can be separated to allow for better loading optimization. Considering how much memory some of the plugins use, it is essential to try and lower required resources. Most WordPress users are on shared hosting servers, and they need plugins that are optimized.

The Bad

Plugins with worst loading stats and worst optimization from this test are: bbPress, GD Star Rating, Subscribe2, The Google+ Plugin, WooCommerce and YOURLS WordPress to Twitter. bbPress should be loading parts of the plugin only when needed, considering that forum is usually separated from normal WP pages. You can have some core parts always loaded, but most things are not needed on every page. My own GD Star Rating is old plugin, and I made some optimizations in some versions, but I need to do more, and GD Star Rating 2.0 will be highly optimized to use resources. The Google+ Plugin loads many libraries that are not needed for the most part, and for a simple plugin that this should be, it uses a lot of memory. I can’t judge quality of WooCommerce plugin, but I couldn’t believe how bad loading for this plugin is, and its main file loads 32 other files always. I have noticed some other things done bad in this plugin only from first few files, but loading is really bad.

Few plugins are a bit better than this, and they have lighter red color: BackupWP, Events Manager, gdHeadSpace4, GD Products Center Pro, GD Unit Converter, GravityForms. BackupWP doesn’t need anything on front end but it still loads things always. Events Manager has some loading optimizations, but I see potential to make it much better. I have modded plugin into gdHeadSpace4 and I didn’t make changes in loading. This plugin doesn’t have big memory footprint, but some changes can be done. My GD Products Center Pro is still in beta, and I plan to finish loading optimization before releasing 1.0 version. Another of my plugin GD Unit Converter is 100% admin side plugin, yet some things are loaded always, and I will improve this soon. GravityForms requires a lot of things on both admin and front end side, but there are some things that can be optimized much better that they are now.

The Good

Contact Form 7 and WP e-Commerce could benefit from some minor changes, but they are good as far as optimization goes. Light green and good optimization is done with: Antispam Bee and BackupBuddy. BackupBuddy would benefit greatly with better main loader file that is now too big. With fragmentation of this file, will help with optimization further.

Best optimized plugins, considering plugin size and features are: GD Affiliate Center Pro, GD Press Tools Pro, GD Custom Posts And Taxonomies Tools Pro, W3 Total Cache, WordPress Download Monitor, WordPress SEO. My 3 Pro plugins all have advanced loaders and modular structure to load things need for admin side or front end. Even the code used for Ajax or saving data is separated and loaded only when needed. W3TC does a great job in loading of different plugin modules and same goes for WordPress SEO by Yoast has loader that loads different files on both sides, minimizing the impact on WordPress.

My GD Press Tools Pro and GD Custom Posts And Taxonomies Tools Pro can replace great many other plugins, and that alone can save you a lot of resources. If you can have 10 plugins and if each one uses 1.3MB on average, that is 13MB, you can replace with GD Press Tools Pro only (and it can replace much more than just 10, maybe 60 or more plugins), that will use only 2.9MB.

Loading used in my plugins

Process of loading for my GD Press Tools Pro plugin is controlled by main plugin file. First, it loads parts of gdr2 shared library (used by all my plugins). Public functions and classes are loaded next (they are used on both admin and front end side). Some parts of internal code are loaded next. Main plugin class is loaded after that, and this class is used to initialize the plugin and load plugin settings. Than, loader checks if its loaded on admin side. If it is, admin core class is loaded as well as some extra functions. And if the plugin is loaded to save settings or through AJAX call, it loads separate settings saving or AJAX classes. This all improves loading on front end side by some 30%. This loading method is changed over time, and I think that it works great right now.

Two plugins I ALWAYS use

I can’t imagine running WordPress website without my GD Press Tools Pro. It is truly ultimate administration plugin, and it does so many things that you simply need on any website: backup, sitemaps, SEO, optimization and integration… Second plugin is W3 Total Cache. Page caching, external files minify and support for CDN are something each website should use to improve website speed.

Cached Pages

If you use W3 Total Cache or some other similar caching plugin, and you have page cache enabled, it is important to know that when cached page is served to a visitor, WordPress (and plugins) are not loaded at all. All these tests are made when there is no page caching active.

Conclusion

As you can see, plugins can have big impact on WordPress. While you can have as many plugins as you like, there are things to consider:

• Compatibility: the more plugins you have, there is more chance to have some of them causing problems. Always test plugins when adding new plugin, it is rare, but it can happen. I always have local copies of all my websites, and when new things are added, I always test locally before moving to live server.
• Resources: the more plugins you have, the more server resources will be used. If you are on the shared hosting, I recommend that you review if you really need all plugins you might have already. Test different plugins you can use, because with too many of them active, you can easily hit the limits imposed by your hosting company. My GD Press Tools Pro can do many things, one of them is to measure data like this, and you can see exact impact of a new plugin added on memory, mySQL server or WordPress.
• Loading Speed: more plugins == less speed. It is very important to use cache plugins to optimize front end loading, to minify external files and use CDN to load external resources.

I hope that other plugin developers will consider the results from this article, and my recommendations to improve loading for own plugins to optimize them so that end users get faster plugins that are not needing too much resources. Lets make plugins even better.

FTP class had some issues with retry procedure, that was likely to fail after first broken connection. This is now fixed, with help from Frank. Low level tracking class had some initialization issues that are now fixed. Debugger module was missing one simple check that caused debug info embedded even when not needed.

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

Links and Resources

Here is the list of tutorials that you might find useful:

Easy cleanup for your WordPress website
How to backup and restore your website
Using GD Press Tools 4.2 Backup
Using GD Press Tools Auto Tagger

Comparing GD Press Tools Pro versus BackupBuddy:

GD Press Tools Pro versus BackupBuddy

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