I have an AEM 6.3 site which uses ACS AEM Commons 3.15.12 sitemap functionality, it's configured on publish instances to use the 'publish' externalizer domain. The rendered sitemap has the correct hostname in the sitemap URLs.
When I add an additional homepage component (for the new site) in the same sitemap config as the existing working one, keeping publish as the externalizer domain, the new site's sitemap doesn't have the new site's domain name in the generated URLs, instead it has http://localhost:4503.
The working site (sitemap) does have some /etc/map/http mappings, which I recreated in kind for the new site, but again, when using the same config (with a home page component for each site), http://localhost:4503 remained as the domain name for my new site in its ACS AEM Commons generated sitemap.xml.
I did not try creating a new config with the new site (and its home page component), using publish as the externalizer domain, and with the new mappings I created.
I did however create a new config, with the new site's homepage component, and using a custom externalizer domain, which I created to match my new site's correct domain name, and did not have any /etc/map/http maps for the new site. In this case, the generated sitemap had the correct domain name in its sitemap.xml.
I'm trying to understand what's going on. Why the different behavior in the domain names printed in the generated sitemap.xml files for each site? Also, why does ACS AEM Commons want a home page component when a path could indicate the root of a site? It makes me wonder if my new site's home page component is missing something, so as not to work (i.e. causing the ACS AEM Commons sitemap to show http://localhost:4503 instead of the site's domain name), or maybe it's mapping related, or something else?
Seeking clarity (09/08/21):
The first site in my AEM to use ACS Commons Sitemap is using "publish" (which maps to http://localhost:4503) as the externalizer domain. How is the generated sitemap for this site getting the correct domain in this case? The only other info in the ACS Commons Site Map config for this site is the sling resource type for this site's homepage component.
Additionally, there are several /etc/map/http/<xxx_site:80> entries for this site, including one for sitemap (a redirect to home.sitemap.xml). I have a feeling these entries are how the sitemap has the correct domain while only having "publish" as the externalizer domain? The protocol shows as http however, could this be changed to https by creating similar /etc/map/https entries?
Instead of creating: publish1 https://www.yourfirstdomain.com, publish2 https://www.yourseconddomain.com for additional sites as suggested (and this does seem to work), could I use the same "publish" externalizer domain, in a new/separate ACS Site Map config, as the first site does, in conjunction with similar /etc/map/http(s) entries for the additional sites/domains?
Default configuration in externalizer for "publish" domain is "http://localhost:4503".
For your new/existing domain you should first configure Day CQ Link Externalizer:
use publish1, publish2...and so on
publish1 https://www.yourfirstdomain.com,
publish2 https://www.yourseconddomain.com
After this, you can enter the respective domain (publish1, publish2,..) in ACS AEM Commons - site map servlet as externalizer domain
Related
Does anybody have sophisticated knowledge about running a multi-domain-site using a single typo3-instance ?
E.g. I have 2 domains, both being served by the same webserver, using different vhosts. What I want to achieve, is both vhosts pointing to the same document root, where a typo3-instance is installed. This TYPO3-instance should check by typoscript, which domain was used in the request and forward requests for each domain to a specific subpage ("landing page for that domain").
I need this to work in a productional & stable environment, due to custom-self-developed extensions, which provide necessary data for both installations, also specific extbase-domain-models should be usable in both domains etc.
I am already able to check the requested domain via typoscript-conditions. What I am missing, is some info, about how I could possibly realize the redirection, without the client being redirected to the landing page each time while using sub-pages of the landing-page. Do I need to set cookies for this !?
Thanks in advance, Oliver
In TYPO3, you can combine several sites (each with a different domain) in one Installation. This already works out of the box.
So, for this requirement
This TYPO3-instance should check by typoscript, which domain was used in the request and forward requests for each domain to a specific subpage
it is not necessary to add a check for TypoScript, TYPO3 will automatically resolve the URLs.
Page Tree:
pid=0
| --> root page 1
| --> root page 2
On both root pages, enter page properties : "Behaviour" checkmark enable "Use as Root page"
On both root pages, create a TypoScript template, edit it, got to tab "Options", checkmark "Rootlevel". Have this TypoScript template include your general TypoScript configuration, e.g. via "static includes" (ideally you put your TypoScript configuration in an extension)
Since TYPO3 9: configure a site for each page tree under "Site Management > Sites". Before TYPO3 9: On both root pages create a "Domain" record
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?
I have the need to create a page in the Alfresco Share context that should be accessible without authentication. When using the page framework it seems pretty straight forward since you can add <authentication>none</authentication> to the page definition.
When using aikau the page definitions is gone and I'm left with the get.desc.xml-webscript file which does to my knowledge does not support the authentication element. Anyone having an idea?
It looks like you are accessing your webscript through the auth-page url:
http://<ip>:<port>/<context>/page/ap/ws/<webscript>
Please note that ap in the URL stands for the authenticated page defined under the directory:
/<project-name>/src/main/webapp/WEB-INF/surf-config/pages/auth-page.xml
This section :
<config evaluator="string-compare" condition="UriTemplate">
<uri-templates>
<uri-template id="remote-node-page">/{pageid}/p/{pagename}/{store_type}/{store_id}/{id}</uri-template>
<uri-template id="remote-site-page">/site/{site}/{pageid}/p/{pagename}</uri-template>
<uri-template id="remote-page">/{pageid}/p/{pagename}</uri-template>
<uri-template id="sitepage">/site/{site}/{pageid}/ws/{webscript}</uri-template>
<uri-template id="userpage">/user/{userid}/{pageid}/ws/{webscript}</uri-template>
<uri-template id="page">/{pageid}/ws/{webscript}</uri-template> <!-- this template matches your URI which means the resolution of which page/webscript would be accessed will rely fully on it -->
</uri-templates>
</config>
of your
/<project-name>/src/main/webapp/WEB-INF/surf.xml
Defines page/webscript resolution policy based on URI-templates. For further infos on how to set/exploit page uri templates please visit this tutorial
The auth-page has authentication set USER as shown here which would result in asking for authentication before even trying to resolve the webscript
So if you want to access some aikau page in un-authenticated mode (as a guest user) you should be using the noauth-page like this:
http://<ip>:<port>/<context>/page/na/ws/<webscript>
FYI: You do not have to set your webscript authentication at all as it defaults to none when the authentication tag is not present
It's worth being aware that you can create your own template pages for Aikau. You aren't limited to the pages that are defined in either Share or clients created via the Aikau Maven Archetype (see https://github.com/Alfresco/Aikau/blob/master/tutorial/chapters/Tutorial1.md).
In Share for example you have 4 templates available out-of-the-box:
dp (Dynamic Page - what you should use in most cases)
hdp (Hybrid Dynamic Page - where the header and footer and rendered above and below the page)
rp (Remote Page - accesses a page stored on the Alfresco Repository)
hrp (Hybrid Remote Page) - accesses a remote page stored on the Alfresco Repository and renders it between the standard header and footer.
In clients created by the Aikau Maven Archetype you have:
- na (Not Authenticated) - renders a page but doesn't require a user to be authenticated
- ap (Aikau Page) - renders a page for authenticated users.
Aikau pages make use of URI templates to reduce the amount of Surf objects that are required to build a page - however you always have the option of building your own pages.
See the examples in the archetype project for reference, the no-authentication page is defined here
Both this page and the standard authenticated page both re-use the standard template type which ultimately maps to the standard page FreeMarker template
However, if you want to build your own pages and templates you can - you're not limited to using what is provided by default.
I have a Hosting in Hostgator with the domain http://vector5.eu set as principal. Also, I have a Joomla installed here: http://vector5.eu/responcat.
Then there is a domain (which I don't belong, belongs to another company): http://respon.cat. This domain have this redirection pointing to my Joomla:
http://respon.cat/newsletter --> http://vector5.eu/responcat
My problem is that this Joomla is not autogenerating the links with the domain http://respon.cat, instead they are generated with the domain http://vector5.eu.
This is an example of one link on the webpage: http://vector5.eu/responcat/index.php/newsletter-en-catala
I've tried almost everything with no luck. Any ideas?
Thanks!
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