Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
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:
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: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.
- 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?)
- 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
- 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
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 tosmd_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-purposedata
field could help. For example, if theinput_control
is a select box, this field could contain a description, plusselect1: 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
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
Offline
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
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
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
- 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
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
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