Go to main content

Textpattern CMS support forum

You are not logged in. Register | Login | Help

#25 2014-09-21 13:55:44

etc
Developer
Registered: 2010-11-11
Posts: 5,028
Website GitHub

Re: Custom theme options

gfdesign wrote #283957:

In case someday it becomes in a polished plugin, don’t forget to include others kind of input fields and their corresponding description in order to the user knows what is filling.

Whether it becomes polished, mainly depends on you (and other users), I don’t know what kind of input fields you need. You (site admin) can already create multiple text, yes/no, on/off, color variables, and give them any description, as explained in the plugins… well… help.

Offline

#26 2014-09-22 04:53:34

gfdesign
Member
From: Argentina
Registered: 2009-04-20
Posts: 401

Re: Custom theme options

etc wrote #283975:

Whether it becomes polished, mainly depends on you (and other users), I don’t know what kind of input fields you need. You (site admin) can already create multiple text, yes/no, on/off, color variables, and give them any description, as explained in the plugins… well… help.

Sorry Oleg, but I didn’t found how to put a name and descripción to the options I’ve created but let’s suppose, I want to create a variable to put an Analytic Google code to my site. This option would be called “Google Analytics”, its variable ‘google_analytics’ and the description indicating “Please insert here your Google Analytics code”. So, basically we’ll need to indicate:
  • Option name: ‘Google Analytics’
  • Variable name: google_analytics
  • Type of field (in this case should be a textarea, don’t you?)
  • Description (to give to the user some instructions about it)
  • Order or position (it would be great if it could be defined through a drag n’ drop feature)
  • Public (as adi_variable puglin brings)
  • Category or group which it belongs
  • Required or not
  • (Anything else?)
Other example, could be give to the client the availability to add some static text for the footer of his/her site. Therefore we’ll have:
  • Option name: ‘Text for Footer’
  • Variable name: text_footer
  • Type of field (I guess, in this case could be a textarea using a WYSWYG editor)
  • Description (to give to the user some instructions about it)
  • Order or position
  • Public
  • Category or group which it belongs
In Wordpress you can use Advanced Custom Field plugin and create some fields for your content, even an Option Page (such as I’d like for Txp). In summary, this plugin brings with some fields as I put below:
  • Text: Single line text field, optional HTML support, character limit
  • Text Area: Multi-line text field, optional HTML support, character limit
  • Number: Number, min/max values
  • Email: Validates email input
  • Password: Masks text for password input
  • Wysiwyg Editor: Optional WP media insertion, basic/full editor buttons
  • Image: Upload image or select from WP library, returns object, url or ID
  • File: Upload file or select from WP library, returns object, url or ID
  • Select: Provide options in drop-down, supports multi-select
  • Checkbox: Allow selection of multiple items in checkbox list
  • Radio Button: Allow selection of single item from radio button list
  • True / False: Simple true / false selector
  • Page Link: Returns URL of any post or page, can be limited to specific post types
  • Post Object: Returns WP object of any post or page, can be limited to specific post types or taxonomies
  • Relationship: Same as post object, but with improved interface and drag-drop reordering
  • Taxonomy: Returns object or ID for one or more taxonomy terms, can be limited to tags, categories or custom taxonomies
  • User: Select one or more users, can be limited by role
  • Google Map: Set lat/long center, zoom level, and width
  • Date Picker: Select calendar date, return formatted date string
  • Color Picker: Select hexadecimal color
  • Message: No options, leave a message for users
  • Tab: Collect following fields into a tab interface.

I don’t pretend all of them fields in a plugin, but I’d like to see some similar in TXP since I guess it would be very handy for many TXP users :)

Offline

#27 2014-09-22 08:34:32

etc
Developer
Registered: 2010-11-11
Posts: 5,028
Website GitHub

Re: Custom theme options

I see better now, thank you, Fernando. The WP plugin looks great, but it’s a big piece of code. Given the forthcoming 4.6-changes, it’s risky to invest much efforts into something potentially incompatible. But the basic functionality could be quickly implemented. Let’s take your example (in smd_prefalizer):

  • Option name: ‘Google Analytics’: these are localized in txp_lang table, let’s pray Stef to add a field or two to smd_prefalizer :)
  • Variable name: google_analytics: that’s ok
  • Type of field (in this case should be a textarea, don’t you?): longtext_input in txp. We could plug some wysiwyg editor in. * Order or position (it would be great if it could be defined through a drag n’ drop feature): ok, d’n‘d why not.
  • Public (as adi_variable puglin brings): what does it mean? Once created, <txp:variable /> is accessible to everyone.
  • Category or group which it belongs: could be grouped in something like variable-design, variable-options etc. What for?
  • Description (to give to the user some instructions about it), Required or not: this is a bit less straightforward, txp_prefs has not enough fields to store data. Probably, adding a general-purpose data field could help. For example, if the input_control is a select box, this field could contain a description, plus select1: Google, select2: Yahoo, ..., maybe json-encoded. But again, 4.6-compatibility? We could also store it in a separate table.

