Add plugin tags in the tag builder

NicolasGraph · 2016-09-14 13:13:25

Hi,
Wouldn’t it be nice to have installed plugin tags added in the tag builder?
Honestly I don’t really know how the tag builder works but that should be possible, no?

etc · 2016-09-14 13:24:20

Hi Nicolas,

NicolasGraph wrote #301450:

Wouldn’t it be nice to have installed plugin tags added in the tag builder?

Yes, indeed.

… that should be possible, no?

Bare plugin tags (registered) we could, but not with attributes (currently unregistered).

And since any plugin can substitute itself to, say, <txp:article /> in 4.6, the tag builder attributes/docs can get misleading.

Last edited by etc (2016-09-14 13:28:47)

hcgtv · 2016-09-14 13:28:08

NicolasGraph wrote #301450:

Honestly I don’t really know how the tag builder works but that should be possible, no?

Hi Nicolas, the tag builder is hard coded into the source.

But I see your point, having to go view the plugin’s help for attributes.

NicolasGraph · 2016-09-14 13:32:21

etc wrote #301452:

[…] (currently unregistered).

Oh, yes, you’re right; and that wouldn’t really make sense if we couldn’t add attributes…

etc · 2016-09-14 13:49:55

NicolasGraph wrote #301454:

that wouldn’t really make sense if we couldn’t add attributes…

We could amend Registry in this sense, but plugin authors would have to register attributes.

NicolasGraph · 2016-09-14 17:13:30

etc wrote #301455:

We could amend Registry in this sense, but plugin authors would have to register attributes.

I would definitely do it if it could help users to build my tags.

etc · 2016-09-15 08:56:47

Registering tags attributes is tempting, but I don’t see how to do it the right way. Take <txp:comment_preview /> tag:

function comment_preview($atts)
{
    global $thiscommentsform;
    extract(lAtts(array(
        'label'  => $thiscommentsform['previewlabel']
    ), $atts));
    return fInput('submit', 'preview', $label, 'button', '', '', '', '', 'txpCommentPreview', false);
}

Ideally (to avoid redundancy) we should transfer this

array( 'label'  => $thiscommentsform['previewlabel'] )

to Registry and use it in the parser and the tag builder. But

that would mean that public side plugins must be registered on the admin side too.
$thiscommentsform is not set on the admin side, we need to store this default value somehow else.
some default values are even more complex (conditionals, function calls)

I’m all for it, since that would make adding new tags to tag builder “automatic”, but it looks complicated. Ideas?

Bloke · 2016-09-15 09:15:33

I don’t know how to do this cleanly, but just adding a caveat: not all tags are available on the Pages and Forms panels, and different ones appear in each place. And the ones on the Files and Images panels are different again.

So there’s no guarantee that:

a) a core tag would appear in either builder. For example, only two of our wealth of conditional tags are featured, and appear only in the Forms tag builder.

b) a plugin’s tags would make sense to appear as an option in any of the builders. smd_calendar, for example as it has over 50 attributes(!) that I’ve had to group in the docs to help people find them.

Presumably this adds some kind of opt-in feature to the above proposal, so even if you register your tag and (optionally, please!) your attributes, you still need to somehow indicate “make this tag available in the tag builder on {these} panels”.

Does that complicate things further?

etc · 2016-09-15 11:51:24

Bloke wrote #301511:

I don’t know how to do this cleanly, but just adding a caveat: not all tags are available on the Pages and Forms panels, and different ones appear in each place. And the ones on the Files and Images panels are different again.

…

Does that complicate things further?

Yes, if we keep it as is. But why, at the first place? A tag is a tag, you may need it everywhere: article tags in a Page form (inside <txp:article /> e.g.), and “page” tags in Forms, if your page uses <txp:output_form />. Files and Images panes is different story, and not really restrictive.

Bloke · 2016-09-15 12:25:50

etc wrote #301524:

A tag is a tag, you may need it everywhere

Very true. Perhaps it’s historically been this way precisely because it offers control instead of allowing 140+ tags in a never-ending sea of twisties.

The taxonomy is bad enough now: category1 appears under the ‘article’ twisty but not the ‘category’ group. We’ve also got a dreaded ‘misc’ group, which is a big no-no.

If we’re going to make all tags available in the tag builder, a minimum requirement should be:

Get rid of the groups.
Show them alphabetically, grouped by first letter.
A (live?) search/filter feature.
Add meta data to each tag (preferably programmatically somehow): i.e. ‘tag’ the tags with multiple words or phrases so they’re searchable by more than just name.
Show most-used tags, easily accessible. Per user storage to track them.

Going further, this does lend itself to more tightly integrating tags and documentation/pophelp. Essentially, clicking to display the tag builder and then choosing a tag loads the builder for the tag as it does now, but brings along its documentation too. Each attribute could have its short description rendered below the attribute title (or under a nearby ‘i’ link). All hyperlinks will fetch other docs — that may not strictly be tags. So the builder pane then becomes a mini browser to all documentation.

If you instead popup documentation from an ‘i’ link, somewhere within those docs might be links to other doc pages, or even tags. Clicking a tag will show the tag builder + docs for that tag and its attributes.

When you think about this system, it’s really just a portal to our docs.textpattern.io/ site. If we can somehow version tag each page on that site, pass a version URL param from the initial click from the admin side, and then pass it from page to page as people browse the docs, there’s suddenly no need to bundle all pophelp and the tag builder inside Txp any more. Approaching it this way means the docs and Txp stay connected, but remain managed separately. Docs are all in one place.

The benefit? Nobody gets out-of-date docs, because the version string passed along means you only see the doc pages and txp tags for that version. And Txp’s distro doesn’t get bloated by bundling docs with it. A downside is that both docs and tag builder aren’t available if there’s no Internet connection.

Off the top of my head, every release time when we tag the master code branch with a version, we also tag the docs with the same version number, therefore cementing the two commit points together and creating a “distributed repo” that’s linked by version number.

If it’s doable, how about that for a revolution? :-) Any major downsides?

hcgtv · 2016-09-15 13:38:35

Bloke wrote #301530:

A downside is that both docs and tag builder aren’t available if there’s no Internet connection.

If you had a /textpattern/docs folder/directory, you can ship a Textiled tag reference with each release. You ship an en-gb.txt for the sole purpose of offline installs.

Maybe even move all those license files from root to docs? Leave a clean root with only a README.txt, css.php and index.php.

colak · 2016-09-15 14:01:26

hcgtv wrote #301533:

If you had a /textpattern/docs folder/directory, you can ship a Textiled tag reference with each release. You ship an en-gb.txt for the sole purpose of offline installs.

Maybe even move all those license files from root to docs? Leave a clean root with only a README.txt, css.php and index.php.

Hi bert,

Although I like the idea, this file will always be out of date as new or updates of plugins normally appear after the txp releases. I’m wondering if this could be done via the plugin authoring. At the moment we have the optional help page per plugin what if there was a third ‘interface’ which could seamlessly be connected to the tag builder from the actual txp install. In this way, only installed and enabled plugins would appear in the builder.

Textpattern CMS

Textpattern CMS support forum

#1 2016-09-14 13:13:25