Thorsten Scherler wrote: >> Unfortunately this is not working properly (with the linkrewriter-part >> throwing an error in some pages) while it does work when I insert the >> same block into the system sitemap.xmap right above the orginal matcher.
> Makes somehow sense since placing it *before* the original match will > work. First matched - first served. Not sure what you mean by that. This is not a problem of priorities, project site maps should and do override the system site map. >> >> Two questions: >> >> - Is this because the required components need to be required >> components are declares in the sytem sitemap and need to be >> referenced differently here? > Do not understand the question. What components? You are using standard > components (already declared in forrest) or did I miss something? linkrewriter uses cocoon components that are declared in the system-sitemap (nothing special used) but I was wondering if they are available just like that in the project sitemap. >> If so, how do I reference this properly (I also need this to >> implement php-support) which I want to do in the project >> sitemap in any case. >> >> - Should I insert my matcher into heads sitemap.xmp like I >> did thus implementing a preferred processing of html? > IMO that should rather go into an input plugin on its own rather then > core. Not only that it is heavily skin specific but can have ugly side > effects for the rest of forrest (since it e.g. reserves an url space > **body-*.html and further is doing a html-to-html conversion of the body > (as I understand it) and not xdocs). I don't unserstand why. Since it is preparing for the transition to xhtml as core formal, why would it become a plugin? > In the dispatcher we are now using extensions like **.body.xml which are > conform to our naming conventions. Hmmm, does that mean I should aim for a different matcher then? -- Ferdinand Soethe
