jQuery 1.9.1 (currently in WordPress 3.6 development builds) removes some core functions that many plugins rely on, and that includes live() method for event binding, and all other bind related functions. In jQuery 1.7.1 a new method is added: on(). So, we need to have all plugins jQuery code updated to use on() instead of live() and bind(). jQuery 1.7.1 is shipped with WordPress 3.3. And because of that, all plugins will get updated jQuery code that will require jQuery 1.7.1 and with that will require WordPress 3.3.

Currently, there was a plan to change requirements for some plugins to WP 3.3, and that plan will go ahead earlier than planned (GD Products Center and GD bbPress Toolbox). And some plugins already require WP 3.3 (GD Custom Posts And Taxonomies Tools 4.1 Pro that will be released this week). But, now all that is changed, and there will many updates during April to stay ahead of WP 3.6 launch. It is very possible that WP 3.6 is not going to be released until late May, depending on how many delays there will be.

During March there are 3 releases planned:

1. GD Products Center 1.2.1 (March 26), it will still work WordPress 3.2.
2. GD Custom Posts and Taxonomies Tools 4.1 (March 27), it will require WordPress 3.3.
3. GD bbPress Toolbox 1.5 (March 31), it will require WordPress 3.3.

In April more updates are coming, all will require WordPress 3.3:

1. xScape Theme Framework 1.9.2 (middle of April).
2. GD Products Center 1.2.2 (in late April).
3. GD aZon Fusion 0.9.7 (in early April).
4. GD Affiliate Center 1.4 (in late April).
5. GD Simple Widgets 2.2.1 (middle of April).
6. GD Press Tools 4.4.2 (in late April or early May).
7. All 3 bbPress free plugins (first week of April).
8. Other free plugins that rely on jQuery (in late April).

Some of these plugins all rely on jQueryUI, and they will also get latest available jQueryUI.

And in the future, plan is to limit support for maximum of 4 versions of WordPress. Once WordPress 3.7 gets in development, minimum required WordPress for plugins and themes will shift to WP 3.4, or WP 3.5 (for some plugins, depending on what they need or do).

My suggestion is to make sure that other plugins you use are also ready for the WordPress 3.6 transition, since now you need to worry about jQuery too, and I think that a lot of plugins will not be ready for such upgrade. Try to reach to developers of plugins you use and remind them of the upcoming changes to WordPress so they will have enough time to prepare for it.

WP activates maintenance mode when upgrading active plugin, or when in network/multisite environment. In same very rare cases, this mode doesn’t get disabled after the upgrade. But, you can disable it using FTP. Simply, open FTP and connect to your website, in the website root directory where wp-config.php, wp-load.php, wp-login.php and wp-admin are, you will see file called: ’.maintenance‘. Yes it starts with the dot, just like .htaccess does. Simply delete that ‘.maintenance‘  file and your website will start working again.

If you don’t have FTP access to your website, you can use access through your hosting control panel or you need to contact your hosting company and get their support people to remove that file for you.

WordPress 3.4 is very similar to previous 3.3, and only some of the API changes can affect plugins. There is one major API change that is not yet supported: old ThickBox powered popups are replaced with new ones. But, for now, to avoid compatibility issues with older WP versions, all Dev4Press plugins using ThickBox, with continue to use it.

If you notice any problems with any of our plugins and themes with new WordPress 3.4, please test with latest WP versions and report back what the problem is, if you have some errors logged or problems with JavaScript. Open new thread(s) in the forums and describe the problem in details. Also, make sure that you are using latest plugin versions.

New Settings Panel

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

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

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

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

newsScape Specific Styling

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

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

There are many cache plugins for WordPress. Some are only for a specific cache related use, and some implement all caching methods. If you want to use only a specific caching method, best solution is to get specialized plugin, if you need more – go with all in one solutions. Here on Dev4Press, cache is controlled by W3 Total Cache. Before we go into specific caching methods, there are some server features that can be used and that you may consider installing.

Why do you need to use cache?

Well, most important thing is speed. With one or more cache methods used, your website will be faster without expanding and upgrading the server. Faster website means that your visitors will get to information quicker, and slow websites are known to lose visitors that don’t want to wait long time for page to load. Also, search engines are taking website loading speed into account.

So, using cache will have some impact on the search engine rankings, will save you money on upgrading server and will improve visitors interaction.

Memcached

This is general purpose solution that is made to work across multiple servers for distributed storage of cached data. Data is stored in memory, and oldest values will be removed if allocated memory runs out. This is a good solution if you need to use multiple servers with a lot of memory and the servers are within the same network.

PHP Accelerators

There are several different accelerators available but most popular solutions are: APC, XCache and eAccelerator. They are storing compiled byte-code of PHP scripts into the memory. Normally, every time a script is executed PHP loads it and and compiles it. If you use accelerator, PHP runs pre-compiled byte-code from memory eliminating overhead of recompiling on each request. Here are some test results for loading of WordPress 3.3 with 3 different accelerators in use.

Accelerated WordPress 3.3 Loading

As you can see, use of accelerator for PHP will improve speed about 3 times. Accelerators can run on their own regardless of the cache plugin you decide to use, and you can’t use more than one accelerator in the same time. One more thing that accelerators can do is to work as object storage, and you can cache data also using functions.

Cache Methods

Page Cache

This is the most popular caching method available, and the method that brings biggest speed improvements. Normally, when page is requested, server loads WordPress and everything else needed, code is compiled and executed. So, for each request server needs to load PHP, to load all required files and compile and execute all. Depending on the server power this can take a different amount of resources and time to complete. If you use accelerators on the server this can be faster due to storing of compiled code. But, you can save even more.

Cache plugin is changing how the page is loaded. When a page is rendered with PHP and you get HTML to output to the browser, cache plugin saves that output as a plain HTML file. Files are stored in the folders that mimic the permalinks structure. Each file is stored as HTML and GZIPPED HTML (well, this depends on the plugin you use). Cache plugins need to modify HTACCESS, and add new rewrite rules. These rules check if the user is logged in and if it is not (checked through cookie), HTML file is loaded. So, when cached page is loaded PHP is not used at all and WordPress is not loaded! User gets simple HTML content from a single file and that is it.

This has some drawbacks: cached data remains the same for every visitor. Cache plugins allow you to rebuild cache from time to time to get new content in (once or twice a day typically, on busy websites once every couple of hours). Also, cache rebuild is run when new content or comment is published. Biggest problem is how to get dynamic data into the page even for visitors. Well, most common method is JavaScript and AJAX (my GD Star Rating plugin does that to get real rating values), and some cache plugins allow special tags in the code to markup the dynamic content. There are different implementation, but basic principle is the same for all cache plugin that use page caching method.

Typical gain in speed with page cache can be up to 10 times over normal non cache loading. Combined with some PHP Accelerator (for logged in users), you will get much faster loading. Accelerators have no impact on speed of page cache, since cached pages are HTML only.

