Skip Navigation

[Resolved] Options Page for site-specific data

This support ticket is created 8 years, 1 month ago. There's a good chance that you are reading advice that it now obsolete.

This is the technical support forum for Toolset - a suite of plugins for developing WordPress sites without writing PHP.

Everyone can read this forum, but only Toolset clients can post in it. Toolset support works 6 days per week, 19 hours per day.

Sun Mon Tue Wed Thu Fri Sat
- 9:00 – 18:00 9:00 – 18:00 9:00 – 18:00 9:00 – 18:00 9:00 – 18:00 -
- - - - - - -

Supporter timezone: Europe/Madrid (GMT+02:00)

This topic contains 3 replies, has 2 voices.

Last updated by Juan 8 years, 1 month ago.

Assisted by: Juan.



Hi Guys!

It would be great, if we could generate an options page out of a custom post type like it is possible with ACF. I have especially data like adresses, phone numbers, the VAT-ID and so on in mind.

Then we could set up a CPT with the data (or fields) we need. This data could then be given out via a View or in a CRED-Form (i.e. the mailto-E-Mail-Adress) by a shortcode.

Most often it is a matter of set and forget, but if you have to make a change to this data sitewide, it could be a lot of work. Working with placeholders (like shortcodes for the forementioned data) would make it very easy. Also, if you are developing client's sites, you would be able to fill in the client-specific data and you are good to go.

A practical example: I have a boilerplate for new projects with some pre-made pages. Every client needs to have a contact page and an imprint, perhaps also a terms/conditions page. The data in the contact page, the imprint and the terms/conditions page are - regarding the contact information - almost the same. So if I could make use of shortcodes as placeholders for i.e. the street or the zip code, I would just fill in the data in the relevant fields in the options page - once (!). And this data would be populated sitewide (esp. on the contact and imprint page) because it is read out of the database.

I know that you made Views integrateable with Theme or Options Frameworks, i.e. Options Tree, Cherry and so on. So I could code these options pages by myself. But the more elegant way would be a tight integration with Toolset and the generation of a options page by Toolset. The corresponding shortcodes could then be populated by your Fields-Dialogue-window in the editor or in the Admin-Header-Menu.

Another suggestion related to my comments on your announcement regarding the integration ov VC and Content Templates ( what about a Layouts-based Page-Builder? Besides my suggestion to use Layouts to create Content Templates and so on. Please refer to my comments.

And could you please reimplement the CSS-Editing-Tab in Layouts’ Row-Editing-Popup which was capable of automagically make the defined rules chooseable in the classes input field. This functionality seems to be abandoned since you implemented the Layouts CSS-editing-screen. It would become perfect, if all the CSS-directives from the rows or content templates or whatever become available in the Layouts CSS editing screen and are also available in the corresponding rows, content templates and so on.

A short feedback is appreciated.

Kind regards & Greetings from Germany!




Timezone: Europe/Madrid (GMT+02:00)

Hi Bernhard

Thanks for your feedback.

Wow, lots of things around here 🙂

We do not have plans at the moment to jump into the Options party. I agree it would be nice to have such feature, and we could even want to addd a new plugin to the family to generate settings pages, but there are tons of frameworks over there that do just that, and we focused on working with them, not replacing them. Also, WordPress as a platform is pushing more and more about moving all options-related GUIs to the Customizer, so adding settings pages seems like something that might be doomed in the medium and far future.

About the page builder integrations, we are on the early stages of this all, so we will be going safe and slow on this. We have big plans and lots of interoperatibility in mind, but this demands time and care 🙂

Finally, about the Layouts CSS storage changes, I will see what I can do. But what I can not do is make promises. 😛

Thanks again.




Hi Juan,

thank you for your response.

I totally get your argument. Could you perhaps provide a blank canvas or some code and further information about integrating Views with a custom framework. This would kickstart my own integration and I won't have to code from the ground up. Perhaps you could provide a link or the code you tested the custom framework integration with (I assume that you tested it before you released Views and the option to integrate it with the frameworks to choose from and the option to integrate with a custom framework)? Those frameworks seem to be overkill. I would like to put the code in my child-themes functions.php or in a custom plugin and I want it to be easily to maintain and lightweight.

Page Builder integrations: I can't wait to see them released, esp. the integration of the Divi Builder. And I'm very happy that you're working on this.

Layouts CSS: Thank you.

Kind regards,




Timezone: Europe/Madrid (GMT+02:00)

Hi there

Well, we have a dedicated documentation page to theme and framework integration for Views:

Basically, you just need to register a framework by providing an ID a name, and some information about the framework (whether it has an API function to get values for option keys, or whether it stores the data on a WordPress option as an associative array). That means thta we do not work out of the box with all the frameworks out there, but with a big chunk.

We also can detect whether your site is using one of the most used frameworks, like the Options Framework, OptionTree of the UpThemes framework - we have a problem at the moment with Cherry that we will address soon.

Once you have registered your framework, you just register also option keys that you want to use in Views, and you will have their values available in several places in Views: query filters, paginaiton options, etc. All the related details are in te linked documentation.

We know that this is a little limited by now. We already have plans to improve this, but as with almost all development, it is better to hold your mouth until there is somethign to show 🙂

Hope it helps.


This ticket is now closed. If you're a Toolset client and need related help, please open a new support ticket.