[Resolved] Toolset Development Roadmap / Feature suggestions & requests

[Author]

Posts

[mb]

Hi Guys @ OnTheGoSystems!

I'm referencing to the thread https://toolset.com/forums/topic/plans-for-toolset-esp-themes/.

Now, two and a half years later, I would like to give some feedback and make or remind suggestions, where Toolset could improve.

But first of all: I would really like to say Thank you for this great piece of software aka My Toolset for building Websites and (Web-)Apps. The most valuable improvement in the meantime - for me - was the integration with Themes, Divi in my case. But I wasn't able to use and/or really test the new Relationships you recently implemented in a productive environment.

In the blog post regarding the Release of the Post Relationships (a special Thank you for that), you stated that you will now focus on Forms, Types and Views, which "hadn't got love in a long time".
So, when you show some love to these components, please have my following suggestions in mind:

1. Overall Performance (s.a. https://toolset.com/forums/topic/plans-for-toolset-esp-themes/):
a) Could you please implement an option, which makes it possible to load or unload css and js? Toolset needs its code-base, of course. But even on sites, on which nothing is presented by Toolset, a lot of js- and css-scripts are loaded which aren't in use.
So is it possible to make a base-js and base-css and make the rest load in a modular way? So that e.g. CRED-scripts are only loaded on sites, on which CRED-forms are displayed/in use? I know that I am able to control the loading of scripts by my child theme's functions.php. But therefore I have to make a rule for each and every script (besides my own scripts and styles for the UI/UE) and I have to overlook them every time you release an update (which luckily happens on a regular basis).

2. Types UI/UX and functionality (s.a. https://toolset.com/forums/topic/plans-for-toolset-esp-themes/):
Basically I would like to ask you to have a look at Pods Backend. I like that you split up the CPTs and the fields for those CPTs. Therefore the custom fields are repeatable (if I got it right). That means a field group "Adress" could be used for several CPTs (i.e. clients and distributors). And I do love the Dashboard.
But the creation of fields in Pods is more intuitive and somehow faster. Please compare the creation of fields with Types and Pods directly. You will get what I mean. The Additional and Advanced Options of those fields are great, i.e. number formats, time formats, even an option to make an WYSIWG-field without the WP Media Buttons and so on. These things are not completely implemented in Toolset and have to be done with hooks or at least CSS. And that is not really user friendly.
Regarding functionality: I am missing
a) REST-API-Support on a field-basis. For app-development this is a deal breaker.
b) HTML5-Markup (esp. for Dates and Time) which would lead to less JS and a native visual output on all devices
c) Markdown-Support for Multiple Lines-field
d) the Option to give the same name to several fields. I think pods handles that by ID while Types is using the name. Why? I.e. I have a task in a relation with or repeatable fields with subtasks. Tasks and Subtasks have a Description. But I can't name it Description in Types. It must be i.e. "Description" for Tasks and "Subtasks-Description" for Subtasks.

f) Speaking of Types please also have a look at the option of Pods to connect to another SQL-Database or server.

g) Please also have a look at the post creation. The interface is much clearer. A two-column-based Interface. The Label or name on the left and the actual field on the right.

h) As you made it possible to see the fields of related post types in the meta box for post relationships, could you also make it possible to have fields of a post type shown in the normal "all posts" screen in the backend so that I have a table which I can sort by field. That would be great and make the use of plugins like Advanced Admin Colums besides the inline editing features of AAC almost obsolete.
i) Regarding the post relationship metabox: Its title should be always the other connected CPT, not the name of the relationship. To make it clear, think of projects and tasks which are in a relationship. While editing projects the title of the Metabox for Relationships should say "Tasks" or "Related Tasks" and while editing Taks "Projects" or "Related projects". Right now it says "Tasks-Projects-Relationship". My suggestion would make the UI a little more userfriendly.

j) Will repeatable field groups be editable in the backend when creating Posts in the future? When editing a post and adding a related post to the current post per Add New-Button a popup pops up where you can create the new related post. That's really nice. But repeatable field groups aren't rendered in these popups.
k) Another question: is it or will it be possible to prepopulate repeatable field groups in backend or frontend?

l) Options pages like mentioned here: https://toolset.com/forums/topic/options-page-for-site-specific-data/

