Request for Feature Enhancement (RFE) Summary: There is an OOTB function CQ.I18n.getDictionary() to get translations, but it always gets the whole dictionary to the UI, which puts much load on the visitor's browser. This reuest is to provide a function that retrieves only the requested translations. E.g. it could accept key name(s) and language name as parameters. Use-case: Use localized strings in custom JS code on user-facing pages. Current/Experienced Behavior: Improved/Expected Behavior: Environment Details (AEM version/service pack, any other specifics if applicable): AEM 6.5 with SP8 Customer-name/Organization name: Veeam Software Screenshot (if applicable): Code package (if applicable):
Request for Feature Enhancement (RFE) Summary: Rollout and publish the rolledout pages. Use-case: A feature in the OOB toolbox that will enable the authors to rollout a page. As a summary of the rollout we need to display which are all the pages that are affected along with a publish button by the side of the list. Rightnow, the author is unaware of what are the pages that affected by the rollout. Publishing each page after the rollout is very difficult. Current/Experienced Behavior: we dont have an option in the sites.html to rollout a page. Improved/Expected Behavior: We need to check if the page is a blueprint or not and conditionally display a button that says "rollout and publish". Once rollout operation is completed the author should be able o see a list of pages affected by the rollout and need a publish button so that the rolledout pages can be published without hastle. Environment Details (AEM version/service pack, any other specifics if applicable): Customer-name/Organization name: Abinaya/Perficient Screenshot (if applicable): Code package (if applicable):
Request for Feature Enhancement (RFE) Summary: Component specific client-library in ui.frontend project and better dependency management for client libraries. Use-case: 1. Currently, all the code written in ui.frontend will be bundled as 2 client libraries i.e: clientlib-site and vendors. These client libraries will be loaded in all pages. There is no way to selectively load only certain components OOTB. This leads to sub-optimal lighthouse scores because unused CSS and JS code on page. Hence, there has to be modularity in the clientlibs generated from ui.frontend project. This can be achieved through proper webpack configurations 2. Currently there are two ways to load client libraries i) At template level: This is recommended because it ensures all CSS wil be loaded at the top (in head) and all JS will be loaded at the bottom. But this gives rise to unused JS and CSS code on page as there is no option to include only those clientlibs which is needed on a particular page. ii) At component level: This ensures that only required CSS/JS will be loaded. If a particular component is not loaded, corresponding CSS/JS will not load. But, with this approach render blocking CSS and JS code is loaded in body tag which is not recommended. Hence there needs to be an approach to fix both of this performance issues. If there can be a way to dynamically load client libs (and its dependencies) based on components present on page, this will highly improve page performance. Current/Experienced Behavior: All ui.frontend code is bundled into 1 single clientlib and is loaded on all pages Single vendor client contains many dependencies which may not be required in all pages Loading clientlibs at template level causes unused JS/CSS to be present on pages. If loaded at component level it causes render blocking calls hampering the performance. Improved/Expected Behavior: ui.frontend should have modular structure and there should be component specific client libs. Vendor clientlib should be generate dynamically to include only necessary dependencies Ability to load only required clientlibs on page at component level. Also these clientlibs need to be loaded in 1 single request. Environment Details (AEM version/service pack, any other specifics if applicable): AEM 6.5.x Customer-name/Organization name: Mindtree Screenshot (if applicable): Explanation: Without optimization: Clientlibs loaded at component level. With optimization: I have used an interceptor to group all CSS in head section and all JS to the bottom of the body tag. Code package (if applicable):
The only class that is specific to the field type is on the input element itself, but I want to style the LABELS of the inputs differently depending on the type. I could probably even manage if I could switch the label in the DOM to come AFTER the input using input[type=...] ~ label... but you know what would be easier??... including a class on the wrapper... PLEASE!! e.g. <div class="mktoFieldWrap MKTO-FIELD-SELECT"> ← ADD A NEW CLASS HERE!!! <label for="foo" id="Lblfoo" class="mktoLabel mktoHasWidth" style="width: 100px;"> Select one:</label> <div class="mktoGutter mktoHasWidth" style="width: 10px;"></div> <select id="foo" name="bar" aria-labelledby="Lblfoo" class="mktoField mktoHasWidth mktoValid" style="width: 150px;" aria-invalid="false"> <option value="">Select...</option> <option value="foo">Foo</option> <option value="bar">Bar</option> </select> <span id="foo" tabindex="-1" class="mktoInstruction"></span> <div class="mktoClear"></div> </div>
I'm struggling with getting some of my users to use the Work List. I've run into a number of situations where users weren't aware they had any tasks to work on because they didn't specifically have Tasks AND Ready to Start selected.In an example scenario, when Approvals (1), Working On (4), and Ready to Start (4) are checked, only the Approval displays. I was told this is because Tasks would also need to be selected. What I would like to see, and what would be helpful for our users, would be if the filters are arranged into subgroups vs a seemingly random order, for instance:Approvals (8)Tasks (32)Ready to Start (16)Working On (4)Not Ready (4)Complete (8)Requests (12)Ready to Start (1)Working On (4)Not Ready (4)Complete (3)Personal (3)Ready to Start (1)Working On (0)Not Ready (0)Complete (2)
Looking to see if a indicator can be added as the first column to a rule to show what kind of "Event Type" the rule has. Something on the lines of what Adobe Target currently offers for their different types of activity.Additionally if a filter can also be created to narrow down all page load rules, DCRs etc besides the existing ones (Status:Enabled / Disabled), that would be great.
If you start typing in a cell within a report and then navigate to a different webpage without clicking somewhere blank on the screen, you will lose that information. If the webpage had an autosave function which admins could turn on and off, this would mitigate this issue.
It's great that we now have the option to add/remove the Documents upload section on requests but it would be nice if it were down on the Queue Topic level, rather than the entire Queue level. There are some topics that we really don't need the Document Upload section cluttering up, but it is useful for other topics within the same larger Queue project.
An easy way to upload word and excel documents as a proof and make the changes live and then execute all the changes in the word document.Adding annotation to an online proof, then require someone to go an make these comments onto the actual word document - it's an inefficient use of resources when the changes will be accepted.Ideally it would allow to track the changes and then an option to apply the changes onto the actual file.
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.