Browser Cache

You can speed up loading on the client side only, by setting up proper request response headers, instructing browsers to store data for later and to load data from local storage on next visit. With this, loading of next pages on one website can be much faster if browser stores JavaScript, images or CSS files to reuse.

Through HTACCESS file you can set up handling of different file types by using expire time, cache control, entity tag and compression. Some WP cache plugin allow you to set this up for HTML, JavaScript, CSS and image files.

Minify Files

Typical page is not only HTML to be loaded by the browser. In most cases, to display the page, additional files are linked from the main HTML file, and that includes JavaScript, CSS and images. While you can’t change images that easily (it is always good practice to optimize them though some optimization software before using on website), you can make changes to JS and CSS files.

This process includes compression of JS and CSS files (special optimization of the code so it takes less space) and combining multiple files into one file. So, if you have 5 CSS files loaded on each page, with minify process you will get one file instead. With JavaScript typically you can get one or two files (one in header, other in footer). Same principle of compressing the code can be used for embedded JavaScript and CSS.

CDN: Content Delivery Network

Very important thing to speed up your website is to have some of the files loaded from some other server. If you have 20 images, JS and CSS files loaded for each page, you can set up CDN network that will allow you to have only main HTML file loaded from your server, while all other files loaded from CDN server. There are different methods to this, but must common one is called Mirror. You set up your CDN server (there are many companies offering this service), and you set up CNAME record on your server to point to the CDN server.

Change URL’s to all external files to use new CDN based URL and that’s it. CDN server will automatically pick files requested through CDN URL and store then on many storage locations (usually in different parts of the world), and when next time someone requests a file that is on CDN storage, it will be loaded from there, and not from your website. CDN can help offloading a large amount of traffic to your website generated by images, videos, JavaScript or CSS files.

But, process of changing URL’s can be very complicated, so cache plugins can do that for you automatically. With all plugins this is very easy to set up, and it depends on the CDN service you are using. CDN is not a free service, but the money you invest in this will pay off since you will save on your own server expanding, and you will have much faster website for your visitors.

Cache used on Dev4Press website

Server where Dev4Press is located uses eAccelerator for PHP. And it uses W3 Total Cache plugin with these cache methods active: page cache for visitors, minify JavaScript and CSS, browsers cache and CDN. Minify process helped by merging 7 JavaScript files into 2 files, and by merging 9 CSS files into 1 file. Typically on each page CDN is used to load 20-30 files.

With all the cache optimizations active a home page on Dev4Press.com (according to Pingdom Full Page Test) loads for 0.857 seconds for 71 requests and 660KB of page size. Without any of the optimizations, home page takes 17.5 seconds to load. That is 2042% gain, or 20 times faster with cache!

Conclusion

There are more cache methods available, but in my experience objects or database cache are not worth using due to problems it can cause and marginal speed gains.

How much you will gain with different cache methods depends on many things including server speed and configuration, use of CDN, cache plugin(s) you use… In some cases you can’t use all cache methods, and it is best to experiment until you find what works best for you. There are many plugins available, different CDN services to use. I hope that this article will help you understand how some of the cache methods work to decide what to use.

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/

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/

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!

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.

Currently all my plugins support WordPress 3.0 or newer (except one that depends on features added in WordPress 3.2). But, with the soon to be released WordPress 3.3, I would need to support 4 different major versions of WordPress. So, I was making plans to drop support for WordPress 3.0 when the WordPress 3.4 goes into development next year. But, I wanted to research this a bit to see how many websites are actually using each of WordPress versions. WordPress.org statistics page has WordPress versions distribution data, and you can see this data on the chart below.

To my surprise, WordPress 3.0 is still very dominant, while 3.1 and 3.2 together are used on about one-quarter of all WordPress powered websites, and all older WordPress version prior to WP 3.0 are used on 22.6% of all WordPress powered websites. WordPress 2.9 is almost 2 years old, and yet 11.1% still uses this version. But, for me, the most alarming thing is that WordPress 3.0 is still the most used version of WordPress.

WordPress Versions, Global Usage

So, what is the problem? Why global adoption rate of new versions of WordPress is so slow? I did some calculations based on the latest download counter on WordPress.org. As of today, WordPress 3.2 has 13.000.000 downloads. While that number looks impressive, in terms of adoption is really not. This number includes both 3.2 and 3.2.1 versions. Let’s assume that many users downloaded WordPress more than once, for development servers or some other reason (maybe 1.000.000 duplicated downloads, well, I have downloaded each of WP 3.2 versions at least 100 times for development). Also, let’s assume that people who decided to upgrade to WP 3.2, upgraded to 3.2.1. Some were switching to 3.2.1 directly, but that is hard to figure out. So, let’s say that based on number of downloads 6.000.000 websites actually upgraded to 3.2/3.2.1. Still looks impressive? Consider that official WordPress stats say that there are 35.000.000 websites using WordPress (this doesn’t include WordPress.com), this is only 17% of all WordPress powered websites switching to WP 3.2, and this is in line with 16.2% from the global usage chart on top of this article. As I said, 13.000.000 downloads doesn’t look so good at all. All these numbers and calculations are not very precise, but they are in the ballpark to illustrate the state of WordPress upgrades.

WordPress Versions by Dev4Press Users

These numbers are for all the websites WordPress.org gathers data from. On the other hand, I have made a similar chart based on data gathered by Dev4Press website from users of our Pro plugins and themes. Thankfully, this shows the desired trend of adoption, and WP 3.0 is going down, with WP 3.1 and WP 3.2 on the rise. If this trend was to continue, WP 3.0 will almost fade out for Dev4Press users in the next 6 months, before WP 3.4 is released. Good to see that WordPress 3.3 in Beta stage is already in use.

This big difference in usage shows that Dev4Press users, in this case, are more informed about the current WordPress development than the general WordPress user base. I expect that any other WordPress based business can expect similar data and trends for their users. These are more technically oriented users or users ready to embrace the progression of WordPress development, and they are upgrading websites to take advantage of new features or to make sure that they have latest security improvements and bug fixes.

With WP 3.3 coming soon, we still have 29.000.000 websites that didn’t upgrade to WP 3.2, and almost 7.000.000 that use pre WordPress 3.0! Why is this so bad? Well, there are few reasons:

