Since you are getting 403 due to default GET servlet, this means that
the URL is not mapping to a resource. It is possible the "provided
navigation option" was generated wrong. It is possible the trailing / is
to blame and could be checked first. Additionally see if the servlet (as
a component) and the bundle are active.
Found the answer, but it took a while dealing with environments with
restrictive permissions.1) The dispatcher filter rules were correct. 2)
No need to remove the vanity URLs section3) Found that the DNS routed
the traffic to a different vhost in this multi-vhost environment4) And
this routed the traffic subsequently to wrong dispatcher farm. In short,
dispatcher behaved correctly as expected - meaning it got a 404 in
filters and thus routed to vanity URLs - just that it happened in the
wrong di...
We have sitemap configured as /en/sitemap.xmlThis is working as expected
in the publisher. However while accessing from dispatcher, see the
following the dispatcher logUnable to fetch vanity URLs from
[ip-address]:4503/libs/granite/dispatcher/content/vanityUrls.html:
remote server returned: HTTP/1.1 404 Not Found [Thu Sep 10 21:37:51
2020] [I] [pid 79557] "GET /[path-to-en]/en/sitemap.xml" ! - 9ms
[publishfarm/-]It seems like the sitemap is treated as vanity URL. Any
thoughts on how to prevent t...
You might want to uncheck isDeep property. This is explained here -
https://helpx.adobe.com/experience-manager/6-3/sites/administering/using/tc-rules.html
You would want to verify what @jbrar suggests. Assuming you are talking
about page load time in your "site", there might be other factors at
play as well Cache ratioSpecific component logicVolume of
trafficClientlibs load time in browserbreaking JSIf in author, also look
at the "developer mode". It should give you component wise breakdown on
loading time.
When you say homepage, this is AEM Admin page? Or is the homepage part
of the site you built on AEM? In any case, for such errors, you need to
troubleshoot, starting with the logs.
If I have to think through the need for this, I can assume that 1) You
have (to manage) static and editable templates2) (at least some of the
)New components need to be supported in both static and editable
templates3) Since one is developing components with style system, might
want to leverage the style system concept in static as well. Otherwise,
one might as well migrate the static to editable templates. Seems like
for some reason you don't want to do that. Anyways, leaving the issues
related...
It is possible Chrome would be expecting some headers that is missing in
6.5 vs 6.4. You might want to scan the response headers in 6.4 vs 6.5
and find if something might be missing.
1. You are not able to set a higher heap size than 1GB. Please verify if
there are any other system limitations - meaning, what is the memory in
your computer and how much is free for AEM?2. If you have sufficient
memory, try setting 4GB in a new aem instance to ensure the issue is
something other than the heap size. Many will normally set more than 1
GB in local. with regards to 12k transactions - I have done similar in
the past but always chunk the transactions to 1000 or so update/inserts
per...
If this is one off, you can probably try that using crxde. However if
this needs to happen frequently, then the best option is to review the
content hierarchy or page building logic. May be the components could be
Experience/Content fragments that could be edited and published in their
own cadence.
Only caveat I would add is that - you standardize on markup. Then apply
styles as needed - either at site level or more granular. Site level is
easier with but more custom code need to be written if you have to make
this granular - to template/page specific.In order to standardize on
markup, I'd probably start from core components. Easier that way. If
not, start from a base front-end framework and build on it. Relatively
easier to maintain and upgrade. Also might have to think about
versioning c...
