rah_metas // new 1.x-versions of SEO/redirecting/automatic meta-tools

Gocom · 2009-09-14 16:04:31

philwareham wrote:

I have always been led to believe that description meta should always appear before keywords meta for fully optimised SEO (as most search engines ignore keywords nowdays anyway). rah_metas seems to default to keywords first then description, or can this be manually changed?

Honestly speaking, the order doesn’t matter IMHO. But, if you are as concerned as it seems, I supose you shouldn’t be using the plugin, rah_metas, at all. It even autogenerates the data from the content, and you are worried about the tag order.

Last edited by Gocom (2009-09-14 16:06:16)

philwareham · 2009-09-14 16:28:55

I’m not overly concerned, it was just a simple question asking whether there is the option of changing the order of which meta tags are displayed first. Sorry if you took that as a criticism of your plugin.

Gocom · 2009-09-14 19:55:44

philwareham wrote:

I’m not overly concerned, it was just a simple question asking whether there is the option of changing the order of which meta tags are displayed first. Sorry if you took that as a criticism of your plugin.

Heh, no I didn’t take it as a criticism. Just pointing out that, if you are concerned about the order, you should really be concerned about the other factors which really do matter. Like the fact you are supposed to write unique meta descriptions, and not to use a plugin that automates the process. As an answer, no, there isn’t a option to change the order, because it doesn’t matter IMHO.

philwareham · 2009-09-15 08:36:01

I’m using the plugin only as a final safety net in case the article authors on my site forget to write an excerpt (which doubles as meta description) and/or omits keywords. It then pulls a description from the body text and uses a preset line of keywords. Works pretty well for that task.

Gocom · 2009-10-09 00:35:38

Major, version 1.1, update released. Note that the code have been rewriten, there might be bugs and malfunction. Changelog:

Added: attribute keywords_limit.
Added: removes doublicated words from keywords.
Added: list view’s description is effected by word and character limits.
Fixed double "=" define bug.
Now escape attribute effects also body and expert, not only custom fields.
Now keywords are escaped, striped from tags and parsed.
Counts white space into chars.
Removed imagetoolbar attribute validation.

More info and downloads

Features, in-sights — A new system, new possibilities?

Does your author abuse keywords? Let’s say Mike used to input keywords:

animal, dog, cat, animal,  cute, human, mortal,keyword

See, there are some double occurances and bit of messyness. Hopefully, we have a new maid in our household. After the magic it’s all clean:

animal, dog, cat, cute, human, mortal, keyword

No extra white space, no words craping commas’ ass. It’s not all. You, users, did request a feature which you could use to do descriptions for list pages, along with keywords. Now we can do those too — totally customized custom-contents.

Simple list page ‘keywording’ might look like something like:

<txp:rah_metas keywords='<txp:article><txp:keywords /></txp:article>' keywords_limit="30" />

After parsing the keywords we end up with a massive list of keywords from all articles on the page. Not nice. But after the new cleaning ‘thingy’ we get clean 30 words without dublicates.

Long tails… what, you got a tail?

Not anymore. Now keywords’ and description’s word and character limits do effect everything. And Google is happy… if that thing has emotions. Oh, and it doesn’t count whitespace in the limit.

Invalid XHTML. B*** you got f**** < there!

That’s why I thought you boys and girls like strippers. Strippers that do strip more stuff than just valid XHTML. White space gone, line breaks gone, f**** < gone. Bare naked. Atleast your description is valid… even that your article is still invalid.

Last edited by Gocom (2009-10-09 00:38:00)

maniqui · 2009-11-30 18:31:48

Hi Gocom,

I’ve two ideas which I would like to share with you. I hope:

they make sense
you like them ;)

1. Option (attribute) to “disable” limits (ie. words/maxchars) if the preferred field (ie. description_from) is being used.

Let me try to explain. For example: rah_metas is configured to use the “metadescription” custom field content as the main source for meta description. If end-user effectively filled the “metadescription” custom field, then, do not apply the words/maxchars limits to its content. That way, it’s up to the end-user to write the “metadescription” as “valid” as possible. If we wants to use 50 words, even when we know that Google will only show 25-30 words, then let him use all of them, and don’t trim the content.
But if “metadescription” is not filled in, and then, rah_metas falls back to excerpt/body, then yes: apply the limit specified in description_limit.

