Types and Views Betas with Many-to-Many Relationships

   Amir

Announcements

December 5, 2017
55

We’re very proud to announce a first beta of Types and Views with support for the new post relationship. This release lets you use the enhanced one-to-many and the new many-to-many relationships and easily display the related content.

Maybe it’s best to start by watching what’s in the package. We prepared two videos that show how to set-up and display one-to-many and many-to-many relationships:

One-to-many

Many-to-many

Now, Views recognizes the new relationships that you set-up in Types. You can use the post relationships in two main places:

  • When filtering items in Views queries
  • When selecting posts for field-display

For example, the first video shows how airports and flights are connected using a pair of one-to-many relationships (which don’t make up one many-to-many relationship).

There are many “flights” in the database. When we show the “arrivals” to an airport, we’re not listing all the flights in the site. We create a View that filters flights and displays only the flights that are related to this airport through the “arrivals” relationship.

When we display the flight information, we also show the departure and arrival airports. For this, we use the “post selection” feature when displaying fields. We are in the template for “flight”, but using the post-selection, we can display fields that belong to the related “airport” posts.

If you get the concept of filtering by related content and selecting which post to display for fields, you’re all set with post relationship.

How to download

Types and Views betas are ready in your Toolset account, under Downloads. Switch to the Betas channel and you will see Types 2.3-b2 and Views 2.6-b1.

These are betas, so please don’t update existing production sites to them. It’s fine to use these betas for testing and more (see below).

Can I update existing sites to use these betas?

The new relationships are stored in a completely different way from the old ones. To protect your work, we intentionally block the new “relationships” GUI when we detect that your site already has some existing relationships.

You can migrate the existing relationships to the new schema and then use the new relationships GUI. To do this, go to Toolset -> Settings -> Custom Content -> Relationships, read the message carefully and click on the Activate button.

Migrate the relationships from the old schema to the new one

Once you do that, there’s no going back to the production versions. If you’re only trying the betas, back-up the database before running this migration.

What’s still missing from Views

This release of Views includes a lot of the planned support for post relationship, but not all. Among the missing feature (in this beta) are:

  • Support for many-to-many filters in custom searches
  • Proper GUI for setting up the display for Post Reference custom fields
  • Convenient display for repeating field groups

All this will come in the next Views beta, right after the holidays.

Can I use it on production sites?

The many-to-many support in this beta is already way ahead of what’s available in the production versions of Toolset plugins. If you’re building a site that depends on many-to-many post relationship, you can go with the betas. They are fully tested through our QA process and we’ll have more similar beta updates in the coming weeks.

We’re going to do our very best to make this chain of betas backward compatible. However, there’s a small chance that you will need to make design changes for new betas. With production versions, we guarantee backward compatibility.

Otherwise, if your site doesn’t require many-to-many relationships, you should stay with the production versions.

When will it be ready in production?

Our target date for a production version of Types, Views and CRED with post-relationship is the end of January (2018, not 2019). We’re still developing most of the new code in CRED and we’re expecting feedback for Types and Views, so there may be surprises.

Feedback?

The videos are great, but please don’t stop there. Try the betas and see how you like it. Then, let us know by leaving your comments. The more feedback we get about the actual betas (not the videos or this post), the better the production versions will be.

 

