The anchor stuff is
solved
But back on the current subject, I kind of agree there should be a way to escape the parser, though I never had this kind of need myself so far...
.: COO - Commerce Guys - Community Driven Innovation :.
MODx est l'outil id
-
MODX Staff
- 10,725 Posts
That said, I always use the base href tag with my MODx sites, for various reasons, but the main reason being to properly handle access to virtual directories within a MODx site. For instance, with friendly URLs and friendly alias paths, let’s say you have the URI /foo/bar.html within your site, but someone goes to /foo/bag.html. They get the error page loaded, but since the client requested a resource within a directory called /foo, the browser now thinks the base location to be /foo. In this situation, if you do not either a) have absolute paths in all of your content or b) a base href tag that appears before all relative paths in your document (including the CSS file), so the browser knows what the base location really is, the error page is going to be loaded without styling, js, etc. properly linked. Further, for friendly alias URLs to work, unless you again use absolute paths for everything (which makes your site instantly non-portable to other installations/configurations), have a template for every subdirectory, or use the base href tag, you’re going to run into the same problem.
So, best practice IMO, is to always build your templates with a base href tag, use relative paths from the site root at all times, and fully qualify any anchor ( # ) links with the proper URI (i.e. href="[~[*id*]~]#anchor" for links to the same page).
Hi,
here is a case where turning off the parser would be useful.
I was trying to write a tv options Editor for the front End but every times I’ve tried to display the values in a form field I couldn’t see its value if it was a chunk (for instance => TV options value : case1=={{chunk1}}||case2=={{chunk2}}).
I guess it was parsed before
:-)