This would add some flexibility that has its advantages, imho:

meta description won’t be cutt off to “satisfy” current word limit on search engines (like Google), which may change any day.
the plugin will “respect” the end-user input, instead of doing too much automagic processing.

2. “id” attribute, to generate/grab meta from a very specific article.

Background: I think it’s becoming a common practice to handle “sticky/static” contents by using standard Textpattern articles, as latest TXP versions make it easier to do so.
For example, when you reach a section frontpage (or a category frontpage), it’s common to use some txp:article or txp:article_custom to grab a very specific article (sometimes passing the id, but also by clever usage of status or customfieldname attributes) as an intro content for the section/category.
That usually involves an snippet of code, something like this:

<body>
...
<txp:article_custom section='<txp:section />' on_frontpage="yes" limit="1">
  <h2><txp:title /></h2>
  <txp:body />
</txp:article_custom>
...
</body>

So, what I’m suggesting. is to be able to pass an article id to rah_metas and so, generate the meta stuff as exactly as it’s done when viewing an article on its individual permanent link (where the id is passed “implicitly”)
That way, on list pages (sections, categories) we could use an snippet, very similar to the above one, to fetch the corresponding article, and pass its id to rah_metas. Like this:

<head>
...
<txp:article_custom section='<txp:section />' on_frontpage="yes" limit="1">
  <txp:rah_metas ... id='<txp:article_id />' />
</txp:article_custom>
...
</head>

I think a method like the above would have some key advantages, improving coding over some of the examples posted on plugin help:

as stated above, opens the possibility of working with rah_metas on page listings (sections, categories) in a similar fashion as it works on individual articles (implicit id).
use the magic inner cogs of rah_metas to generate the meta contents for page listings, instead of what the current plugin example suggests (examples use tags-in-tags to feed the description attribute, that is somehow rather limiting, compared to just passing the article id and letting rah_metas work out the magic of which content use for meta description and meta keywords)
it would add consistency to the code: you could use a very similar snippet (= a very similar logic/code) to fetch the corresponding article, both to generate the meta contents (at top of page) and to output the contents (on the page, somewhere inside <body>). In other words, it makes code easier to understand and maintain, imho.
will make it easier (I should demonstrate this) to manage this things at a “per section page template” level, without the usual (ab)use of if_section conditionals. At least, that’s what I’m imagining.
btw, if id is empty, fall back to standard behaviour (which would be backward compatible)

Gocom, I hope you could consider this ideas as something viable, particularly the last one :)
Thanks!

Gocom · 2009-11-30 20:58:40

maniqui wrote:

1. Option (attribute) to “disable” limits (ie. words/maxchars) if the preferred field (ie. description_from) is being used.

User won’t need the plugin for that. If user doesn’t want limit or whatnot, the one can use custom_field. But if the user wants, the user can use if_custom_field to raise the articele word limit to huge amount.

[...]words='<txp:if_custom_field name="description">9999<txp:else />25</txp:[...]

Possibilities are limitless.

“id” attribute, to generate/grab meta from a very specific article.

Sure. Thanks. When I’m going to release the next version, it will include the id support.

Currently, custom article content can fetched by using article_custom and feeding it to the attributes. Tho, that is useless for list of articles, because if you are making metas for that particular need, you don’t obviously need rah_metas for that.

Last edited by Gocom (2009-11-30 23:43:47)

maniqui · 2009-12-11 02:27:54

Oh, I missed your reply, Gocom.

Gocom wrote:

(…) But if the user wants, the user can use if_custom_field to raise the article word limit to huge amount. (…)

Thanks for the trick.

Sure. Thanks. When I’m going to release the next version, it will include the id support.

Great! Much welcomed :)
Is the next version just around the corner? ;)

geroldbraun · 2010-01-21 10:44:41

a wonderful plugin, Gocom, thank you. After tweaking around for a while, i have still one small issue i cannot fix.

The facts: i use txp 4.2.0 + rah_metas 1.1; keywords=’<txp:article><txp:keywords /></txp:article>’ keywords_limit=“30”
In my blog-startsite there are several single postings, each with its keywords (titled in german as “abgelegt unter”).

The issue: the keywords are comma-separated but the last keyword of each posting has no ending comma. That leads to: it is meltet with the first keyword of its following posting. To be seen in html view.

