On larger projects, designs that need to be turned into a custom WordPress theme can have a wide array of image sizes. I’m currently working on such a project, and I thought I’d share a few things that might help others working in a similar situation. My aim is to contribute to a better understanding of how WordPress currently handles image sizing, how understanding this can potentially feed into the design process, and how WordPress developers can respond to design requirements while not making life too confusing for the client’s content editors.
For anyone using my Custom Fields plugin, version 0.7.3 is close to being released, with some good improvements:
- The addition of
datetimefield types, using jQuery Timepicker addon. Thanks to Saurabh Shukla for this contribution!
- Made the Google Map geocoder bounds update when map bounds change so that only addresses / locations from within the current map display are suggested
- Moved enqueuing of Google maps JS inside the
slt_cf_gmap()function, so the scripts are only used where necessary. This is made possible by registering them to be included in the footer – see http://scribu.net/wordpress/conditional-script-loading-revisited.html
- NOTE: The
datepicker_css_urlsetting, to account for additional UI elements, is now
ui_css_url. Please update this in your code if you use it.
You can download the latest code at GitHub. Especially if you use Google Maps, please test this latest version out and let me know if you find any problems. Hopefully it’ll be released on the WordPress plugins repository soon.
A large WordPress project I recently worked on had requirements for post and user metadata that resulted in me creating and working with custom database tables. The ins and outs of that particular project are very complex—in the end I’m not sure the custom tables were 100% necessary. However, there are certainly cases where custom metadata tables will be the best approach.
For instance, if you need to get a lot of posts with all their meta values in one go, WP’s data schema may be unworkable. The default
wp_postmeta table is structured for maximum flexibility in terms of adding new fields; there isn’t a column for each field, rather the structure allows for fields to be added on an ad hoc basis via the
meta_key column. This is great for being flexible about adding new fields, but getting a post or a number of posts together with all metadata will involve a table join for each field. The more joins, the more impact on the query’s performance. The same applies for the similarly-structured
For what it’s worth to anyone attacking this kind of issue, I want to document here how to integrate custom metadata tables with WP’s core metadata handling.
I’ve just put all my WordPress plugins onto GitHub:
That’s all the ones that I’ve released via the wordpress.org plugins repository. On GitHub you’ll also find SLT Global, which is basically my collection of snippets that I want running on every WordPress project I deploy.
I’ve just released version 0.7.1 of Developer’s Custom Fields. It should be showing up on the repository and in your WP admin very soon.
It fixes a couple of bugs, one to do with the version number storage, and a more important one for anyone using Gmaps. Because of the attempt to exclude the Gmaps functionality when it’s been turned off with
shortcode wasn’t working. This should be fixed now.
Also, I’ve made the WYSIWYG field type play well with the nice new WP 3.3
wp_editor function. When you upgrade to 3.3 you’ll also be able to pass values to the
$settings parameter of this function with the
wysiwyg_settings field parameter. Follow the source to the
editor method of the
WP_Editor class for details of what settings you can pass through. Thanks to katoen on the wordpress.org forums for the heads up!
There are some other things I’m hoping to address very soon. I just had to release this asap because of the Gmaps shortcode fix and the compatibility with 3.3.
I’ve just released 0.7 of my Developer’s Custom Fields plugin, which is now available for download from wordpress.org or automatically via your WordPress plugins page.
There’s quite a few fixes and changes in this version. I’ll try and detail the most significant changes here in this post.
A quickie post about a few functions that I’ve only recently discovered, and really wish I’d discovered sooner! One is a PHP function, two are WordPress core functions. Both help immensely when you’re dealing with URLs.
I’ve been finding more and more WordPress plugins that, when they check if the current user should be allowed to view / edit the plugin’s settings page, check whether the user has the
edit_plugins capability. I think this is a bad practice; let me explain why.
Last night’s London WordPress meetup was good. Hosted by a company called Headshift, we got a quick-fire run through beginner, intermediate and advanced-level topics. Emily Weber gave an overview of how, as a non-techie, she got the social networking site yeah! Hackney going using BuddyPress. Keith Devon heroically compressed WordPress theme development into 20 minutes. And Chris Adams gave an equally succinct tour of the WP core. This is an important topic for budding WP developers, I think. Do check out Chris’ slideshow for some good pointers about where to look to start to understand the important aspects of the process that the core goes through when processing a request:
And come along to the next meeting!