I'm working in AEM 6.3. I'm trying to extend the default behavior of vanity URLs such that the following will happen:
User navigates to vanity URL and is redirected to actual URL
An ID that is associated (and authorable) is appended to the URL
Profit?
So I'd be extending the default page properties vanity functionality to include an ID.
Example:
Vanity URL: /foobar
ID: 123
Actual URL: www.test.com/plans
Resulting URL: www.test.com/plans?123
I've been able to modify the page properties to include a new field associated with the vanity URL in the UI. It doesn't appear to be saving the actual value though.
Haven't gotten to actually trying to apply this saved value to the URL through the dispatcher. How that would work is still very vague as well.
Yes. You could do that. But you will have to build your page rendering logic based on the URL used for accessing the page. Guess you could manage with two public facing URLs - the vanity url and the final url constructed based on the ID.
As for dispatcher configuration, check the official documentation at the below link for handling vanity URLs
https://docs.adobe.com/content/help/en/experience-manager-dispatcher/using/configuring/dispatcher-configuration.html#enabling-access-to-vanity-urls-vanity-urls
Related
I have a typo3 Plugin (my own) which have lots of sub pages.
Now all Pages got their own canonical URL ... but I want that they only have the canonical from the page which contains the Plugin.
Is that possible?
Thanks in advance.
As far as the content changes with the parameters these parameters belong to the canonical URL.
You might not want your parameter specified pages indexed, but that needs other metatags than a non unique canonical url.
A canonical URL is used to have a unique URL for a page which can be accessed with multiple URLs. So Search engines know which URL to use and don't think of duplicate content.
If you really want to fool search engines with multiple content for the same URL you can of cause generate the base URL without all parameters and use it as canonical URL. Mind the value of config.linkVars. Just build your meta tag by hand using page.headerData.
I am a beginner at CQ5. I created a simple workflow with 2 paths - accept and reject. I created a page and set its vanity url the same as the original page url and checked the "Redirect Vanity url" text box. Next I pushed the page down the workflow. But then when I opened up the page in the browser and clicked on the workflow tab of the sidekick, it was completely blank. Removing the vanity url brought back the workflow tab contents. Can someone explain to me why this happened so? This wasn't mapped in the ConfigMgr console.
I found that the vanity url actual does something like a "Redirect". So if we add a vanity url to a page which has the same url as the vanity url, the page goes into something like an infinite loop, redirecting to itself. This causes trouble in various sorts. In my case, it was affecting the workflow.
What are the best practices for assigning vanity URL to a content page in AEM 6.1.
When an author mentions a vanity path to a page and activates it, it does not really reflect in publish. Problem I observed is: when the save operation carries out on page vanity property, it saves an rewrite rule at the map location, which is generally at /etc/map unless it is specifically changed.
So when the page containing vanity path activates then this rewrite rule does not really activates along, although the JCRResorceResolver map location is same for publish and author instance which is /etc/map.
Therefore, I wanted to understand what is the way of activating the resource resolver rewrite rule along with page activation? Or are there any best practices that the vanity should not be given a control to page editors and should only be performed by an administrator directly in publish instance?
/etc/map has nothing to do with vanity urls. In /etc/map you can manually add some path/host to resource mappings.
When an editor adds a vanity url, the resource resolver(s) will catch that event and add the url to their list - if a page with a vanity url is published, the AEM publish servers will also add the vanity url automativally to their resolvers.
Take a look at /system/console/jcrresolver on both author and publish. You should see the vanity url on both machines.
If you want your vanity url on root level, it should start with "/". Other things that might prevent the vanity url from working:
You might have additional mapping rules on /etc/map(.*).
There is a dispatcher in front of your CQ/AEM Publish server that is filtering or manipulating the incoming urls.
What exactly is the vanity url added by your editor (content path and content of field vanity url) and what is the url you are calling to get the page via vanity url on the publish instance?
What is the meaning of the below mentioned terms ? Are they any different from each other?
URL Redirect Rules
Resource resolver settings for URL shortening
Sling Mapping
Vanity URL
Vanity Domain
Update :: Re- constructed the question
As per my understanding the above terms mean the same thing. I have read the documentation but haven't clearly understood it.
Found an awesome link to my questions.
AEM URL Rewriting
The typical website structure for an Adobe CQ5/AEM project begins with /content in the URL structure and typically contains the application name. My example application’s homepage has the URL structure /content/cookbook/en/home.html which matches the JCR structure for the website. This is not an ideal url path most people would like for their site. To address this concern we will utilize two methods for rewriting URLS within AEM.
Sling Resource Resolver
Inside AEM you can configure the Sling Resource Resolver to filter out the initial path of your site structure. To achieve this you need to edit the Apache Sling Resource Resolver Factory inside the system console’s configuration section (/system/console/configMgr). You will need to add an entry under the URL Mapping property to remove the beginning portion of the URL you want remapped. In my case I have entered /content/cookbook/-/ so that /en/books.html now resolves the url /content/cookbook/en/books.html. This will apply to all sites within your site so you may want to review your site structure to avoid a conflict.
Vanity URLs
For some sites there might be a requirement to create a friendly url for navigating into your site. In my case I want to type http://localhost:4502/books to navigate to the /en/books.html page. In this scenario I may just decide to edit the Vanity URL property for the books.html page. I can specify that /books is the vanity url and any traffic to that URL will be redirected to books.html. This can be convenient for site with only a couple vanity URLs but isn’t idea since it can be edited by an author.
Sling Resource Mappings
If you wish to keep url mapping rules outside of the author’s control then you should utilize the Resource Mapping features in Sling. Under /etc/map/http you can create nodes of the jcr type sling:Mapping that will allow you to do the same thing as vanity urls. These nodes require two properties to be set: sling:match and sling:internalRedirect. The sling:match property uses regular expression to evaluate the url to match. If the url is matched then the request is redirected to the path set in the sling:internalRedirect property. In the example application, the matched path localhost.4502/authors is redirected to the /content/cookbook/en/authors.html page.
I'll give it a try:
URL Redirect Rules -> This sounds for me more like mod_rewrite in apache
ResourceResolver settings -> Can be configured in OSGi (Apache Sling Resource Resolver Factory). Usually the path to a page starts with /content/sitename/language. So the language maybe interesting for the visitor, but the first two are not, so you want to map /content/sitename/ to / so you can have call mydomain.com/language in the browser
Sling mapping is more or less the same logic as ResourceResolver, but you don't configure the ResourceResolver in OSGi, but have a mapping below /etc/map/http
VanityUrl -> This is more like an alias for a path mostly used for marketing URLS like mydomain.com/product1 which could point to /content/sitename/language/products/product1 It would not make sense to have a ResourceResolver or Sling mapping for each product
Vanity Domain is linked to VanityUrl so you can have the same VanityUrl for different domain: mydomain.com/product1 ponts to a different site than myseconddomain.com/product1
I'm attempting to put a named anchor on a part of our Facebook tab and add "#anchor" to the shared URL so when users click the shared link it will take them directly to the proper content on the tab.
I added to my tab and then recoded the FB Feed Dialog URL so
link=http://www.facebook.com/mybhg?sk=app_279723102083145#quiz
and
actions={name:'name',link:'http://www.facebook.com/mybhg?sk=app_279723102083145#quiz'}
In testing the dialog displayed an error saying both of these were invalid links:
Requires valid redirect URI
actions should be a JSON-encoded dictionary with "name" and "link" keys
So I bit.ly'd them which Facebook accepted and you can share the short URL. When users click the shared link though, the correct URL is used (with "#quiz") but the browser does not snap to the anchor location.
Since FB failed on the original URL, I suspect they aren't set up to parse #named anchors in their URLs, but I wanted to put it out to the community and see if someone has made it work (or confirmed it doesn't.)
Thanks!
URL fragments (the #) can't be read on the server side.
What you can do is use the app_data parameter, which is forwarded to you on the signed_request parameter, parse it accordingly, and have some Javascript to force the jump yourself.