Types, Views and CRED Betas with Post Relationships and Repeating Field Groups

   Amir

Announcements

February 20, 2018
43

We’re proud to hit another milestone in our journey for post relationship in Toolset. Today’s beta release includes Types, Views and CRED with support for post relationship and repeating field groups.

Support in Views for Repeatable Field Groups

In the previous beta, Types included “repeatable field groups”. This means that you can make entire groups of fields repeat and even nest repeatable groups under others. In this beta update, Views comes with complete support for displaying repeatable field groups. Actually, the process is simple. You set-up a View which will go through the items in the repeating group. In the View, you choose which fields to display and how.

It’s a View, right? So, you get all the goodies that Views offer. You can display all the items or use Views filters to choose only specific groups to show. If the repeating fields are many, you can use pagination and even AJAX updates.

Read more on the documentation page about creating and displaying repeatable field groups.

“Rooms” of a “House” set up and displayed as a repeatable group of fields
“Rooms” of a “House” set up and displayed as a repeatable group of fields

Support in Views for Post Reference Fields

Post Reference fields are a mirror image for repeating field groups. If a repeating field group implies adding many pieces of information to a post, the post-reference field allows connecting several posts to one (you can call it a parent). This update of Views lets you treat a post-reference field as a connected post, so you can include its fields in templates and in Views.

Easily display any information from the post related using the Post Reference Field
Easily display any information from the post related using the Post Reference Field

Post Relationship in CRED

Much of the work in this development cycle went into adding support for relationship forms to CRED. In this beta, you will discover a new kind of CRED forms called “Post Relationship” forms.

As their name implies, post relationship forms allow you to create and edit post connections, from the front-end. You can connect between any two posts (for post-types which you’ve defined a relationship in Types), or choose another item to connect to a given item. You can also edit the connection information between two posts.

CRED Relationship Forms allow you to connect related posts from the front-end
CRED Relationship Forms allow you to connect related posts from the front-end

In all honesty, this is a complex subject. We ran several usability tests on it and we see that CRED forms for relationships are not a trivial thing. It’s not so much because of CRED GUI, but a lot because the workflow requires careful planning (by you) and a good understanding of the elements involved.

We strongly recommend that you start by reading the new guide on CRED forms for post relationships.

There, we do our best to explain the idea, your possibilities and what’s involved. Then, building it in the GUI will make a lot more sense.

It’s worth your time. These CRED forms for post relationships are definitely not a beginner’s subject, but they open up possibilities for building sites that were completely outside of our reach until now.

Gutenberg Integration

This beta of Views comes with first-time support for the new Gutenberg editor. It allows you to build Views and Content Templates using Gutenberg. You’ll discover new Views cells in Gutenberg and enhancements for the HTML cell. An example site and full documentation are “in the works” right now. Next week, we’ll have the complete demo and tutorials on how you can use Gutenberg with Toolset. This is our first part of the integration. We’re continuing to work on integrating the rest of Toolset with Gutenberg, but what we have now is already a pretty good indication of where this is going.

BTW, I’ve seen a lot of concern about backward compatibility once Gutenberg is out. We want to assure you that there will be no backward compatibility issues. We’re adding new Gutenberg cells and integration with Toolset. You can always run existing sites without Gutenberg (even once it’s already bundled with WordPress). It’s important for us to stay ahead and make sure that when you choose to work with Gutenberg, Toolset has everything ready for that.

Download and Try

These are betas, right? So, please don’t use them yet for your production sites. We’d love to get your feedback about the new betas. Best is to try it on fresh installs. If you’re trying them on sites that you’re developing, please make a copy first, so that you can easily go back to the “production” versions of Toolset plugins.

To get the betas, go to the Downloads section of your Toolset account. At the top-left, select the Beta channel. You should download Types, Views and CRED (of course, only the ones that you use). Don’t mix production with development versions.

Coming Next

