Go to main content

Textpattern CMS support forum

You are not logged in. Register | Login | Help

#25 2015-06-22 10:45:45

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

Re: Description field and tag

philwareham wrote #291779:

Yeah but there is already a <txp:keywords /> tag hence the <txp:if_keywords>.

OK, yeah, I s’pose. So the conditional tag kinda serves to allow you to differentiate both tags. And the two tags do exactly the same thing, except one outputs formatted content, the other outputs raw.

We can play it either way. Or take the curveball and deprecate <txp:keywords> in favour of adding a format attribute to <txp:meta_keywords>. The existing <txp:keywords> tag in use in people’s templates would then just throw a warning in testing mode (but would still work), acting as a stub for <txp:meta_keywords format="raw" />.

EDIT: Or vice versa: keep <txp:keywords> and <txp:description> with format attributes and remove the <txp:meta_*> variants (though what to do with <txp:meta_author>… deprecate that too and add a format attribute to the <txp:author> tag?)

Don’t mind either way. Whatever the community prefers.

Last edited by Bloke (2015-06-22 10:48:02)


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

#26 2015-06-22 10:50:10

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

Re: Description field and tag

Bloke wrote #291783:

We can play it either way. Or take the curveball and deprecate <txp:keywords> in favour of adding a format attribute to <txp:meta_keywords>. The existing <txp:keywords> tag in use in people’s templates would then just throw a warning in testing mode (but would still work), acting as a stub for <txp:meta_keywords format="raw" />.

Sure, that could work too. I guess keywords are ‘meta’…

“Meta is a prefix used in English to indicate a concept which is an abstraction from another concept, used to complete or add to the latter.” – Wikipedia

Offline

#27 2015-06-22 14:04:30

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

Re: Description field and tag

I’m tempted to rethink this meta lark a bit. 4.6.x introduces <txp:author url="1" /> for displaying the author as a raw link instead of a name. What about if we tried to standardise things a tad:

  • <txp:author format="url" /> (instead of <txp:author url="1" />). It’s more readable if nothing else.
  • <txp:author format="meta" /> (same as <txp:meta_author />, except it won’t return empty if there’s no author at present).
  • <txp:author format="link" /> (instead of <txp:author link="1" />, outputs a linked author name).
  • add escape="html" attribute so you have the option to output the author raw.

That would have a knock-on effect for standardisation that we would:

  • have <txp:description format="meta" /> (instead of the proposed format="tag" attribute).
  • ditch <txp:meta_description />, or use it as a shortcut to the above.

And:

  • have <txp:keywords format="meta" /> (same as <txp:meta_keywords> without the check to see if it’s empty. Alternatively, deprecate the meta-specific tag).
  • add escape="html" to the <txp:keywords/> tag for output flexibility.

Using format="link" fits in with the <txp:css>, <txp:feed_link> and <link_feed_link> tags. But it does mean that we might consider the same attribute in place of link="1" in <txp:thumbnail>, <txp:link_author>, <txp:link_category>, <txp:comment_name>, <txp:author_email>, <txp:category>, <txp:category1>, <txp:category2>, <txp:section>, <txp:image_author>, <txp:file_download_author>, and <txp:breadcrumb>. It also scuppers <txp:image_url> slightly as that has an link="auto" option. And does it clash with the ‘date-based’ usage of format in the posted, modified, expires tags? (although we have those already alongside other format attributes).

So maybe it’s not such a good idea, but I dunno. I’m not talking about removing the attributes, just deprecating them and moving towards fewer, more standardised attributes. Is that a long-term goal?


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

#28 2015-06-22 14:22:40

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

Re: Description field and tag

I don’t know – that sounds more complicated to me. I’d be OK with deprecating <txp:keywords> and having the format="raw" on the <txp:meta_keywords> and <txp:meta_description> as suggested previously. The keywords and description appear in the meta section of the Write page after all, so the tags are quite self-explanatory.

Offline

#29 2015-06-22 14:42:14

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

Re: Description field and tag

philwareham wrote #291812:

format="raw" on the <txp:meta_keywords> and <txp:meta_description> as suggested previously.

Yeah, that’s the inverse of the above. And equally valid, it’s just that if we’re considering deprecating <txp:keywords>, and using <txp:meta_description> instead of <txp:description>, where does that leave <txp:author>? It’s sort of a special case in a way, that just happens to have a companion <txp:meta_author> for specific meta-usage. But that’s why I considered keeping the ‘non-meta’ versions with an attribute, versus keeping the meta versions, ditching keywords and also having an author tag.

