Is there a standard way in Adobe CQ5 to get the current page url in order to create automatic canonical links in the head of the JSP?
Basically we have a dialogue config box where you can override the canonical link, but by default if this is empty I want to construct the link based on the raw URL path for the current request.
The JSP for the head is shared across all requests.
Many thanks
The ${currentPage.path} variable will give you the path of the parent page to the current resource, but you should use the Externalizer to make this into a nice user-facing URL, (i.e. applying any mapping rules that you have in place & using the correct domain name, rather than the server name e.g. prod-server-123)
i.e.
ResourceResolver resourceResolver = request.getResourceResolver();
Externalizer externalizer = resourceResolver.adaptTo(Externalizer.class);
String canonicalUrl = externalizer.publishLink(resourceResolver, "http", currentPage.getPath());
You can customise what the externalizer treats as the base URL via Felix, or via an osgi:Config node in your repository. and read more on the official docs on the Adobe site.
(Note that the Externalizer is CQ5.5+)
Related
I'm having trouble with the basesite service. We currently have three websites: global, cn (China), and tw (Taiwan) (Taiwan)
To pick the region, we have a drop-down menu on the global site. Using baseservice(spartacus), the selected region is set.
this.baseSiteService.setActive(region);
localhost:4200/cn/cn When the above line has run, appears in the URL
Could someone please explain how it is appended twice in the url and how to override this?
You said in the comment that you "don't have any services or configs related to site context". So I guess what you see in the URL by default are 2 different site contexts: baseSite and language, which "by coincidence" have the same values pairwise):
localhost:4200/<baseSite>/<language>
I guess what you want to achieve in this case is to have an URL of the shape localhost:4200/<baseSite>. This can be achieved in 2 ways, depending on whether you're using static or automatic site-context configuration.
You can configure which site contexts should appear in the URL in 2 ways:
if you're using CMS-driven site context configuration in Spartacus (aka. automatic site-context-configuration), then you need to configure it in CMS Backoffice tool. As in the screenshot below, for each of your basesites go to WCMS -> Website -> <select your base site> -> Administration (tab) -> URL Encoding Attributes and put there only the value storefront (get rid of language or anything else there). And save the changes.
if you're using static site-context configuration in Spartacus, then you need to provide the following static config in your app:
provideConfig({
urlParameters: ['baseSite']
})
References:
Automatic Site Configuration Detection from URL (demo video)
Spartacus docs on Site-context configuration
I have already add the rest support (link)of my website. the CMS and my website are under different domain. when I used restcall to pull the contents like html code " the contents will automatically convert to site is for hippo site and rest is for rest call mount point.
so obvious the relative path does not support if we use rest call to pull contents from cms to other websites.
I am just wondering that is there anyway to keep same relative url after rest call and instead using absolute path.
Please have a look at the long thread posted here: https://groups.google.com/d/msg/hippo-community/L417REGg2pY/YPtawvh0M8IJ
In an ASP.NET MVC 4 website I'm using Web API to return JSON-formatted resources including links for authorized actions (e.g., DELETE). To create these links I'm using the GetUrlHelper() extension method on the HttpRequestMessage...
_httpRequest.GetUrlHelper().Link( routeName, routeValues );
My concern is that the string returned from Link() is a fully qualified URL (it includes the https://example.com/...) when all I think I need is the relative URL (just the /my/resource). Currently, I've got a server problem where our production environment is adding http when it should be https, which doesn't work. I can fix that separately, but it raises the question, should I just supply a relative URL? And if so, is there a better way of getting a relative URL than trimming off the root part of the UrlHelper.Link()-generated URL?
Edit:
After consulting Richardson's & Ruby's meritorious RESTful Web Services, I believe more firmly that a relative URL is wholly appropriate here.
Does the PathAndQuery on Uri help you?
Example: (new Uri(_httpRequest.GetUrlHelper().Link("DefaultApi", new { controller = "Values", p1="abc" }))).PathAndQuery...this would give you like /my/resource?p1=abc
I'm trying to achieve urls in the form of http://localhost:9294/users instead of http://localhost:9294/#/users
This seems possible according to the documentation but I haven't been able to get this working for "bookmarkable" urls.
To clarify, browsing directly to http://localhost:9294/users gives a 404 "Not found: /users"
You can turn on HTML5 History support in Spine like this:
Spine.Route.setup(history: true)
By passing the history: true argument to Spine.Route.setup() that will enable the fancy URLs without hash.
The documentation for this is actually buried a bit, but it's here (second to last section): http://spinejs.com/docs/routing
EDIT:
In order to have urls that can be navigated to directly, you will have to do this "server" side. For example, with Rails, you would have to build a way to take the parameter of the url (in this case "/users"), and pass it to Spine accordingly. Here is an excerpt from the Spine docs:
However, there are some things you need to be aware of when using the
History API. Firstly, every URL you send to navigate() needs to have a
real HTML representation. Although the browser won't request the new
URL at that point, it will be requested if the page is subsequently
reloaded. In other words you can't make up arbitrary URLs, like you
can with hash fragments; every URL passed to the API needs to exist.
One way of implementing this is with server side support.
When browsers request a URL (expecting a HTML response) you first make
sure on server-side that the endpoint exists and is valid. Then you
can just serve up the main application, which will read the URL,
invoking the appropriate routes. For example, let's say your user
navigates to http://example.com/users/1. On the server-side, you check
that the URL /users/1 is valid, and that the User record with an ID of
1 exists. Then you can go ahead and just serve up the JavaScript
application.
The caveat to this approach is that it doesn't give search engine
crawlers any real content. If you want your application to be
crawl-able, you'll have to detect crawler bot requests, and serve them
a 'parallel universe of content'. That is beyond the scope of this
documentation though.
It's definitely a good bit of effort to get this working properly, but it CAN be done. It's not possible to give you a specific answer without knowing the stack you're working with.
I used the following rewrites as explained in this article.
http://www.josscrowcroft.com/2012/code/htaccess-for-html5-history-pushstate-url-routing/
I'm trying to implement some omniture requests on server-side. I've got the calls set up, and the requests make it to omniture, but the referrer is not showing up in omniture.
Here is an example of one of the urls for omniture my code creates. Am I missing something?
http://[id].112.2o7.net/b/ss/[group]/1/H23.2/s1328206514850?AQB=1&ndh=1&ns=[id]&g=http%3A%2F%2F[domain]%2Flogin.asp&vid=1328206514850&pageName=Login%20Page%20!test!&r=http%3A%2F%2Ftest.com
The Internal URL Filters in the Report Suite Admin Console specifies what your internal domains are (i.e your domains). Any referal from any other domain will be recognised as a referrer.
I generally use a Firefox addon like WATS to debug the variables that are on a particular page, including referrer.
Keep in mind that there needs to be a referral from an external site. If you just type in the URL, or reload, or click from your own site, there is no referral. When testing this, I would create a page on another domain (e.g. localhost), and create a link to my page.
https://omniture-help.custhelp.com/app/answers/detail/a_id/1652/kw/JavaScript/related/1
COMPARISON: s.linkInternalFilters vs. Internal URL Filters
s.linkInternalFilters: The linkInternalFilters variable within the s_code.js file is used in exit link tracking. If s.trackExternalLinks is set to true, it is used to determine if a specific link a visitor clicked on is internal to your organization's site or not. Clicked links that match a value in s.linkInternalFilters are ignored, while links that do not match any values are sent to SiteCatalyst as an exit link.
Internal URL Filters: The Internal URL filters within the Admin Console is used in Traffic Sources reports, such as the Referring Domain report. Every s.t() request checks to see if the referring URL (contained within the referrer variable) matches any of the rules set up. Referring URLs that match any of these rules are excluded from all Traffic Sources reports, while referring URLs that do not are included.
It is recommended that s.linkInternalFilters and Internal URL filters match eachother, however the two operate completely independently and serve completely different functions.
The last part of that image is the referrer value, r= . Is that the correct value? Also you should check your Internal URL Filters in the admin console for that report suite. Typically for new report suites you will find the value of . (a single period) set in there. If you do have that then no referrers will be recorded.