1. As with any other software, it is a fact that old versions have bugs and security risks. This is true for WordPress also, and we have millions of vulnerable websites using WordPress. While it is a great thing to have big part of the Internet powered by WordPress, it is frightening to know that most of these websites are not secure. Bug fixing for new versions are great, but they don’t mean much if most website will not upgrade anyway.
2. This makes plugins development very hard, considering that developers need to support several very different WordPress versions, or to decide to drop support for older versions. This can be a good thing, if the users are forced to upgrade. But, many websites are postponing upgrade because of old and outdated plugins, and this is main reason we still see 2.3 or 2.5 on the chart. New WordPress and old plugins is an old problem, and I don’t see solution any time soon.
3. Money. Yes, for old websites dependent on old and no longer developed plugins, moving to a new WordPress is not cheap. In some cases, new plugins with similar functionality can be used. In most cases even if there is a new and different plugin, it will be incompatible with old plugin. So, website owner need to pay, in some case a lot of money to get old plugins fixed and upgraded, or rewritten.
4. WordPress development is not really driven by the needs of wider community. Many website owners I talked with, that use old WordPress, don’t feel the need to upgrade, since they have all they need with WordPress they are using. We may like it or not, but frequent interface changes in WordPress are not something users like to see, because very often they need to learn things they may not need at all. It is easier when users upgraded to each new WordPress, because changes are comparatively smaller, making a jump from 2.3 or 2.5 to 3.3 now, is a huge change, almost like using completely different system.
5. For a community so big as WordPress is, there isn’t a single website that can be considered as information center for all things WordPress and it is not a big surprise that website owners are not well-informed on current status of WordPress, plugins and themes development. And when I get a question from a user: ‘where can I find information on all things WordPress’, I honestly can’t recommend any website. I believe that lack of quality information is one of the major problems with adoption of new versions.

How to solve all these problems? How to improve the number of websites willing to upgrade and how to have a more secure websites running on WordPress. I know about all the obvious methods like better education of users on upgrade benefits, or improved security, but so far, that is not done properly at all. Individual efforts by people with work based on WordPress, have an effect on a very small number of users. Global community of WordPress website owners is not really affected at all by that. There are a couple of things I can leave as a suggestion:

1. WordPress.org based information portal would be best source of information. Right now, WordPress.org website is not useful to majority of users. Codex is largely used by developers or users that want to do things themselves, Forum is again a bit too technical, Plugins Repository is mostly a mess, News and blog are very limited in scope. I know that improving that website is not easy, but in the past 2-3 years hardly anything was changed there, apart from few updates to repository and small updates to Codex.
2. Slower development cycles. Right now, goal is to have two major WordPress releases each year. That is too fast, too many versions are in use already, and each year 2 more are added to the mix. One new WordPress version each year would be better, to allow users to get familiar with new versions, to have fewer changes and problems to worry about. Current core developers and contributors would have much more time to develop, much less chances to have bugs (most bugs are caused by haste) and maybe to focus their development time to WordPress.org.
3. Better literature. I know of many good WordPress books, but they are mostly written by developers for developers. I am still to see a good book about using WordPress. Even when such books are published, they are already outdated due to fast development cycle of WordPress. Only book that I know to be updated from time to time (still, development book for the most part) is Digging into WordPress by Chris Coyier & Jeff Starr.
4. Objective and open news websites. I am sad to say, but that there are no such websites now. There are some smaller websites that try to be informative, but they don’t have enough reach. The big, ‘the best’ WordPress websites are far from that. I know that editorial policy is internal matter for each website, but basic fairness in dealing with WordPress related services and products is not much to ask. I have personally experienced double standards from some WordPress websites and I know many fellow developers that had same bad experience. Whatever influences exclusion of information (money in most cases, or conflicting interests), is very bad for  the community and it creates a negative reputation for WordPress.
5. Better co-operation of developers. We have a lot of plugins, even very popular plugins that don’t play well with other plugins. In many cases, there is no will to resolve the issue. And that causes problem to end users that try to make their website work after upgrade and are getting broken because of the plugins. Many developers, even developers of commercial products, simply don’t care what they plugin or theme will do to the website and other plugins.

This was a lengthy article, but I think that current state of WordPress and slow adoption is a very serious matter that is not only about the fact that users don’t upgrade on a regular basis, but that WordPress developers and core of the community is not doing the right things to inform and educate about WordPress and related products. And I tried to include all things I considered relevant for the current state.

I would like to hear from you what do you think about current state of WordPress, about updates and how often do you upgrade your websites. What are most common problems you have when it comes to upgrade?

I am using latest trunk code for WordPress 3.3 for a week now, and even now, I can feel the performance improvements that are continuation of the work done with WordPress 3.2. These are not drastic changes, but many things in WP are improved: improved permalinks performance, some meta and navigation menu changes and many UI improvements. CSS used by WP is optimized further to load less files and have less of it, so that also is noticeable during page load.

Admin bar is looking a bit different, with darker look and few pixels less height (you can see it in action already on WordPress.com). Some of the important admin bar elements use improved dropdown and some of the admin side elements are further integrated into admin bar. So, admin side pages don’t have normal header as before: website name is now also part of the admin bar, and same goes for tabs for Screen Options and Help. This makes admin pages looks cleaner, but it makes admin bar a must have element on the page, and disabling it will leave you without many options you are used to have by now in the page header. Is this good or bad, it depends on you, but it will take some time to get used to. New admin bar can’t be disabled from Profile page for admin side anymore.

Improved Menus

But, there are two great additions to UI: improved menus and pointers.  As you can see on the image on the left, if the menu is active, it is displayed as before (Users menu in this case). But if you hover over the menu (Appearance) you will get nice popup menu for it. This way, you can find much quicker page you need.

Pointers are nice addition to admin side UI, and they are used to inform user about some changes in the WordPress or plugins (there is a way for plugins and themes to use it). So, after WP is upgraded, you will get a pointer with info and links on update. If a plugin gets updated, it can use similar pointer to let know user about changes. Image below shows a pointer to admin bar with Screen Option and Help icons in the bar and the new admin bar slimmer and darker look.

Pointers and Admin Bar

Dashboard now has auto size option, allowing it to resize based on the display used, so it can have different number of columns on different devices. This also means that menu will automatically collapse if the screen is smaller.

New uploader

But, most important changes are in the editor and uploader. Uploader dialog now supports drag’n'drop and uses Plupload library instead old Flash based one. Depending on the browser this new library can downgrade to different upload methods. Firefox and Chrome support drag’n'drop, and it is expected that Opera will get it soon.

Post editor uses latest version of TinyMCE, but the code behind it is changed to allow better re-usability of the editor. Right now there are few methods (none of them working well) to have rich editor on the admin page, but with latest changes this should be really easy to do. New WP will have jQuery 1.6.4, jQueryUI 1.8.16 (finally complete version with all components), editor API for easy use of editor anywhere and improvements to scripts enqueue process.

Many of these new features  are still in development, and WP is not yet usable for live websites, but it is stable enough for testing and for improving plugins to use new features. I will be adding support for it into Dev4Press plugins in the next month, but for now, there are only few visual issues with my plugins and new WordPress.

Current WordPress development cycle is working nicely, smaller set of changes for faster development, and changes coming in 3.3 for the most part are really great. I think that new admin bar will get mixed reception, but the rest of UI changes, API and performance improvements are gold.

