If have a (reasonably 🙂) finite number of inputs producing a
(reasonably) finite number of permutations of JSON - you could also look
at using HTTP Cache [1] to cache the entire JSON output in AEM memory
and serve it from there. [1]
https://adobe-consulting-services.github.io/acs-aem-commons/features/http-cache/
Well - they are, theyre just in the wrong package (for AEM as a Cloud
Service) .. theyre in the ui.apps package.I assume you have your own
ui.content package (thats a sibling to your all pacakge)? Just add them
in there... You can copy them from
here:https://github.com/Adobe-Marketing-Cloud/asset-share-commons/tree/master/ui.apps/src/main/content/jcr_root/etc
Make a package of those from local and install on Cloud and see if it
works. I dont think that should break the functionality you said it
broken though. After packaging them up - you could also try to removing
them from SDK to see if you can reproduce the breaking behavior that
way.
SDI expects the output to be HTML.Sling Model Exporter implies the
output is JSON. What exactly are you trying to do? Are you trying to
stitch together a JSON response, where parts are static and other parts
dynamic? If that's the case SDI doesn't support this - and TBH, I'm not
sure if Apache webserver even has the ability to do SSI in JSON (im not
sure what that syntax would look like).
UPDATE: i misread this error (thought you were referencing the impl
class, but really it looks like the HTL cannot instantiate the Sling
Model via the interface reference (which is bound to that Impl). See
Arun's answer below. You are trying to access an INTERNAL class as
denoted by the "internal" package name:
com.adobe.cq.wcm.core.components.internal.models.v1.ExperienceFragmentImplClasses
under internal packages are considered internal implementation details
of the project and cannot be used ...
@Adilmo i dont recommend trying to surface anything other dam:Asset
nodes with Asset Share Commons. There is *alot* of plumbing of that
assumes results themselves as well as the "target" of results (when you
click on a result, what you're taken to) is a dam:Asset. Many, many,
many things will break if you try to adjust this paradigm - and you'll
have to rip out the guts of Asset Share Commons to get it even close to
working. This is also covered here:
https://adobe-marketing-cloud.github.io/asse...
This looks correct (though i'd probably scope the
/apps/-packages/application/install and
/apps/-packages/content/install just to align w/ common
convention. Assuming the search itself actually works, that means the
Bundle is active, etc. - which is a great sign. If search doesnt
work/page is broken - then youll need to do some more investigating. If
it's just the actions (share, download, add to cart) that arent
available - double-check that on your Search page's Page Properties that
you have t...
Have you tried using AEM Mock's AemContext to create mock sling request
context? I highly, highly recommend using AEM Mocks when possible rather
than mocking out everything yourself. These sorts of problems should go
away, and also lets you write more natural tests.
https://wcm.io/testing/aem-mock/usage.html
You can upload files via CRX Explorer on AEM Publish at
/crx/explorer/index.jsp ..make sure you login as a user w/ permissions
to create a node where you need it. You could try /miscadmin and see if
you can upload through that to /etc/designs - but that might not let you
in AEM Publish (havent been there in years!)
Unfortunately that is a (very) sub-optimal query, and very hard to
tailor a custem index for. A few major issues: * Queries on nt:base, aka
"everything"* Lots of lowercase comparisons (i doubt any indexes are
tailored for that property comparison)* LIKEs with leading wildcards
'%someterm....' To be honest, I would log an issue with Support and see
if they have recommendations and/or if they can escalate to Engineering
to provide a performant OOTB index (or tweak the underlying query to be
able t...
Can you provide more details. Are you talking about changing an Asset's
image? Or just "some image" in AEM Publish? Also, is this some
development stop-gap solution or are you looking to do this in
production? Lastly, can't you just get an AEM Author for Dev? Im shocked
youre able to perform adequate development with one.
Yes - the wcmmode code will work when you deploy it to your live site on
whatever domain. The wcmmode on AEM Publish is always "disabled". Think
of it this way, AEM uses "wcmmode = disabled" when the page should be
rendered without all the WCM (Web Content Management) bells and whistles
that are used by authors to author the content.
As mentioned in few other posts here, JS YOUR page loads will have a
window.location.href pointing to YOUR Page. If you want to look for
/editor.html you'd have to check window.top.location.href since it loads
your page in an iframe
Your use case: "My component should be visible if URL contains
editor.html and it should be hidden when editor.html is not present." So
you have a component that you want to display when the page is: * Being
Edited in Edit mode* Being Previewed in Preview mode* (Or any of the
other views provided by Page Editor).The only view you don't want this
component to display is when it's outside of the Page Editor, which
effectively means its in "Disabled" mode (youre just looking at the
rendered web pag...
Well the problem here, is /editor.html loads the AEM Page that has your
custom components via an iframe. If you try to resolve the URL
server-side, it's going to be the path to the AEM Page (since the
components/page are on the URL loaded by the iframe IN the page editor,
rather than Page Editor's URL). So, if you have a component on an AEM
Page loaded via the Page Editor (aka via its iframe), The component's
access of slingRequest.getRequestUrl() will be something like
/content/foo/bar.html and...
As noted in the other threads.. Toggling based on wccmode is indeed
preferred over the other solutions, as AEM Author's preview view should
mimic Publish as closely as possible. The wcmmode is actually extracted
via Sling Filter (which looked for in a variety of places; query param,
cookie, or default/forced values per environment type). AEM Publish has
a default, forced wcmmode of disabled, so you can always rely on Publish
resolving wcmmode to disabled.
The way to do this (especially when talking about DAM Assets, which need
to have a canonical source in AEM) is to simply put a CDN in front of
Dispatcher/AEM. If youre talking about AEM Author, you can cache
Clientlibs on the CDN, but you must expire them after ANY code
deployment. Never cache DAM Assets on AEM Author as this will result in
content mis-matches, and result in a broken experience. If youre talking
about AEM Publish, you can cache both Clientlibs and Assets on the CDN.
You would se...
TL;DR - there really isnt a magic number. I assume Android has something
similar (Im sure google can help you), but I expect it's close to what
Apple recommends:
https://developer.apple.com/design/human-interface-guidelines/ios/icons-and-images/image-size-and-resolution/https://developer.apple.com/design/human-interface-guidelines/ios/visual-design/adaptivity-and-layout/
I'd take a look at what mobile device families your targeting and then
look up the recommendations from iOS/Android and do wha...
@software_engineer Can you try again? I just tried while logging the
issue and these resolve for me. Also, FWIW, the intention is never to
remove content 🙂
Hi, unfortunately i was not able to get an ETA. An engineer did ping me
a few minutes ago asking me for details around this specific report
though, so that's positive :). Since this is effecting ExL users
directly, I expect this to have an elevated priority.
What sort of Application is this exactly? (SPA, Desktop app, mobile
app?) Either way, this certainly sounds like what other mentioned,
likely at an issue with:* CORS* Referrer Filter* CSRF Token CORS seems
like the most likely suspect. Can you log the response headers from your
app?
Are you saying: When you use a tool like Postman or CURL to hit the POST
servlet via Akamai OR AEM Publish's IP, then the Servlet works. When you
invoke the action on your Web site that invokes the POST servlet, then
you get the 204?
This is being worked on by the Experience League engineering team - if
you see similar issues in other courses, they will all be resolved
together as part of a larger fix. Thanks for reporting!
Are you saying you can reproduce the issue by hitting AEM Publish
directly via IP? Do you have multiple AEM Publish instances? Are you
sure the one you're getting Recent Requests for is the one you are
hitting?
Looks like there are too many other requests coming in with that POST.
Can you try increasing the number of requests logged as described here?
http://www.albertoalmagro.com/en/how-to-increase-aem-recent-requests/
Maybe try setting it to 50 or 100 -- just remember to turn it back to 20
after you've grabbed the logs though.
I think @BrianKasingli hit this one on the head.If youre dead set on
automating this through custom code, two approaches to look at are:
First approach, Update Activate WF Model 1. Remove replication ACLs on
the content so the Activate Workflow Model is invoked when a user tries
to Publish2. Augment this Workflow Model to include a new Custom WF
Process Step3. This Custom WF Process Step would have available to it
the path of the Asset being activated, at which point you'd have to be
able to wri...
