If you are running a plugin named “Dean’s FCKEditor With pwwang’s code plugin for WordPress,” remove it from your site immediately. Note that I don’t just mean deactivate; remove the entire plugin from your site. It is important that it is completely removed as just having the vulnerable file on your server allows people to upload their own files to your site. With this ability, attackers could easily compromise your entire site. So I cannot stress enough how important it is that the plugin files are completely removed.

This is also a good opportunity to remind everyone of the TimThumb vulnerability from nearly a year ago. TimThumb is an image resizer that many themes and plugins used. A vulnerability was discovered that allowed attackers to upload their own files to your site through the TimThumb code. Fortunately, none of our themes ever used TimThumb, but many plugins and other theme companies did. TimThumb was updated to fix this issue, but it may be possible that you have an older plugin or theme on your site that still has the vulnerable code.

Now would be a good time to run the Timthumb Vulnerability Scanner plugin on your sites. This plugin will scan for vulnerable versions of TimThumb and automatically update the code to remove the vulnerability. This is a great way of ensuring that all of your site’s plugins and themes are properly secured against this vulnerability.

Presenting iThemes Builder 3.2. This release is available now in your member area.

This release is a bit special, so I’d like to take a few minutes of your time to talk about it.

As projects get older, they pick up more features, expand in scope, and like many of us humans, put on some extra pounds. With this release, I really wanted to make Builder a lean, mean, fighting machine again. So I dug in deep, benchmarked the code like mad, and trimmed away as much fat as I could. In total, 20% of Builder’s load time and 36% of its memory usage was trimmed off.

While this post will mainly talk about what the efficiency of Builder means to both you as the user and me as the developer, I don’t want to overshadow the other parts of this release.

This release removes both the Billboard and FeedBurner Widget features. Builder customers still get these features as they are now available as separate plugins that you can download in your member area. If you use either of these features, make sure you read my Preparing for Builder 3.2 Release post. But don’t worry, all of your settings will still be there once you install and activate the plugin version of the feature.

Users of the Pods plugin should enjoy this release as Pods now has special support in Builder. Prior to this release, to make Builder and Pods play nicely together, you had to create a pods.php template file in your child theme. No more! Now Builder will automatically use the default Layout on Pods pages. The pods.php template is still supported though, so you can continue to use that if you prefer. In addition, selecting Builder Layouts to use in the Pages setup of Pods is supported in the upcoming 1.12 version of Pods.

For details about the other changes in this version, please read the full release notes.

The short story of the efficiency improvements in this release is that the load time of Builder’s code is reduced by 20% while the memory consumed is reduced by 36%. Not bad if I do say so myself.

If you want more details on what efficiency means, why you should care, and how Builder compares to other themes, please read on.

Efficiency as far as themes are concerned relate to how long it takes for the code to run, how much memory is consumed by the code, and how many database queries are run.

When code takes more time to run, the server the code runs on can handle fewer requests at a time and the page will load more slowly for people visiting your site. Since most people want their sites to handle high-traffic loads (such as when a popular site starts linking to your’s), keeping the load time low is important.

Memory usage doesn’t impact the visitors to your sites directly, but it does affect your hosting. Let’s say that your hosting only allows you to consume 200MB of memory at a time, max, and that your WordPress site takes 35MB of memory to load a single page. In simple terms, that means that you site can handle, at most, 5 people requesting content at the same time before someone either has to wait a bit or your hosting just craps out and refuses to send content to the other visitors. If the total memory consumption on each page load could be lowered to 30MB, your same hosting could now support 6 simultaneous requests. This is an overly-simple way of looking at the importance of being conservative with memory use, but I hope that the point is clear: Having WordPress, your active theme, and active plugins take up as little memory as needed is good for your hosting and your site’s performance.

The number of database queries run on page load is important because for every query run on the database, additional load time and memory consumption is added. Some queries are expensive (high cost of memory, load time, or both) and some are cheap (low memory and load time impact), so finding out how many queries are run is just an indicator of how mindful the developer was of performance and is not a definitive measure of efficiency.

Keeping all of these in mind when developing is important as not all hosting servers are the same. Some have very powerful processors, a huge amount of memory, and very fast databases. On systems like these, improving efficiency typically has very little impact. However, some hosting is slow, dreadfully slow. Since we don’t know where the code will be run, ensuring that our code is as lean and fast as possible means that our code will hold up better on these slower systems and our customers on these slower systems will have faster sites to show for it. A win/win scenario.

