New Tutorials on How to Extend and Customize Toolset


January 23, 2018

If you’ve been using Toolset for a while already, you probably needed to add your own features here and there. New tutorials that we published will help you extend Toolset even further.

What it means to “extend Toolset”

Out-of-the-box, Toolset lets you do quite a lot without writing PHP. But there are cases that Toolset’s GUI cannot cover. For example, let’s say that you need to do some math between two fields. Implementing this in Toolset’s GUI is possible, but would be extremely inefficient and limited. Instead, you can achieve this with several lines of PHP.

Or, let’s say that when submitting a CRED form, you want to trigger some actions. Again, we could build a monster GUI that will list all the different actions that WordPress offers and allow you to run them. That’s nice, but our list will never cover your own functions of actions coming from other plugins.

The answer to these lies in Toolset’s API.

We gave the API documentation a major update, focusing on the kinds of customizations that site developers often need. The main entry points depend on what you’re trying to accomplish:

  • Building Web-apps with Toolset – this guide will teach you how to use CRED hooks to run your own actions with CRED forms. This technique will let you build sites with advanced workflows with a tiny bit of PHP and most everything else coming from Toolset.
  • Displaying Custom Functions with Views and Using Them in Conditional Logic – learn how to create shortcodes for your custom functions, display them and use them in conditionals. With this, you can easily display the distance between two points, the area of a field, etc.

Finally, when you’re facing large scale custom development, you might want to check out our recent blog post about WordPress Development – Coding from Scratch vs. Using Plugins. We show how we’ve developed our Contractors System, with Toolset, Gravity Forms and a bit of custom code.

What else do you need?

We want to make sure that you have everything you need when you go to build advanced sites with Toolset. Let us know by leaving your comments. Your feedback is what drives Toolset development and documentation.


Comments 19 Responses

  1. This is awesome!

    Still feels like having the ability for subscribers to add images to posts without accessing the whole media library of the website, when submitting from a front-end CRED form is a must.

    Without doing extra coding 🙂

    Fingers crossed to see this fixed soon

    • We have a bunch of feature requests for CRED, which we really want to implement. Honestly, in the coming weeks, our entire team is on the post-relationship project. It’s a huge project and we need everyone on it to finish that. Most of the work is on CRED now. Once this big development is done, we’ll be back to the less huge features. Sorry it’s taking a lot of time.

      • No worries if you don’t, but is there an ETA on the post relationship functionality, or any news on it?

        Keep up the great work!

        • Yes. First combined beta for Types + Views + CRED, with full WPML compatibility at the end of this month (a little over a week from now). Then, a production release about a month later.

  2. This is quite coincidental. I was looking specifically for this type of information, I will be reviewing all these materials, since they really open the door to a lot more customization that I am sure to need in up coming projects.

  3. My hope is that Toolset might provide an option for dates to be posted to the DB in regular format rather than just unix date . When trying to extend Tooslet using WPDataTables and other options it shows the unix date rather than reguler

    • Hi there

      Thanks for the feedback. This is Juan, Toolset team leader.

      We do store date fields as timestamps in the database, for a number of reasons (and forgive the tech talk):
      – First, it makes easier to sort and filter results by a timestamp, since it is already a numerical value which is easy to compare. However, the SQL DATETIME format also supports sorting and filtering in an easy way.
      – Second, we have an extended range support. By default, timestamps are restricted to a somehow short range of allowed dates. The same restriction applis for Sthe QL DATETIME format, although with a different range of allowed dates. We have been asked several times in the forum about extending that range, since users do need to set dates that fall outside of the supported range. Hence we included a library that adds support for extended dates when stored as timestamps. I know of no solution to extend the range of SQL DATETIME formatted values.

      In other words, we use and keep using unix dates because it gives us a wider range of supported dates. Should we want to move to a different date format, we would need to either create a new type of date field or offer an upgrade mechanism, which might fail in those dates outside of the supported range.

      However, I am adding a note to myself about this, to evaluate and investigate whether this can be done, and how.

      Thanks again.

    • Hi, could you please clarify this a little more?

      Do you mean, like there are built-in fields for Date, Colorpicker, Checkbox, and so on, you would like a tutorial on how to create a completely custom type of a field?

        • I understand now, thank you for clarifying!

          I checked with our development team and currently, it is not possible to add a custom type of a field to the Types plugin. They are already aware of this idea/request but there are no plans to add this feature in the near future.

          Could you please share, what type of a field are you missing?

          • For different projects, these are different types of fields. At the moment, it is for this reason, we do not fit Types.

            • I understand. We are now focused on the new many-to-many relationship features, which will be a huge release for Toolset users. This means that most of the other feature requests need to wait.

              One of the things with the proposed custom field types feature is that they would need to work with all Toolset plugins, and they would need to be “searchable” by the Views you create with Toolset. This includes lists of posts, custom searches, etc. You can see how this makes it a whole project in itself.

              Thank you very much for your feedback, I have forwarded it to our team!

    • Hi, Tina!

      Are you referring to the “Implementing custom logic” code snippet found at the bottom of the “Building Web-apps with Toolset” page? If so, that is only an example and it is based on our own “Contractors” system, implemented on

      The examples in the CRED API documentation are more general and try to represent some typical examples one could take as a starting point.

      Does this help?

  4. Dear Dario,

    I saw you mention underneath Oleg his comment that the current focus, of the toolset team, is on the release of the new many-to-many relationship features. I’m rather curious and kind of waiting for the release!

    Do you’ve got any indication on the releasedate? I read somewhere that the aim was around the end of January.

    Kind regards,
    Haimanti Dekker

    B&S Media Internetmarketing

    • Hello! 🙂

      I cannot give you an exact date, but if all goes well, we should release the next (stable) beta for the new post relationships – early next week. We are in final stages of testing and documenting. This beta will bring CRED plugin into the mix, plus some other improvements. Naturally, this will be announced with more details. So yes, very soon.

      Kind regards!