hCard format information in the site settings

I think it would be handy if the MODx backend had an hCard form in the site configuration settings. Maybe with a check box to display the information or not.

Perhaps an even more advanced implmentation would be to have such an hCard option in each web user’s profile such that hCard data could automaticly be inserted to a user’s public profile page if such a pager were designed into a site.

http://microformats.org/wiki/hcard

I believe Fickr and Yahoo already use the hCard format, Google Maps has recently added support on their site, and FireFox 3 is due to recognize sites with hCard data. I suspect it will catch on.

Any microformat can be achieved as a MODx add-on for presentation on the front-end. I’ve created calendar applications that simply use placeholders and chunks to output the event data into hCalendar format, and doing the same for user data in hCard format should be trivial.

...I was just working on an hatom implementation on Ditto [+placeholders+], it’s as easy as adding the proper class-names in the chunk Ditto uses as template:

<div class="ditto_NewsPage hentry clearfix">
<h2 class="entry-title"><a href="[~[+id+]~]" rel="bookmark">[+title+]</a><abbr class="published postDate" title="[+date+]">([+date+])</abbr>
</h2>
<p class="entry-summary">
[+summary+]</p>
<p class="tags">tags: [+tagLinks+]</p>
<address class="vcard author">[+author+]</address>
</div>

I have run into 2 problems (click on them in the above chunk code) but it basically works, ’Tails’ Microformats extension for Firefox and other online parsers are able to identify hatom blocks on the MODx-generated page.

Another easy way to add Microformats to pages is by defining Microformat-compliant classes in your css, and have them listed in TinyMCE’s Styles menu: once a Microformat tutorial had been given to your editors they will know how to Tag content-blocks properly in their wysiwyg environment.

What is the problem with the title="[+date+]" part? if the format is not correct by default, you can use PHx to modify it to be what you want.. or is there some other problem?

The problem was that i still have to look into PHx, thanks for the hint I’ll try it out!

seems it can also be good to get the correct format for tagLinks, but then a mod_rewrite is needed for the linked tag-landing document.
Anyhow I believe this rel-tag support will be supported in Ditto next release (?!)

ok PHx installed:

[+date:date=`%Y-%m-%dT%H:%M:%S+%Z`+] returns a wrong date (jan ’70);

[*createdon:date=`%Y-%m-%dT%H:%M:%S+%Z`*] works fine!

not sure whether this is a PHx or a Ditto issue, should I report it somewhere else ?!

The Ditto [+date+] placeholder is in a different format than createdon modx document variable.. If I remember correctly, the ditto date placeholder is already formatted to string and createdon is a unix timestamp.. In anycase, if it’s string, you can create a custom PHx modifier to do strtotime first and then strftime to the results.. I believe that I have seen this done in some thread already..

Edit: No.. I did it my self for MaxiGallery when someone asked.. but if the ditto date placeholder is already formatted to some string, you can use that.

The [*createdon:date=`%Y-%m-%dT%H:%M:%S+%Z`*] actually outputs the ’createdon’ date for the whole page, not the ones from the posts recovered with Ditto, thus it is useless for building microformats from them.

Following Doze’s suggestion, I am now calling a PHx custom modifier for the placeholder:

[tt][+date:hatomdate=`%Y-%m-%dT%H:%M:%S+%Z`+][/tt]

and it works correctly. The phx:hatomdate gets the Date string from Ditto, converts it back to a unix-timestamp, then it transform it into the needed formatted string:

[tt]return strftime($options, strtotime($output));[/tt]

Thus we have a way to output both a machine-readable and a human-readable date from the same single Ditto placeholder.