You can check how your request is being processed/forwarded in
/system/console/requests console. You can also check the incoming
requests in request.log, access.log and the reason for failure in
error.log. Also try enabling DEBUG logger for your custom servlet. That
may also help. Hope these help. 🙂
On the publish server, are you able to reproduce the issue, when you
bypass the dispatcher(i.e., access the publish server using its host &
port directly)?a) If not, then enable DEBUG logging for dispatcher, and
see which filter is blocking the request. You can then allow this
request to go through dispatcher. b) If it's still reproducible,
invalidate cache & rebuild clientlibs via File System, as per , clear
all browser cache & cookies, close all browser tabs & windows, open a
new one in Inc...
In addition to it, since AEM 6.4 onwards, Repository Restructuring
occurred.The following doc may be helpful in finding the correct
locations/paths of nodes in AEM
There are many clientlibs that are not just specific to authoring. They
are also related to how your content/components appear on the UI, lazy
loading of assets, etc. If you remove any clientlibs that might be
required, it would mess up your UI. You would have to replicate them
from author and even rebuilt clientlibs, if needed.Just do a thorough
testing when you perform the cleanup, such that you don't miss anything
that could lead to potential issues in the future.
@kartheekd203042 The count seems to be 0. It could be something to do
with cqPageLucene(/oak:index/cqPageLucene). Try re-indexing it and
verify whether the issue still exists. Try using OOTB cqPageLucene index
and then verify whether the issue still exists.
* Check for the existence of ensure-service-user on your AMS
environment.* Go to /system/console/configMgr, search for the service
mapping for this bundle and ensure that the service user is included
within , and then save it.Ex: I don't have acs bundle, but I have the
following mapping configured for a service
user.com.adobe.cq.cq-experience-fragments:target=[targetservice] Hope it
This issue isn't reproducible OOTB. * Do you see any Console errors in
Developer Tools of your browser?* Do you see the same issue using OOTB
admin user? If it's not related to permissions, try the following steps
as well:* Enable DEBUG log level on query class below in
/system/console/slinglogorg.apache.jackrabbit.oak.query * Reload the
your AEM environment.* You will see the logs showing some query. It
would be something like: SELECT ...
You can use the Asset Interface to achieve the same. // to create an
asset AssetManager assetManager = resolver.adaptTo(AssetManager.class);
Asset newAsset =
docs may be
You can refer to the following documents/links. These may be helpful.
You can refer to the following documents/links. These may be
The following docs may be
You can try using variables in your workflow, and then add a Process
Step to your workflow to use that information.The following docs may be
If the values are selected just on front-end, you can create a JS code
Version Purge definitely helps reduce the repository size.Versioning in
AEM occurs a bit differently for both Pages & Assets. Versioning in
You can check the repo size before and after performing the version
You can use Manage Publication or even create package of the entire site
on your instance and deploy it on other environments. The following doc
may be helpful in publishing
The following doc may be helpful in creating
The following may be helpful:*
Uninstalling SPs and CFPs is unsupported. However, if you must revert it
and do not have a backup, try this:1. Backup your AEM instance2. Package
up the /libs folder from another working environment and installing it
to the post-CFP environment. Note that you must also make sure to
package and install the ACLs from the /libs folder as well (that can be
done with the ACS Commons Query Packager).3. Allow the packages to fully
install and all bundles to restart, then restart AEM. The following
You can reach out to the person in your organization who has admin
access in the Admin Console(Org Administrator), such that they can add
you to the solution, or raise a case with Admin Console support team, if
you still run into any such issues.
Check the ACLs on that node in crx.If there's no deny ACL for the user
that you want to deny, add one(such as deny on jcr:All), and then verify
whether that user still sees the option to use custom workflow. The
following doc may be
The following documents may be helpful:1)
Try reindexing that index. It helped resolve the case for one of my
customers. They had somewhat similar scenario of migration from 6.3 to
6.5 and issues in retrieving the correct number of records using the
QueryBuilder API with their custom index.
@BrianKasingliThe UI seems fine for me. Try opening your AEM in
Incognito Window or other browser. You might be seeing weird icons due
to Chrome's caching issues. The UI is appearing fine for me on the
latest version of Chrome.
It's reproducible. Seems like a Chrome issue. Try to reload the browser
after a few seconds. You will see the package installed.Or, you can
either go back to a previous version of Chrome, or use some other
browser. Hope it helps !!
@chintan97 I was just sharing the information about 1) of your question.
You can point it to author URL. Ex: in case of Asset
Regarding 2), I haven't tested that.