So Builder 3.2 is more efficient than the previous release of Builder, how much more efficient is it?

Since comparing Builder against Builder does little to help me understand how Builder compares to other themes, I ran benchmarks with a set of popular themes. If you don’t see your favorite theme in my list, I apologize. I used what I had access to and biased my selections towards themes that are considered to be highly flexible while also including other more simple themes (coding wise) to round out the testing set.

My benchmarks follow. To make the numbers easier to read, I am only showing what each theme added to the total time, memory, and queries used by WordPress itself. So while rending a page with the sandbox theme took a total of .15 seconds, I’m only showing the .024 seconds that sandbox itself added. In addition, rather than showing .024 seconds, I show 24 milliseconds.

You can click on the different headings to sort by that heading. This makes it easy to do specific comparisons.

As you can see, I included four different versions of Builder to see how it fared over time. Builder 2.0 (the last time I focused very heavily on performance improvements) is still the speedy one of the Builder series, and I hope to get it back to its salad days with enough improvements. Given how much more Builder does now though, those days may be out of reach.

Falling consistently at the two-thirds mark for both time and memory, Builder isn’t the fastest of the lot. For me as the developer, knowing what Builder is doing with this time and memory, I’m actually quite pleased with the result.

I also included BuddyPress in the list. This is benchmarking the plugin while running on a completely blank theme, so only the plugin overhead itself is being tested. While BuddyPress is a heavy plugin and most plugins are much lighter on resources, it does add an interesting point of comparison to show how much plugins can add to the overhead of WordPress.

I do want to make sure that I don’t ignite an arms race of performance metrics with themes. I posted these details not because I want Builder to be in the number one slot (it simply wouldn’t be possible for Builder to do what it does and be as fast as TwentyEleven) nor to shame any other developers.

I also want to make sure that users of themes don’t go too crazy over performance of plugins and themes. One theme being faster than another theme doesn’t make it any better. If the slower theme has valuable features, those features typically come at the cost of speed and memory. This is the nature of code.

For users of Builder, I simply wanted to share how important performance is to me and that I’m very serious about making Builder as lean and fast as possible.

For fellow developers, I’ve developed some cool code while doing the performance improvements and benchmarks. I hope to have time this afternoon to start sharing the code I used. If you are interested in how I did anything, please ask in the comments.

For those that just like the chart, I used Google’s Charts API to create it.

I hope everyone enjoys Builder 3.2.

All active Builder members now have Billboard and FeedBurner Widget available as plugin downloads in your member area. You can find them listed below the listing of Builder child theme downloads.

If you are using any Billboard widgets on your Builder site, please install and activate the Billboard plugin before you upgrade to the Builder 3.2 release. If you do not, you may have to recreate your widgets later on after installing and activating the plugin.

The same goes for the FeedBurner Widget features. If you are using any widgets for that feature, make sure you install and activate the new plugin before you upgrade to Builder 3.2.

End of Support for Internet Explorer 6

First, Internet Explorer 6 will no longer be supported by WordPress starting with the 3.2 release. It’s important to know that this affects the dashboard of WordPress and not the front-end. This means that if you are using Internet Explorer 6 and manage WordPress sites, you will either want to upgrade Internet Explorer or install another browser that you can use while managing WordPress sites. We recommend using either Firefox or Chrome.

To make sure that there is no misunderstanding, our themes will still continue to work on IE 6 browsers, even after you upgrade your WordPress site to 3.2. At some point, we too will have to discontinue support for IE 6, but that time is not now. If and when that day comes, we will let you know ahead of time so you can make plans as necessary.

Currently, the dashboard of WordPress 3.2 looks like the following image in IE 6. Things could change by the time 3.2 is officially released, but I wouldn’t expect it to get much better.

Requires PHP 5.2.4 and MySQL 5.0

WordPress 3.2 will require PHP 5.2.4 and MySQL 5.0 at a minimum. This means that you need to make sure that your server is ready to meet these requirements.

Last year, we launched our Are You PHP 5 Ready site to start spreading the word about this eventual requirement. Unfortunately, we don’t have a way to verify that your server’s MySQL version meets this requirement in the same way as the PHP 5 Ready site. But don’t fret; we can still help you.

