Problem:
Client wants to store related posts in a custom field and to then be able to output content of those related posts when viewing the first post (a simple bespoke solution that doesn't involve post relationshipts).
Solution:
Store the related post IDs in repeating numeric fields, i.e. add as many as there are related posts.
Then in the Content Template for this post type, to display content from the related posts use the wpv-for-each shortcode to loop over the numeric fields which store the post IDs which can then be used as the id attribute of the shortcodes used to output the required fields.
The issue here is that the customer wanted to know if it was possible to change the order of how the post relationships are displayed on the Parent Post on the backend.
Solution:
Unfortunately this functionality is not available on our current production version of our Types plugin. However in our Types Beta plugin you are able to do this but its not recommended to use Beta plugins for Live websites.
Problem: I would like to know if I should use the new M2M beta plugins now, or continue using the production versions. I am creating a new site. I would like to choose the safest option, and I would like to know about backwards compatibility.
Solution: The safest solution is to wait until the new relationship production versions are released, since beta plugins are more prone to errors and less complete. However, new features in the beta plugins are not available yet in the production versions so you will not be able to take advantage of key improvements, like repeating field groups and more robust relationship filters in Views. When the new relationship features are released in the production versions, a migration process will be offered that will migrate existing relationships into the new relationship structure. This will help ensure existing content works in the new relationship structures. Once migration happens, there is no reversal process so at that point any new relationship data added to the system will not be backwards compatible. If any custom code is put in place that queries those old relationships, some manual code changes may be necessary as well.
How can I create custom PHP templates to address my custom posts?
Solution
If you need to create Custom PHP templates for Custom Post Types in WordPress you can follow and refer to the WordPress Codex for it.
To create such a file, you need to name it "single-post_type_slug.php" (replace "post_type_slug" with the slug of your post type).
Then, this file will be used instead of the single.php file.
We also have documentation for the Toolset related part of this, which is to display Types Fields for example, with PHP, or how to fully customize Archives and other templates using PHP.
However, it's easier to use Toolset Views to display the data.
Usually, Toolset allows you to customize the entire website without the use of PHP - only if you use just Types, then the usageo of custom code is not avoidable.
Problem: I would like to restrict edit access to some posts using categories.
Solution: Access can restrict User access based on User role and post group, but not post category (or categories). Post Groups and custom User roles might work but you can only assign one Group to any Post, and only one Role to any User. If you have multiple combinations of post permissions this might not be an option. If your Users are only editing posts with CRED, then you can use conditional HTML or CRED conditionals to show or hide specific content depending on some criteria of the current User, like a custom field value. Store some value in the User's custom field and check that value to determine whether or not to show them a specific CRED form.
Problem:
The issue here is that the user wanted to know if it was possible to create a custom backend Layout with our plugins.
Solution:
Unfortunately no it won't be possible since our tools are designed to be frontend builders, they won't be able to setup designs for a backend layout.
We document known issues and their solutions in Toolset errata. Save time by checking there first and seeing if what you are facing is a known issue. This list is kept short. We do our best to resolve all known issues with every release of Toolset plugins.
Support Policy
Toolset staff will help you use the Toolset plugins correctly, provide any information you need, help troubleshoot problems and advice on best-practices.
Please make sure to issue only one topic per each support ticket.