Comments 55 Responses

    • Weird, I don’t see the new relationships option in the Toolset admin menu. Both Types and Views beta plugins are activated and I’ve created two post types. I’ve installed the plugins on a local test site which previously had the production versions of Views and Types installed.

      • I’ve asked Konstantinos, from Toolset dev team, to contact you and see what’s happening there. Can you try this on a fresh site? The relationship menu will not display if old versions of ANY Toolset plugin is running on that site.

        • That goes for WPML plugins as well? Otherwise I don’t have any Toolset plugins installed. I’ll check with a fresh db.

          • There is no dependency between this Toolset beta and WPML. WPML still doesn’t translate the new post-relationship, but this will come for the production release.

  2. Can we connect users with different roles? eg. connect trainers and students with courses.Trainers and Students would be different roles of users..

    • This development cycle will cover only posts and not users. We will work on users support later, but it will take a while before we get there.

        • If you don’t need these ‘people’ to login to WordPress, you can store them as posts. Otherwise, if they really need to be WordPress users, you can use custom fields to point them to posts. It’s a lot of work.

  4. Regarding relationships, when should I let Types create an intermediary post type? Are there benefits in performance when NOT creating an intermediary post type? Is there a difference in functionality between the two options, specific use cases?

    • In this new implementation, there is no cost for the intermediate post and fields. If you need this data, use it. Otherwise, it doesn’t matter. Since we now use a custom table, performance is very high either way.

    • Thanks! After you’ve had the chance to use it, can you post here again with a story of how you’re going to use post-relationship?

  6. It looks fantastic! I would like som info on how this changes the database structure. For developers. New/removed/changed field names. In order to get a scope of how we need to change our custom functions, like; “get_post_meta _wpcf_belongs_xxx_id”

    • Instead of using these fields directly, it would be better to use Types API to get lists of connected posts. I’ll see that we have this documentation in the release plan and will write about it when it’s ready.

  7. Not directly related to this beta and relationships (which I love so far!), but when the new Views releases, could you please implement a better solution regarding the custom css? The way it’s being injected in the pages right now is kind of a hack, messy and bad for SEO. Eg:

    /* ----------------------------------------- */
    /* Inhoudssjabloon: Single Diensten - start */
    /* ----------------------------------------- */

    /* ----------------------------------------- */
    /* Inhoudssjabloon: Single Diensten - einde */
    /* ----------------------------------------- */
    /* ----------------------------------------- */
    /* Inhoudssjabloon: Loop item in Animatiefilm - start */
    /* ----------------------------------------- */

    /* ----------------------------------------- */
    /* Inhoudssjabloon: Loop item in Animatiefilm - einde */
    /* ----------------------------------------- */

    I never use Toolset for custom CSS so I’d like to get rid of these scripts and divs in my html code entirely. A toggle switch in the settings to completely turn custom CSS off would be great.

    Many theme’s/plugins these days dynamically write user generated CSS in a separate CSS file. For those that do use Toolset custom CSS perhaps you could implement something similar.

    • Unfortunately the scripts within the blocks are being cut out in my post above. The two scripts are the ones that inject the views-extra-css and ct-extra-css

    • Hi Taiko, this is Juan, Toolse team leader.

      Thanks for the feedback.

      We are not totally happy with our solution for custom CSS; but the reality is that our current implementation came indeed from a client that mentioned both SEO and standards as reasons for chaging.

      We used to load our custom CSS in the footer, after collecting all the extra CSS that Views or Content Templates rendered in the page would produce, but CSS in the footer seems to be considered a bad practice, so we ended up moving it dynamically to the header, after rendering it inside a container.

      I understand this is not good enough.

      The main problem we have, and what limits our ability to introdue dynamic stylesheets, is that we do not know what pieces we need to render until the very end. You can use a View in the footer widgets, for example, and we can not know it until you render it. By the time that good practices consider that all your CSS should be loaded, we still do not know which pieces we will need to include.

      Anyway, we will be looking for better solutions and we will probably try to offer some level of customization for this. Any idea is welcome!

      Thanks again.

      • Hi Juan,

        thanks for getting back to me. First I’d like to say that for the most part I love Toolset and really enjoy using it. However, I think there are still a couple of things that are a little rough around the edges, mostly having to do with the way Views CSS and JS are loaded into pages. In my opinion they should be loaded in a cleaner and more dynamic way, with web standards, pagespeed and SEO in mind.

        With Views activated, by default a LOT of scripts and css gets loaded into pages, whether these features are being used or not. For many projects I don’t need most of these Views features. As I prefer using my theme for including custom css and js. Fortunately I’m able to deregister and dequeue most through php. However these (https://pastebin.com/r2BTqVQE) particular scripts/css for the extra css (and IE7 style) seem to be hardcoded into the page with an echo. As far as I can tell it’s not possible to get rid of them using the standard WP dequeue/deregister methods.

        I’m no programmer, so unfortunately can’t give any detailed suggestions how to go about implementing it, but in general I would kindly suggest to improve/change the following:

        If custom css IS NOT being used, don’t load any of the associated scripts and css in the page (see my pastebin link above). Also load these css and scripts using WP enqueue/register methods instead of hardcoded echo’s, so that they can be dequeued/deregistered. Or perhaps a global setting in Views to toggle between enabled or disabled custom js and css.

        If custom css IS being used, load the css preferably in a separate, dynamically populated css file instead of inline in the page. I have seen other plugins/themes implement it in such way. At the very least don’t output the ‘overview’ of the used custom CSS within the div with class ‘ct-extra-css’. It clutters the page with unnecessary code.

        Some additional improvements of lesser priority, since I can deregister/dequeue them myself, but still nice to have:

        Load scripts/css for things such as front-end controls, pagination, datepicker, onthegosystems-icons, sorting, filtering, parametric searches etcetera, ONLY when actually in use on a particular page.
        When the mentioned pagination etcetera is not in use, I think the div block with id ‘wpv-view-layout’, should not be loaded either.

        Somehow Views also triggers the loading of WP’s Playlist scripts on every page, whether a playlist is in use or not. Standard WP behavior, without Views activated, is to only load these playlist scripts on a page when needed.

        I’ve read on the support threads there are a more people with similar ‘concerns’ and suggestions. I hope you guys find a way to improve these things in a release soon!

        Best,
        Richard

        • Hi Taiko

          Thanks again for the feedback.

          I see that you have very valid concerns and I am opening a dedicatd task for myself to improve the frontend assets management so we avoid the main two issues I see you mention: too many assets loaded in the frontend when they are not needed, and not god enough management of custom CSS added to Views and Content Templates.

          I do agree about your comments on the multiple assets we load in the frontend, especialy regarding the media player and playlist scripts and styles.

          Most of the problems we face while rethinking this are related to the fact that we need to load things in advance because we are not sure whether we will use them or not. In the case of players and playlist scripts and styles, it is easy to explain: consider a View that contains a playlist, not on its first page, but on the second page, which is loaded after a Views AJAX pagination. Now, WordPress includes those assets in the frontend when it detects a shortcode to display a player or playlist, but since those shortcodes are not in the first, natural pageload, WordPress does not include them. So, if you paginate to the second page, the playlist will not be rendered properly and visitors will not be able to use it.

          Because of that, we need to include the player and playlist script on every View that uses AJAX. Right now we are including it on every View, but I am sure we can improve it to only force those in when AJAX is involved.

          This same kind of limitation explains other dependencies we do load. We will try to better estimate when they are needed and avoid them when possible.

          Regarding inline CSS, we probably did not take the best path to solve the underlying problem. We used to include the extra CSS as inline styles in the footer, but this is only supported in HTML5, while it is considered a bad practice in (X)HTML. Maybe we should detect whether the current theme supports HTML5 and act diferently depending on the answer.

          Agin, the main problem here is that we can not see the future. Custom CSS from Views and Content Templates used on a page can only be crafted while the page is being endered. Yes, we can put them on a dynamic stylecheet and load it, but still footer stylesheets are only supported in HTML5, so for (X)HTML we still need to use a different solution, that will probably still be adding the styles to the header dynamically using javascript – that we can place in our main frontend script, instead of in a hardcoded script tag, of course. As well, I will review that thing about IE7 that looks really really weird.

          We will be doing such imporvements probably as batches, starting now, and they will span over several releases I think. Thanks fory our patience and I hope we wil eventually get to a point that makes you happy.

          Regards.

          • Thanks for the explanation. I do better understand now why it’s tricky to manage assets not knowing beforehand which are needed. I am confident you and your team will find a solution though!

            For me, the most pressing issue right now is not being able to remove the extra-css and ie7 scripts/css (including the divs), using the standard WP dequeue/deregister method. It would really be of great help if that can be fixed with the upcoming release or soon after.

  8. This is great news and I will certainly use this. However, the site I am building right now heavily relies on front-end generated content, so I absolutely need CRED. I will not be able to test before you push a beta version of CRED that works with the beta versions of Types and Views. January is not very far, but as soon as you get a CRED version to test, I am in!

      • Yup, that’s coming. We’re aiming for a first production release with CRED by the end of January. This will include the most basic support for post relationship in CRED. You will be able to build CRED forms that create and modify any sort of association.

  9. Custom post types don’t show up in my navigation menu’s (Admin > appearance > menus). Is there an extra setting required to enable them, or bug perhaps?

  10. Amir,

    This isn’t a specific comment regarding the new m2m release. I just wanted to take the time to drop a quick comment and say that you Amir and your team’s collective vision in Toolset’s overall development is absolutely stunning.

    I still don’t think some users of your plugins grasp the potential of what you can build using Toolset beyond the typical membership / classifieds / realestate type websites.

    I am a frontend ui/ux developer that recently parted ways with my backend dev teammates in favor WordPress + Toolset (minus Layouts).

    I know I’m in the minority, but I’m using WP & Toolset as a development framework for building full blown progressive web applications.

    And soon, I plan to use WP & Toolset to develop offline-first headless WordPress PWAs via the REST API just as soon as you have CRED up to par with the m2m features and Types custom fields have REST API support.

    Anyhow, for about a year now I’ve been very hesitant to completely adopt Toolset as a core development tool in my stack. The past round of updates has solidified things for me and my hesitance is no longer.

    You have earned a lifelong user. I now proudly preach to other devs the power of Toolset, as well as the well oiled machine that is the OnTheGoSystems management, development, and support teams.

    Thank you for all you do Amir!

    • Thanks for your kind feedback. You should know that the people who are leading the development of post-relationship here are Jan Ε tΔ›tina and Juan de Paco. The lead developer for m2m for CRED is Riccardo Strobbia. I’m sure that you’ll run into them at one point or another.

      I appreciate your support and am proud to have earned your trust! Have a great weekend.

    • I think that we’re talking about two different thing. A “View” is something that you create once and is used to display the data. A site that has many page-views doesn’t generate new Views in the DB. It just runs the same View over and over. When the site also has page caching, there’s no impact on the DB or on page load times.

  12. Is there a problem with using the Beta version of Types (this looks great!) and the current stable version of Views… or do I have to use the beta versions of both Types and Views? I have a many-to-many relationships configuration.

    • If you want to use Types beta, please use it with Views beta. There is some dependent code, which needs to run together. Views beta includes everything that the production version has, but adjusted for Types beta.

      • Thanks for the response. My confusion was related to the following from the post:
        ——
        This release of Views includes a lot of the planned support for post relationship, but not all. Among the missing feature (in this beta) are:

        – Support for many-to-many filters in custom searches
        – Proper GUI for setting up the display for Post Reference custom fields
        – Convenient display for repeating field groups
        ——

        Is this saying the many-to-many Views related stuff will not work in the beta? Unfortunately, I am new to Toolset, and I don’t know what views vs. “custom searches” are.

    • This will come in about a month. In order to have self-joins, we need to complete the ‘connection aliases’. It wasn’t complete for the last beta, so we intentionally disabled self joins. For sure, it will be part of the production release. We’ll try to have it before in a beta, so you can try it and give feedback.

  14. Since there are no tutorials yet for relationships apart from the 2 video’s, I was wondering if it’s possible to achieve the following use case and if so how?

    I have two custom post types Services (hierarchical) and Cases (non-hierarchical). They have a many to many post relationship between them. Now I want to show on a case post, a list of links to other case posts that are connected to (one or more of) the same service(s) as the current case post. So as a result the displayed list of other cases on an individual case post varies, depending on which connected service(s) it has in common with other cases.

  15. The production releases of Types, Views and CRED scheduled for the end of January, they will include FULL support for repeating field groups as well?

    Any chance these Types and CRED updates will also allow us to use per-field custom regular expressions to validate/sanitize/replace data on both the back and front ends?

    Would like to start building a very large site soon with a lot of user submitted data and the above features are very important. Hope the end of January release date sticks! πŸ™‚

    Thanks!

    • Repeating field groups are already included in Types and Views (in the current beta). The CRED support will start as more basic, so we can release a production version soon. Then, we’ll add more and more features to CRED. Our goal is to allow you to do with CRED, on the front-end, what you can do with Types in the admin. It’s a lot more complicated in CRED because you have full control over the HTML. In the WordPress admin, it’s a more straight forward implementation (which has been a significant project by itself).

      In order to meet our schedule goal, we need to cut down on features for the first release.

  16. I am just starting to work with relationships. They are SUPER easy to set up, and the interface is really clear.

    When working to create a view, I am having trouble accessing fields when the relationship is many-to-many. Is this to be expected? It is only showing me the relationship I set up that is many-to-one. Are views not ready for many-to-many yet? Or should I keep trying?

    • Views beta works with the Types beta to display the fields of related posts. Did you look at the video at the top of this post? When you need to display the fields of related posts when connected as many-to-many, you need to create a View. You cannot just insert a field and select the ‘related post’ because there will be many posts that are related. You should create a View, set it to filter by the related posts and then use it to display the fields. You can see it here:
      https://www.youtube.com/watch?v=hmhiXHpwWYI

      This ‘video documentation’ is very partial. I’m working now on proper documentation that will show how to display fields of related posts, with all relationship kinds.

  17. HI Amir,
    I love the concept, can’t wait for the custom searches. Will it also be possible to choose fields to display with the related post (as is possible now in the production version?) With the beta the metabox becomes quite large πŸ™‚
    Thanks anyway for the great work!

    • When you’re displaying the ‘one’ side of one-to-many relationships (the parent post), you can choose for which post to display the field. If you can show a screenshot of what you’re referring to, I can answer better. I’m not sure what’s missing and which metabox becomes too large.

    • These Types and Views betas are ready and available for download right now. By the end of January, we’ll also have a beta for CRED with post relationship. Then, it moves to production.