Option 1: ServerBuddy

The first option is to install and run the ServerBuddy plugin on your site. This is the easiest way to confirm exactly what version of PHP and MySQL is on your server.

Once you have installed and activated the plugin, you can navigate to the ServerBuddy menu item to see a listing of information about your server and site. At the top, you will see a section listing your WordPress, PHP, and MySQL versions. Here is an example from one of my sites:

As you can see from the image, I’m running PHP 5.3.3 and MySQL 5.1.49. So my server is good to go as both versions meet the requirement.

Option 2: call your host

Of course you can always ask your host if your server is ready to run WordPress 3.2. Here is some boilerplate text that you can send to them in a chat or email:

WordPress 3.2 will be released very shortly. They are changing their PHP and MySQL version requirements with this upcoming release. The requirements are PHP 5.2.4+ and MySQL 5.0+. You can see the announcement at http://wordpress.org/news/2011/05/wordpress-3-2-beta-1/

I need to make sure that my site is ready to be upgraded to 3.2 when it comes out. Can you confirm that my site is on a server that meets these requirements?

If my site’s server does not meet these requirements, please let me know how I can be migrated to a new server that does support these requirements.

Addition of Browse Happy Messages in the Dashboard

WordPress 3.2 joins the Browse Happy movement by encouraging users with older browsers to upgrade. These messages will only appear on the dashboard and can be dismissed, but they will show up by default for users that haven’t seen it and are running an out-of-date browser.

Correction: As pointed out in the comments, Browse Happy was started by the people behind WordPress.

New Dashboard Design

WordPress 3.2 will also introduce a new design which is starting to show some real promise.

It is still in the works, so many more changes may occur before release. Here’s a sample of what I currently see in my development dashboard:

Thoughts

WordPress 3.2 is looking to be a good release. The new design will breath some new life into the dashboard and make it interesting and new again.

There is also the “distraction-free writing” full-screen editor view that some users may really enjoy. WPCandy has a post with a video showing the feature in action.

For a major release so soon after 3.1, 3.2 is really shaping up to be an impressive effort by everyone involved with the WordPress project.

I am very pleased to announce that we are now ready to start the beta test for the new Builder version that includes the import/export feature. A beta test is when a pre-release product is made available to users for further testing before the final release. We don’t do many releases like this, so we are very interested to see the response from testers.

The reason that we are doing a beta test is that Builder has gone through many large changes to allow this new feature to work. Since so much has changed, there could possibly be problems with the new code that we haven’t found yet. Our hope is that some of our community members will try out this pre-release version and run it through the wringer so that any remaining issues are identified and fixed before the full release. In other words, the more people that use the code, the faster any potential problems can be found and fixed.

To participate in this Builder beta testing, first, you need to have an active Builder theme (or package with Builder) membership. Second, join our Beta Program if you have not done so already. Once you are part of the Beta Program, a new “Beta Downloads” section will appear on your member page with a download link for “Builder Theme Import/Export Beta”. Applications to join the Beta Program are processed manually. You will be notified by email when your beta application is approved.

Please use the Builder Import/Export Beta Feedback thread in the support forum to report any issues you encounter while testing.

There has already been a large number of new Beta Program signups. Thank you in advance to everyone for helping test this pre-release version.

I’ll describe the changes in more detail below, but a video may communicate some of the details more clearly. Full screen and other resolutions are available if you’d like to see more text detail.

Editor Redesign

The purpose of the interface redesign was to make it easier for new users to get started while giving experienced users more options.

To prevent from overwhelming the user with too much information at once, the settings were divided into discrete logical groups. This allowed for the addition of detailed descriptions and more settings without making the interface too crowded.

Since the settings now takes up so much vertical space, a Quick Links box was added to inform users what types of settings are available without requiring them to scroll through the entire page.

With plans for integrated SEO options and a settings importer/exporter, a place had to be created for these new features. They are similar in concept to the settings editor and would clutter up the My Theme menu if they were added to it. The final decision was to use the tabs from WordPress’ Themes page interface. With the addition of tabs, the settings page can be expanded to include many new similar but separate pages of settings and settings-related tools.

Menu Builder

The Menu Builder has not been modified. It has worked well for a long time as is. It merely got a facelift and some description.