3. Relationships:
Is it possible to relate to Users (in the future)? I would like to relate CPTs to specific users without making them the author of that post. Some posts should be editable by specific users not roles or capabilities. Think of a support system. There are companies as clients. And there are several contacts in this firm. If I set capabilites for those companies and contacts and make the specific post only available for these capabilites, then It is available to all users with these capabilities. That means to other companies and contacts. By a User Relationship between Users and Companies and Contacts it would be possible to grant access only to those people who belong to the specific company and/or project.

4. Access/Views (just UI/UX):
Is it possible to deactivate the meta boxes for Access and Views (Content Templates)? (of course via Custom Code) But I mean in the Settings for Toolset? If not, could you please implement that? Those settings should be made sitewide or for all posts of a CPT and not on a per post basis. Or we should be able to choose what seems to be better for a specific project.

5. Forms (s.a. https://toolset.com/forums/topic/userpostmultiple-forms-on-the-same-page-conditional-display-of-user-fields/):
CRED or now Forms needs improvement. I really need:
a) HTML5-Inputs (esp. Date and Time). Even generic fields won't work because they are also Shortcodes and use the same logic as normal CRED-fields. And if I use just HTML5 I am not able to connect to the specific CPT and save the data to it.
b) Because of the lack of support for basic HTML - and please correct me if it is possible to save data by using hooks for those HTML-Inputs - it is also not possible to add fields like a signature. This lack of functionality is really a showstopper.

Nice to have would be support for
c) Multi-Step-Forms
d) Chained Selects with populated post relationships or related posts as options like if product A is chosen then in the next select-field related taxonomies or other related posts are loaded as selectable options (s.a. https://toolset.com/forums/topic/kickstart-development/).
e) Conditional Logic within the form. As far as I know it is possible to make conditions regarding the value of field types. But for forms it is needed to make conditions based on values chosen in the form. Or I don't get how to manage that. And it is not very user-friendly to not have an option to edit the wpv-conditional-shortcode via GUI.
f) Calculations (with PHP or JS) for a numeric Types-field which should be marked as Sum and on which the user inputs of other fields would then be populated.
g) multiple Forms on one page to edit several post types with one Click or update specific fields of different post types with one form.
h) Webhooks to save data in other applications or perform other actions like connecting to a PDF-library and save the post or the form inputs as a PDF or save attachments to a Webdav-server. Or a GUI for the Forms-Hooks.
i) a Form Builder and/or a tight integration with Page Builders like Divi, Beaver or VC like you did with Content Templates. As CRED is Shortcode-based, you should be able to integrate these in a similar manner like you did with Types and Views Shortcodes in the case of Divi.
If you need some inspiration please have a look at Gravity Forms and Plugins like GravityPDF or Gravity Flow.

I would be happy if I gave you some valuable feedback and some ideas for future development. Please take those suggestions as just constructive feedback. When I mention other software - directly or indirectly - it should help to make my suggestion as clear as possible. If you have any questions please feel free to ask.

Thank you for your patience and time and a short response in advance. Also thanks again for Toolset.

Kind regards

mb

P.S. I can't wait to see what happens in the next two and half years.

[Beda]

Hi, first of all, thank you for the continued feedback.

Let me straight away introduce something that changed meanwhile:
The Toolset Starter Theme is not anymore actively maintained or available on Toolset.

You can read more about this here:
https://toolset.com/forums/topic/toolset-starter-theme-discontinued-do-we-have-to-worry/

Now, I see that you mixed a lot of requests but as well how to questions, in the same ticket.
Let me reply to your new feedback and see what we can do, but please try to open each problem a ticket if there are How To or BUG reports I missed out.
We cannot gather several issues in one thread.

Could you please implement an option, which makes it possible to load or unload css and js?

This is in the progress and planned for a future release of Views (one of the coming).
It will be a filter, not an option.
You can then apply that on your own risk with a custom code snippet that we provide.

REST-API-Support on a field-basis.

This is not planned yet and you can natively only add this for Post types, but the feature is filed.

HTML5-Markup (esp. for Dates and Time) which would lead to less JS and a native visual output on all devices

We use Bootstrap for most fields output and a JS library for the date fields-
Date fields are under a revision to maybe add more features, eventually, we can look into that with this tasks

Markdown-Support for Multiple Lines-field

I filed this, but there are no plans for it.

the Option to give the same name to several fields.

