Yes, as exotic as it ever gets.
I was honored to give a talk at the second WordCamp Russia event. Like last year, I decided to speak about a general development topic and how it can be applied to WordPress. This time my talk was on profiling.
Here’s a video. English subtitles are available by selecting “Subtitles” in the player.
And here’s wptop on GitHub, an XHProf-based WordPress plugin that gives you an overview of your WordPress website performance. Feel free to give it a spin and let me know what you think.
WordPress clients are available for many devices, but since I’m an Android fan I get to use WordPress for Android.
Yesterday, I came across a bug report outside of the developer ecosystem, managed to reproduce the bug using the release version, and, decided to write and submit a patch to fix the bug.
The main WordPress for Android repository is over at GitHub. But as it turns out…
…one does not simply build WordPress for Android.
By default, the WordPress
wp_mail function will not set the actual sender for
$domain instead of the actual sender. Which, in turn, means that when using relay maps (sender_dependent_relayhost_maps) to map senders to correct SMTP relays none of them is matched because of the sender is not set correctly…
Fortunately, the mailer class used by WordPress, PHPMailer knows how to correctly specify the sender via the chosen backend (which in WordPress is the
Sender property of the mailer we’re able to have Postfix identify the sender correctly.
I took part in WordCamp Russia 2013 this year, which was organized by my brother (with huge help from a handful of volunteers and the WordPress Foundation). This was the first ever WordCamp in Russia.
Konstantin wrote about the event in much detail.
I have written yet another Gravity Forms plugin/addon. This time the plugin was to generate bulk reports for form entries, digests of sorts. Based on a set schedule (which can be altered using the
cron_schedules filter), this addon will aggregate all new form entries it hasn’t seen yet (including very old ones) and send them out to predefined e-mail addresses.
The whole thing works best with regular single-shot notifications turned off, probably.
Download it from github now.
Here’s a list of functions that are now deprecated in WordPress 3.4:
add_theme_supportaccepts multiple arguments for some features. remove_custom_image_header has been deprecated in favor of remove_theme_support. Same goes for
wp_get_theme, mentioned above
update_page_cacheand clean_page_cache are replaced by update_post_cache and clean_post_cache
That’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.
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.