Analytics and JavaScript Code

Builder’s old settings page included a single text area to input code for either the header or footer. While this has worked very well for a long time, I thought that it could definitely be improved.

I dug around and found that most WordPress users use either Google Analytics or Woopra for their site’s web analytics solution. This being the case, I thought I could create some tools to make integrating these services easier to do. Beyond just providing an easy-to-use tool, I thought that this settings section could also serve as an introduction to the concept of web analytics for some users.

I should note that simple integration is just the beginning for the Google Analytics and Woopra tools. Code is already being put together that adds event tracking (such as visitor commenting and searching), action tracking (outgoing, download, and mailto link clicks), as well as visitor data (details about logged in users and visitors that have left a comment).

Of course there will always be a need to input custom code. The old settings limit of supporting either header code or footer code but not both was unnecessary. The new settings supports having custom code in both locations at the same time. A simple change that should be very helpful to some users.

Identify Widget Areas

In the past, Builder would always put some filler text in empty widget areas so users could easily see the name of that area. This helps users work with numerous layouts quickly, but it wasn’t without problems.

One of the biggest problems was that this filler text would show not just to logged in users but to visitors as well. An option existed to turn this off, but this really wasn’t ideal. Now there are three choices for who can see the filler text: users that can modify widgets, any logged in user, and everybody. By default, this information will only be shown to users that have the ability to manage widgets.

Another issue is that the filler text would only show in empty widget areas, which could make it difficult to quickly identify a widget area after having added widgets to it. Builder still has this behavior by default, but settings are available to either always show or never show the widget area identification.

Comments

In many themes, comments don’t exist in the page.php template. This means that many themes don’t support page comments even though WordPress does. Builder has always had support for page comments, but this has caused a great deal of frustration for some users that couldn’t stand seeing the “Comments are closed” message on their pages. Eventually, a rule was added to stylesheets to hide this “Comments are closed” message, but this also had the effect of removing that message on posts that actually did have their comments closed.

The correct solution became very clear, provide settings to control this. Now, by default, pages are devoid of comments as many users expect; however, by checking the “Pages” option and saving your settings, page comments can be very easily enabled. Similarly, the “Comments are closed” message is disabled by default and an option has been added to provide a custom message if desired.

Theme Features

Over the past year, a number of features have been bundled in with Builder. If a user wished to disable a specific feature, customizations to Builder itself would be required, and the process would require specific knowledge. Now the features that can be safely disabled are centralized in a standard system and can be enabled and disabled from the settings screen. No code modification required.

Other Stuff

There have been a large number of other changes, but most of them are boring technical details, so I won’t bore you with that information. These other changes boil down to a benefit of faster theme performance. I’ll leave it at that.

Many of the decisions that went into this redesign were in response to feedback from Builder users. Please let me know what you think about the changes by leaving a comment below.

***

Check out the iThemes Builder Blowout Sale

Today, I’d like to share a sneak peak of this new approach as I work on rebuilding Builder’s Settings screen.

These are some of the key elements of this redesign:

• Use the tab design found in the Appearance > Themes menu to offer the basic and advanced settings pages. This approach is used to prevent the menu from growing too large.
• The settings have been divided into logical groups. Each group is placed inside a collapsible box that can be moved around. Since the boxes will remember their position and closed state, this makes it easier for users to hide away settings that they don’t need or rarely modify.
• More description must be used to clarify the purpose of each setting.
• Existing options that may be difficult to understand should be rethought to allow for ease of understanding.
• Options should be simplified as much as possible while still allowing flexibility.

Some observant readers may have noticed the “Import / Export” portion at the top of the preview image. Yes, importing and exporting settings is in the works as part of this new settings page.

Please share your comments, critiques, praises, criticisms, etc you have for the new design in the comments below.

The updates didn’t add any new features, but they did add an important change to the code contained in each one. The full story on that is technical and likely to be quite boring (I’ll expand on this for those interested later in the post). The important bit is that I highly recommend those using Builder and/or any of the above-mentioned plugins upgrade their sites to these new versions.

Updating is important as some of the new features that will be released soon (such as the Builder Blocks that we discussed during yesterday’s iThemes.tv show) will only work properly if all of these updates are present on your system. In other words, if you update Builder to 2.4.15 but have an older version of Tabber Widget on your site, these new features will have a chance of not working properly. Again, please make sure that you upgrade Builder, Builder Style Manager, Builder SEO, and Tabber Widget.