Front Page

New minor revision is here with few new features and several bugs fixed. New features are debugger tools to display WordPress or system created error logs. Front status page is expanded with few new PHP related settings. And several bugs are fixed in this release.

Debugger Tools panel got two new features: WP Error Log to display content of debug.log file created if you set to use WordPress controlled error log file, and Error Logs to search WordPress folders for system created error log files if the server is set to create different error log files in the folder where the error occurred.

As for the bugs, broken post tags panel is now fixed, display of extensions status on the plugin front page if extension is missing, missing login button from admin bar and minor issues with pinned posts dashboard widget.

Links and Resources

Here is the list of tutorials mentioned in this post:

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

Promo coupon

To get 30% discount for this plugin (for yearly recurring payments standard and developer licenses, coupon is applied to initial payment only): GDPT42PRO. Coupon can be used until September 5 2011, so hurry up!

New Icons

Plugin already supports custom icons for the post types used for admin menu, but for that you need to prepare and upload image you want to use. And the way WordPress uses that image, it will never look like a built-in menu icon used by default. So, now plugin allows you to select from the icons that are built in with the plugin. There is a selection of 100 icons available from the great Fugue icons set created by Yusuke Kamiyamane. On the image on the right you can see few custom post types using these built-in icons.

To support WPML plugin and translation of custom fields names and descriptions, all print and echo functions used to render the meta boxes now use translation functions that WPML can pick up and filter.

Rest of the changes include improvements to widgets rendering, changes to JavaScript used to attach images to terms and loading and initialization of plugin. Export settings options is fixed to allow selecting parts of the data to export.

Please, report any problems with new icons or with attaching images (old code was causing problems in Firefox 6 and Opera 11), in comments or in the forums.

More about GD Custom Posts And Taxonomies Tools:

http://d4p.me/gdtt

Page tag for the meta elements rendering was broken, and some post type related functions were missing. That is fixed now. Meta box for posts belonging to custom post types is added. Support for archives for custom post types is also included.

Initial release post:
http://www.dev4press.com/2010/blog/development/modded-plugin-headspace2/
gdHeadspace4:
http://www.dev4press.com/plugins/gd-headspace4/
Original Headspace2:
http://wordpress.org/extend/plugins/headspace2/

New blog is using latest WordPress with P2 theme, and only 5 plugins: GD Press Tools Pro, Dev4Press Updater, Akismet, W3 Total Cache and YOURLS. All new posts are automatically sent to Twitter, and you can subscribe via RSS to all posts or only selected products/tags. Blog is available on this URL:

dev.dev4press.com

Anyone can read posts and comments on this blog. To leave comments, you need to have account on this website, and with Dev4Press account you can log to Development Blog and leave comments. New posts will be added anytime I start working on bug fixing something, or adding new features, preparing release. Anything related to plugin, xScape framework or a theme based on the framework.

Link to this blog is added to top menu on Dev4Press. I plan to add latest posts widget to Dev4Press website soon.

Older WordPress versions (before 2.9) could work with 16M of PHP memory. Even later 3.x versions can work with so little memory if you don’t use any plugins. But, using plugins increases memory requirements, and using only 32M is at most times not enough. For latest WordPress with average of 20 plugins you will need 48M to 64M. Most hosting companies keep this value at 32M, so when you upgrade WordPress, upgrade plugin or add new plugins, you will run out of memory and you will see variation of this error (on screen or in log, depending on server settings):

Fatal error: Allowed memory size of 33554432 bytes exhausted (tried to allocate 345234 bytes) in /path/to/public_html/wp-content/plugins/plugin.php on line 56.

To increase memory, you can uses different methods. Examples bellow are for 64MB of memory. You can set it lower and experiment with higher values. Setting this to 128M or 256M is fine also, PHP will really use as needed, this value is limit. Use only one of these methods, don’t use all of them in the same time!

Method 1: Change PHP.ini

On some shared hosting servers and on VPS or other dedicated hostings, you will have access to php.ini file with all main PHP settings. This file should have memory directive, so you need to find it and change it, if it is not there, you need to add it. Here is the directive you need to find/add and set different value for memory size:

memory_limit = 64M

Method 2: Use .htaccess

If you don’t have access to php.ini, same thing can be done using .htaccess file. This file is in the root folder of your website, if it’s not there you can add it, but in most cases it is added by WordPress. This file is only available on Apache servers. Again, search for this in that file, if it is not there add it, and set memory value you need:

php_value memory_limit 64M

Method 3: Use WordPress wp-config.php

WordPress way to do this is using almighty wp-config.php file. If this define is in the file, change it to memory value you want, if it’s not there add it before “That’s all, stop editing!” comment in that file. Here is the code to find and change or add if not there.

define('WP_MEMORY_LIMIT', '64M');

Method 4:  Contact your hosting company

If you don’t want to do it on your own, you can always contact your hosting company support. Some hosting companies can impose limit to this value, so no method you can try can change it, and only hosting support can change it for you.

GD Press Tools: PHP Status

Check current memory limit and memory usage

Simplest way is to use our GD Press Tools plugin (you can see this with both Lite or Pro version). On GD Press Tools main page you can see the PHP Status block, and there you can find Memory Limit item and value for it. How much memory is used, plugin can add into the footer, and image bellow shows you used memory during the page creation, footer value is most important, that is total memory used for the whole page.

GD Press Tools: Memory usage

Admin side uses about twice as much memory then front end side.

Test Environment

For tests I have used WordPress 3.0.4, WordPress 3.1.4 and WordPress 3.2. Test machine is CentOS powered VPS server with PHP 5.3.6 and mySQL 5.1.57. All WP installations used only GD Press Tools 4.0.9 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. Other than that, no caching plugins, APC on server (or other similar extensions) are used for the benchmark.

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 5.0, and before each measurement, all cached data was emptied. I use 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.

Server Side Execution

For client side I have measured 3 elements: used PHP memory to generate the page, number of SQL queries executed and time server needed to generate the page. WordPress 3.2 uses a bit more memory from 3.0.4 and 3.1.4 as it is expected, but on the other hand, it needs less SQL queries and less time to do it.

Admin, Server Side: PHP Memory

Admin, Server Side: SQL Queries

Admin, Server Side: Execution Time

As you can see, WP 3.2 uses about 1% more memory from WP 3.1.4. In case you add 10-20 plugins (common number of active plugins on any website), this relative difference will remain the same in 1% to 2% range increase.

The only anomaly for the WordPress 3.2, is that it uses much more SQL queries on the dashboard to prepare the page, but considering that page is generated and loaded faster anyway, this is not a big deal. These extra queries are very simple and they are executed very fast. On some pages this speed difference is significant, making WP 3.2 is some cases even 40% faster on the server side. WP 3.1 is the slowest of the three.

