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

maniqui · 2010-05-15 20:04:38

BTW, what would happen if more than one article is “feeded” to rah_metas?

Will it just use one of them? If so, which one on the loop?

Or will it combine stuff from every article and then generate one set of meta tags? That could be cool, particularly now that keywords would be unique set.

Or will it just return n-plicated set of meta tags? (hopefully not!)

Gocom · 2010-05-15 20:42:52

maniqui wrote:

Will it just use one of them? If so, which one on the loop?

No, it doesn’t even see any kind of loop. It just sees the context.

Or will it combine stuff from every article and then generate one set of meta tags?

No.

That could be cool, particularly now that keywords would be unique set.

That is fairly possible with keywords attribute, or with rah_repeat. Combining all the data with the current method is not. If you ask me, it’s way out of scope of the plugin.

Or will it just return n-plicated set of meta tags?

Yes. Rah_metas just uses the current article context. If the tag is placed inside article list, that is the context. It works like any other article context tag would.

maniqui · 2010-05-15 20:46:37

Good to know! And sorry if my “hopefully not” sounded a bit harsh!

Probably the best way to avoid undesired output (ie. more than one set of meta tags) would just be to add always a limit="1" attribute to the article/@article_custom@ tag wrapping rah_metas.

Gocom · 2010-05-15 21:18:06

maniqui wrote:

Good to know! And sorry if my “hopefully not” sounded a bit harsh!

Not at all :-) /me hides shotgun. What shotgun, hehehe. I kid :P

Probably the best way to avoid undesired output (ie. more than one set of meta tags) would just be to add always a limit="1" attribute to the article / article_custom tag wrapping rah_metas.

Yep :-)

Techinacally the combining is fairly possible. The problem is PHP, and what happens to other metas (author, description etc).

I could do something to it by changing the starting lines of rah_metas() function to:

global $thisarticle,$rah_metas;
if(!empty && $thisarticle['last'] == false) {
	$rah_metas[] = $thisarticle;
	return;
}

Which then would store the loop for later use. Then we just need to wrap the existing rah_metas_keywords()/rah_metas_description() contents with:

global $rah_metas,$thisarticle;
foreach($rah_metas as $thisarticle) [...]

And imploding the results before cleaning the contents.

If the loop is large that will be bit slow, because it needs to go thru every article individually as not all articles use the same fields. It also makes it impossible to end the loop before the real end. For example if_first_article, variables, if_keywords — all that become useless because the results are only returned when $thisarticle['last'] == true.

Last edited by Gocom (2010-05-15 21:21:57)

whocarez · 2010-05-16 14:06:26

Gocom wrote:

Maybe there is something wrong with registering the directory index. Does the ?id=1234 show the article? What happens if you remove the comment hashtag from the DirectoryIndex line in the default .htaccess file?

Sorry, I was mistaken. The problem lies not in the plugin. It is the caching (aks_cache) of the “rah_metas” call, I think.
JFYI: the DirectoryIndex equivalent is enabled in Lighttpd and refers to the index.php and the articles show everytime up. So it is really a minor problem

maniqui · 2010-05-22 20:55:44

Hi Gocom,

Suppose I’m using a custom field to store the text for meta description, by adding description_from="my_custom_field".
I’ve noticed that, if the custom field is empty, then rah_metas resorts to body to generate the meta description. I wonder if it’s possible to change this behavior so, if custom field is empty, rah_metas tries to generate the meta description from excerpt first, and if not, then in that case, yes, use the body.
I think it’s a more common scenario to use text on excerpt field as meta description, than using generating it from article’s body.

Currently, i think it’s not possible to achieve this behavior using rah_metas attributes, but correct me if I’m wrong.
If not possible, and you know which lines to hack to give precedence to excerpt over body, that would be great.

In other words, make rah_metas work as it implicitly was fed with descritption_from="my_custom_field, excerpt, body".

Thanks.

Gocom · 2010-05-23 05:17:11

maniqui wrote:

In other words, make rah_metas work as it implicitly was fed with descritption_from=“my_custom_field, excerpt, body”.

Thank for the idea. That’s been added to the implemention list. Tho there is slight issue: backwards compatibility. It will break content prefererring on older installations if the have description_from is filled, which will override the default value. But I will hate implementing yet new attribute :-)

Gocom · 2010-05-23 09:38:13

Version 1.3 was just released. Changelog like list of things:

Now description_from and keywords_from take comma seperated list of fields. The first field in the list that isn’t empty is used as keywords or description.
Removed attribute prefercontent. Using the attribute will throw notice in testing and debugging mode.

Colors are nice. Blueeeee! …and downloads, docs and some other tiny things

thebombsite · 2010-05-23 10:56:13

Hi Jukka. I started using this recently and an excellent plugin it is too, particularly this new version. My single minor gripe is that I still use a form for the “robot” meta as I see no point in indexing a listing page, at least not for thebombsite. I don’t know if it possible or worth doing but it would be good for me if there were a separate robot attribute for individual_article view.

Gocom · 2010-05-23 11:16:16

thebombsite wrote:

I started using this recently and an excellent plugin it is too, particularly this new version.

Glad to hear that Stuart :-)

My single minor gripe is that I still use a form for the “robot” meta as I see no point in indexing a listing page, at least not for thebombsite.

Could this help to cut the ton of pasta? Anti-mass med:

<txp:rah_metas robots='<txp:if_individual_article>index,follow<txp:else />noindex,nofollow</txp:if_individual_article>' />

I don’t know if it possible or worth doing but it would be good for me if there were a separate robot attribute for individual_article view.

Yeah. You don’t need a plugin for it, and it’s not that much markup.

Last edited by Gocom (2010-05-23 11:19:58)

maniqui · 2010-05-23 19:47:46

Gocom wrote:

Version 1.3 was just released. Changelog like list of things:

Now description_from and keywords_from take comma seperated list of fields. The first field in the list that isn’t empty is used as keywords or description.

Removed attribute prefercontent. Using the attribute will throw notice in testing and debugging mode.

Great, Gocom.
Thanks again for accepting the request and pushing it into rah_metas.

I think this new way (a comma-separated list of explicit values on description_from or keyword_from attr) makes it much more easier to understand where the description/keywords are coming from.

A note for those upgrading (Gocom, correct me if I’m wrong): now, if you would like to have some “fall back” content for your meta description/keywords, you have to make it explicitly in your description_from or keywords_from attribute.
In other words, if you just do description_from="my_custom_field" and my_custom_field is left empty, then you won’t get any description from body or excerpt.

PS: Gocom, you may also want to remove the prefercontent example in rah_metas’ page.

thebombsite · 2010-05-23 23:10:07

Shoot! Why didn’t I think of that? I mean it’s just what my form is doing. Bugger!

Thanks for the reminding me I can use tags-within- tags Jukka.

Working too much with all this jiggery-pokery WP code is what it is. Bugger, bugger, bugger! ;)

Last edited by thebombsite (2010-05-23 23:12:52)

Textpattern CMS

Textpattern CMS support forum

#61 2010-05-15 20:04:38

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

#62 2010-05-15 20:42:52

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

#63 2010-05-15 20:46:37

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

#64 2010-05-15 21:18:06

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

#65 2010-05-16 14:06:26

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

#66 2010-05-22 20:55:44

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

#67 2010-05-23 05:17:11

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

#68 2010-05-23 09:38:13

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

#69 2010-05-23 10:56:13

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

#70 2010-05-23 11:16:16

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

#71 2010-05-23 19:47:46

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

#72 2010-05-23 23:10:07

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

Board footer