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

Bloke · 2009-08-04 13:26:46

Gocom, been using this plugin for ages now: a real time saver, thanks.

Just noticed a curious behaviour that I think (not 100% confirmd yet) may be related to the relnext attribute. What I’m seeing is that when I visit Page A, the TXP logs dutifully show that I visited Page A but also show that I visited Page B. Similarly, if I visit Page J, the logs show Page J and, immediately after that, Page K.

In short, it seems to be logging two hits per page visit; one for the current article and one for the next article. Switching rah_metas off appears to make the logs record one hit per page.

Could there be something in your use of link_to_next() or newer() that’s causing this? It’s just messing up smd_lately which uses the log files to show what a visitor has viewed recently. Confused me for ages because it was showing articles I hadn’t actually viewed and I thought smd_lately was broken!

Any ideas?

EDIT: I’m running a stock 4.0.8 with rah_metas 1.0.5

Last edited by Bloke (2009-08-04 13:31:11)

Gocom · 2009-08-04 15:52:08

Bloke wrote:

Gocom, been using this plugin for ages now: a real time saver, thanks.

You’re welcome.

Bloke wrote:

Could there be something in your use of link_to_next() or newer() that’s causing this?

I don’t think it’s in the server side code, Mr. Bloke :)

If there is log hit made with your referrer, I would suspect the method your browser uses to handle relative links. Is the hit also noted by the server not just by TXP?

If it is, then most likely the browser is pre-fetching/checking the previous and next pages. For example, browsers, like Firefox even if there isn’t favicon, try to load favicon.ico from the root of domain. Similiar case. Some media browsers check the rss feeds for instance.

You can avoid that by turning relative links off from the plugin.

Last edited by Gocom (2009-08-04 15:54:17)

Bloke · 2009-08-04 16:17:19

Gocom wrote:

I don’t think it’s in the server side code, Mr. Bloke :)

Hehehe, that’s what confused me: I couldn’t find anything in the core that ran log_hit in any of the functions you used!

So I guess it’s browser-related. Stupid Firefox trying to be clever and doing what I don’t want it to. I’ll check the server logs to find out. Guess I have to live without relnext then :-(

Thanks for putting me on the right track, man.

maniqui · 2009-08-04 16:47:45

That prefetching thing seems evil… it’s unwanted optimization, slowing down the tubes, wasting resources, compromising privacy (I don’t want you, Firefox, fetching unwanted pages just to trick people that your browser is faster than others).

Gocom · 2009-08-04 17:06:00

maniqui wrote:

That prefetching thing seems evil… it’s unwanted optimization, slowing down the tubes, wasting resources, compromising privacy (I don’t want you, Firefox, fetching unwanted pages just to trick people that your browser is faster than others).

It is (if it’s true that is). Even that favicon thing is bad IMHO. Eats both, users and server’s bandwidth. Plus what I’ve have tested, Firefox is slower than all the other major browsers, when looking at the hardware load stats and memory eating.

Hopefully, you can disable all (read: some) the nasty features by config in firefox. Also the memory optimizing feature that just eats CPU. Only thing that you can’t change by config is the new JavaScript engine, which IMO is really bad and unstable.

Note: my post is entirely IMO. You can take it as fiction.

Last edited by Gocom (2009-08-04 17:14:28)

philwareham · 2009-09-14 13:51:59

Hi,
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?
Thanks,
Phil

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!

Textpattern CMS

Textpattern CMS support forum

#25 2009-08-04 13:26:46

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

#26 2009-08-04 15:52:08

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

#27 2009-08-04 16:17:19

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

#28 2009-08-04 16:47:45

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

#29 2009-08-04 17:06:00

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

#30 2009-09-14 13:51:59

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

#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

Board footer