Product ideas | Community
Skip to main content

10000 Ideas

lutzUNew Participant

External Link Checker UI: improve UI and provide downloadInvestigating

Request for Feature Enhancement (RFE) Summary: Enhance External Link Checker page Use-case: As en editor I want know about broken external on my website which I'm responsible for and want to fix the links efficiently. Current/Experienced Behavior: Under /etc/linkchecker.html you get a list which but you can not export it to a csv. Imaging you have a lot of editors working on AEM instance each responsible for different subtrees reflecting different business groups. Now it is hard to figure out the error for specific paths in order to fix this. It is even harder if error occurs not just on a single page but in blueprint page and the connected livecopy pages (imagine 20 livecopies) - here the column get's flooded (just very long comma separated list) and hard to retrieve the information out of that.   Link to documentation: https://experienceleague.adobe.com/docs/experience-manager-65/content/sites/administering/operations/external-link-checker.html?lang=en#external-link-checker Improved/Expected Behavior: Enhance the existing overview with option to export: with the exported list you could filter for paths in the referrer column and assign the list to responsible editors. Maybe a filtering directly in the UI regarding the referrer column would be even better, to see just the paths of /content which I'm responsible for not the ones of whole instance and to export this filtered view. It would be even better if I would informed about broken external links via email providing all the necessary information, meaning path to page and the external link which is not working there. Environment Details (AEM version/service pack, any other specifics if applicable):   Customer-name/Organization name: Carl Zeiss AG Screenshot (if applicable):   Code package (if applicable):  

JamesAp1New Participant

Add jcr:created to ntBaseLucene index or change DAM interface to use better indexInvestigating

Request for Feature Enhancement (RFE) Summary: Our system has some DAM folders with more than 1000 PDFs in a single folder.  We are encountering an index error when using the default Assets interface. Use-case: This should occur in an AEM system with no custom code, provided that some DAM folders have huge numbers of assets in them. The user opens Assets and traverses the system using various views. Some folders may fail to open in certain views. Current/Experienced Behavior: This appears in the log: *WARN* [10.240.32.86 [1693910873433] GET /mnt/overlay/granite/ui/content/tree.0.html/content/dam/document-library/corporate-pensions HTTP/1.1] org.apache.jackrabbit.oak.plugins.index.Cursors$TraversingCursor Traversed 1000 nodes with filter Filter(query=select [jcr:path], [jcr:score], * from [nt:base] as a where ischildnode(a, '/content/dam/document-library/corporate-pensions') order by [jcr:created] desc /* xpath: /jcr:root/content/dam/document-library/corporate-pensions/* order by @6655266:created descending */, path=/content/dam/document-library/corporate-pensions/*); consider creating an index or changing the query   Subsequent investigation showed the most common places this query was coming from is:/mnt/overlay/granite/ui/content/tree.0.html (117 in 4 hours)/assets.html (97 in 4 hours) Improved/Expected Behavior: Currently the system seems to pick the ntBaseLucene query, which doesn't have the jcr:created in the index.  Either that index should be changed, or the system should use the ntFolder index, which does have that. Environment Details (AEM version/service pack, any other specifics if applicable): AEM 6.5 SP17 Customer-name/Organization name: Not disclosed Screenshot (if applicable): N/A Code package (if applicable): N/A

cvergesNew Participant

dateDifference function behavior around Daylight Savings Time and Standard Time transitions (an idea and a warning)New

The dateDifference(t1; t2; unit) function in Fusion allows you to compute the number of hours/days/etc. between two timestamps (t1 and t2) provided.  This behaves oddly whenever the number of hours in a day isn't exactly 24, which happens twice a year when crazy countries/localities switch between Daylight Savings Time and Standard Time.Example: On March 10, 2024, at 2am, the clocks "jump" forward to 3am.  That is, there technically is no 2:00am to 2:59am on March 10.  This results in March 10 having only 23 hours in the day.  (The same thing happens on November 3, except we actually repeat 2:00am to 2:59am, resulting in 25 hours in the day.)This website has more information that corroborates: https://www.ge.com/digital/documentation/csense/version2023/Blocks/Daylight_Saving_Time.htm#:~:text=In%20spring%3A%20if%20a%20one,the%20day%20to%2025%20hours.If you're trying to use something like dateDifference(t1; t2; days) and expect something like 2024-03-09T00:00:00 to 2024-03-11T00:00:00 (both in America/Los_Angeles time zone) to return a value of "2", it will instead return a value of "1".  This occurs because dateDifference is computing a delta of 47 hours, which is less than 48 ("2 days" as per how dateDifference is written).  When dateDifference divides 47 by 48, it results in 1.979... which is then truncated to just "1".Note that this appears unique and different than any other programming language that has similar functions.  You can test this using a Java online compiler such as https://www.programiz.com/java-programming/online-compiler/ and the code below: import java.time.ZoneId; import java.time.ZonedDateTime; import java.time.temporal.ChronoUnit; class HelloWorld { public static void main(String[] args) { final ZoneId timeZone = ZoneId.of("America/Los_Angeles"); final ZonedDateTime start = ZonedDateTime.of(2024, 3, 9, 0, 0, 0, 0, timeZone); final ZonedDateTime end = ZonedDateTime.of(2024, 3, 11, 0, 0, 0, 0, timeZone); System.out.println(ChronoUnit.DAYS.between(start, end)); } } Java is appropriately handling the fact that the length of a "day" is actually variable and thinking more in terms of "midnight to midnight" rather than "how many 24 hour periods exist".It is possible to workaround this using by casting every date to UTC, but this is super cumbersome, as shown by this Fusion example: The awareness required around this renders dateDifference as a dangerous function to use without advanced Computer Science knowledge.  For example, the help text (shown below) is fairly simple with no warnings around this, nor are the online docs (below) hinting to the need to use UTC -- though they do only show "Z" (UTC) in the examples, which is perhaps too subtle of a thing.Ideally, dateDifference should internally cast to UTC if that's what's required to bring in line with the semantic notion of "hours" or "days" or other units.  For dates that are already in UTC, this would be a "no-op" and things would work fine.  For non-UTC dates, it would make things more intuitive.While a support ticket was filed on this, they redirected to submit an Idea via the forum here, saying that the current implementation of dateDifference meets the desired behavior and indicated that it would likely only get actioned if it received enough upvotes.  So take this as both a warning in use of the function with its current behavior and an idea ask for the community to vote on.  Hope this helps someone either way!