How would you decide what field to display later?
I suggest creating repeating Fields Groups if you need to have the same field again.
Or, create a Field with the same Slug in another Field Group.

Speaking of Types please also have a look at the option of Pods to connect to another SQL-Database or server.

Filed, but I think we will not add such feature as this is out of the native WordPress behaviour

Please also have a look at the post creation. The interface is much clearer.

We do as well look at other plugins, surely.
We rely thou majorly on WordPress and present our Fields in native meta boxes, they are editable as they should, but not an "appealing" look, that is subject to continuous improvements.

could you also make it possible to have fields of a post type shown in the normal "all posts" screen in the backend so that I have a table which I can sort by field.

This request is filed, but mostly not possible due to the narrow space in that list.

1. Regarding the post relationship metabox: Its title should be always the other connected CPT, not the name of the relationship.

2. Will repeatable field groups be editable in the backend when creating Posts in the future?

3. is it or will it be possible to prepopulate repeatable field groups in backend or frontend?

Please test the new Many To Many Relationships, I think most of this is all implemented.

Options pages like mentioned here: https://toolset.com/forums/topic/options-page-for-site-specific-data/

This is not planned, but filed nonetheless.

Is it possible to relate to Users (in the future)?

We will document how to do that very soon.

Is it possible to deactivate the meta boxes for Access and Views (Content Templates)? (of course via Custom Code) But I mean in the Settings for Toolset? If not, could you please implement that? Those settings should be made sitewide or for all posts of a CPT and not on a per post basis. Or we should be able to choose what seems to be better for a specific project.

If you mean the MetaBox in Edit Posts, and the Buttons in Editors, then no, there is no such feature implemented but filed.
No ETA as well.

a) HTML5-Inputs (esp. Date and Time). Even generic fields won't work because they are also Shortcodes and use the same logic as normal CRED-fields. And if I use just HTML5 I am not able to connect to the specific CPT and save the data to it.
b) Because of the lack of support for basic HTML - and please correct me if it is possible to save data by using hooks for those HTML-Inputs - it is also not possible to add fields like a signature. This lack of functionality is really a showstopper.

I am not sure what you mean with lack of support for basic HTML
Toolset uses Bootstrap markup, a widely used framework, not pure HTML (but of course you can use that)

For this issue, if there are problems please open a new ticket
You can of course always get your values from the $_POST and update your fields with update_post_meta(), hooked into the cred_save_data() hook:
https://codex.wordpress.org/Function_Reference/update_post_meta
https://toolset.com/documentation/programmer-reference/cred-api/#cred_save_data
Please open an assistance ticket if you need help with that.

c) Multi-Step-Forms

This is filed but no ETA either.

Chained Selects with populated post relationships or related posts as options like if product A is chosen then in the next select-field related taxonomies or other related posts are loaded as selectable options

Right now you can add related posts in a one to many or one to one relationship using the "old" method, for many to many relations you use the new Relationship Forms which by now can only connect 2 posts of a type each time.

There are plans to enhance that however a logic like you suggest will always require custom code on top of it.

Conditional Logic within the form

https://toolset.com/documentation/user-guides/conditional-display-for-form-inputs/

If you have issues with that, please reach out to us in a separate ticket.

Calculations (with PHP or JS) for a numeric Types-field

We are about to document that.

multiple Forms on one page to edit several post types with one Click or update specific fields of different post types with one form.

For what this is not already possible, it will always require either a Custom JS or other Code, that applies your action to all forms, that cannot even be changed if you create forms without Toolset.
This is how forms behave, if you need to submit them with one button, this requires custom code.

Webhooks…

Toolset Provides a large set of hooks.
Please refer to the WordPress API as well, but for Toolset:
https://toolset.com/documentation/#programmer-information

a Form Builder and/or a tight integration with Page Builders like Divi, Beaver or VC like you did with Content Templates. As CRED is Shortcode-based, you should be able to integrate these in a similar manner like you did with Types and Views Shortcodes in the case of Divi.
If you need some inspiration please have a look at Gravity Forms and Plugins like GravityPDF or Gravity Flow.

We already integrate Toolset with many page builders:
https://toolset.com/documentation/user-guides/#integration-themes-plugins

For Toolset Forms, we plan a special surprise related to how you build the forms.
It includes an in-house builder.

Please let us know if anything is remaining uncleaer.