There’s a few posts on this around. I’ve based my work doing this on the ever-reliable Chris Coyier’s post at CSS Tricks. However, here’s my own summary and notes…
I no longer use my WordPress plugin Force Strong Passwords, since that functionality’s included in Wordfence. However, the plugin is quite popular, and one aspect of it that has suffered due to my lack of experience is multisite support.
On GitHub, Damien Piquet has submitted a simple fix in a pull request, which I’ve accepted. I’m not in a position to properly test this, so if anyone uses Force Strong Passwords on multisite installations, please grab the code with this commit and test away. Providing no issues arise, this will soon be released on wordpress.org.
Comments will be closed here – please give any feedback via GitHub.
Did you know that every individual Google search you do has half the carbon footprint as boiling a kettle? That data centres have now overtaken aviation as a global source of CO2 emissions? Dale Lately highlights these and other discomforting facts in his excellent piece on the Baffler, which explores the deception we engage in when we believe digitisation is ‘etherealising’ us all away from messy material problems.
Of course, on carbon emissions, the only real solution is global action co-ordinated by those entrusted with power. But reading these stats reminded me of something I tried to get into the habit of using, but didn’t – the offline documentation browsers Dash (for Mac) and Zeal (for Windows and Linux).
Together with the Dash plugin for PhpStorm (which adds a keyboard shortcut to search either Dash or Zeal), I’m now set to quit boiling the endless kettles that get pointlessly boiled in an average day’s coding.
Here’s a nice addition to WordPress, which I missed in last year’s 3.9 release. Now, when you define an image size with
add_image_size, instead of just saying ‘soft crop’ (keep proportions) or ‘hard crop’ (fit to area), you can now also pass an array to define where you want a hard crop to attack the image from. For example:
add_image_size( 'custom-size', 220, 220, array( 'left', 'top' ) );
The first element in the ‘crop array’ can be ‘left’, ‘center’, or ‘right'; the other can be ‘top’, ‘center’, or ‘bottom’. Nice!
As an image size bonus, here’s what I came up with recently when I wanted all WordPress image sizes to be controlled via custom theme code (not just the custom sizes).
Version 1.0 of the Developer’s Custom Fields plugin is in development. I’d hoped that the core Metadata UI API would have made progress enough for me to revamp DCF in light of the new core functionality, but that’s not looking likely. DCF 1.0 won’t be a major update, but I’m hoping to get some significant things sorted out.
The most important, I think, is getting the
file field type working with the new (well, introduced in WordPress 3.5) media upload API. It’s pretty much there, but I’m looking for some help with it. Does anyone know the media upload API well?
Very often while building a WordPress site, I need to see how a layout works with a load of posts. Maybe 4, maybe 40. In any case, it’s tedious creating dummy content.
There’s a number of dummy content dumps out there to use, but often we’re working with custom post types and we need particular custom fields working right.
This bit of code will allow you to add a particular argument to the query (
get_posts, etc.) to artificially multiply or repeat the posts returned.
Like every developer, I’ve got a particular configuration for most sites I deploy. My WordPress sites are mostly all based on my Pilau parent/child themes, and I’ve a set of “usual suspect” plugins I include in most projects. Some plugins—in particular Developer’s Custom Fields—are pretty much indispensable to my work. So much so, that for a while I assumed, in my custom theme code, that the plugin would be installed.
More recently I’ve forced myself to follow best practices better. So, even if I know a certain plugin will be installed and active, because I manage the site, I still surround a call to a function from that plugin with a
function_exists() test. I just found out why that’s a good idea.
I use the Wordfence plugin on my WordPress sites for extra security. Generally it’s great, but it can be a bit over-sensitive (granted, it’s best to err in this direction with security!).
Anyway, however dangerous (or not) this site is, the URL in the JS file is utterly harmless – it’s in a comment. Furthermore, the URL is only in the dev version of the script. Only the minified version – stripped of comments – actually gets used on live sites.
I’ve removed this URL from the latest version of the plugin on GitHub, but it might be a little while before it gets rolled out on wordpress.org. Until then, please ignore this issue if Wordfence flags it up for you.