I’m very sorry for this inconvenience. Please leave a comment if you have any questions or concerns.

Technical Explanation

For those that want to know the technical details, I am more than happy to share them.

The Builder, Builder Style Manager, Builder SEO Plugin, and Tabber Widget projects all have a shared set of code found in each project’s lib/classes directory. The lib/classes code library provides a robust set of functions and classes that makes development quicker and more reliable. For example, this library contain classes and functions that generate forms, process form data, provide versioned storage systems complete with upgrade abilities, handle files and images, offers a parent class that allows for rapid creation of new editors, etc. This central set of libraries started development with the Builder project and has grown to contain a wealth of valuable code that can be used for numerous projects (as none of the code is Builder-specific). Thus, this library has found its way into other projects.

For a couple of months, I’ve known of a serious problem with this code spreading to other projects: the fact that there is now a possibility of multiple versions of the code being present on the same system. This can be easily caused when more than one project that uses the library is present and only one of the projects is updated after a new library release. Since only one set of the code libraries can load, it was impossible to ensure that only the most current version of the libraries loaded. If the old set of libraries loaded, it could very easily cause the updated project code to fail.

These new releases contain a new set of the lib/classes code (version 1.2.0) which addresses this issue. Now, instead of a first come, first loaded process of deciding which library version loads, each project’s library registers itself. When all the plugins and the theme have loaded and registered their respective versions of the library code, a process runs that identifies the most current version of the library and loads only that one.

If you are interested in how this works, check out the load.php and init.php files in lib/classes of one of the updated projects. The init.php file is what is loaded when the current version is identified. Inside the init.php file, a function is defined that all the projects use to load that version’s file when needed.

As with any major WordPress release, there is concern over whether your plugins and themes will be compatible. Wondering what will happen when you click that upgrade button is a valid concern.

We should say that before doing any major upgrades, you should always do a full backup of your site. If you don’t currently have a backup process, please checkout BackupBuddy. We developed this plugin specifically to help our customers do easy, fast, reliable backups. Beyond offering fast, complete backups, BackupBuddy also supports restoring your site from the backup and migrating the site to another domain and/or server (this makes spinning up a test site to try out the upgrade very quick and easy to do).

For many months now, we have tested all of our themes and PluginBuddy has tested its plugins with the development versions of 3.0. We are pleased to announce that all of our themes and of the PluginBuddy plugins work properly with the new 3.0 release.

Beyond just having functional compatibility, we are extremely excited to start taking advantage of the new 3.0 features. Our first focus is to add support for the new Menus feature. Both Builder and our Flexx series of themes have full support for Menus right now. Over the next week or two, we are dedicated to getting full Menus compatibility added to all of our themes.

The new Network feature that allows for having multiple sites on a single installation is another very exciting feature. For those who aren’t familiar with this feature, it is the result of merging the WordPress Mu code with the main WordPress code. No longer will there be two different versions of the code. From our testing and reports from our users that have tested this new feature, all of our themes function properly with this new Network feature.

Another exciting new feature is the custom post types. While not technically new to 3.0, only now can developers take full advantage of the feature and offer users a consistent interface. We have a very exciting new Builder child theme in development that takes advantage of this feature. So, stay tuned for more news on this exciting new child theme.

As always, if you have an upgrade problem or feature request, please stop by our forums and let us know what your needs are.

In closing, we’d like to mention that this new WordPress version release represents a huge investment of time and energy by hundreds of people. While a list of people that contributed code can be found in the announcement post, there are many, many more that contributed ideas, tested code, wrote documentation, created translations, and moved the project forward in a huge variety of ways. The iThemes, PluginBuddy, and WebDesign teams would like to extend our thanks to the hard efforts of the hundreds of people that made this release possible and would like to ask our customers to share their appreciation as well. Please consider donating to the WordPress Foundation, blogging about the new release, or simply sending out a tweet with #wordpress that shows your appreciation for everyone’s hard work.

Here’s a video tutorial on using BackupBuddy to backup your WordPress site

This plugin is available as a beta to our Builder customers. Once the code is well-tested and the features are finalized, these SEO features will be bundled directly into the theme.