Before we go on, here is the reminder for the article published yesterday about upcoming WordPress:
What will we get with WordPress 3.4?

This list is based on the features requested by WordPress community, and things I consider important. This features are in circulation for over a year now, and still most of them are not even mentioned in the future development plans. Problem with most of these features is that they need much more time to do, and current quick development cycles core team insist on are simply not long enough to make these things happen.

• Replacing outdated and no longer maintained ThickBox with jQueryUI Dialog. This is actually something that was in works, and from what I have seen, it should be ready for the next WP 3.5. ThickBox popups are very complicated to control and they lack many features that jQueryUI Dialog popups can do. Replacing them would be great. But, that will also cause all sorts of problems for plugins developers, because most of the code using ThickBox will not be compatible with new popups. Colorbox is also a good way to go to make popups, but I would prefer jQueryUI approach, considering  how much WP relies on jQueryUI already.
• Custom post types posts relationships. This is very, very important feature that will move WordPress in the field of full-fledged CMS systems. Right now, you can’t connect posts directly and with more and more popularity custom post types gain, this is a very important addition. There are several plugins for this, all implementing this differently, but this is something that must be in the WordPress core. This would need additional database table for bridging posts.
• Meta data for taxonomies terms. There was some talk about this, but it was always dismissed when plans for next WordPress were made. Right now all data types in WordPress have meta fields (users, posts, comments) with the exception of terms. It would be very beneficial to have those. This also would require another database table.
• Improved media library. This can be found on most WordPress wish lists on the Internet. I don’t have too many complaints to Media Library, but there are many things that can be improved, including attaching one image/file to more than one post. Other important improvements would include: user controlled folder structure for storing files (not only dates based as it is now), with improved URL rewriting rules that can hide wp-content from the URL. Also, real galleries implementation would be of great benefit for media library.
• Shared resources between sites in multisite. It would be of great benefit to have central media library with assets and images that all multisites can use (logos for instance). Only super admins get to control that, but any site admin can use those resources. Beyond files, sharing can be done for taxonomy terms, maybe even pages and posts to some extent. This can be useful if you have same Terms And Conditions page that any site in the network can use as its own.
• Improved posts management. Right now, posts lists on the admin side are real pain to use when you have large website with thousands of posts. Changing category for hundreds of posts at the time is impossible. We need better system that would allow simpler and more powerful filtering on that page and operations that go beyond current, flawed bulk operations (if you want to bulk edit 10 or 15 posts, you can wait good minute or two before you can do anything, and some browsers can freeze with bulk edit).
• New Taxonomies Terms management. This current is very bad, and if we get meta data for terms, this current interface must be replaced with something that is actually usable for website with large number of taxonomies and terms.
• Real search. Maybe the worst thing in WordPress is absolutely useless search feature. There is no need to explain how bad it is, and how much we need something useful to search posts. We need full text indexing, some search operators, easy set filters for post type, custom fields or taxonomies terms. There are some plugins for this, but this is a feature that should be in the core.
• Remove Akismet from core distribution. Akismet is a commercial plugin, and for most websites, it must be purchased to use. Bundling it with WordPress core is not fair to all the other commercial plugins developers. Considering that many users prefer solutions that work on site only with no remote servers involvement, there are better solutions that Akismet, and also free solutions.

And what we should not see in future WordPress version (for a while at least):

1. We don’t really need new core themes. TwentyTen is great, and TwentyEleven is awful. I would like to see TwentyTen as HTML5 theme and be done with it. From what I have seen of TwentyTwelve, I am not impressed.
2. No more cosmetic admin side changes. We need real changes to posts lists panel, taxonomies terms pages, leave the rest of WordPress admin as it is. It looks great as it is now.

With few teams working only on these features, I think (based on earlier development cycles) that these would take 9 to 10 months (maybe a year) to implement and test properly. Also, having longer beta testing period for it would be beneficial to convince larger group of users to switch to new version when it gets released. And I am sure that powerful set of features would be the best incentive for adopting new WordPress.

What do you think about these features? Would you prefer to wait longer for a WordPress that comes with most of these things, than to waste time on small updates as we have now? Let me know with a comment.

Username: admin should be changed

Before WP 3.0, in every new installation of WordPress, main user account was named admin. After WP 3.0 you can choose new username during installation. Also, WP doesn’t allow changes of username directly. It’s not recommended to have admin username at all because hackers expect it and can use it to only crack the password and get access to your website. Considering that many websites use simple passwords, that can be easier than you may think.

Update WordPress, plugins and themes

This is something you hear from everyone: keep your installation up to date. But, on the other hand that can be a problem in some cases. Updating WordPress is a good thing if you don’t use some old and outdated plugins that don’t work with new WordPress, and is not maintained anymore. Situation with updating themes is similar, once you start changing the theme, you can’t update anymore or you will loose your changes. That is one of the reasons I added theme upgrade to my xScape premium themes, allowing you to change theme and still be able to update with new version.

If you still run some old WP version (any 2.x version), from security point of view, you need to upgrade to latest WP 3.x version. If some old plugin is preventing you to do that, try to find someone to fix the plugin or write a new one. Investing in that can prove very important to keep your website safe in the long run.

Best security policy with WordPress (and other well maintained CMS systems) is to use latest versions, since WP core developers are always been very fast in fixing all potential security holes. Compared with other similar systems, in my experience, WordPress is most secure one with a lot of security features built into the core.

Remove WordPress version

Each WP page contains meta tag with version of WP. It’s best to remove it so that hackers can’t use that info to target your website with potentially targeted attacks, and that is potential problem with older WP versions. To remove the WP version, you can use this line:

add_filter('the_generator', create_function('$wpv', "return null;"));

Injection attacks through URL

One of the most common attacks hackers use is adding so called injection code to the URL. If the URL is not properly filtered, such code can take advantage of bugs in the WordPress (or other CMS systems), and run SQL query that can be very harmful. WordPress already does good job in preventing such attacks, but it is a good idea to detect such attacks and log them so you can use that to prevent access to such users in the future. Scanning and filtering URL can be used to prevent too long URL’s also.

There are many variations to this code allowing filtering on admin side only, or for some user roles. But, core code is this:

$url = $_SERVER['REQUEST_URI'];
$request_url = $_SERVER['REQUEST_URI'];
if (stripos($request_url, "eval(") || stripos($request_url, "CONCAT") || stripos($request_url, "UNION+SELECT") || stripos($request_url, "base64")) {
  @header("HTTP/1.1 414 Request-URI Too Long");
  @header("Status: 414 Request-URI Too Long");
  @header("Connection: Close");
  @exit;
}

GD Press Tools Pro: General Security Settings

Using GD Press Tools Pro

GD Press Tools Pro allows you to do all the things listed in this article, and a lot more minor tweaks and changes. Some things are global security settings or available for individual sites (if you run multisite installation). Image on the right shows one more feature that can be useful to force settings CHMOD for files and folders created by WordPress for some hosting systems where default CHMOD’s are not already properly set.

Conclusion

Keeping WordPress website safe mostly depends on outside factors we discussed in the previous parts of WordPress Security articles series. But, there are still some minor things that can help if you make some changes from inside WordPress.

Finally, WordPress 3.0 supports hierarchical custom taxonomies, and plugin will now allow you to make such taxonomies and use it. Also, some elements in the custom taxonomies structure have changed and for now plugin handles both old and new formats well. If more changes are introduced in WP 3.0, plugin will follow soon after.