Client Side Execution

WordPress pages continue to grow and they need more JavaScript for all the new and improved features. And this size was noticeable with WordPress 3.1, a version that you can feel its slower than earlier one. But now, with WordPress 3.2 we have very interesting situation: pages are growing, but overall loading is faster. As I said, all measurements are taken with no caching in the browser. And first charts show improvement in WP 3.2 but not by much. Things change much more when you take into account that browsers always use cache, and there WP 3.2 shines.

Admin, Client Side: Page Size

Admin, Client Side: JavaScript Size

Admin, Client Side: Page Load

Pages with new WP are some 10% bigger than previous WP 3.1, JavaScript also, and yet times are same or lower. Reason for this is in the speed of the JavaScript code. The extra time needed to transfer more data is compensated by faster jQuery library and all jQuery used code. I haven’t seen detailed of all JavaScript changes in WP 3.2, but the results are impressive.

And all this is with no browser caching. Speed increases much more when you take into account browser caching and then you can see and feel the speed of new WordPress as soon as you try it.

Client Side Execution, Cached

Two charts below show page load time when cache is active, and relative speed change in page load when you calculate page size against load time.

Admin, Client Side: Page Load Cached

In almost all instances, pages load faster when cache is used as it normally is in the browser, and that speed is very obvious. Also, these are Firefox 5.0 measurements. Opera 11/11.5 and Chrome 11/12 are much, much faster than Firefox, almost 50% and even more in some cases, so new WP will be faster if you use these browsers. Just to compare, with Opera 11.5 post edit page in WP 3.2 loads in 2.4 seconds, almost 3 seconds faster than in Firefox!

Admin, Client Side: Relative Page Speed

Last chart shows one interesting comparison. Compared value take into account page size and loading speed with cache and shows relative change between versions. Lower value is better. If we take WP 3.0.4 as a referent version (normalized to 1.0 for all pages), you can see that WP 3.1.4 is slower in almost all cases from WP 3.0.4, but WP 3.2 is faster in all cases from both 3.0.4 and 3.1.4 in some cases even 40% faster, in the case where matters the most: post editor. Post editor is typically the slowest part of WordPress, and now that has changed and all is good.

Conclusion

So, as you can see, new WordPress 3.2 is significant improvement over the earlier 3.x versions. Only issue with new WP is that some users don’t like visual changes. Some of my clients expressed that they don’t like so many interface changes with every major version, and it would be good to leave interface as it is for some time and that interface changes should be reserved for major, number changing versions like 4.0 or 5.0.

For my part, I like new interface, but more I like the new WordPress speed, and I will be switching all my websites to WP 3.2 as soon as I make sure that all plugins I use work with it. Before upgrading to WP 3.2, check out the system requirements of your server. If you want to read more on new WordPress, check out my review. And benchmark of the front end for all 3 WP version is coming in the next couple of days.

GD CPT Tools 3.1: Updated Interface

So, new interface is as on the image on the right, making everything look cleaner, with more uniform coloring. As usually, all plugins will get this style in the future.

Big thanks goes to Roberto Scano for providing Italian translation. New version contains updated jQueryUI (to 1.8.13). As for the bugs, minor problems with meta box editor are fixed and major bug with adding styling on the post editor page is also gone. Plugins own AJAX handler file is finally gone, and now TinyMCE plugin operations are also handled by WordPress built in AJAX handler.

If you find more bugs with this version, please leave comment or post in forum, and it will be fixed as soon as possible. And if you have suggestions for future version, please leave a comment.

More about GD Custom Posts And Taxonomies Tools:

http://d4p.me/gdtt

xScape Core will be released today. For the rest of the themes, you can download and update framework only. Again, best to use Dev4Press Updater to take care of that for you. To use new comments.php template you can find more info at the end of this post.

Once again, xScape is updated for latest changes in bbPress 2.0. Right now you need RC1 version of the plugin for new xScape module to work. Google Web Fonts module got another 10 fonts. WP 3.2 adds some changes to the login form, and that is now followed for xScape login styling, also now including new options for shadows for the login box.

Most important change is with the comments.php template. Template is handled by the framework, and has several improvements for better translations support and few other changes. All themes will still work with own comment templates, but if you want to take advantage of new file, you can just replace that one file. No need to release full theme for this minor change that is not even needed at this point. You can download replacement comments.php file bellow.

Replacement comments.php file

Promo Codes

During this and next month, you can take advantage of big summer sale and 40% and 50% discounts. Hurry up, offer is limited to number of licenses each promo code can be used: xScape Themes Big Summer Sale.

Demo Website

Test all themes, and try them with a free test drive, for both front end and back-end before deciding what is right for you. Free registration is disabled, so you need to send the request for the test account using the contact form.

Demo Loader: http://xscape.info/load/
Demo Home: http://xscape.info/

Warning: This is a development snapshot of the upcoming version, and its for use only on test environments. I try to make even alpha versions as stable as possible, but still I can’t recommend that you use this plugin version on your live websites.

Enhanced Menu

Development of GD Press Tools 4.1 will take some time, since there are many features planned for this one, and plan is to have several alpha stages. Each stage will bring one new feature made as stable as possible, for testing, and bug fixing in next alpha version. This first alpha is released with bug fixes (minor sitemap problems, admin bar toggler visible in IFRAME elements and some warnings and notices in PHP), uses updated jQueryUI 1.8.13, adding changes for WordPress 3.2, enhanced color coding for admin menu, using timepicker for scheduling backup and sitemaps and new color scheme for the user interface.

Improved color scheme

Menu items (image on the left) uses different colors for different groups of menu items, that also depends on the WordPress mode (multisite, network mode…).  New color scheme for the user interface is simpler, doesn’t uses so many colors and now relies on black, red and white only. New interface looks better, especially in the new WordPress 3.2.

Alpha #2 is coming on Tuesday, and it will include scheduler for the Auto Tagger with more options on getting the tags for posts (post type filters and few others). Please, test new version and report back any bugs you may find with both old and upcoming WordPress versions.

Plugin is relatively easy to install and setup, and this video shows the whole process from installing plugin, explaining forums, topics and replies, creation of static pages based on templates, bbPress compatible (and not so compatible) themes and basic info about using xScape themes with bbPress 2.0 plugin.

xScape Theme Framework has built in support for bbPress with templates based on the original templates in bbPress default theme, and because of that it will make easy switching to xScape powered themes without loosing previously created functionality. To read
more about plugin and xScape themes visit links bellow:

xScape theme Framework:
http://www.dev4press.com/themes/xscape/
bbPress Home:
http://bbpress.org/

Bug fixes include minor problem with auto generating one of the labels for custom post type (Parent item with colon), it was using plural instead of singular label. You might wanna fix that with your post types. Taxonomy registration procedure had a minor bug with non cached registrations, now fixed. Registered meta boxes were not properly displayed on the post type panel.

