[SOLVED] - Tagging: rel-tag URL sintax does not conform to Microformats specs

The links Ditto produces for the tags (DITTO::buildURL function), do contain the ’rel=tag’ attribute, but don’t conform with the rel-tag microformats specification that Technorati and other spiders exploit to automatically classify posts/articles.

As a result the tags are only usable as an alternative navigational system within the site, but standard microformats tools such as Operator and Tails Firefox extensions cannot parse them correctly.

The tags are currently outputted as url parameters as in:



while the specs clearly states:

Tags are embedded in HTTP URIs in a well-defined manner so that the tag embedded in an HTTP URI can be mechanically extracted from that URI. Specifically, the last segment of the path portion of the URI (after the final "/" character) contains the tag value. For example, the URI http://www.example.com/tags/foo contains the tag "foo".
The destination of a rel="tag" hyperlink is required to be a tag space (a place that collates or defines tags), where the last segment of the path of the URL is the tag, e.g. http://technorati.com/tag/tech is a URL for the tag "tech".

Tags may only be placed in the URL path, and only in the last segment of the path.
Tags may not be placed in query parameters or fragment identifiers. e.g.

http://technorati.com/tag/tech?tag=fish#emu

is still a URL for the tag "tech", not "fish" or "emu". Since the only part of a tag space URL of which any structure is required is the last path segment, a tag space URL can be hosted at any domain.

I understand this is strongly dependent on MODx friendly-urls settings and maybe solvable by .htaccess rewrite hacks,
but there should be a supported way to include this important semantic element in Ditto Output.
can I add this as a new ticket in the Ditto codebase track?

Know your microformats -> rel-tag

Yes please file this as a task ticket in TRAC. This will require some brainstorming to figure out how to accomplish...

You can get the alias field of the landing page using the getField snippet at the moment until a better solution arises.

I tried the new ’tplTagLinks’ parameter included in the latest development version (1454); calling up a chunk that builds the correct rel-tag sintax:

<a href="[(site_url)]tags/[+tag+]" class="ditto_tag" rel="tag">[+tag+]</a>

this correctly returns standard-compliants tag links.
Now, to make the urls point tho the right content (the Taglanding page), you’ll have to add a modRewrite rule in the .htaccess, assuming your tagLanding page has a docID of 495:

#.htaccess apache-server directives
#RewriteRule ^(.*)$ index.php?q=$1 [L,QSA]
RewriteRule ^tags/(.*)$ index.php?id=495&tags=$1&start=0 [L,QSA]

works, but as you see I have commented the general Rewrite-rule for friendly urls;
infact I still have to understand how to make the 2 RewriteRules co-exist, it should be something like:

#.htaccess apache-server directives
RewriteRule ^(.*)$ index.php?q=$1 [QSA]
RewriteRule ^tags/(.*)$ /italiano/Tagged-documents.html?tags=$1

where the 2nd line tries to match and substitute on the friendly-url created by the first one.
This is having no effect on the server behaviour, either the rule does nt match anything, or it needs some specific
RewriteCond %{REQUEST_URI} before it...
Any Apache ModRewrite guru wants to take a look into this?
I have spent the morning on the apache docs without finding the fix! then issue#48 in Ditto Trac is [SOLVED] !

This is quite an important aspect to market MODx (also) as a blogging platform...

PS: Mark, [+tags+] in the longtitle field of the landing page is again returning me empty strings with rev1454, can it be it got screwed with all the activities you are doing on tagging functions to support these new parameters?

Maybe put the tags rewrite rule before the normal one?

As for [+tags+], it is being set fine in my test case at the same revision on MODx 0.9.6.

Ok assuming your tplTagLinks sets the tagLinks string to ’<a href="[(site_url)]tags/[+tag+]" class="ditto_tag" rel="tag">[+tag+]</a>’, these 2 lines in the .htaccess will work:



where you’ll have to substitute the id of your tagLanding page.

They work on the url-query string created by the ’RewriteRule ^(.*)$ index.php?q=$1 [QSA]’ , the MODx default .htaccess rule for friendly URLS); thus they should follow it.

Ticket #48 closed ! (??)