I’ll experiment with it and report back.

Offline

#28 2014-09-22 09:38:02

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 11,250
Website GitHub

Re: Custom theme options

gfdesign wrote #284008:

I didn’t found how to put a name and descripción to the options I’ve created

I haven’t looked at etc’s code but the way to probably do this is via Textpack language strings. We could do with a string editor plugin being created, similar to smd_prefalizer in concept (but better executed!) specifically for managing language strings.

Descriptions of fields are covered by help topics. A better system for allowing plugins to define those is being worked out: they are essentially language strings. At the moment, such strings come only from the RPC server, which is a constraint, but the core help topics have been migrated to Github in preparation for bundling them with a core distribution at some point.

Other example, could be give to the client the availability to add some static text for the footer of his/her site.

Hmmm, this I’m not so sure about. While the new custom fields feature will address a large portion of your meta data needs out of the box, for blocks of content like footer text, it’s less useful.

Why not use either a Form to hold the text (which you pull into your templates at the correct location via <txp:output_form form="footer_text" />) or use the Write panel to compose text in a special Section that you never display articles from? The latter allows you to employ WYSIWYG plugins and there are probably plugins out there that can limit the panel’s content for certain Sections. Umm, maybe, if they still work.

There’s nothing to stop a clever plugin operating like adi_matrix for Forms, allowing you to use them as true snippet holders without all the other interface clutter. So you could give admins access to this stripped-down, sanitized area that only showed Forms of maybe one type (like ‘Section’ or ‘Misc’ or something). In there, people could just write content which would get folded into the site’s templates.

Footer content isn’t custom meta data, as such. It’s more presentational than data- or content-driven and usually doesn’t vary that much from page to page. That said, plans are afoot to embed custom fields against Sections so you could conceivably do this kind of thing, but it would get annoying pretty quickly if you had a lot of Sections to have to paste the same content in the field for every Section: a reusable Form is a much better place for this than a per-Section field, imo.

Going back to the footer example, I don’t see why you’d need an order/position field. The position is always “the footer” isn’t it? You don’t stack content do you? A need for Category is questionable. And as for ‘Public’… erm? What have I missed here about the design process? Everything’s public, right?

Regarding the list of field types you gave, there are some interesting ones there. I haven’t thought about File/Image upload directly baked into core custom fields, nor colour pickers or user lists or any of the other esoteric ‘aggregate’ types. But since the system is designed to be extensible, there’s no reason a short plugin couldn’t add them as a new ‘type’. Same with Geo location: you can either add four or five fields yourself, or a tiny plugin could add them for you as a set.

Some interesting ideas there, though. We’ll consider them as development presses on.


The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.

Txp Builders – finely-crafted code, design and Txp

Online

#29 2014-09-22 11:20:20

etc
Developer
Registered: 2010-11-11
Posts: 5,028
Website GitHub

Re: Custom theme options

Bloke wrote #284030:

I haven’t looked at etc’s code…

Globally sane attitude, but the code is manly copy/pasted from txp_prefs.php in this case (as promptly complained few posts above)

…but the way to probably do this is via Textpack language strings.We could do with a string editor plugin being created, similar to smd_prefalizer in concept (but better executed!) specifically for managing language strings.

Wouldn’t it be loverly if you could integrate txp_lang.data field into smd_prefalizer interface (with save/delete)?

Offline

#30 2014-09-22 12:15:01

philwareham
Core designer
From: Haslemere, Surrey, UK
Registered: 2009-06-11
Posts: 3,564
Website GitHub Mastodon

Re: Custom theme options

Bloke wrote #284030:

Regarding the list of field types you gave, there are some interesting ones there. I haven’t thought about File/Image upload directly baked into core custom fields, nor colour pickers or user lists or any of the other esoteric ‘aggregate’ types. But since the system is designed to be extensible, there’s no reason a short plugin couldn’t add them as a new ‘type’.

Also remember we have support for jQuery UI in 4.6, so things like datepickers would be fairly easy to incorporate I hope. I’m sprinkling a few jQuery UI bits into my changes to the UI at the moment. Some of the other input types such as input type=color could handle colour pickers if/when all the major browsers fully support HTML5 input types. Just a thought.

