Thanks for the hint about extending the Parser. What I don't understand yet how I can replace the existing parser without touching the files that come with MediaWiki. I try to get this in as extension without modifying files... Roman

Roman, I had a similar problem when I was trying to figure out how to add <link> tags to for RSS and Atom feed based on the presence of custom tags. Here's the source in case you're the kind of person who wants to dive right in: http://jimbojw.com/wiki/index.php?title=WikiArticleFeeds Read on for my take on what you want to do and how you might go about being successful at it... What you want to do /is possible/ using existing hooks, but it requires multiple hooking methods working in concert. This is because anything that happens as the result of a tag extension executing (other than providing output) expires after the page is rendered. Since all Parser output is cached, when the Parser runs its parse() method, this typically only happens once per edit. In other words, this means that your tag extension will not be re-run for every page view. The meta tags exist outside the Parser - pulled into the Skin by the OutputPage as you noted. As it turns out, there is a hook in OutputPage that you can use to affect the Meta tags just before they are rendered out to the browser: 'OutputPageBeforeHTML'. This hook runs on every page view, except when Squid caching is used. In your case this probably wouldn't make a difference anyway though since the meta tags will be the same as long as the page content hasn't changed - which would purge the squid cache anyway. The difficulty lies in passing information from the custom tag (which the Parser will only run once per edit) into the meta tags (which must be done on each page view to be effective). This can be achieved by hiding data from the Parser. To do this, you can have your tag extension output an HTML comment with the data tucked away inside. Here's an outline of what you could do: 1) Hook into the parser creating your extension tag 2) Have your tag interpret the internals of the tag, or attributes to the tag, as a meta keyword (or list of keywords) to be injected into the page header later. 3) Encode the incoming data as base64 to make it look like regular text. Then wrap this in an HTML comment with flags to indicate the beginning and end. Something like this: $encodedComment = '<!-- @METAKEYWORDS@'.base64_encode($input).'@METAKEYWORDS@ -->'; 4) Output the wrapped, encoded comment tag. The Parser will faithfully push this into the page contents. 5) Hook 'OutputPageBeforeHTML', and in the implementing function, use a regular expression to search for your encoded comment tags in the provided $text param. 6a) If you find any matches, and want to delete all existing keywords (meaning you only want those that the user specifies), then you can call something like this: $out->mKeywords = array(); Note: I'm not completely sure this will work though since I don't know with certainty where mKeywords gets populated in the first place. If it happens after the call to addParserOutput( ), then you may be out of luck. 6b) For each encoded comment found, add it to the OutputPage's keywords like this: $out->addKeyword(base64_decode($encodedText)); That's about it. Good luck! -- Jim On 2/27/07, christoph.huesler(a)css.ch &lt;christoph.huesler(a)css.ch&gt; wrote:

Using display: none to enforce semantics is bad. It will then show up for many cell phone users, old screen readers, Lynx, etc.

The comment was probably a better idea, although unfortunately still

On 2/27/07, Jim Wilson &lt;wilson.jim.r(a)gmail.com&gt; wrote: Common.css): Using display: none to enforce semantics is bad. It will then show up for many cell phone users, old screen readers, Lynx, etc. The comment was probably a better idea, although unfortunately still rather hacky. _______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikitech-l

Probably the "cleanest" way to do it would be to create a new database table for it, akin to categorylinks or other metadata tables, and query that on page render. Whether in practice that's better than the hacky solution, I don't know.

Probably the "cleanest" way to do it would be to create a new database table for it, akin to categorylinks or other metadata tables, and query that on page render. Whether in practice that's better than the hacky solution, I don't know.