Default values for users related attributes via plugin prefs

NicolasGraph · 2016-04-27 11:59:02

I recently updated oui_instagram and added some plugin prefs to allow a user to choose/change the default values of attributes like username, user_id, cache_time, etc. I thought it could be interesting to do that to facilitate the themes development (what I’m doing). In the case of my plugin you can now use <txp:oui_instagram_images /> (or even <txp:if_plugin name="oui_instagram"><txp:oui_instagram_images /></txp:if_plugin>) in your code and the end user (or you!) don’t need to go into pages or forms to set or change its username*.

Of course it works for the instagram images of one account only, but I think that it covers most use cases, and you can still hardcode the attributes if you need differents values…

I know it can’t be used for every plugins but for some as zem_contact_reborn, wouldn’t be great to set the default value of the to attribute via the prefs for example?

I’m sure there are other useful cases… what do you think?

* …and you don’t need any useless variable.

Last edited by NicolasGraph (2016-04-27 12:14:48)

etc · 2016-04-28 11:28:40

A related question: where do plugins prefs go in 4.6? Before, we had basic/advanced panes, but they are gone now. Is there some reserved “Plugins” pane, or we need to plug into core “Site”, “Admin” etc?

Bloke · 2016-04-28 11:58:10

Not sure I quite understand the issue. Plugin authors have access to the wealth of PHP globals and whatnot that Textpattern exposes so you can set the default attributes of either your plugin tags or your prefs (at install time) to whatever you can get your hands on. If that’s per-user info, great. Just set the user pref flag when calling set_pref().

With regards prefs in 4.6 onwards, the entire panel is open to all users by default. Previously, only levels 1-3 could access it, which meant any plugins that wished to offer prefs to lower level users had to write their own panel.

From 4.6, there are PREF_CORE and PREF_PLUGIN preference designators. PREF_CORE used to be made up of PREF_BASIC and PREF_ADVANCED, but those are now deprecated. If you store a plugin pref against a core event name it’ll appear intermingled with the core prefs, in the order you specify. If you set the event to your plugin name, you get your own preference area twisty on the prefs panel.

Thus a plugin author that wishes to offer prefs on the main Preferences panel only needs to define them in their plugin and add privs for the prefs event: add_privs('prefs.abc_plugin_name', '1,2,6');. As long as you’ve added them to the prefs table during install (or, as I do in smd_article_stats, when you view the prefs panel, in case the install lifecycle event hasn’t fired: register_callback('smd_artstat_prefs', 'prefs', '', 1);) they’ll be saved along with the core prefs automatically.

Take a look at smd_article_stats for an example (though it’s not a class-based plugin yet: I’m gradually moving my admin-side plugins over to that model on a case-by-case basis).

etc · 2016-04-28 13:01:54

Thanks Stef, I’m progressively updating some plugins too, and it was add_privs('prefs.abc_plugin_name', '1,2,6'); that I was missing.

NicolasGraph · 2016-04-28 16:31:09

Bloke wrote #298866:

Not sure I quite understand the issue.

It’s not an issue but a thought about the fact that moving some default values for attributes which are not presentational attributes into the prefs panel could make the themes development or administration easier. I suggested that the default value of the to attribute of zem_contact_reborn could become a pref. Even for a simple plugin like ~~aks_cache~~ aks_header, why should we go into the code to des/activate gzip or strip via attributes? Some onoffradio prefs would be more user friendly… Of course it’s something to establish on a case-by-case basis but as I don’t see many plugins using this way of thinking I wanted to share my thought…

Edit: I was talking about aks_header and not aks_cache of course…

Last edited by NicolasGraph (2016-04-28 16:51:07)

NicolasGraph · 2016-04-28 17:41:42

…and while we get you Stef; how do the following enhancements work?

Bloke wrote #291307:

From 4.6+ there’s a callback in the popHelp() function to allow plugins to customise the content. There will also be some helper functions to render standard help templates to fit in with the current theme, plus we’ve introduced the notion of inline help to show up on-screen, which is manipulated through Textpacks for full i18n.

Last edited by NicolasGraph (2016-04-28 17:41:50)

Bloke · 2016-05-03 15:43:53

NicolasGraph wrote #298872:

how do the [popHelp / instructions] enhancements work?

OK, pophelp first. Register a callback on the admin_help event with a ‘step’ of the language string and your plugin will get called:

register_callback('abc_pophelp', 'admin_help', 'some_language_string_key');

The stuff about templates is deferred to a later release, sorry.

For inline field help:

Ensure the place you want to add the help text is using inputLabel() behind the scenes. That’s the only function that calls fieldHelp() right now. Most of the Write panel uses it. And a lot of the other panels have been converted to use it.
Make a new Textpack string in your txp_lang table with the name of the input field, preceded by instructions_. So, for the title field, make a new string in your chosen language called instructions_title. For publish date, use instructions_publish_date, and so on. The text you enter in the lang table will be rendered near the input widget.

If you wish to customise the output, raise a callback:

register_callback('abc_inline_help', 'admin_help_field', 'field_name');

Hope that helps.

NicolasGraph · 2016-05-03 15:50:28

Bloke wrote #298945:

Hope that helps.

That will, surely. Homework time now…
Thank you Stef!

Last edited by NicolasGraph (2016-05-03 15:50:41)

NicolasGraph · 2016-05-03 17:34:36

Bloke wrote #298945:

OK, pophelp first.

Ok, it works, not as I expected but it will be ok. In the future, couldn’t we enhance the popHelp() function to call it back on plugin prefs using an internal url like http://www.mysite.com/index.php?help=item&language… where the item would be a textpack string installed with the plugin for example?

Last edited by NicolasGraph (2016-05-03 18:33:01)

Bloke · 2016-05-04 08:50:19

NicolasGraph wrote #298948:

In the future, couldn’t we enhance the popHelp() function to call it back on plugin prefs using an internal url

At the moment, all pophelp is served externally from the RPC server, so it generates external links. Hooking into the callback enables you to replace that URL, but that is all. Look at smd_article_stats on the prefs panel, which does exactly this (although I haven’t written the help docs on my site, you can see the links to the site on hover).

Longer term, pophelp is probably going to be bundled with core in the downloads and/or served from the lang table so we’ll alter the callback(s) accordingly to permit custom plugin help topics to be returned from the database or file system.

NicolasGraph · 2016-05-04 09:17:27

Bloke wrote #298961:

At the moment, all pophelp is served externally from the RPC server, so it generates external links. Hooking into the callback enables you to replace that URL, but that is all.

Ok, I’ll find a place to store some external help contents for now.

Longer term, pophelp is probably going to be bundled with core in the downloads and/or served from the lang table so we’ll alter the callback(s) accordingly to permit custom plugin help topics to be returned from the database or file system.

We look in the same direction; nice.

Textpattern CMS

Textpattern CMS support forum

#1 2016-04-27 11:59:02