Offline

#31 2014-09-22 14:30:09

etc
Developer
Registered: 2010-11-11
Posts: 5,028
Website GitHub

Re: Custom theme options

philwareham wrote #284043:

Also remember we have support for jQuery UI in 4.6, so things like datepickers would be fairly easy to incorporate I hope. I’m sprinkling a few jQuery UI bits into my changes to the UI at the moment. Some of the other input types such as input type=color could handle colour pickers if/when all the major browsers fully support HTML5 input types. Just a thought.

Yes, that will be fairly easy to do.

I have uploaded a new version of the plugin, just for testing. It adds custom radiosets to the input controls family.

Offline

#32 2014-09-22 16:26:47

gfdesign
Member
From: Argentina
Registered: 2009-04-20
Posts: 401

Re: Custom theme options

Hi guys. Thanks for your replies. Let me to explain better each item of a customized field.
  • Option name: ‘The friendly name that user reads’
  • Variable name: ‘For internal uses on page templates’
  • Type of field: As it’s commented above
  • Description A simple text to give to user some instructions about it.
  • Order or position: Here, I ‘m referring to order in the UI screen regarding the other fields. (If I am not wrong, would be ‘Position’ in the ‘smd_prefalizer’ plugin)
  • Public. In adi_variable puglin you can set up some variables as public or not. Basically, it does to enable or disable (not hide) the edition mode depending on user’s privileges.
  • Category or group which it belongs. Yes. here etc is right. I mean, the super admin be able to create fildsets in order to group the created fields to get a better UI experience. By way of example, a group called ‘General setting’, ‘Social networking’, ‘Options for “Home” section’, ‘Colors scheme’, and so on.
  • Required or not. Options won’t be saved at least that user enters the mandatory or correct data.

About my example “Footer text” may be it’s not be the most representative, but I thought like some editable text displayed across in the whole site.

Bloke wrote #284030:

There’s nothing to stop a clever plugin operating like adi_matrix for Forms, allowing you to use them as true snippet holders without all the other interface clutter. So you could give admins access to this stripped-down, sanitized area that only showed Forms of maybe one type (like ‘Section’ or ‘Misc’ or something). In there, people could just write content which would get folded into the site’s templates.

Yeap. This is what I’ve thought but the (just a bit) annoying thing is to access to these options is that involves more clicks and users some times won’t know how to find them. Please, don’t take this as a complaint, I’m trying to put in the final user’s shoes. :)

etc wrote #284051:

I have uploaded a new version of the plugin, just for testing. It adds custom radiosets to the input controls family.

I don’t see the hour to have a bit spare time to try it :D

Last edited by gfdesign (2014-09-22 16:55:34)

Offline

#33 2014-09-23 01:00:42

gfdesign
Member
From: Argentina
Registered: 2009-04-20
Posts: 401

Re: Custom theme options

etc wrote #284051:

I have uploaded a new version of the plugin, just for testing. It adds custom radiosets to the input controls family.

Hi Oleg. I’m testing your beta plugin but I guess I am stuck :P. I’ve read the help but I feel fool because I couldn’t create the variables you put as example. Please, don’t rush. I can wait for other versions and give you some feedback in other new topic if you want. (is it important if I try it in a TXP 4.5.2 installation?)
Please, let me know if I can help with something.
Regards

Offline

#34 2014-09-23 07:30:19

etc
Developer
Registered: 2010-11-11
Posts: 5,028
Website GitHub

Re: Custom theme options

Oops… I guess I have forgotten to precise that you have to disable/enable the plugin to trigger a db table creation, sorry :(

Offline

#35 2014-09-24 04:43:27

gfdesign
Member
From: Argentina
Registered: 2009-04-20
Posts: 401

Re: Custom theme options

I’ve done what you pointed..

but I get this.

Certainly, I am doing something wrong. :|
(pd: Sorry if I delay to answer, but I no longer receive notifications by email about the topic I am subscribed. I no have idea what it’s the problem, even I’ve changed my email several times.)

Offline

#36 2014-09-24 07:42:11

etc
Developer
Registered: 2010-11-11
Posts: 5,028
Website GitHub

Re: Custom theme options

gfdesign wrote #284145:

Certainly, I am doing something wrong. :|

Just put these {"good","bad","ugly"} options into the right field of your second picture, and you should be set. :)

(pd: Sorry if I delay to answer, but I no longer receive notifications by email about the topic I am subscribed. I no have idea what it’s the problem, even I’ve changed my email several times.)

I’m not getting notified, neither.

Offline

Board footer

Powered by FluxBB