Description field and tag

Bloke · 2015-06-22 15:00:15

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.

Bloke · 2015-06-22 15:11:03

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.

Dragondz · 2015-06-23 08:08:05

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

phiw13 · 2015-06-23 08:52:56

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.

Bloke · 2015-06-23 09:03:30

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.

philwareham · 2015-06-23 10:11:01

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.

Dragondz · 2015-06-23 10:12:31

Thanks Stef for clarification.

Destry · 2015-06-23 12:28:04

philwareham wrote #291859:

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

Assuming I understand the function of these tags so far, and that I understood your doc, then they could be cleared up a bit, for example…

——

<txp:meta_keywords />

The meta_keywords tag is a single tag used in one of two ways, or both. One is to output keyword data as the content of a standard HTML meta tag in the head of a page template:

<meta name=“keywords” content=“{your keywords}” />

The other is to output raw keyword text anywhere else:

{your keywords}

Context of use must be with a single article (as opposed to an article list). The tag can be added directly in a [[Page template]] or as part of an article [[Form template]]. Either way, you may also nest it in a given article tag.

Note: The corronsponding keywords field has a 255 character limit by default, which includes spaces and commas. This is the MySQL database default. You can edit the default using phpMyAdmin, for example.

Bloke · 2015-06-23 12:45:22

Destry wrote #291870:

they could be cleared up a bit

Much obliged. I’ll clean up the meta description tag in a similar manner for clarity next.

EDIT: no I won’t, Phil’s done it!

philwareham · 2015-06-23 13:04:48

Sorry, we were both editing the same file for a minute there! Done now.

Destry · 2015-06-23 15:37:56

philwareham wrote #291859:

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

What does “raise an issue” entail? I.e., if I wanted to offer help on doc pages (as I happen to see things in the course of life) besides posting notes in the forum (which won’t go far) what is the process?

N.B. I rarely look at Github. Every time I learn to use it in some small way, months go by and I forget what I learned. Is there a quick-up-to-speed guide somewhere in this case? I’m happy to relearn again. Just point me in the right direction.

philwareham · 2015-06-23 16:08:02

Destry wrote #291889:

What does “raise an issue” entail?

All our GitHub projects have the issue features turn on. So for instance if you want to raise an issue on the documentation, go here then click the ‘New issue’ button.

jakob · 2016-05-28 23:05:06

Is it possible to retrieve a particular description field, for example from the default section when not in that section?

The thinking behind this is to specify a default/fallback value if no description is specified.

I tried with:

<txp:section_list sections="default"><txp:meta_description /></txp:section_list>

but had no luck. Putting <txp:section /> in the container returns the correct section but txp:meta_description doesn’t work in the same way. Any other ideas?

phiw13 · 2016-05-29 01:21:06

If I understand correctly: you want something similar to what already exists (docs) for categories: txp:meta_description value="category.image">.

Thus extending the existing txp:meta_description value="section"> to txp:meta_description value="section.default">

Yeah, that would be useful to output a description meta if no description exist for a given context. For now, in my <txp:if_description><txp:else />….. block I (manually) add a @<meta name=“description” content=“foo”> as a last resort.

jakob · 2016-05-29 07:17:40

phiw13 wrote #299351:

If I understand correctly: you want something similar to what already exists (docs) for categories: txp:meta_description value="category.image">.

Yes, kind of. Except that my understanding of the value="…" method is that it is an additional specifier within the prevailing context (i.e. “which aspect of the current page context am I specifically interested in?”). Being able to retrieve the value for another section would be stepping out of the existing context, kind of like how txp:article_custom works with respect to txp:article.

Yeah, that would be useful to output a description meta if no description exist for a given context. For now, in my <txp:if_description><txp:else />….. block I (manually) add a @<meta name=“description” content=“foo”> as a last resort.

Yes, exactly. Now that we have the fields for sections and categories – which I think is excellent – I can ditch all those extra adi_variables/cnk_snippets fields for each section that I used to use. And it is better that the fields live with the respective item they belong to. Except, that is, for the default case where I still need an adi_variable if the default meta description is to be user-editable.

—

An aside: What do you think is better from an SEO perspective?

Specifying a default meta description. This gives you potentially better term correspondence across parts of the page (depends a bit on the variance of topics in a site, of course) but you also end up with duplicate meta description values across pages when the user doesn’t specify a description, which could lead to exclusion of similar pages from search results.
Using no description. You forfeit any extra term repetition gain but google will do its best on the search results page to provide an extract for that page.

Textpattern CMS support forum

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

Re: Description field and tag

philwareham wrote #291816:

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

Re: Description field and tag

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

Re: Description field and tag

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

Re: Description field and tag

Dragondz wrote #291850:

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

Re: Description field and tag

Dragondz wrote #291850:

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

Re: Description field and tag

#37 2015-06-23 10:12:31

Re: Description field and tag

#38 2015-06-23 12:28:04

Re: Description field and tag

philwareham wrote #291859:

#39 2015-06-23 12:45:22

Re: Description field and tag

Destry wrote #291870:

#40 2015-06-23 13:04:48

Re: Description field and tag

#41 2015-06-23 15:37:56

Re: Description field and tag

philwareham wrote #291859:

#42 2015-06-23 16:08:02

Re: Description field and tag

Destry wrote #291889:

#43 2016-05-28 23:05:06

Re: Description field and tag

#44 2016-05-29 01:21:06

Re: Description field and tag

#45 2016-05-29 07:17:40

Re: Description field and tag

phiw13 wrote #299351:

Board footer