The next version of my Developer’s Custom Fields plugin is available for testing, though not yet flagged as stable as an official release. You can download it from GitHub.
Tag archive: WordPress
An unusual release, this. There’s just one new feature, and it’s not one that’s been necessitated by my work or by requests. I won’t do this often, but I recently noticed the Post Meta Inspector plugin, which outputs all the post meta values on post (and page, etc.) edit screens. I realized this is a very simple, but very useful feature. I know that it will save me endless flipping back and forth between WP and phpMyAdmin when I’m trying to track down a custom field issue.
It parses and dumps serialized data. There’s probably other enhancements that are possible, but for now I think it’s useful enough.
Due to the media changes in WP 3.5, as it stands it won’t output on attachment edit screens for previous versions. I don’t think I’ll bother with this—but I probably will find some time in the future to add it to user edit screens, which aren’t currently supported.
There’s no way to turn it off, but if it’s in the way you can fold the meta box up, or hide it with Screen Options.
I’ve finally got the latest version of my Developer’s Custom Fields plugin released. It’s bumped up to 0.8 because there’s a number of new features as well as improvements and fixes.
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.