As for updates, custom field shortcode has a new filter that can be used to change the output for the custom field value. A function is also added as alternative to WordPress default get_post_meta that uses shortcode method to get value. As for the meta box, you can select default location where to display meta box on the post editor page. And custom field has a new content type: select box that gets data from predefined functions. You can register functions for this field. Function needs to return array with keys and values, and they will be displayed as a choice. Tutorial on this is coming tomorrow.

If you find more bugs with this version, please leave comment or post in forum, and it will be fixed as soon as possible.

More about GD Custom Posts And Taxonomies Tools:

http://d4p.me/gdtt

Bug fixes this time are connected to limited meta boxes replacements that were not working properly for non hierarchical taxonomies. This is fixed now, along the invalid height for this new meta box if there are too many terms. Deleting taxonomy with delete terms option enabled was acting up, and that is also fixed now.

GD Custom Posts and Taxonomies Tools Pro 3.0.2

WordPress 3.2 is coming soon, and one of the changes is updated interface. So, plugin now have additional styles for new WordPress. Also, some general styling changes are added to improve the way the plugin looks. In the next few versions, interface will get updated styling and better color scheme with less color contrast. Other changes include improved JavaScript code.

If you find more bugs with this version, please leave comment or post in forum, and it will be fixed as soon as possible.

More about GD Custom Posts And Taxonomies Tools:

http://d4p.me/gdtt

There was a minor problem with flushing rewrite rules when adding new post type or taxonomy, and that is fixed now. Also, flushing of rules is added when post type or taxonomy is deleted. Each post type or taxonomy adds many new rules into the system, and if you experiment with them, its a good idea to remove them if no longer in use. With Front option for taxonomy rewrite options was broken, and it was always set as true. This is now fixed. Also, displaying post type or taxonomy function was incomplete and some of the settings were missing. That is also now fixed.

If you find more bugs with this version, please leave comment or post in forum, and it will be fixed as soon as possible.

More about GD Custom Posts And Taxonomies Tools:

http://d4p.me/gdtt

Since WordPress 3.2 Beta is released now, I have made preliminary tests for GD Press Tools and new WP. Except for few styling issues, everything works fine. Plugin version 4.0.9 includes fixes for these styling problems. Detailed report on new WP Beta is coming next week.

Admin bar toggle

Debug panel is expanded to include info about $_SESSIONS super global and details for all registered post types and taxonomies. Fixed bugs include: pinned dashboard widget had invalid edit link and invalid security report on plugin front page.

Main new feature for this release is toggle control for admin bar. You have control of the position from the right side, default status for the admin bar (opened or closed) for both admin and frontend sides. In network mode, global settings for admin bar can override individual sites.

Announcement for 4.1: http://www.dev4press.com/…press-tools-4-1/
GD Press Tools 4.0 Pro: http://www.dev4press.com/gd-press-tools/

When new module is added, xScape wasn’t able to apply settings for it, and initially it appeared blank. Now, that is fixed. Web Fonts module is a bit changed and it also have one more option for adding important! to styles override. All themes have own default set of fonts for major title. If you don’t want Web Fonts, simply disable it. Also, there is a video explaining how the module is used, so check it out:

Google Web Fonts Module: http://d4p.me/1ac

To see the theme and framework in action, visit the WordPress MultiSite powered demo website. You can get your own demo website to test themes controls. If you want one, use contact form.

Demo Site: http://xscape.info/

R8 with Google Web Font

Image on the right is example from R8 with custom Google Web Font. Currently module for Google Web Fonts contains 62 fonts to choose from, more will come in next versions.

To see the theme and framework in action, visit the WordPress MultiSite powered demo website. You can get your own demo website to test themes controls. If you want one, use contact form.

Demo Site:
http://xscape.info/

R8: Front Page

This is a bit out of the blue, but, here is the brand new theme called R8. Theme features new xScape Theme Framework version 1.6.2 and 8 built-in color schemes and has a third top navigation menu under the header. Also, it uses Nivo slider with even more customization options.

R8 is the theme I am developing with GD Star Rating 2.0 to integrate and test all new plugin features. But, I managed to assemble theme very quickly, and it’s a shame to leave it waiting for next two months, so here it is. Right now, theme is fully functional, and over time it will get specific GD Star Rating 2.0 features as the plugin development progresses.

Theme has 8 color schemes built-in, it uses Nivo slider with wide range of settings per template basis, 3 navigation areas in the header (extra menu are is added above main menu). As with all other themes, all xScape features are implemented, there are 2 sidebar areas (only one is on by default) and footer widgets area.

xScape Theme Framework 1.6.2 will be available for download later today, with all themes updated in the next 2 days.

To see the theme features and read more about new R8 theme or watch introduction video, check the main theme page:

R8 Info:
http://www.dev4press.com/themes/r8/

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/
R8:
http://xscape.info/load/?theme=r8

This is the current list of features GD Search Tools plugin will have:

1. Use of MySQL FULLTEXT index for indexing posts and comments table.
2. Support for natural language and boolean types of search as supported by MySQL.
3. Implementation of filters based on content type and other criteria.
4. Expandable search context with additional data types.
5. Use of AJAX to get search results with on the fly filtering.
6. Logging of all the search requests into database.

Plugin will have predefined templates for displaying search forms and search results with filtering so you can get it to work with any theme. xScape Theme Framework will support new plugin with all themes. List of features is far from complete, and there is always room for more suggestions. Plan is to get current planned features into first stable version, but all good suggestions will go into the future features list.

Pricing for the plugin is yet unknown, but it will be comparable to GD Press Tools. As of yet, I am not sure if plugin will have Lite version, but it’s not impossible. I hope to release first test versions by the end of May 2011.

Menu Designer with Yellow Target

Menu designer got a very interesting feature I like to call ‘target element’. When you making big menu with many elements, it can be tricky to use only drag’n'drop to move things around. Now, you can mark element that will be used as target, so adding new menu item will go as a child into target menu item. Image on right shows how the designer looks like. Yellow button is target, and when you click on it it will get black circle. Only one element can be target at one time. If you click on target element, target will be removed, and new items will go to the end of the menu.

Several obscure bugs with menus are fixed and also, menus and layout manager support new WordPress 3.1 custom post types archives. In the theme folder you have a new file called custom.php. This will be loaded by the framework, and it’s recommended that you put your own code there. You can use functions.php for same purpose, but it’s good to have alternative.

eScape 1.4, photoScape 1.7 and Focus 1.0.1 updated yesterday, already have new xScape 1.6.1. All other updated themes will be uploaded to Dev4Press with new framework today and tomorrow.

Test all themes, and try them with a free test drive, for both front end and back-end before deciding what is right for you. Free registration is disabled, so you need to send the request for the test account using the contact form.

Demo Loader: http://xscape.info/load/
Demo Home: http://xscape.info/