We’re at about 90% development of the entire post-relationship project. Just a bit more to go and we’re closing development to start QA and prepare for production updates.

Gutenberg Tutorials

Next week we’re planning to publish the tutorials on how to build Views and Content Templates with Gutenberg. If you’re curious, you can try it already yourselves. The functionality is already in the current betas, but the documentation isn’t yet ready.

Complete WPML Support

Next week we’re also going to update the betas with full support for WPML. It’s almost ready but needs a little more polishing. This support for WPML will allow you to run multilingual sites with post relationships, repeating field groups and post reference fields. The idea is to make everything translatable both via WPML’s Translation Editor, when using translation services and when translating in the native post-editor.

If you’ve been using WPML and Toolset, you should know that you’re getting pretty great integration. WPML team works with other developers (like ACF) on complete compatibility. Because we have full control over both WPML and Toolset, the level of integration and the convenience it offers (to you) is unique. Of course, we’ll write about it separately.

Integration with Layouts for Post Relationship Forms for CRED

The final major development remains between Layouts, CRED and post relationship. We’re planning to have this within about 2-3 weeks from now. This will allow you to use everything in Toolset and build sites that take advantage of post relationships (and repeating field groups, etc.). The planned beta for Types+Views+CRED+Layouts will be the last beta before a production release.

A Production Release

So, it looks like a production release for the next major version of Toolset will be ready around the end of March or sometime in April (and we’ve been known to make wrong schedule predictions in the past). At that time, we’re planning to do two other important changes. We’ll be moving our site from wp-types.com to toolset.com and we’re moving the payments system to be based on automatic subscriptions.

Questions? Ideas? Suggestions?

It’s been a long journey so far and we’re almost there. Let us know what you think and we’ll get back to you.

 

