I am trying to: I'm testing this site to see how it's going to react when the new versions are released. The beta version of Types works (didn't until I went to Permalinks and clicked Save Changes), but uploading the beta version of Views breaks the site by not showing the results like it should.
You can compare a direct example by looking at the staging site at hidden link and comparing it to the live site that isn't running the beta version of Views at hidden link The staging site was just created, so they are the exact same sites, except the staging site is using the beta version of Types and Views.
I haven't tried applying the beta Layouts plugin yet.
Since this View is added to the page using a Layout, you must use the Layouts beta. Using the old Layouts and the new Views will lead to problems, so please update to Types, Views, Layouts, and CRED release candidate betas.
I uploaded the new beta plugin for Layouts now (I was just trying to test one at a time), but it's still not loading. I don't have CRED in there...is it now required?
It's not required to use CRED, so if you haven't used it in the past you do not need to use it now. I see that you have not yet run the post relationship migration process:
hidden link
Both the Map and Videos Views shown on the City single post page rely on post relationships, so that could be part of the problem. Please run the migration process and let me know the results.
Oh, okay, I didn't realize I needed to run the migration process. It did detect some conflicts in the functions file. I've attached a screenshot. It looks like it isn't liking the WHERE clause for "meta_key = '_wpcf_belongs_neighborhood_id'" I had to add a few of these functions, but they are very similar.
An example of the full function is:
add_filter('wpv_filter_query', 'parent_neighborhood_has_childs_func', 101, 3);
function parent_neighborhood_has_childs_func($query, $view_settings, $view_id) {
if ( $view_id == 2908 ) {
global $wpdb;
$ids = array();
$metas = $wpdb->get_results( "SELECT meta_value FROM wp_postmeta WHERE meta_key = '_wpcf_belongs_neighborhood_id'");
foreach($metas as $id) {
if(isset($id->meta_value)) {
$ids[] = $id->meta_value;
}
}
$query['post__in'] = array_intersect($query['post__in'], $ids );
}
return $query;
}
Since this is part of a SELECT statement and not a WP_Query argument ( like your site is showing at https://toolset.com/documentation/customizing-sites-using-php/post-relationships-api/ ), does this error/notice still apply...or is it just flagging it because it found "_wpcf_belongs"?
This is not a false alarm, unfortunately, it must be modified. The code makes a direct get_results query on the database, bypassing WP_Query. We have implemented some backwards compatibility fixes for queries made with WP_Query, but direct get_results queries on the database are not backwards compatible. Instead of testing for the meta key, you can use the toolset_get_related_posts API to query related child posts, as described here:
https://toolset.com/documentation/customizing-sites-using-php/post-relationships-api/#toolset_get_related_posts
Let me know if you have questions about the new API and I'll be glad to assist.
Thanks, Christian. I'll check this out when we get some time, but I doubt the client is going to be willing to pay us an hourly rate to re-code multiple sections of their website that is less than a year old. They only pay us a monthly rate to perform general plugin updates. What do you recommend as the best way to disable updates, so all the new changes don't break the website? We may end up needing to keep the current version for an extended period of time.
Let me ask my 2nd tier support team for the best process here. I'll update you shortly.
Hi, Types 2.3.2 has been released, and does not include the new relationships system. It does have a fix for the disable auto updates bug, so this code should work:
define('OTGS_DISABLE_AUTO_UPDATES', true);
Please update to Types 2.3.2 and let me know if the issue is not resolved.