There are 0 new tickets waiting for review. 121 themes were reviewed in the last 7 days. #wptrt #WordPress #Inbox0 twitpic.com/9cw4b4
— Chip Bennett (@chip_bennett) April 22, 2012
There are 0 new tickets waiting for review. 121 themes were reviewed in the last 7 days. #wptrt #WordPress #Inbox0 twitpic.com/9cw4b4
— Chip Bennett (@chip_bennett) April 22, 2012
WordPress Stats Infographic by Joost de Valk shows off WordPress numbers and compares them to Drupal, Joomla and others. Includes some stats from WordPress.com too.
While sanitizing and escaping everything is very important when dealing with websites, I think there are times when we need to back off a little bit, and trust the functions that have been given to us by WordPress.
<a href="<?php echo esc_url( get_permalink( get_the_ID() ) ); ?>" title="<?php echo esc_attr( sprintf( __( 'Permanent Link to %s', 'domain' ), the_title_attribute( array( 'echo' => false ) ) ) ); ?>" >
I call that paranoia (and I see it in a lot of themes.) Dirty, difficult to read and understand, and even more difficult to spot an error. The permalink and the title attribute are never going to break out of the attributes syntax and escaping them a billion times doesn’t really help. Here’s a cleaner version for comparison:
<a href="<?php the_permalink(); ?>" title="<?php the_title_attribute( array( 'before' => __( 'Permanent link to ', 'domain' ) ) ); ?>" >
Quite straightforward and easy to understand. You don’t even need to worry about escaping the “before” text, because the_title_attribute will escape it for you. One might argue that explicit escaping (right at the output) is more secure than implicit escaping, but since functions prefixed with the_ are meant for output, I tend to trust their output. You just need to know where each one should go.
With that said, if you have a super hi-jacked WordPress installation with a malicious plugin overwriting the output of the functions mentioned above, there’s really not much you can do. Even if you triple espace with get_permalink, a plugin might just filter in on post_link and output whatever it needs to output by-passing all escaping.
Thoughts?
How to write a terrible WordPress tutorial: “Do X without a plugin. Just paste Y into your functions.php!”
— Evan Solomon (@evansolomon) April 11, 2012
True, and here’s a related post I wrote earlier about Plugins vs. Without a Plugin. Still, we keep seeing such tutorials piling up everyday, even obvious ones like Google Analytics.
Why would one want to go through the trouble of copying and pasting code into their theme’s header.php file, and then breaking everything when they change their theme or when the theme gets an update? Why not just use a plugin that will retrieve the analytics profile via OAuth?
Is it considered “cool” to copy/paste all my plugins into my theme’s functions.php file? If so, I might just try it out right here on my site! And since I’m running multisite with quite a few different sites, I’ll have to do that ten times for each plugin that I need to use. Then maybe use constants to indicate which snippets I want active and which ones I don’t. *
And as soon as I end up with a 5000-line functions.php file, I can go complain that WordPress is too difficult to learn, and that it’s a pain switching themes or domains, and maybe blame Otto for absolute URLs too. *
* Sarcasm
Considering doing a new WP plugin. I’d call it “inbound marketing for WordPress”, does the same as my SEO plugin, but paid :-P
— Joost de Valk (@yoast) April 9, 2012
New version of #WordPress P2 Theme by @automattic is now available: wordpress.org/extend/themes/…
— Emil Uzelac (@EmilUzelac) April 9, 2012
Not much has changed from the previous version. Perhaps the most exciting change is that you can now create todo lists, by adding an “o” or an “x” at the beginning of a new line. Cool huh? If you’re new to P2, don’t forget to read this article by Matt on why we use P2 at Automattic.
The MIT license is compatible with the GPL and can be used when submitting plugins to the WordPress.org directory. Thanks to Mark Jaquith for clearing that up.
Custom backgrounds are handled through add_theme_support since WordPress 3.4, and although you can add your custom callback to wp_head, you don’t need you. You can simply pass a default-image to add_theme_support for your custom background:
add_theme_support( 'custom-background', array( 'default-image' => get_template_directory_uri() . '/images/default-background.png', ) );
The default custom background image will be used when one is not set, or the user hits the “Restore Original Image” button in the custom background options. However, the old method should still be compatible with WordPress 3.4, unless you’re doing something wrong :)