Comments 43 Responses

  2. I’ll look more thoroughly this weekend, but I was curious about the Gutenberg integration so looked at the Types and Views beta with Gutenberg installed. Nice job! It looks like all of that page builder integration paid off. I’m sure everything will get tweaked as it goes along, but it is good to see that you were somewhat aggressive in implementing it.

    I did notice that you put your block links under “Widgets” while Beaver Builder put theirs under “Layout”. I guess the WP core team hasn’t given any guidance on that so we will see a lot of variation.

  3. I started to play with the new (and exciting!) relationship system and tried to add a post relationship filter in a view’s custom search, but I had this message:
    “Before using a post relationship filter, you need to set a Types parent-child relationship for the post types selected in the Content Selection section.”
    I already set parent-child relationships so I guess it hasn’t been implemented in custom search, right?
    (by the way, great work as always!)

    • Hi Sebastien. Thanks for the feedback.

      Yes, at this moment and regarding what we included in this beta, filtering by post relationship is limited to query filters, no frontend custom search filters.

      This means that you can filter items in a relationship by the other end of the relationship, but only if that other end is fixed, ste by the current post, set by a View shortcode attribute, or passed by an URL parameter. This also means that the frontend controls for selecting the element to filter by are not ready yet, and will be included in a not so distant upcoming new beta that Amir mentioned in the blog post: count like 2-3 weeks for it.

      We are very close, and it is not a very big piece of pending development work, but we had to cut the current release somewhere 🙂

      Hope it helps.

  4. I tried the new beta Types and Views on a dev site without Gutenberg, which uses Beaver Builder for a Content Template. When I visited those pages the body (results of the Types body shortcode) doesn’t show and I see a PHP warning related to function “gutenberg_wpautop”. I reverted back to the production version of Types and Views and it works as expected.

    • Hi David

      Thank you very much for the feedback.

      Yes, we noticed yesterday a small glitch that produces this error when Gutenberg is not installed. We are double testing a fix for it, and we will be updating our Views beta package to include it very soon.

      Regards.

    • Hi David

      Just a follow-up. We released a new beta ZIP for Views addressing this issue last Friday afternoon. Hope it solves the problem for you.

      Thanks.

  5. Warning: call_user_func_array() expects parameter 1 to be a valid callback, function ‘gutenberg_wpautop’ not found or invalid function name in /srv/www/mysite.test/current/web/wp/wp-includes/class-wp-hook.php on line 286

    Installed types/views over the previous beta’s (no CRED installed). I don’t have Gutenberg installed, nor want to at the moment.

    • Hi there

      No, self-reference relationships are still in the roadmap. Before getting there and raising the restriction on self-referenced relationships we need to include alias names for the sides of a relationship: we call them internally “parent” and “child”, but for self-reference relationships a different name per side will be needed.

      Thanks for the feedback.

  7. Getting 500 errors for the admin dashboard after installing the latest beta. I think this is a different issue than the one Taiko and David note.

  8. Was hoping that you would have fixed this issue:
    https://toolset.com/forums/topic/certain-action-not-working-when-saving-child-data-via-parent-post/
    When saving a child within Parent Post Screen the save_post does not fire.

    I need this to work. After version 2.2.16 you ‘fixed’ the behavior where previously a date field that was not set was saved as an empty meta value. After 2.2.16 no meta value is saved at all which breaks my application. I can solve that by adding a blank value for a date that is not set, but my users add the child posts from the parent screen. And as per above link, the ‘save_post’ will not be triggered.

    If you do not plan to fix this, will you please tell me what code to use so I can add a value to the database when a child post is saved from the parent screen?

    Though I would prefer you just fix this since it kinda weird that a regular WP hook does not fire on Save Post.

    • Hi Bente

      Thanks for the feedback.

      I am sure I must be missing something. I just did some checks with the code, and also with some dummy data, which consist basically in adding a new child post to another parent post screen, and editing a child that already was assigned to that parent post, and in both cases the save_post action was fired properly.

      In all cases we are using native functions like wp_insert_post and wp_update_post, which do trigger that save_post action, but we might have missed some edge case.

      Can you please open a support ticket about this, and include a detailed explanation of your setup and what steps you performed? I will make sure this gets to the right developer and gets resolved as soon as possible.

      Thanks in advance.

      • OK, I did a bit more testing. Indeed the save_post does fire, but something from the WP Types plugin still comes after my save_post function. Saving the child in its own edit screen works fine with priority 30, but when I save the child from the parent screen the field values as entered are saved and not the values that I use in my own function. I’ve even set the prio to 999, still something from WP Types overrules.
        If I insert a meta value for a field that is NOT on the form, then I do get the value from my code, so you are correct in that the save_post is fired.

        However, I still do not understand why there is a difference in saving the Child by itself and saving it from the parent Screen.

        Any help would be appreciated.

    • All Lifetime accounts continue without any change. You will have lifetime access to new versions (including automatic updates) and to support. You paid for it.

      At some point, in the not-so-distant-future, we will stop selling NEW Lifetime accounts and start offering accounts with automatic yearly payments.

  10. Is the new relationships bacwards compatible with the old parent-child relationships. I notice an database update wizard. WIl this also update all shortcodes. In addition I have some custome PHP which accesses the _wocf_Belongs_toPARENT_id fields. Will these referncess all need to be updated.

    • Hi Russel

      The upgrade will be transparent for existing sites.

      Yes, there is a database upgrade routine, because we moved away from a data structure that depends on custom fields to another structure that uses custom database tables. This will bring relationships to a new level in several areas, and especially on speed: the fields table in WordPress stores too much data, and taking out the one we use for relationshps can only make it more powerful.

      Once the upgrade routine is completed, sites should keep on working as before without the need to change anything. Shortcodes are, in almost all of the cases, already compatible. The main usage for shortcodes involving relationships is the “id” attribute that you can use on most of Types and Views shortcodes: it is fully compatible with legacy and new relationships, and after you update, new shortcodes that you add will work as well as old ones that you already have.

      We are still working on some edge cases for some specific uses, like accessing a given field for a legacy relationship with a conditional shortode from Views, for example. Those edge cases will also be supported and will work properly without any intervention.

      Now, regarding your custom code, I have some news. We are currently working on a small API that should make sure that you can write your own code to access legacy relationships without needing to access the database or the fields storing them manually. The idea is that you have time enough as to update your custom code to use this API before we move on to a production release.

      Also, we re working on alternatives that will minimize even the need to modify your custom code. If you are accessing the “_wpcf_belongs_PARENT_id” using native functions like get_post_meta, update_post_meta or add_post_meta, we will have you covered. We will recommend and encourage that you adopt our API for manipulating legacy relationships, but we do want to minimize the impact for those that will not do it.

      Hope that this helps.

      • OK. Great. Thanks for quick response. I dont mind updating my legacy custom code, as long as some guidance on new structures. (Understandably, the new documentation so far only covers the standard API)

  11. FYI, After installing, I get errors:

    WPV_Post_Relationship_Frontend_Filter::get_settings_post_in_without_m2m(), 4 passed in /Users/RULO/Google Drive/MyWeb/Wordpress/approved/wp-content/plugins/wp-views/embedded/inc/filters/wpv-filter-post-relationship-embedded.php on line 134 and exactly 5 expected in /Users/RULO/Google Drive/MyWeb/Wordpress/approved/wp-content/plugins/wp-views/embedded/inc/filters/wpv-filter-post-relationship-embedded.php:550

    and also

    PHP Deprecated: Function create_function() is deprecated in /Users/RULO/Google Drive/MyWeb/Wordpress/approved/wp-content/plugins/types/vendor/otgs/installer/includes/class-wp-installer.php on line 2559

    • Hi Russel

      Thanks for the feedback.

      We will be addressing the first issue right away, and we will have another Views beta containing the fix in the coming days.

      The second one might be a little longer to solve, and as far as I know affects only PHP 7.2. Once we have a solution for it, we will also update our betas.

      Regards.

  12. I have the latest beta and have created a post type and custom field group for testing.

    In the custom field group, I have some test single line fields, and then the new repeating field group with some single line fields in it. Seems all fine so far.

    However, when creating a new cred post form I cannot see how to add the repeating field group block of code. It doesn’t auto scaffold either.

    Is the functionality of creating a cred form to allow submission of posts with repeating field groups from the frontend not included yet in the beta or have I missed something?

    Thanks!

  13. I just found in the new docs that the repeating field group is to be set as a separate cred form.

    I’m a bit confused as to what the workflow would be like? I imagined it would work like the previous version of custom fields where you just have “add another” on the frontend and the field shows up. I assumed in the beta it would the same way but add another block of fields.

    So for example… If you wanted your users to submit a post on a single frontend cred post form that did something simple like:

    Post Title
    Department
    New Part (repeating field group)
    – Part Name
    – Length
    – Width
    – Height
    + Add another New Part (adds another repeating group)

    Is that not possible in on a single cred post form?

  14. Sorry, one last follow up.

    If the answer to this is to have the cred form redirect to another page having a cred form with the repeatable group (using the cred setting “After visitors submit this form: go to page x”), then how would we handle conditionals?

    Using the same example as above, but with a condition:

    Post Title
    Department
    Do you need a new part?
    – if no, allow post submission
    – if yes, submit and redirect to page with repeatable group cred form

    New Part (repeating field group)
    – Part Name
    – Length
    – Width
    – Height
    + Add another New Part (adds another repeating group)

    Thanks for any insight.

    • Hi Jay

      Thanks for the feedback.

      Our main end goal is to make adding repeatable field groups in the frontend work as adding the in the backend, when using Types alone. That means that our end goal is to let you add repeatable field group instances right away fro the CRED form of the post where this field group belongs, instead of sending you somewhere else.

      However, there are some limitations. If you noticed, in Types you can not add a repeatable fields group instance until you first save the post for at least once. This is important: repeatable field groups are managed as seprated elements linked to the post where they belong, so there needs to be a post to add them to.

      In CRED forms, this can be kind of workarounded. For CRED forms to create new content, we are aiming to implement a solution to let you add repeatable field groups before submitting the form, but then again there are some dead ends to solve. For example: we need to do some garbage management if you add a repeatable field group but you never submit the form.

      This is still a work in progress, so for now the best way to set or edit repeatable field groups is to manage them with specific CRED forms, and in a separated place.

      On your last query I see a very good request, but that can also be requested without this new feature of repeatable field groups. As I see it, it makes sense to have different redirection options depending on the form submitted data, as in your example that makes it dependent of a submitted field value.

      I am filling this request in our internal tracking system, but I can not make promises about how, when or even if this will get to CRED anytime soon.

      Hope it helps.

  15. Hey there

    Does this views beta have a method to display the custom fields of the intermediary linking two custom post types in a relationship.

    e.g

    CPT Music Store
    CPT Album

    Music Release – Many to Many Relationship between Music Store and Album
    – has intermediary with custom fields:
    — purchase link custom field
    — purchase price custom field

    Want to be able to display the Music Store Link and Price on the Album and Store posts.

    Thanks

    Jeff

    • Hi there Jeff

      Thanks for the feedback

      Unfortunately the answer is no. This is in our roadmap, but it was not included in the current bet. We understand how importnt this is, especially now that you can indeed create and edit relationships in the frontend. Displaying dta from the relationship intermediary object is natural.

      We have almost everything that we need code-wise for this feature. We just need to get the GUI right and we will include it in a future update.

      Hope it helps.

      • Hi,
        Displaying intermediary CPT custom fields is super important for my situation (also a music site) I only know how to do it via shortcode at the moment. I need to learn how to do via API? Thanks.

        • Hi Scott

          Thanks for the feedback

          I am taking note of the urgency and need for this. We had this feature planned for a slightly later update, but I am going to try and push it for the Views next beta that we will generate with new features.

          The idea is that you can do this all directly from the GUI, no API usage should be needed.

          Hope this helps.

          Regards.

  16. is it possible to store arbitrary information per connection, i.e. to have connection metadata? Like Posts 2 Posts.

    • Yes, that’s already included in the current betas for Types, Views and CRED. During the setup for the relationship, you can choose if connections should have their own fields (meta). Then, you can use these fields to filter and display.

  17. Is there anything special we should know about installing these over existing production types and views installations? I’d like to try these on a copy of a site that already uses types and views. I have a backup. I can copy the beta versions over the production versions in the plugin folders but do I need to deactivate and reactivate them to build the relationships tables or do anything else to be ready to try out the new features with existing CPTs and Views?

    • Disregard my question. It looks like it just works to copy the beta versions over the production versions.

      Really liking how the relationship features are turning out. One thing I noticed is that the search takes two extra clicks when editing a post right now. To add a relationship, I clicked connect to an existing invasive (I’m connecting eradication projects with invasive species) and the prompt says “start typing …” but you can’t start typing until you click the box then click inside the box. Functionally this works but it isn’t a great user experience. You probably have this on the list of things to fix already but thought I’d mention it, just in case. As soon as I hit “connect to …”, the box should come up ready for me to start typing.

      • Hi Scott,

        to be honest – it wasn’t on our list yet, but you’re absolutely right. A tiny thing, which can become very nasty. We will apply your suggestion for the next release.

        We highly appreciate your feedback. Thank you.

  18. Another UI/UX issue: the relationships in the post editing screen in WP admin run over whatever is in the second WP admin (categories, tags, Toolset taxonomies, featured image, etc.) column if there are more than a few fields in the post types in the relationship.

    Is there a specific place on the Toolset site where we should report issues we find in the beta like this one?

    • It’s perfectly fine to post them directly here. So feel free to flood the comments with your helpful feedback. A fix for this problem will also go into the next release.

      Thank you.