Today I had the “pleasure” to manually merge two versions of the same application that was maintained in two different instances by three different programmers without any version control whatsoever.
The versions were quite different, with directory names changed (for now apparent reason) and all sorts of other funky stuff. Manual merging seemed like the only way to go and I chose git branches as my merging headquarters.
Here’s a list of functions that are now deprecated in WordPress 3.4:
add_theme_support accepts multiple arguments for some features. remove_custom_image_header has been deprecated in favor of remove_theme_support. Same goes for add_custom_background and remove_custom_background.wp_get_theme, mentioned aboveupdate_page_cache and clean_page_cache are replaced by update_post_cache and clean_post_cacheThat’s it for deprecated functions. Check out a comprehensive list of changes here. Although WordPress is known to be highly back-compatible and the deprecated functions will be available for a long long time, developers are highly discouraged from using these in the future.
Codename “Green”, WordPress 3.4 was announced yesterday, boasting flashy features and upgraded functionality.
Lots of hard work involved, lots of excitement and most can’t wait to upgrade, including me. However, as much as I want to update to WordPress 3.4 and enjoy the new stuff, I find it difficult to do so in production right now. I’m sure WordPress 3.4 is fantastic, but it’s too early, there’s bound to be a WordPress 3.4.1 with security fixes (or at least hot fixes) sometime this year.
My suggestion is that unless you have a huge need for one of the new features just wait a bit, see how it behaves out in the wild, how it is targeted. At a little over 200,000 downloads and less than 24 hours out in the wild it’s too early to tell. I’ll personally wait a couple of months before upgrading in production.
Other than that, hurray! Off to play with the new XML-RPC methods.
It’s been a while since news from the trunk have been published on my blog due to the lack of time on my part and the lack of substantially juicy stuff happening in the trunk. With WordPress 3.4 coming up most of the movement in the trunk is related to fixing bugs. So today’s post will combine the 15th, 16th and 17th editions of WordPress trunk news into one post.
As of this day, there are 12 active tickets. And with WordPress’s 9th birthday earlier this week (yay!) here’s the latest news from the trunk.
Gravity Forms is one of those plugins that many enjoy and make use of. A recent project of mine involved adding some functionality that seems as indispensable as conditional field logic – conditional notifications.
Based on the values of form fields selected notification settings are overridden, including e-mails and, more importantly content, and whether a notification is sent or not in the first place.
This Gravity Forms Addon allows users to select specific conditions that override the default notification settings. The first condition that is met will provide the settings that replace the ones that are set in the Notification area for a form. If no condition is met for a form the default Notification settings happen.
A fantastic use for this Gravity Forms Add-on would be to have an auto-responder setup for an inquiry form, where visitors select a predefined inquiry (although an FAQ would handle that in most cases). Applications to specific departments where a response arrives with that departments contact details, terms, working hours, or something. In short, should be quite useful.
Gravity Forms Conditional Notifications Add-on is available on Github.
We’ve hit May 9th, the target release day of WordPress 3.4 two days ago, and quite expectedly WordPress 3.4 is still two steps behind release at beta 4 from last week. There are currently 19 active tickets that are awaiting resolution until release. Fear not, WordPress 3.4 RC1 will probably land this coming weekend, though. WordPress core development chat offers some great insights into what’s pending (“We went from 20 tickets…to 20. Go team. 😉” rboren).
The WordPress.org SVN server hosts some interesting repositories apart from WordPress.org plugins and themes, some of which are not too widely known, and might be considered to be obscure or not pertaining to WordPress in any direct way.
Here’s a list of some of the useful and intriguing ones:
Know of any other?
First of all, WordPress 3.4 beta 4 has rolled out earlier this week. Only 23 tickets are open, which means that it’s almost there.
So what’s new?
When code is executed by a machine it takes some time to do so. Execution time ranges from nanoseconds to months and years and even more (think bruteforcing). Web applications construct output producing, in most cases, very short delays (think the time it takes to show Google search results after typing in the query). Depending on what output is request, how it is requested and what the input is web applications can vary their execution time.
In this article we’re going to exploit some of the open-source content management systems available using delays in its execution under differing conditions to evoke distinct differences in execution time, which allow us, as attackers, to make some useful conclusions.