Both themes are complete as the features go, and they will get updates only when something major is changed in xScape to require changes in the themes. I don’t plan to release minor updates for both themes if not required, but framework only updates will work as always.

To see the theme and framework in action, visit the WordPress MultiSite powered demo website. You can get your own demo website to test themes controls. If you want one, use contact form.

Demo Site:
http://xscape.info/

newsScape Dark

Number of framework related fixes are applied to this new version, template for Google Adsense powered Search is added, and there are some fixes in some of the default templates. New version now includes 18 default color styles.

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/

Focus: Front Page

Theme number 8, Focus is released. This is first xScape theme to feature new jQuery powered highly customizable Nivo slider. Theme has 14 color styles built in, allows for control panel background control and has different templates for both normal blog or magazine style layouts.

Focus Slider Settings

Theme has 2 menus, top menu can be moved bellow the main menu. Nivo slider has tons of options to set and use thumbnails, numbers or bullets for navigation, many transition effects and also if the slider is full width or same as content. Categories posts area can have 2 or 3 blocks with different categories and adjustable number of posts. Content has two layouts: block (like on the image) or listed. As with all other themes, there are two vertical sidebars areas and one footer widgets area.

Background settings are same as in the previous FrameFX theme and allows you to set image or color as background with many ways to set it up. To see the theme features and read more about it or watch introduction video, check the main theme page:

Focus Info:
http://www.dev4press.com/themes/focus/

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/
Focus:
http://xscape.info/focus/

Plugin adds date year, month and day based templates for archives and adds ID based post templates, that, as far as I know will work fine. But, post types templates for archives are a bit of a problem.

For WP 3.0, plugins added type-{post-type}.php and type.php templates support for archives of custom post types posts. WP 3.1 added standard archive-{post-type}.php template and for various reasons, type templates stopped working. Plugin implements several functions and enhancements that don’t play well with WP 3.1 due to conflicted functionality, so last plugin version 2.6.2, added some warnings and more info on how to use the templates.

GD CPT Tools: Settings

Many users of Pro version liked the idea of custom post types archives and used them with the plugin long before WP got them, and now is the problem compatibility of using both. So, on the plugin Settings panel you see options, and first two are now clearly marked as WP 3.0 options. So, if you use WP 3.1, disable these.

Third option from the top is to add type based templates to WP 3.1, but that is not working as you expect it now. On some installations is OK, but not on all. It all depends on the existing rewrite rules and on some installations is conflicted. I still have no idea why this happens, and I am trying to determine what is happening with WP template loader to cause problems.

Solution to problem is simple, and it involves renaming the existing template. So, if you have custom post type movie, and your existing template is type-movie.php, simply rename it to archive-movie.php. WP 3.1 will now load this template and everything will work, and all the code you already have will be used.

But, I will still try to determine why the loading of additional template for custom post types fails in WP 3.1, and you can expect solution in some of the following plugin versions.

Intro

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

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

Cache Functions

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

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

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

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

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

Example: WP Menu Cache

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

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

To use cache, code will change to this:

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

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

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

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

gdr2 Library

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

Conclusion

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

Settings panel is displaying info on WP version for custom post type archives, so change it depending on version of WP you use. Still, you can enable type based archives for post types for WP 3.1 if you need them, but be careful so that rewrite rules don’t clash with something else. Custom post types registration procedure is updated a bit, and also new filters are added to override the settings and options plugin generates for post types and taxonomies. Terms list and term cloud widgets are updated with random and  slug added for ordering terms beside names and counts.

gdr2 library is updated with latest version that has some improvements to widgets, core classes and functions.

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

List of added tags will depend on the taxonomies registered and it will be available in the list of tags, so you can try it our. Main tagger class is updated and cleaned up a bit to remove some old, duplicated and outdated code. Please, test new features and changes and report problems in the forum or in comments.

Initial release post:
http://www.dev4press.com/2010/blog/development/modded-plugin-headspace2/
gdHeadspace4:
http://www.dev4press.com/plugins/gd-headspace4/
Original Headspace2:
http://wordpress.org/extend/plugins/headspace2/

xScape Context Help

Context help shows a list with links of tutorials that are relevant to that panel. List of tutorials will be updated with each xScape version. Next version of xScape will add context help extensions for some native WP panels like Widgets or Posts.

Experimental support is added for upcoming WordPress 3.1 post formats. Right now, you can enable it from Global Settings panel, Integration tab. If active, xScape will register theme support for all commonly used post formats. Formats add CSS styles to post blocks, and it can be used to style them differently. On a later date, I will rethink the way xScape can use post formats in full capacity.

Widgets are improved, and now each one includes the option for displaying widget to everyone, logged in users or visitors only. This way you can have ads widget hidden from registered and logged in users. Similar option is added to Ads Manager and each ad space can control display in the same manner. Also, video widget is improved allowing display of more than one video in the same time. Contactable module now can include URL of the page from where the contact message is send in the message, with new template tag. Other widgets have updated options to include display option as all the other xScape widgets also. Images icons used by xScape  interface are now merged into a single image for better reuse and a bit faster loading of the interface panels. CSS files are also improved and optimized.

Main update in this version is change in layout manager blocks that allow display of thumbnails (sliders for instance). Before, you could choose only xScape custom field image. Global settings could be used to override it and display post featured image or first image from the post. Now both these options are allowed as a choice in the layout manager, making the use of images much easier and comfortable.

All themes will be released during the day with new framework. Some of them have some fixes and improvements also.

Test all themes, and try them with a free test drive, for both front end and back-end before deciding what is right for you. Free registration is disabled, so you need to send the request for the test account using the contact form.

Demo Loader: http://xscape.info/load/
Demo Home: http://xscape.info/

Install Panel

Plugin now has Install New panel that will show products available for your API key and is not installed already. And you can install them with a single click. It can’t be easier, all done from WordPress panel.

Update panel works pretty much like as it did before, with some minor styling changes. Another option in the menu is added for checking for updates directly, anytime.

To see new plugin in action, you can check out the video bellow.

With each backup, plugin is saving the log file with backup job details and backup progress and status. This file can be included in the archive file. Running backup now is not creating one time only job, but it’s running job in the background, and plugin is waiting for the response on the job process and if the backup is successful it’s adding it to the list without reloading the page. Scheduling jobs allows you to set how many old archives to keep, so you can set daily backup job that will keep last 7 archives only, and remove backups older than that.

Backup works for normal WP installations and with multisite/network installations allowing super admin to backup everything, and individual websites admins can only backup their own files and database tables. GD Press Tools is the only backup plugin for WordPress that supports backup in multisite environments!

List of archives is displayed on the image below. You can now delete and download archive, you can upload it to CDN or FTP manually and you can see the log file.

Backup Archives

