I am using ejs template engine and express js (node js), when i pass the reference parameter in url, static css files stops work
Your reference parameter is separated from the rest of the URL by a path separator character (/).
Relative URLs which don't start with a / are relative to the current path.
By changing the path, you change where the URL is relative to.
Since you are relative to a different path, your new URL resolves to the wrong place.
Change the href of your link to the stylesheet so it points to where the stylesheet is. This is most easily achieved by starting it with / (e.g. href="/static/styles/your.css").
Related
This is the weirdest issue I've ever faced in a long time. I have a URL that is authored inside a multifield. The URL has an underscore eg. http://example.net/_pinkPanther_is_pink it is currently inside ${item.link}
When I do Click <br> ${item.link} and inspect, it renders as
Click
<br> http://example.net/_pinkPanther_is_pink
If you notice both values are coming from the same variable in Sightly still when the link is used inside href of anchor tag there is double underscore added by God know who after example.net/
Does anybody have a clue as to what on earth is going on ?
That's caused by the display context aware XSS protection. Sightly/HTL automatically detects the display context of a HTL expression, using its location within the structure of the HTML page to detect it.
For example, if the expression appears in a place that would produce a text once rendered, then it is said to be in a text context. If it is found within the value of an attribute, then it is said to be in an attribute context, and so forth. More about contexts in the htl specification page.
In your example, the implicit context inside the href attribute is uri while in the later case is text.
In order to overwrite this behaviour, you may explicitly set the context like href="${item.link # context='text'}.
When we take a pathfield value in jsp, need to provide harcoded ".html" or ".pdf".
Is there any way to make pathfield generic, hence no need to provide hard coded extensions? So if a user selects .pdf it will display a pdf file and if user selects .html it will open a html file.
Not sure if there is a OOB way to do this. Alternatively, You can create a script/custom jstl tag which take path as input, load resource and find out resource type and generate path with correct extn as output.
Call this script from all your components which generate links.
Another option is you extend com.day.cq.rewriter.pipeline.RequestRewriter and in rewriteLink() function write your logic to set correct extn.
There is an extension in my TYPO3 website that uses the following line of Typoscript:
EXT:ts_example/social_bookmarks-min.js
This translates to
typo3conf/ext/ts_example/social_bookmarks-min.js?1416308825
If I use absolute URLs in my website, this is not a problem, but if I intend to use relative URLs, this won't work, as it won't replace the entire pathname of the base URL, since it does not start with "/".
In short, I wish that it would output this instead:
/typo3conf/ext/ts_example/social_bookmarks-min.js?1416308825
Is there a way to achieve this?
In your main TypoScript use:
config.absRefPrefix = /
and DON't use config.baseURL at the same time!
When I create my menu I only have relative paths for the different menu links. How do I get an absolute URL (i.e. a typolink with the baseURL in front of it).
I can think of either defining a variable or write the domain name in the wrap. E.g.
10.wrap = <option value="http://www.domain.com/|">
But are there better options?
Simply set the typolink parameter forceAbsoluteUrl of the links in your HMENU construct: http://wiki.typo3.org/TSref/typolink
Set config.absRefPrefix = http://www.yourdomain.com/sub/path/. That will prefix any properly generated site-root relative links with the domain.
There may be an alternative way using domain records (Linking across domains in multidomain-sites does exactly what you want), but I can't point you to anything there.
While analyzing some requests on our dispatcher, we noticed that we continually get a 0 byte file generated from hitting the following path
/etc/clientlibs/foundation/testandtarget
This file is a ClientLibraryFolder. Its js.txt defines the base file as such:
#base=source
There is no "source" folder that is a direct child of testandtarget. The testandtarget folder contains two ClientLibraryFolders, mbox and util. The js in these folders is loaded on the page just fine. This is why Test&Target still works. However, the testandtarget ClientLib seems to be wrong by default (this is the OOB 5.5 setup). We get a 0 byte file because the js.txt file's base points to a folder that does not exist.
Is anyone else seeing the behavior? It appears that I could just rewrite the js.txt file. Are there any ramifications for doing so?
As best I can tell, that node is an empty clientlib, but it has a child node of "mbox" with the same clientlibrary category. That clientlibrary WILL produce content, and references a source folder beneath it.
http://{localhost}/libs/cq/ui/content/dumplibs.test.html?categories=testandtarget
http://{localhost}/libs/cq/ui/content/dumplibs.html?categories=testandtarget&type=JS&theme=
I am not aware of the version history, and whether it used to have valid content, or is planned to in the future.
I would be more tempted to remove or change the category than to play with the js.txt file. Editing the js.txt file will change what content goes into the clientlib. Changing/removing the category would no longer cause a call out to the zero byte file.
<cq:includeClientLib categories="testandtarget" />
=>
<script type="text/javascript" src="/etc/clientlibs/foundation/testandtarget/mbox.js">
<script type="text/javascript" src="/etc/clientlibs/foundation/testandtarget.js">