Example: <meta name=“keywords” content=“cms, txpB2B-Marketer, sales-pipeline, ..
“txp” was the last keyword of the youngest post and “B2B-Marketer“was the first of the elder post. Where do I have to screw?

Last edited by geroldbraun (2010-01-21 19:14:38)

Gocom · 2010-01-21 19:20:27

Thank you geroldbraun. Sort of quick fix:

keywords='<txp:article><txp:keywords /><txp:if_last_article><txp:else />,</txp:if_last_article></txp:article>'

geroldbraun · 2010-01-21 19:32:14

thank you for a perfect quick fix and really quick answer, Gocom. Everything is fine now.

jan · 2010-01-28 01:51:39

Hey Gecom, nice plugin!

One problem:
Although the messy_to_clean_redirect redirects to the clean url nicely, it doesn’t seem to create a genuine 301 header. Instead, I get the “usual” 304/Not modified header.

I have observed this with the Live HTTP Headers add-on for Firefox.

I see nothing strange in you code though…

Could this be a malfunction?

Gocom · 2010-01-28 02:39:14

jan wrote:

Could this be a malfunction?

Hi Jan,

Could be that Textpattern’s header block owns the flat of the tiny teddy bear; TXP’s core is defined first. To get over double headers-sent and content-before-headers boguses, one can use new output buffer.

Likely this includes that the header code is sent before TXP starts own markup output. To do this we could take redirection code off and put it inside a shiny new function:

rah_metas_totallyunofficial_redirect();
function rah_metas_totallyunofficial_redirect() {
	if(!is_numeric(gps('id')) and !gps('s'))
		return;
	ob_start();
	ob_end_clean();
	if(gps('s')) 
		header('Location: '.pagelinkurl(array('s' => gps('s'))),TRUE,301);
	if(is_numeric(gps('id'))) 
		header('Location: '.permlink(array('id' => gps('id'))),TRUE,301);
	exit();
}

Something along those line. I would put my hopes on in tho.

jan · 2010-01-28 13:49:40

Makes sense :) Will try that, and post results!

geroldbraun · 2010-02-01 11:04:14

as far as i can see, description_from=“metadescription” and keywords_from=“custom2”, will not work with sections (will work fine with articles); If i want static pages (sections like .. www.mysite.com/contact/) with keywords and description, i have to “hardwire” it in the page header, right? Or did i miss something?

Textpattern CMS

Textpattern CMS support forum

#31 2009-09-14 16:04:31

Re: rah_metas // new 1.x-versions of SEO/redirecting/automatic meta-tools

#32 2009-09-14 16:28:55

Re: rah_metas // new 1.x-versions of SEO/redirecting/automatic meta-tools

#33 2009-09-14 19:55:44

Re: rah_metas // new 1.x-versions of SEO/redirecting/automatic meta-tools

#34 2009-09-15 08:36:01

Re: rah_metas // new 1.x-versions of SEO/redirecting/automatic meta-tools

#35 2009-10-09 00:35:38

Re: rah_metas // new 1.x-versions of SEO/redirecting/automatic meta-tools

#36 2009-11-30 18:31:48

Re: rah_metas // new 1.x-versions of SEO/redirecting/automatic meta-tools

#37 2009-11-30 20:58:40

Re: rah_metas // new 1.x-versions of SEO/redirecting/automatic meta-tools

#38 2009-12-11 02:27:54

Re: rah_metas // new 1.x-versions of SEO/redirecting/automatic meta-tools

#39 2010-01-21 10:44:41

Re: rah_metas // new 1.x-versions of SEO/redirecting/automatic meta-tools

#40 2010-01-21 19:20:27

Re: rah_metas // new 1.x-versions of SEO/redirecting/automatic meta-tools

#41 2010-01-21 19:32:14

Re: rah_metas // new 1.x-versions of SEO/redirecting/automatic meta-tools

#42 2010-01-28 01:51:39

Re: rah_metas // new 1.x-versions of SEO/redirecting/automatic meta-tools

#43 2010-01-28 02:39:14

Re: rah_metas // new 1.x-versions of SEO/redirecting/automatic meta-tools

#44 2010-01-28 13:49:40

Re: rah_metas // new 1.x-versions of SEO/redirecting/automatic meta-tools

#45 2010-02-01 11:04:14

Re: rah_metas // new 1.x-versions of SEO/redirecting/automatic meta-tools

Board footer