Preview for Nested Repeating Fields Groups

   Amir

Announcements

August 1, 2017
129

We’re completing the implementation of repeating field groups in Toolset. This will use the post relationship infrastructure, to make repeating fields super efficient. See how it’s going to look and give us your feedback.

For years, Toolset offered parent/child relationship, which we advocated as a good implementation for repeating groups of fields.

From the database point of view, this is OK, but our GUI implementation made it less than ideal to use. As part of our post-relationship project, we’re also creating convenient GUI to handle repeating sets of fields.

See how it’s going to work:

And, we got a lot of feedback that editing fields in narrow table is not always ideal. In fact, it’s also visible in our own video. So, we’re thinking about an alternative editing mode, which will display only one row for editing at a time.

Setting up repeating field groups

When you edit a fields group, you’ll see the usual button to Add new field. Next to it, you’ll find the new Add new repeatable group button. This adds a sub-group of fields.

Setting up a fields group with repeating groups in it

It’s not shown in the screenshot, but you can add repeating groups to repeating groups, providing infinite nesting.

Editing fields in a group

When you edit a post that has repeating fields group, it will look like this:

Nested repeating fields group in the post editor

You can add as many items as you need to any group. Click on ‘Create’ to add the first nested item or ‘Add new’ to add more items. Nested groups are tabulated under their parents.

This is how the ‘vertical-alignment editing mode for fields will look like:

Vertical-alignment editing mode, allowing to focus on one row at a time

Displaying repeating fields

You will be able to create a View that loops through a group of repeating fields. This way, you get full control over how the fields look. When you need to display a nested group, create a View for it and insert that View into the View of the parent group.

Including repeating fields in forms

CRED will provide a GUI that’s very similar to Types. You’ll be able to add items to the top-level group as well as to nested groups. Generally speaking, CRED gives you the same editing capabilities in the front-end as Types gives in the backend. This will be part of the CRED scaffold, so when you’re creating a form for a post that has repeating fields, you don’t need to manually create this complex data-entry.

How it works under the hood

In the GUI, there’s not much to do. You click a button to create a group of repeating fields and you add fields to the group.

Behind the scenes, Toolset uses child posts for the repeating items. This means that each field sits in a separate post-meta and not as part of a huge serialized array. By default, you never see the containers of the repeating fields. They appear to belong to the main post you’re editing.

Using separate post-meta for repeating fields allows Toolset to run efficient queries. In our example, we’ve created Universe > Planet > Country.

When you need to display all the planets that have a country by a certain name, it’s important to be able to run one query on the database and get these countries. If all this information is serialized into one post-meta, this query is impossible. With Toolset, it takes one efficient query on the database to get any post that you need. I hope that this makes sense.

Schedule

Our post relationship project has been “in development” for a long time and I’m guessing that it looks like it’s never going to complete 🙂

Actually, we’re just a few short weeks now from a first public release of Types.

Feedback?

Please tell us what you think about this new implementation, its GUI and workflow. We’re part-way through the implementation, so it’s a good time to get feedback and make adjustments.

 