I’m equally fine with keeping both the ‘meta’ and ‘non-meta’ versions of all three tags, so having six tags in three pairs. Maybe adding format="meta" to each of the non-meta variants too. That would then mean more than one way to produce a desired result, which could be regarded as a boon or a potential source of confusion / bloat.

Not sure. Changing the tag handlers to be more consistent isn’t hard, it’s just whether we want to consider it. I don’t want to introduce a format="tag" attribute for the sake of it when it’s the only tag using it, but then <txp:meta_description format="meta" /> seems over-wordy and largely redundant. I like format="raw" or format="" though, if we keep the <txp:meta_*> tags.

Hmmmmmmmm.


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

#30 2015-06-22 14:56:07

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

Re: Description field and tag

Actually format="" is pretty good idea, it’s got previous history on other tags’ syntax.

I’m still leaning towards deprecating <txp:keywords> tag.

<txp:author> has other uses outside of meta stuff, so I don’t see that as an inconsistency.

Offline

#31 2015-06-22 15:00:15

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

Re: Description field and tag

philwareham wrote #291816:

Actually format="" is pretty good idea, it’s got previous history on other tags’ syntax.

Cool.

I’m still leaning towards deprecating <txp:keywords> tag.

Fine by me.

<txp:author> has other uses outside of meta stuff, so I don’t see that as an inconsistency.

Yeah, it is kind of an anomaly in that regard.

I’ll see what I can come up with and give it a spin.


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

#32 2015-06-22 15:11:03

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

Re: Description field and tag

Although not directly related, if we were looking at tag attributes with a view to trying to consolidate them over time, there’s nothing to stop us using it as a vehicle to run certain attributes side-by-side for a while.

The immediate one that springs to mind is form. If the lAtts() function had a conditional added to it such that any time it saw form it rewrote it as, I dunno snippet or something, then existing tags and plugins continue to work, but we’d be free on the admin side to rename every instance of the attribute form and all the admin widgets likewise. When we publicise the change of name, we just let the two run side by side for a few major versions and then remove the conditional in lAtts() so form is no longer recognised, once plugins have caught up. We’d need a replacement tag for <txp:output_form> still.

I also like the escape attribute and think it should be on more tags that offer different output options. That means we can do more stuff with them like injecting content into other tags. Being forced to have the output sanitized when it’s not destined for the screen seems a holdover from when tags were not permitted as attributes and container support was limited. Yes it’s a security risk, but as long as it’s on by default (which it is in all instances) I don’t see the harm in allowing a designer to turn it off if they know what they’re doing or intend to sanitize via an external manner.


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

#33 2015-06-23 08:08:05

Dragondz
Moderator
From: Algérie
Registered: 2005-06-12
Posts: 1,529
Website GitHub Twitter

Re: Description field and tag

Hi Stef

For txp:keywords i personnaly use it like a tag field for some website when needing a multiple category assignement for articles i hope the tag will not be removed even if tagged as deprecated (it will be annoying to have the message on front end when working on those website!! can be those message put off with a pref?)

I am also in favour for adding description or meta description, that is now common for SEO.

Cheers

Offline

#34 2015-06-23 08:52:56

phiw13
Plugin Author
From: Japan
Registered: 2004-02-27
Posts: 3,079
Website

Re: Description field and tag

Dragondz wrote #291850:

(it will be annoying to have the message on front end when working on those website!! can be those message put off with a pref?)

The warning will only be visible when you set textpattern in testing mode (in the prefs).
Then you can easily replace the old tag with the new one: <txp:meta_keywords format="" separator=", " /> in your templates.


Where is that emoji for a solar powered submarine when you need it ?
Sand space – admin theme for Textpattern

Offline

#35 2015-06-23 09:03:30

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

Re: Description field and tag

Dragondz wrote #291850:

For txp:keywords i personnaly use it like a tag field

So do I. Even though the tag is (tentatively, I may be swayed to reinstate it) deprecated, you can still get the list of keywords by issuing:

<txp:meta_keywords format="" />

That performs exactly the same function as the <txp:keywords> tag did, but has the benefit that you don’t (necessarily) need the conditional <txp:if_keywords> around it, because it will automatically display nothing if no keywords are defined.

In addition, I’ve just added the separator attribute which means you can output the list in a more readable format if you wish. I’m toying with permitting it to be used as a container so you can customise the output more. Not sure if it’s worth it.

I am also in favour for adding description or meta description

<txp:meta_description> has landed for 4.6.0 on articles, sections and categories. Hope they prove useful.


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

#36 2015-06-23 10:11:01

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

Re: Description field and tag

If anyone wants to give these a try, I’ve done some initial documentation of the tag changes:

meta_keywords

meta_description

If you spot any errors or improvements for those docs, then raise an issue or mention here.

Offline

Board footer

Powered by FluxBB