Description field and tag

philwareham · 2015-06-19 11:23:26

The current selection of tags and fields in Textpattern make it a massive headache to get one of the simplest site content requirements into the CMS, namely descriptions. Be that used for meta description, Twitter Card, Open Graph, Schema.org microformat, etc.

Yes there is an excerpt field, but since that is controlled by Textile at an article level toggle, it can’t be used for both short in-page content snippets and in head area descriptions (not without a plugin or some raw PHP anyway).

Yes here is also custom fields and plugins, but again that is counter-intuitive for such a basic requirement (and pretty unfeasible for packaged themes).

There needs to be a description field in the meta fields of the write page, along with a <txp:description />, <txp:if_description> tag set.

Ideally sections should also have a field for description too I think so that can be harnessed on non-individual article pages. Even categories could benefit from the additional field.

NicolasGraph · 2015-06-19 11:28:45

The best would be arc_meta in the core.

Last edited by NicolasGraph (2015-06-19 11:28:58)

colak · 2015-06-19 11:47:17

I normally use the keywords field for that which could be renamed using wet babble.

philwareham · 2015-06-19 11:52:55

colak wrote #291694:

I normally use the keywords field for that which could be renamed using wet babble.

I do too, but it strips certain characters out of the text so it’s not a great solution. This request is generally geared towards making themes easier to install without having to use hacks or having to provide an essay in the README on how to create custom fields.

Bloke · 2015-06-19 12:09:47

philwareham wrote #291692:

There needs to be a description field in the meta fields of the write page

OK, so as discussed elsewhere, this entails a new varchar in the textpattern table called description (is that a good term for it, or is it too vague for its intent to be understood?) which can hold the meta description for an article. Is 255 chars enough max storage? FYI, MySQL 5.0.3+ supports up to 65KB varchars.

The new field should go under the ‘Meta’ twisty, immediately above Keywords.

a <txp:description />, <txp:if_description> tag set.

Assuming the name description is acceptable and intuitive, presumably you want the former tag to output one of two things:

<meta name="description" content="field contents here" />

or, perhaps if an attribute is set, to output the raw field value so you can roll your own. Which should be the default? Raw or cooked? Bear in mind that every other ‘specific’ tag (i.e. pretty much all those except <txp:custom_field />) outputs cooked stuff unless told otherwise, so maybe we should continue the tradition. You will be able to use the <txp:custom_field name="description" /> trick to output the raw value too.

Any preference for attribute names to use?

Ideally sections should also have a field for description too I think so that can be harnessed on non-individual article pages. Even categories could benefit from the additional field.

I agree, and easy to add. The same tag as above could be used with an attribute to choose which type to display (article, category, section). Maybe it could be context dependent to auto-switch if possible, not sure.

GugUser · 2015-06-19 12:17:30

Bloke wrote #291696:

The new field should go under the ‘Meta’ twisty, immediately above Keywords.

Normally I use for this a glz_custom_field as textarea, so the field is situated in the middle column with more space for the text. I don’t like the left column for this type of things.

philwareham · 2015-06-19 12:20:52

Looking at previous tag syntaxes used, maybe we also add a <txp:meta_description /> tag that outputs:

<meta name="description" content="field contents here" />

In addition to a <txp:description /> tag that just outputs the raw field value and can be used for all manner of things (see original post).

Then they don’t really need any extra attributes I guess.

How’s that?

uli · 2015-06-19 12:20:52

Bloke wrote #291696:

Raw or cooked?

Cooked, so that apostrophes can’t do any harm.

philwareham · 2015-06-19 12:24:23

Bloke wrote #291696:

Is 255 chars enough max storage? FYI, MySQL 5.0.3+ supports up to 65KB varchars.

The current optimal description length for Google is around 115-120 characters – so it’s up to you. With that in mind, I am OK with it being in the meta twisty. Anyway, our plans are to eventually let users move bits of the UI around, so for now that is OK place to put it.

colak · 2015-06-19 12:28:50

Hi Phil, I see what you are looking for.

Stef, I think that the new field should be similar to the keywords field so the new tag should -in my view – be used like

<meta name="description" content="<txp:description" />

In this way, the field could be used for something else should someone wants to. Re the varchar, does anyone remember what is the max number of characters Google is allowing for descriptions? One cool way is to have the field have 65k but limit its characters in the preferences. Is this possible?

Bloke · 2015-06-19 13:02:31

philwareham wrote #291698:

<txp:meta_description /> tag… in addition to a <txp:description /> tag that just outputs the raw field value

If that’s what you want, sure. I’d prefer fewer tags as it’s less code, but the user needs outweigh that ;-)

They’d still need an attribute to select between section, category and article description (assuming we go for those too, which makes sense).

An alternative proposition:

Tag	Output
`<txp:meta name="description" type="article" />`	`<meta name="description" content="article field content" />`
`<txp:meta name="description" type="section" />`	`<meta name="description" content="section field content" />`
`<txp:meta type="article" />`	`article field content`
`<txp:meta property="og:title" type="article" />`	`<meta property="og:title" content="article field content" />`

and so forth. If possible, the type should be optional since it’s probably possible to detect it from context, i.e. if in individual article context, type="article" by default, if inside a <txp:if_category> block, then set type="category" by default, else set type="section". So you’d only need to override it if you’re doing something out of the ordinary.

Edit: Maybe the name="description" could be default so you only need to use <txp:meta /> in most cases. And if you want to output the raw value, you use <txp:meta name="" />. Less typing, but a bit counter-intuitive maybe? Presumably property and name are mutually exclusive? [EDIT2: According to MDN there is no property attribute… urk]. In which case, specifying a property attribute would automatically set name="" so it didn’t output the name attribute when specifying OpenGraph or other meta content.

Any other attributes that the HTML meta tag can output which are of use here?

uli wrote #291699:

Cooked, so that apostrophes can’t do any harm.

Sorry, when I meant cooked, I meant with markup (like the <txp:article_image> and <txp:css /> tags do by default), as opposed to the raw value. But you’re right it would need an escape="html" attribute too.

Last edited by Bloke (2015-06-19 13:12:57)

NicolasGraph · 2015-06-19 13:06:30

Bloke wrote #291703:

If possible, the type should be optional since it’s probably possible to detect it from context.

Yes, I would prefer on my side.

Textpattern CMS

Textpattern CMS support forum

#1 2015-06-19 11:23:26