Comments 129 Responses

  1. I have been wanting something like this for so long! I have been considering moving our productions to Craft as they have the handy Matrix fields, which this is somewhat similar to except for the ability to move the blocks around.

    • Thanks for the feedback. My video doesn’t show it, but this implementation does include drag-and-drop ordering for items in a group. When you look at the extended fields-table, does it feel convenient and clear?

      • It looks great. We have built several dozen sites with WP-Types and just love it. We have so many great examples of usage.

  2. Excellent! This is going to be a delightful addition the plugins, the far and away most needed one I could ask for. I “rig” child posts on a regular basis and work arounds with fields now, when all need is this. Woohoo! I am confident you will nail the execution!

    • Thanks 🙂 We are working very hard on the implementation to make it convenient to use, while still efficient on the database.

  3. I’ve always found the use of horizontal scrolling somewhat “strange”… I mean it works fine for light scrolling, but if your “child/ repeatable” field has 20-30-40 fields, then that scrolling becomes confusion / complex.

    UI-wise, has there ever been discussions to make date-entry vertical vs. horizontal ?

    • That’s a valid point. I’ve asked Jakub, our UI designer to join this conversation and reply. It’s the middle of the night for Jakub now, so we should get a reply tomorrow.

      • That’s great, tks. I’ve had to work on a site using Pods a few months ago, and I remember thinking that their UI for Advanced Custom Post Types seemed to tackle this differently, and the resulting UI in the dashboard for clients seemed “cleaner” / easier.

      • Oh.. wow! I stopped the video at 0:41, I’m sold! I’d never use the horizontal layout anymore 🙂

        So now, I WANT that UI.

        And the automatic folding for the active item makes sense. At the same time, I could see times where it might be nice to have 2 open to visually compare, and ability to re-order them through drag’n’drop.

        This is DEFINITELY going in the right direction, nice (and fast) work, guys !!

      • I definitely prefer the new vertical presentation over the horizontal. However, the floating panels look like they take up a lot of horizontal space themselves. That and having floating panels on various parts of the screen could make the UX hard to use on smaller screens.

        Would it not be easier and more compatible with various screens to simply nest each repeating field group inside the boundaries of its parent? I made a quick mock-up to demonstrate…

        http://imgur.com/5yE2EPP

        By the way, it would be nice if the box surrounding each section or repeating field group was a darker shade of grey or a different colour all together to make each one stand out better from their surroundings.

        Thanks!

        • What you’re suggesting was our first thought too, but then we realized that it’s going to be a very long vertical scroll and would make drag-and-drop ordering challenging. Honestly, I wouldn’t recommend anyone to edit this kind of content on a cellphone.

          I agree about emphasizing the box of the element that you’re editing. It’s not always easy to notice which fields belong to an item and which belong to its parents. We’ll make sure there’s enough contrast.

          • But if this feature is going to be implemented in the same way on the front-end via CRED, we can’t control which type of screen visitors are going to use. Seeing as more than 50% of website traffic now days comes from mobile, don’t we have to assume that many users are going to be entering repeating-field-group data using phones?

            Unless you’re planning a different UX for CRED?

            • You have a good point. For CRED, we’ll need to give more flexibility. This means that the HTML output will include smaller elements that you can edit yourself. I’m making a note about this.

            • Thanks for taking my comments into consideration.

              Since you’re working on Field Groups as part of this new feature, I’d just like to make a couple suggestions while we’re on the topic…

              Can each field we add to a field group get its own regex field where we can enter any regex we want to validate the field on submission? Currently I don’t understand how people are keeping their data uniform.

              When adding fields to a field group, can we please get a “duplicate field” option on each field? For example, if I make a phone number field and I fill in several of its options, I’d like to be able to quickly duplicate the phone field to add fax, cell, home and toll-free fields without having to repeatedly fill in the options with the same info.

              Thanks again!

            • I’m taking note of these requests, but I can’t promise when they will be available. I think that your second suggestion is also possible to implement with JS, so it’s less critical to implement in Types.

    • The first beta release (in a few weeks, not months) will include only Types. This will be something for testing and not for production sites. We’ll need to update all Toolset plugins to be ready for production sites.

  5. Have been waiting for it forever. My first question to support was exactly about that function, because I was moving from Piklist that had it a few years back. Thanks for doing it. Hope it won’t introduce too many new bugs though, have been suffering of those a few times.

    A remark on the GUI: some of your interfaces look well only on very big screens, especially when there is a lot of data. I’m particularly talking now about “CRED Forms” settings in “Access Control”. After adding a few roles and quite a few forms, I have to remove unnecessary rows via inspector to be able to work with the table. The “edit a post that has repeating fields group in it” seems to be the same case. There should be a way to make this UI fit to smaller screens better.

    Thank you for a wonderful plugin overall, it’s saved and keeps saving incredible amounts of time and efforts.

    When this update is planned to be released?

    • Right. Someone else already mentioned here the possibility to select horizontal/vertical orientation. I’m making a note of this and we’ll see if/how it’s possible. I agree that when posts have many fields, it’s not practical to show them one next to the other. It’s even showing up in the video that I produced, with only 5 fields. Good catch!

  7. Thanks for showing this preview. I guess I was alerted to this demo because I had a problem setting up a slideshow using a repeating field.

    The repeating field contained the images for the slideshow, but to display the captions, I need to add them to each repeating field instance, such as this:

    [photoslideshow (repeating field)]
    photo 1 upload
    photo 2 upload
    photo 3 upload

    Currently I can upload the images, but I can’t assign the captions to the relevant images in the media post type. I have to access the image via the WP media uploader, but the media uploader is not available to the visitor via Cred form.

    This looks as if I would be able to do this now, is that correct?

    [photoslideshow (repeating field)]
    photo 1 upload
    caption 1
    photo 2 upload
    caption 2
    photo 3 upload
    caption 3

    Please let me know if that needs further explanation.

    In any case this looks like you doing some great work. Thanks for the preview and good luck with the implementation.

  8. Looking forward to this new feature. My biggest concern is the actual UI for an end-user. Obviously, we don’t see a CRED demo in the video but for my users, it needs to be dead simple to understand how to create child records and the Create button might be a stumbling block.

    Would it be possible (maybe as an option) to display that first empty child row initially instead of having them have to click the Create button to display the child form?

    I know it gets complicated if you have multiple repeating field groups but in my case, I just have one and I’d like it to be displayed by default, ready for user input.

    • I think that it’s something we should do with lower priority. First, I want to check with out UI folks if we can choose horizontal / vertical alignment. Having an empty row open by default can bring more complications, because we also validate some fields (which you select as ‘required’). If it takes one more click to open a row and it saves all this complication about knowing which is a totally empty row to ignore, I think it’s better to keep that click.

  9. So essentially each repeating field is a mini post type with it’s own post fields? This is possible in the current builds, but this seems way more convenient. Looking really good

    • Yes, exactly. From the DB point of view, it works already today. However, the process today is exhausting. The new implementation handles all the complexity behind the scenes and allows you to create nested field groups in a single click. By knowing that you’re creating nested field groups, rather than only DB connections, we can optimize the GUI.

  10. This will help me so much in project I am working on right now. I hope they release ASAP. The other thing I would like to see is to be able to use full width with Divi.

    • We’re also in touch with Divi folks, but it’s a different project done by different developers.

    • There are many ways to implement full width for custom post types in Divi at the moment but it is not trivial, requires some patience and understanding of the the structure used in Divi and its styling, and may not be for those who aren’t into hacking.

      That being said a progression to more customisable integrations is an inevitability and from what Amir has hinted, that is indeed what is happening, which is more good news!

      Stephen

      • Right. At this moment we are finishing super tight integration with GeneratePress, OceanWP and Astra themes. This will allow you to control sidebars and other theme-elements for pages that you design with Toolset.

        We started with these three themes because we had to start somewhere and they are pretty popular among Toolset clients.

        As soon as we’re done (very soon), we’ll do the same for Divi, Avada and Genesis.

  11. So will this essentially substitute the child/parent relation ship or will this be an added layer to the existing implementation?

    • Sounds promising! Do you know if this meta would be attached to the image itself, or to the repeating post’s meta as a custom field? I’m wanting meta attached to image for image SEO purposes.

      • I need to check how to enter a field into the placeholder of the alt and description attributes of the image field. If this is possible, then you can use the image field conveniently. Otherwise, you can manually write the ‘img’ tag and construct it from the various fields in the group. Does this make sense?

        • I would greatly appreciate it if you looked into implementing a simple way to add/edit image alt and description attributes. I’ve only found this to be possible with ACF, but I’d much prefer to use Toolset!

          I’m not sure what this means: “Otherwise, you can manually write the ‘img’ tag and construct it from the various fields in the group. Does this make sense?” but understand if we’re diving too deep in this unrelated thread. Just wanted to suggest the feature listed above.

          • Brent, you’re absolutely right. This is the reason I wrote this post. I want to get feedback from people who actually build sites (we don’t) and to understand what YOU need. I’m adding a separate task about image fields so that we make sure that you can create efficient galleries with Toolset. Thanks for your help in identifying this.

            • If the repeating images (and their metadata fields) were attached to the parent post, it would be easy as pie to use the gallery shortcode to create a super simple image gallery.
              This is the way it works now, but that might mean that the images are attached to the post for the repeating fields/image and won’t work with the gallery shortcode to display all images together for the parent post.

            • Right, but you can create a View and use that to display the gallery. Should be very straight forward.

            • Being able to use the gallery shortcode is by far the most straight forward method.

              If you have to rely on creating a view to display your image gallery, then you also need to create the styling to display the images in a nice looking grid. If you want a masonry grid layout (like the one in JetPack), then to be honest, I would be completely lost and the complexity would make it not worth the time.

              Unless we were able to use the image ids. Then something like

              gallery ids=”729,732,731,720″

              would would be trivial to create with a View and the day would be saved.

            • Thanks for the explanation. Toolset allows you to set-up repeating fields in two ways. You can declare individual fields as repeating. In this case, they belong to the post you’re editing. If you create a group of repeating fields, they will belong to a container post that holds these fields. The other alternative is to store them serialized, which will cause all sorts of problems and would still not allow you to use them in galleries.

              So, if you want to upload multiple images and use in a gallery, you can set just the image field as repeating without putting it into a group.

              Does this help?

  15. Thank you for this demo. Will it also be possible to sort the repeating fields by drag and drop in the UI ? Indeed, until now for some projects I had to use this feature from old posts2posts plugin instead of adding an order number field in the child posts with Toolset solution

    • Yes, we’re including D&D ordering in the fields group editing. It’s not showing in the video because of a problem loading Font Awesome icons, but it’s in the implementation.

  16. Will these “mini-pages” of sorts be “displayable”? Or will they be something on the backend that’s no-indexed, removed from site-map, and never seen? If they’re viewable, I’m curious how the design/display of the particular minipage would work, as well as the options for URL structure. Care to elaborate?

    Regardless… Excited and looking forward to the release, as always 🙂

    • We’re talking about fields that belong to posts. Fields don’t get displayed alone. You can create a View, which goes through the items and display them any way you want.

  18. Great addition, thks Amir! About CRED, one of the difficulties so far was to link child field selectors to their selected parent; indeed, for visual comfort, a user should only see a separate dedicated child field selector after having selected a particular parent field: will this be possible?

    • I’m not sure I understand the whole scenario. Can you describe (with some real-world example) what you’re doing and what’s challenging?

      • Hi Amir, I realize I barged in out of context…
        Using your example, when a front end user selects one universe he should be presented (in a CRED form) with a new selection field listing all planets available for this selected universe. To achieve something like this, my idea was originally to use hierarchical custom taxonomies; alas, as I found out in this support exchange https://toolset.com/forums/topic/how-to-create-conditional-child-taxonomy/, it is not straightforward. So the alternative was to use custom post field instead with conditional display, although without proper parent/child logic it is very diffcult to maintain. I was thus hoping that your repeating field project would sort of automatize the process, whenever a new child field is added to its parent.
        Does this make the matter clearer?
        Thanks.

        • It does now. Thanks. I’m taking a note of this and we’ll handle when we start adding the post relationship to CRED.

  20. This is SO GREAT!!! 🙂

    Can you tell me how it works with WPML?
    Is WPML handling these “nested” child post type as a regular post type with settings for “copy”, “translate”, “do nothing” etc. and if it´s set to “copy”, will the content of these field groups appear automatically in the translated “parent post”?

    Thanks for all the effort!!!
    Manuel

    • Yes, WPML compatibility is part of the core design for this and other Toolset features. If you set to “copy”, the translated posts will have the exact same fields (with their nesting) as the original.

  21. Hi Amir,

    Nice one. Looks like a a more logical and user friendly way to implement repeating grouped fields than doing so through the current parent/child relationship method.

    Cheers

    Stephen

  22. This is a great functionality! I wanted for a long time to get rid of using ACF along with Types. I do have a question though: is there any way you can add a Post Object type of field where you can select what format should be returned (most needed is the ID of a post) and what post type should be (eg. event)? Thank you and again great job!

    • We’re going to add a new Post Reference field (it’s not in the current demo, but it’s going to be in the product).

      This is actually the reverse of a repeating fields group. A repeating fields group implies that you’re creating child items. A “post reference” field implies that you’re creating a parent.

      Right now, to reduce complexity, we’re not going to add polymorphic relationships. I know that it’s easy with ACF, but displaying this content is a lot more complicated. You have different displays for different kinds of linked items. Doing this now opens a whole list of issues to handle.

      So, when you create a “post reference” field, Toolset will require you to choose to what post type you’re referring.

      I hope this is what you intended to ask.

  23. Thank you, Amir
    I do not know what to say … Relationships, repeating field groups … This will be the most major update for all time! When is it planned to completely update all plug-ins (more or less)?

    • We plan on having a beta for Types in a month. When this is out, I’ll also have an update about the production schedule for all other Toolset plugins.

      • An important question for me.
        Is it possible to do a parametric search in Views on these fields – select the grandparent, then select parent, then child?

        • Yes. And this is exactly why we’re saving each of these fields in a separate post-meta, rather than a serialized array. Only separate DB entries allow to create efficient custom searches.

          • You guys are moving in the right direction. Without a doubt, your work is worth a lifetime license

  24. Does this also work with the basic repeating fields? I made a tryout earlier with the child posts which contained a repeating inputfield. And this one was ignored at the parent post. I could edit it in the child off course, but as soon as I editted the parent post it was gone again.

    • I’m not sure I understand the scenario. If fields are ignored, it sounds more like a bug to me. Can you report it in our forum and leave another comment here with the link to the thread? It would be good to have there screenshots that show what’s happening.

      • I have a fieldgroup where one field is a repeating inputfield. This one doesnt work from the parent post. When I edit it in the childpost where the fieldgroup is refered too, it is shown off course and I can edit too. But when I save the parent page, it is undone. I always thought it was not able to use it. Hope this will work in the next update because I use this for a section template.

    • Is there a beta version I can test? Than I will make screenshots for you. Happy to help off course.

  25. Great work Amir. Agree with others. We have been waiting for this update for a while now and it great to see that you’ve incorporated most outstanding “issues” into this.
    Can’t wait to give it a go when it’s release. Keep up the good work.

    • You can create a View that will access this fields. Then, you can display that View anywhere, inside any page. So yes, you can display these field groups anywhere in the site.

    • Toolset will automatically upgrade your database to use the new schema. We’ll make sure that existing sites are not modified when this new functionality becomes ready.

    • Thanks for the answer. But I was more refering to importing data sets into the new structure. Say I had countries， states, cities postcodes (abriviated states) etc. Would this now be possible ?

      Thanks guys and love your work

      • Even if you could set up the structure in types. Export to excel, manipulate the extra data and import it would save some data entry.

      • I think that we should work on this import with other folks who are creating content import plugins. We’ve already done some work with WP All Import.

      • I think that this will require manual work on your side. You could have stored this information in all sorts of different ways. I don’t see a way for us to build a tool that will import from any structure to the new relationships.

  31. This is a very cool feature, and I think it is super useful for many purposes (including galleries and sliders – there will be no need for a plugin for that). UI is very logical and easy to use. I could only wish it would scale better on smaller screens to avoid horizontal scrolling. It looks like a dinosaur among modern responsive UIs. If screen estate is limited (which is, with two sidebars at the left and at the right) maybe a full screen popup with options would be a solution (although I tend to avoid popups as much as possible)?

    Discussing UI, can’t stop thinking about probably the biggest challenge to Toolset in the coming year: a Gutenberg project. It’s sleek and modern (although half-baked, on my opinion, as it is now), but it can create so many potential issues for plugins, themes, and everything that modifies a post editor UI. However, despite that, WordPress people seem to be really serious about it. Hope you guys are aware of that thing coming and will be able to come up with some solution up your sleeve. I love Toolset and wish you best with all my heart. Hope you will be able to solve that challenge! On the bright side, it could be a chance to remove whatever little imperfections Toolset UI has as of now.

    • Thanks Kirlat. We also have a draft for a second UI that shows individual rows open with full details. Have you seen it?

      We are closely watching the Gutenberg editor. So far, it’s not ready for us to start integrating. You probably saw some of the feedback that testers left on it. This feedback makes us feel that Gutenberg is still going to have many changes before it goes into WordPress.

      Of course, once it settles and it’s on its way to become the official WordPress editor, we’ll make sure that Toolset works with it.

      • Hi Amir!
        I’ve missed that alternative UI due to a glitch that caused a delay between when my comment was written and when it was published. I like the alternative UI a lot, it looks really cool, on my opinion. It should scale well on devices with screens reasonably small, so I think users with any screen size should be happy.

        It’s great to know that you are preparing for Gutenberg. It’s probably a lot of work for you, but we, users, do value your support greatly. Because if it, our sites that are using Toolset would be able to run smoothly. Thank you for your great product and your hard work!

  32. Hi Amir and All Toolset FAN,

    To prepare for “Nested Repeating Fields Groups” we would like to structure a national wide directory with the following main Fields Groups:

    – (ONE) country with (12) region and (70) main city.
    – (TWO) languages.
    – (EVENTS) for national wide.
    – (GEO) map for all locations.

    Example1: If a places like museums in all (12) regions how the nested repeating fields groups structure will look like.
    Example2: How we setup the repeating events for all the citys.
    Example3: How we do deep linking with the things of the same category.

    What is the best way to define correctly the Fields Groups to reflect the new coming update, although I could open support thread but
    it will be better to be here for further discussion from toolset members.

    Finally thanks for this excellent news.

  34. Toolset is becoming more awesome at each release and this way of handling nested repeating fiels with the child posts looks really awesome. Well done to have added the ability to stack them vertically. I already have some ideas to use it.

    Great Work, as usual.

  35. It will be nice with little CRED FRONT-END DEMO, showing how to upload multiple images on “PRODUCT GALLERY” element of WooCommerce plugin.

    Thanks

  37. If I already have a site that uses parent child relationship posts in order to get around the issue this is solving for; will it be possible to convert those without having to recreate the posts in the new format?

    • Sorry for the slow response. I missed this last question. Yes, we’re building a content migration tool. All old ‘one-to-many’ relationships will move to the new schema. Existing sites will continue working as before, you will use the new DB connections. I’m still not sure if we will manage to handle double one-to-many relationships and turn them into the new many-to-many relationships. I want to have it, but it’s not simple.

  38. How about existing fields, so far not marked as repeating fields? Will they be converted automatically if desired (also replaced in the db to it’s own meta?)

    What about taxonomies and term fields?

    Any suggestion how much longer do we have to wait for this feature?

    • Types will continue using the same storage for custom fields (the normal WP meta), so we don’t need to migrate any fields. Types will migrate the post relationships. So if you are using the parent/child connections today, your site will automatically use the new post relationship schema. Custom fields belong to posts, so they don’t require any movement.

      Same for taxonomies and their metas. They don’t require any move.

      We’re aiming for a first release in about a month. It’s taking time because this is such a complex project, but it will be ready.

  39. This is going to be very useful, I look forward to the release. I also cannot wait to see the improvements you make to the post relationships.

    • With relation to the changes, you talked about many to many relationships. How will these change? Thank you

      • Today you can implement many-to-many relationship using an intermediary post. This works (and we use it also), but it’s not very easy to set up and not very high performance.

        The new many-to-many relationship in Types will take just a few clients (in a wizard) to set up and use. Pages that display related content will be super fast, because they will use a dedicate database table, rather than jump through the WordPress post-meta for connections.

  40. Very interesting stuff! Thinking of so many applications!

    Quick Question:
    How will this work in conjunction with your post about the integration of the 3rd Party Tables plugins ? Will this remove the need for it? Will it work with the repeated groups created? Is this not necessary to use when using that plugin?

    • Most Toolset clients build tables just fine with Views, without needing additional plugins for that. If the developers of the Tables plugin will decide to integrate with the new post relationship, it will be possible. I haven’t checked on this.

      • Hi Amir, I have where possible avoided many to many relationships for the reasons you state but I am getting into the situation where a small number of my posts need more than 1 parent (many to many).
        Will this be possible soon without adding an intermediate post type? Thank you

        • The next major version of Types (and all Toolset) will include the convenient and efficient many-to-many relationship. We’re planning a first beta in 4 weeks from now and it will only cover Types. Views will come next and finally CRED. I wish we could have it faster, but that’s the best we can do.

          • Thank you, Amir, No rush. I look forward to the release. It is amazing how quickly 4 weeks can pass when you are busy.

  41. Hi Amir.

    We’ve definitely been waiting what seems like forever for the post relationship feature so roll out! I do think it will be worth our wait. 🙂

    However, judging by your comments above… a first beta for only Types in a month? Then Views and CRED integration betas further down the line?…

    Judging by that, could you be very clear here… Are we realistically looking at the beginning of 2018 before its integrated into the entire Toolset suite and stable enough to use on live sites? Before that do you reckon? Or even later? Perhaps you have a roadmap now that it’s further along?

    Basically, it seems that most of us are wanting an idea of a stable release that is integrated into all Toolset plugins and ready for live sites, but it’s hard to judge how many more months we are looking at when considering a beta for Types in a month.

    I’m definitely not complaining here! Sorry if it comes across that way. And I understand the huge complexity of this project. I love everything you guys do and think you have a brilliant team! It’s just that I’ve gotten so eager!!! Especially after your little video sneak peaks! 🙂

    Thanks again Amir,
    Jay

    • I understand that you need a clear roadmap and schedule for this development. We’re in the same situation as you.

      Our understanding of the project evolves over time. We implement something, show a preview, get feedback and act on it. It’s the first time we’re building a project like this, so it’s hard for everyone involved to have accurate estimates.

      This month, we’ve been completing the editors for related post types. You probably saw the updated demo with the vertical editing. This was a significant addition to the scope and schedule, but I think that it’s worth it.

      The reason why we’re so flexible about the scope of the project is because we’re building here something that will likely be the basis for many WordPress sites in the coming years. We want to get it absolutely right. Future changes to the schema or workflow will be very costly both for us and for clients.

      Our goal is to have a good first production version for Types and for Views during 2017. Types includes about 90% of the work. The updates for Views are relatively small. The work on CRED is more complex, so it will spill into 2018.

      Does this help with your planning?

  42. Will there be an option to limit the number of times a field group can be repeated? If I want to limit the user to entering only a maximum of 5 items, will I be able to set this limit? This also needs to be added to the existing repeating field.

    Thanks

  43. This all looks good.
    I would also need a way to import data from CSV file when you’re setting up this kind CPT.

    • I agree. We should probably talk about this with the authors of import plugins. We’ll do that when there’s a beta version that they can use.

  45. Hi Amir may i know when this will be implemented?

    prev, i had issue using flexsider esp the caption as i could not fetch individual images and its captions. after this, I hope i could achieve this.

    • We’re planning to have the first public release for Types by the end of September and a production release for Types and Views about two months later. CRED will require a couple more months.

  46. Hi Amir, at the beginning of August you said to expect “the first beta release (in a few weeks, not months)” – is this still the case or will there likely be more and more delays to this project that was originally scheduled to be released late last year?

    • You’re absolutely correct here. We under-estimated the project in its earlier stages. Last time, we showed a preview of the Fields Table and we got some very valuable feedback. This feedback led us to spend a few weeks developing an alternative way to edit repeating fields. I hope that this investment will justify itself.

      Right now, there are no planned surprises for Types. We got feedback about everything that we need and it’s up to us to build it.

  47. I love the direction this is taking. Can you tell me if there is any plans to add a gallery field to types? I’ve been using repeating image fields to create galleries, however uploading a lot on images one at a time can be quite time consuming.

    • Yes, but we’re not sure about the timing. A mass upload for images (for galleries) is a very popular request. You can see that we’re handling very big development now, so it’s better to focus on one thing. When we complete this post-relationship project, we’ll be free to add important features like the mass image upload.

  48. Hello Amir… The entire Post-relationship Project is quite exciting, appreciate all the hard work that you and your team put into Toolset.

    Are there any plans to allow for deleting of related posts and their attachments when the parent post is deleted?

    This functionality is important when building a pro business solution like a project management system that is fully managed via custom Toolset built admin area, not the WordPress admin area.

    In previous tests I have noticed that uploaded files are stored as part of the WordPress media workflow. When deleting the uploaded file they are orphaned rather then being deleted when a parent post is deleted. Fully aware of the WordPress centric argument that attachments are used in multiple areas of a site and while this makes sense for building a blogging site, this is not the workflow when building a professional business centric solution.

    Kind Regards,
    Dave

    • You’re right. Deleting orphan posts is important. It’s on our planning but not for the first release of the post-relationship project. We’ll have it in the second version. Can’t squeeze everything in the first release and have it on time 🙂

  49. Great work guys. Can’t wait for it to come out!

    Will repeating fields groups also be available for user fields?

    • We can’t enable it for user fields, because the repeating field groups rely on post relationships, which we only have between posts. We’re planning to extend this to users, but it’s going to take a while.