If you use job scheduling, all schedules for backup you make will be available on the Jobs tab. For each job you will see list of job tasks, next run date and time, schedule interval. You can delete jobs in the list.

Backup Jobs

Backup for files is unlike anything seen in any of the WP backup plugins (both free and commercial). You can backup full installation, only files belonging to individual blogs (in multisite environment), or you can do partial backups. There are several predefined partial backups: only plugins, only themes, only htaccess and wp-config, wp-contents folder. Using filters, more partial backup tasks can be registered. Also, exceptions can be defined (name of files and folders to match, like SVN or CGI-BIN folders), list of exclude files and folders to skip during backup (no need to backup W3 Total Cache plugin cache storage, or similar folders).

New backup is fully functional already, but if you have any suggestion for it, you can leave comment here or in the forum. There is still time to make more improvements to Backup system.

airScape Login Styling

Both these themes have new xScape Theme Framework 1.5.5, and the rest of the themes can safely be updated with framework only by using updater or download it from your account panel on Dev4Press. New xScape updates many aspects of jQuery and jQueryUI use, and it will work fine with the new version of WP 3.1 that will have jQuery 1.4.4 that caused so many problems to xScape already. more info on that will follow tonight, as well as the release of framework for update for other themes (testing some things with other themes, just to be safe).

With these updates, all themes now support all xScape features added over the past months.

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/

Examples bellow are for WordPress 2.9 or newer. This is re-revised version of last years tutorial, this time with added meta info links block. New method is used that doesn’t require for you to check if the filter is executed for your plugin only. New filters already include plugin name in the filter name.

Additional options

Each plugin row on the Plugins panel has several standard actions. You can add more actions like the link to the settings panel or anything else. You need to add filter function that will be used to add this action(s).

<?php
add_filter('plugin_action_links_$plugin_file', 'add_plugin_links');

function add_plugin_links($links) {
  $links[] = '<a href="index.php">Dashboard</a>';
  $links[] = '<a href="edit.php">Posts</a>';
  return $links;
}
?>

Lines 5 and 6 are adding new action to the plugin row. This example adds link to the dashboard and to post edit page, you can change it to whatever you need. Don’t forget to return $links because this is a filter not an action.

Very Important: On line 2 filter has $plugin_file. You need to replace this with the relative path/name of the main file of your plugin. For instance, my plugin GD Press Tools has a $plugin_name: gd-press-tools/gd-press-tools.php. It has folder name, slash, main plugin file name (with extension), and full filter name will be than: plugin_action_links_gd-press-tools/gd-press-tools.php. Same method will be used in the last expand examples.

Plugin Meta options

Description column in the plugins grid have also number of links. This can be expanded similar to additional options from previous block.

<?php
add_filter('plugin_row_meta', 'add_plugin_meta_links', 10, 2);

function add_plugin_meta_links($links, $file) {
  if ($file == "$plugin_name") {
    $links[] = '<a href="index.php">Dashboard</a>';
    $links[] = '<a href="edit.php">Posts</a>';
  }
  return $links;
}
?>

Lines 5 is there to ensure that you add settings only to your own plugin. Lines 6 and 7 are actually adding new action to the plugin row. This example adds same links as previous one, but, you can add whatever you want leading to your own plugin. In the case of this filter, you must check on your own if the filter is run for your plugin.You must $plugin_name on line 5 with the string as described in the first example above.

Additional plugin info

WordPress shows description from your plugin file. And when the new version is available for update, there is no detailed info about the the update. Adding that is not very hard.

<?php
add_action('after_plugin_row_$plugin_file', 'add_after_plugin_meta');

function add_after_plugin_meta($file) {
  $current = get_site_transient('update_plugins');
  if (!isset($current->response[$file])) return false;

  $url = "http://www.yoursite.com/info.txt";
  $update = wp_remote_fopen($url);
  echo '<tr><td colspan="3">'.$update.'</td></tr>';
}
?>

Function checks to see if you add row to your plugin as the previous function does. Lines 5 and 6 will check if there is an updated found for your plugin. If no update is found, additional row will not be added. You can remove this part, and added row will be always visible. My intention with this code is to display details about the plugin update, you can change it to anything else. You need to echo only TD part of the row, WordPress already echoes TR tag. Function will get contents of the file from $url variable and will echo that file in the row.

Example

Example above shows both functions used in GD Press Tools plugin. First row is a standard plugin info, and you can see Settings action added by first function. Second row is WordPress info that plugin upgrade is available. Third row is info displayed by second function that has retrieved this changes notice from my website.

This example uses same $plugin_name method that is described in the first example.

And with anything that is popular, when your website starts growing, and getting more and more visitors, attacks will increase and attackers will became more inventive to find different ways to get data from the website, user accounts, delete data or just cause you trouble just fro troubles sake. One post to explain what can go wrong and what you can do to improve security is not going to be enough, so I will not even try to do it with this article. I am preparing series of 6 (or maybe more) tutorials on WordPress Security that will be published every 3-4 days starting on December 14 2010, each one concentrating on a specific security area. Tutorials will cover: hosting environment, files and folders protection, using of htaccess, preventing spam registrations, wordpress specific tips and info about securing plugins and themes (mostly info useful to developers).

If you tried to find plugin for WordPress that can help you with security, you will find out many (too many?) plugins that are usually not enough , so you will end up installing several plugins. In the past 2 weeks I have tested over 20 plugins available and I was really surprised to find out that there isn’t a single plugin I am willing to use on any of my websites full time. Several plugins were completely broken, and one of them I couldn’t even activate and many caused far too many problems if left active. Many plugins were not updated for a while, throwing all sorts of warnings after activation. So, as with many other things I needed for my websites, I am adding all sorts of security features myself to already all powerful GD Press Tools Pro.

For some time now, GD Press Tools Pro has options to fight spam registrations, that is now improved with many new options. With new centralized Security panel that is added this week, plugin will get more and more tools and options in the coming weeks spread over 3-4 revisions. All this will be in Pro version only. Some security related features are available in Lite edition.

So, stay tuned and wait for the comprehensive series of articles on WordPress Security starting in the next couple of days.

eScape Maintenance Mode

Important updates for eScape and photoScape themes contain latest xScape Theme Framework 1.5.3.1. Both themes now support all the latest framework features, especially new layout manager custom templates options and add support for GD Press Tools Pro Maintenance Mode.

Before xScape 1.5.3.1, if you use theme upgrade, if you have in the list of files and folders to keep one that actually don’t exists, upgrade will fail. Now, such file or folder will be skipped. So, check always the list for upgrade to avoid problems.

photoScape Maintenance Mode

Promo coupon

Starting now, until the December 14 2010 you can get 25% discount for individual xScape themes and xScape Theme Club Membership. For this discount you need to use coupon: LIGHTSCAPE.

xScape Theme Club:
http://www.dev4press.com/themes/xscape/purchase/

And more

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/