if (!defined('WPCF_META_PREFIX')) {
define('WPCF_META_PREFIX', '');
}
to remove the wpcf prefix because I'm working with legacy data. This was working fine until Views 3.0 was released. Now my data won't display unless I remove the code and put the prefix back and then re-save my data. But then of course all my legacy data doesn't work because the prefix is wrong. I am at an impasse. Is there a fix for this?
The screenshot shows my template code. I am not doing any custom PHP queries and I am using Toolset's custom fields to create the custom fields (again, with the prefix removed via wp-config).
I can't send access to a site because I work for a large university and everything in my dev environment is behind the firewall. But you should be able to recreate the issue by adding the wp-config code above, then adding some custom fields to a custom type and saving some data, then upgrade to 3.0.7. You will see your data will no longer display.
I tested this and found the same, including when using a custom string (e.g. "custom-") instead of no string for the prefix.
Modifying the wpcf- prefix is undocumented, so I'm not sure that it is supported, but we surely didn't intend to break it between Types 2 and Types 3, and so I have reported the issue and am escalating this thread.
I discussed this with the Types developers who said that Types 3 stopped using this constant because it wasn't consistently implemented throughout the code, with many cases where the wpcf- prefix is hard-coded.
While it shouldn't be too difficult to revert the changes, without a complete review it would still mean that there are probably random-seeming cases that you may not be aware of where your Types fields don't behave as expected.
It is not documented and not intended for client use (the supporter in the previous ticket was being a little too helpful).
So, it's use is discouraged, and the preferred solution would be to see if I can help convert your site so that it works using the standard wpcf- prefix for Types fields (by running a script to update the keys for the Types fields in wp_postmeta, for example).
The main obstacle to that would be if you have custom code that retrieves the fields directly from wp_postmeta using the field slugs without the prefix, or if there are many cases where you output the fields using the wpv-post-field shortcode instead of the types shortcodes. (Or if you have very many types fields, rather than very many posts using a reasonable number of types fields.)
If that's not going to be feasible we can ask the developers to revert the changes, with the caveat that it is not expected to work reliably (and anyone else reading this thread should certainly not use the constant to modify the prefix).
If updating your site sounds viable I'll need a copy: hidden link
Let me know what you think. (I'll set your next reply as private in case you have the site credentials to share.)
I think that not allowing the prefix definition is probably a mistake. A lot of people have legacy data, and expecting them to modify their database just to use your plugin seems unrealistic. I would rather be able to use the prefix definition. It makes your plugin more flexible and user friendly, and allows users to move their data around different plugins and tools more easily.
Having said that, if that's not going to be supported moving forward then it doesn't really make sense to put it back in now only to have it break in the future.
I appreciate your offer to help with the database but we're running a multinetwork multisite with about 150 sites, using SSO to login and locked behind our firewall, I just don't see how creating a site copy is going to work without a LOT of work on both our parts. If you're still willing to try, even knowing that, then I can give it a shot, but I have my doubts. I certainly can't add a user or disable SSO on the live site so I'd need to be able to log into the copy site before you can have access.
I'll think about how best to proceed given our limitations, but perhaps revisit this issue with the developer and consider the plugin from a perspective of flexibility and usability?
I'll ask the developers to reconsider and get back to you.
I would point out, though, that you can use existing fields from legacy data with Types.
If you go to Toolset > Custom Fields > Post Fields, at the bottom of your list of field groups there is a button "Post Field Control".
Using that you'll see a list of all custom fields, whether they are managed by Types or not. For those that are not you can choose to bring them under Types control.
When you do, if you go back to edit a Field Group you can choose from existing fields.
In the screenshot I have an "existing" custom field which I brought under Types control, and which is now available to add to my field group.
So I can enter/edit data for this field when editing posts, and I can use it in Views filters etc. and output it in templates with types/views shortcodes.
That is the intended way of using legacy data with Types fields.
Anyway, I'll check with the developers again and get back to you.
OK, well that sounds like it could be helpful. I had to delete the prefix definition in my wp-config file in order for your suggestion to work properly, when I left it there the fields showed that they were already managed by types, so clearly something in the plugin is still using the prefix definition.
I did as you suggested, but I can't set any of the legacy fields to dates or radio buttons, which is what they were before. They came in as single_line fields which is fine, but I need them to be date fields in order for my users to be able to continue to use them. All the dates in the database are formatted as standard dateTime data so I'm not sure why I can't set the existing fields as date fields. The information does at least display in the template now. When I set the date field to display as a formatted date in the template using this provided code -
It still displays as the string, like this 1534302000, instead of the formatted date.
My existing conditional shortcodes also display the string version - [wpv-conditional if="( !empty($(cas_event_start_date)) )"]Event Start: [types field='cas_event_start_date' style='text' format='F j, Y g:i a'][/types][/wpv-conditional]
So, at least we are getting closer to a solution, but not quite there.
You are right that when you bring a non-Types field under Types management it is set as a single line field (which is because all post_meta is stored as strings, even if some plugins, such as Types and ACF, use proprietary formats for non-simple fields).
You can change the field type, but only to other simple string fields, such as email or URL.
Changing them to date fields or radio/select/checkboxes etc. isn't possible.
I spoke with the developers this morning and it was agreed that the best solution is probably to revert the changes that were made between Types 2 and Types 3 that affected this, so that your site should continue to work as before. (There are many places within the Toolset plugins where the wpcf- prefix is hard-coded, but it doesn't seem to be affecting your site.)
So, that's what we'll aim for.
I just need to confirm with you specifically what stopped working moving from Types 2 to Types 3 to pass that on to the developers.
From your original question, it looks like outputting fields with a types shortcode no longer worked, and you are also using these fields in wpv-conditional shortcodes, and I take it these stopped working also, yes?
Yes exactly, all output of the legacy fields stopped working whether via types shortcode, conditional, or the {{}} code, everything else seemed normal to me, it's pretty basic usage. Thank you!
The developers have updated the code to revert the changes so that the behaviour in Types 3 will be the same as in Types 2.
It will be included in the next Types release, which is due to enter QA testing next week and can be expected shortly after. Keep an eye out for the update notice.
