The latest version of Developer’s Custom Fields is out, with a few new features. Read on for detailed release notes…
Management of term splitting for WordPress 4.2+
NOTE: This feature is not activated by default.
WordPress 4.2 introduces term splitting. Basically, this means that up until now, terms that are shared between multiple taxonomies have shared the same entry in the database. Now, terms with identical names in different taxonomies will have their own entries in the database. Existing terms that are shared will be split the next time they’re updated in admin. There’s a full explanation here.
This change does affect Developer’s Custom Fields, since it’s possible, using the
options_type of ‘terms’ for a field to use taxonomy terms for a custom field. The term IDs will then be stored in the
usermeta tables, which won’t get updated by core code if it splits something (because the core won’t know about them).
Now, as the referenced post points out, this problem is definitely an edge case:
The vast majority of terms are not shared between taxonomies; shared terms themselves are an odd edge case. The vast majority of plugins and themes do not store term IDs. And, moreover, WP 4.2 will only split terms when a shared term is updated (eg, when its name is updated in the Dashboard) – an infrequent event. … Even in cases where a plugin is technically affected, depending on the way the plugin uses its stored term IDs, there may be no perceptible effect at all.
I’ve added a hook in DCF that will hopefully manage the bulk of these infrequent events. It uses the
split_shared_term action detailed in the referenced post. However, for now this feature is inactive by default. If you’ve used ‘terms’ as an
options_type, follow these steps:
- Make sure you’re on WordPress 4.2+ (official release imminent) and DCF 1.1+.
- Check if you’ve got any shared terms on your site using this plugin.
- If you have some shared terms, add this line to your
define( 'SLT_CF_HANDLE_TERM_SPLITTING', true );
- Back up your database.
- Go to the edit screen for a taxonomy with a shared term, and edit the term (no need to make any specific changes).
- Check that the splitting has occurred correctly, and repeat #5 until you’re done.
IMPORTANT: Note that this will only manage term IDs stored using the
options_type of ‘terms’. It’s entirely possible for developers to create a custom field with DCF which uses term IDs without going through that method. Developers are advised to check their code for such cases and implement their own term splitting management.
Note that no data is actually lost in term splitting. See the referenced post for details on recovering data, should a split happen before management code is in place.
Query variables management
I developed this functionality in order to integrate this plugin better with a common project scenario: a landing page with a series of filters, allowing you to filter the list of posts according to various criteria. These criteria are usually taxonomies, but sometimes also custom fields. One situation where I use custom fields rather than a taxonomy is where a custom post type is effectively used as a taxonomy, and associated with another custom post type via a custom field.
So, to help this process along, there’s now a
make_query_var field parameter. Set it to true, and the field’s name will be registered as a query var, via the
query_vars filter. This means that when WordPress parses the current request, if that name is used as a query string variable, it’ll be recognised.
Now, by itself this won’t do anything. So some code hooked to the
parse_query action converts these query vars to parts of the
Query string variables are only normally included in the main loop’s call to
WP_Query. For various reasons, I often have landing pages which list custom post types, which don’t use WordPress’s built-in ‘post type archives’. And so, often my loop listing the posts I want to filter isn’t the main loop. For this reason, I’ve added a custom parameter that you can pass to
dcf_use_query_string (which, set to
true, makes sure the query will pull in registered vars from the current query string).
You’ll also have to add this parameter to the main loop query if you want custom field query vars applied there. By default that won’t happen. This is because of the above scenario, where you want the query vars applied to a custom loop, but not the main loop (which will be getting the page you’re on).
Custom taxonomies are automatically registered as query vars, but again, if they’re in the query string, they’re only recognised by the main loop query. I’ve made it so that, if a custom query has
dcf_use_query_string set to
true, taxonomies will also be parsed from the query string and applied to the
tax_query. If for some reason you want to disable this, set
In order to clearly warn site managers about updates which may require attention to your DCF-related code, we’ve implemented a system to output warnings according to which version you have, and which is the latest version available on wordpress.org.
The first feature to need such a warning is to be released imminently in
1.1.1 1.2 – multiple map markers (detailed below). This code is ready to go, but we’re hoping to make sure people are alerted about it by getting the code with the update warnings functionality out there first.
Multiple Google map markers
Adrian Toll has helped revamp the
gmap field type to support the placement of multiple markers (in version
1.1.1 1.2). Old single-marker data should be displayed as before, and will be seamlessly converted as posts get updated.
For anyone who’s implemented any custom code which draws directly on the post meta stored for these fields – whether accessed via
slt_cf_field_value, core functions such as
get_post_meta, or otherwise – the old
marker_latlng entry in the serialised array is maintained. However, it will no longer be updated as the marker is moved, or other markers are added. You’ll need to convert your code to check for the new entry in the array,
map_markers, which is itself an array of comma-separated latitude / longitude pairs.