adobe / aem-core-wcm-components

Standardized components to build websites with AEM.

AEM WCM Core Components

Set of standardized Web Content Management (WCM) components for Adobe Experience Manager (AEM) to speed up development time and reduce maintenance cost of your websites.

Welcome

• Contributions are welcome, read our contributing guide for more information.
• Ideas and questions are discussed on our public mailing list; you can also subscribe via email.

Documentation

• Component Library: A collection of examples to view the components in their various configurations.
• Component Documentation: For developers and authors, with details about each component.
• Get Started:
  • WKND Tutorial: A two-day tutorial for building a new site.
  • Summit Tutorial: A two-hour tutorial for building a new site (from a Lab at US Summit 2019).
  • Gems Webinar: A guided tour of the Core Components (recorded on Dec 2018).

Features

• Production-Ready: 29 robust components that are well tested, widely used, and that perform well.
• Cloud-Ready: Whether on AEM as a Cloud Service, on Adobe Managed Services, or on-premise, they just work.
• Versatile: The components represent generic concepts with which the authors can assemble nearly any layout.
• Configurable: Template-level content policies define which features the page authors are allowed to use or not.
• Trackable: The Adobe Client Data Layer and Google Data Layer integrations support the tracking of all aspects of the visitor experience.
• Accessible: They comply WCAG 2.1 standard, provide ARIA labels, and support keyboard navigation.
• SEO-Friendly: The HTML output is semantic and provides schema.org microdata annotations.
• WebApp-Ready: The streamlined JSON output allows client-side rendering, still with a possibility of in-context editing.
• Design Kit: A UI kit for Adobe XD allows designers to create wireframes that they can then style as needed.
• Themeable: The components implement the Style System, and the markup follows BEM CSS conventions.
• Customizable: Several patterns allow easy customization, from adjusting the HTML to advanced functionality reuse.
• Versioned: The versioning policy ensures we won't break your site when improving things that might impact you.
• Open Sourced: If something is not as it should, contribute your improvements!

Template Components

1. Page
2. Navigation
3. Language Navigation
4. Breadcrumb
5. Quick Search
6. Table of Contents

Page Authoring Components

6. Title
7. Text
8. Image
9. Button
10. Teaser
11. List
12. Download
13. PDF Viewer
14. Embed
15. Sharing
16. Progress Bar
17. Separator
18. Experience Fragment
19. Content Fragment
20. Content Fragment List

Container Components

21. Container
22. Carousel
23. Tabs
24. Accordion

Form Components

25. Core Form container
26. Form text field
27. Form options field
28. Form hidden field
29. Form button

Roadmap

To learn about the main upcoming components and features, visit the roadmap wiki page.

Usage

To include the Core Components in a new project, we strongly advise to use the AEM Project Archetype; this guarantees a starting point that complies to all recommended practices from Adobe.

For existing projects, take example from the AEM Project Archetype by looking at the core.wcm.components references in the main pom.xml, in all/pom.xml, and in ui.apps/pom.xml. For the rest, make sure to create Proxy Components, to load the client libraries and to allow the components on the template, as instructed in Using Core Components.

System Requirements

Core Components	AEM as a Cloud Service	AEM 6.5	Java SE	Maven
2.25.4+	Continual	6.5.21.0+	8, 11	3.3.9+

For the requirements from previous Core Component releases, see Historical System Requirements.

The Core Components require the use of editable templates and do not support Classic UI nor static templates. If needed, check out the AEM Modernization Tools.

Setup your local development environment for AEM as a Cloud Service SDK or for older versions of AEM.

Building

To compile your own version of the Core Components, you can build and install everything on your running AEM instance by issuing the following command in the top level folder of the project:

mvn clean install -PautoInstallPackage

You can also install individual packages/bundles by issuing the following command in the top-level folder of the project:

mvn clean install -PautoInstallPackage -pl <project_name(s)> -am

With AEM as a Cloud Service SDK, use the cloud profile as follows to deploy the components into /libs instead of /apps:

mvn clean install -PautoInstallPackage,cloud

Note that:

• -pl/-projects option specifies the list of projects that you want to install
• -am/-also-make option specifies the dependencies that should also be built

For detailed informations see BUILDING.md.

Configuration

The Core Components leverage both OSGi configurations and Sling context-aware configurations. For a description of defined configurations see CONFIGS.md

Known Issues

• The provided oEmbed URL Processor configuration for Facebook and Instagram is not working at the moment as a new version of the endpoint was released by Facebook and now an access token needs to be passed in the request. A possible workaround is described in #1225

aem-core-wcm-components's Issues

[v1.0.6 - Forms Container] Does not appear on page when added

When adding the Forms Container Component (v1.0,6) to a v1.0.6/page derived Page in AEM, the Container does not display, or allow other Forms components to be dragged into it.

• When viewing the resulting node structure of the page, the container resource exists.
• When i manually move form components (ex. text field) to be UNDER the container component, then the container renders on the page, and i can edit it (set its action etc.)
• However I cannot re-arrange form components IN the container, nor can i add new Form components to the now visible container component.

I assume it should work similarly to the layout container, where it will create a drop-zone within it, at which point I could add a layout container for complex layouts, or simply drag in forms components.

Image: Upper case extensions in referenced assets lead to a 404

The AdaptiveImageServlet is only registered for the lower-case extensions jpg, jpeg, gif and png. Unfortunately the extension for images which refer to a DAM asset is extracted from the asset node name (https://github.com/Adobe-Marketing-Cloud/aem-core-wcm-components/blob/master/bundles/core/src/main/java/com/adobe/cq/wcm/core/components/models/impl/v1/ImageImpl.java#L128). So in case the assets is named myimage.PNG the used image url is not correctly resolved by the AdaptiveImageServlet. The extension should rather always be generated depending on the asset's metadata (i.e. the mime type) via the MimeTypeService like it is done for locally uploaded binaries (https://github.com/Adobe-Marketing-Cloud/aem-core-wcm-components/blob/master/bundles/core/src/main/java/com/adobe/cq/wcm/core/components/models/impl/v1/ImageImpl.java#L134).

Clarify compatibility with older AEM versions in readme

Are the core-wcm-components really only compatible with AEM 6.3? What about older version. It would be good to add a dedicated section "Prerequisites" to the readme, which does not only outline the build requirements but also the runtime requirements.

Model interface evolution

How is the evolution of a Model interface handled, since the interface itself is not versioned?

For example, in v1 suppose the Title interface defines getTitle() and getType().

If in v2, there is a desire to expose a sub-title via getSubTitle(), would this be considered a new "component" and/or require a new interface?

Clearer separation between author and publish client libraries

Currently both author-only as well as author/publish client libraries are having category names which don't allow to tell on which instance they should be loaded.

Examples:

• Category core.wcm.components.page.v1.sharing (https://github.com/Adobe-Marketing-Cloud/aem-core-wcm-components/tree/master/content/src/content/jcr_root/apps/core/wcm/components/page/v1/page/clientlibs/sharing) seems relevant on publish and author.
• Category core.wcm.page.properties (https://github.com/Adobe-Marketing-Cloud/aem-core-wcm-components/tree/master/content/src/content/jcr_root/apps/core/wcm/components/page/v1/page/clientlibs/properties) seems only relevant on publish.

I think it would be good to follow the AEM naming schema that all client libraries which are only relevant for authoring (i.e. should only be loaded for WCMMode != disabled) should have a category name starting with cq. (examples in AEM are cq.wcm.edit or cq.authoring.page)

As soon as v2 of a component is created, we will run into problems with client libraries

I.e. https://github.com/Adobe-Marketing-Cloud/aem-core-wcm-components/blob/master/content/src/content/jcr_root/apps/core/wcm/components/form/button/v1/button/clientlibs/editor/.content.xml

As soon as we create v2 of this button component, it will again have a clientlib category of cq.authoring.dialog - Causing 2 client libraries to be loaded (and in this case 2 validators to be registered)

[Form] Client and server-side form validation

the core form components currently are doing validation only on the client side (e.g. checking "required" for a textfield). there is no server-side validation at all.

the forms helper logic of the AEM foundation components provide some support for server-side validation, it should be used to check the constraints the user can activate via the edit dialogs of the form components.

Document the client library categories per component

Currently a lot of Core components require client libraries (e.g. https://github.com/Adobe-Marketing-Cloud/aem-core-wcm-components/tree/master/content/src/content/jcr_root/apps/core/wcm/components/page/v1/page/clientlibs, https://github.com/Adobe-Marketing-Cloud/aem-core-wcm-components/tree/master/content/src/content/jcr_root/apps/core/wcm/components/form/container/v1/container/clientlibs, https://github.com/Adobe-Marketing-Cloud/aem-core-wcm-components/tree/master/content/src/content/jcr_root/apps/core/wcm/components/list/v1/list/clientlibs). Those categories are not mentioned in the readme for each of those component. It would be really helpful to add those, as those need to be included as well to make the component fully working. The only reference to it I could find is in https://docs.adobe.com/docs/en/aem/6-3/develop/components/core-components/using.html#Load the Core Styles, but I think it is rather reasonable to document it here at github to be able to adjust this from release to release.

How "semantic versioning guidelines" work for individual component and the whole project?

I read the doc https://docs.adobe.com/docs/en/aem/6-3/develop/components/core-components/guidelines.html#Component%20Versioning and got a question:

If the "semantic versioning guidelines" is followed, presumably the resource path should be /apps/core/wcm/components/breadcrumb/v1.0.0 instead of /apps/core/wcm/components/breadcrumb/v1? or here v1 = v1.0.0?

V1 makes me tempting to think the immediate next version would be v2 but not v1.0.1 or v1.1.0.

On the other hand, Core components project as a whole has its own evolving version, latest version is 1.0.4. I wonder if I can use "semantic versioning guidelines" to interpret its version, what should I do with my project when I see new release like 1.1.0 and 2.0.0 come out, assuming I am using 1.0.4 for my project at the moment?

My understanding is I do not need to do anything if I am happy with old versions of individual core components that are used in my project using proxy pattern. Even if I update my maven pom file to include the higher version of core component project, because I used the proxy component pattern, as long as the original versions of all the core components did not get removed, I will be fine?

When I move to read https://docs.adobe.com/docs/en/aem/6-3/develop/components/core-components/customizing.html#Upgrade%20Compatibility%20of%20Customizations. It indicate "semantic versioning guidelines" should apply to core components project version but not individual component...getting lost.

Remove usage of cq:htmlTag for the image component

Currently the image components uses a cq:htmlTag node (https://docs.adobe.com/docs/en/aem/6-3/develop/components/components-basics.html#Properties%20and%20Child%20Nodes%20of%20a%20Component) in addition to the explicit markup being rendered in the HTL script. What is the reason for that and why is the additional surrounding div necessary? The image markup would be easier to overwrite in case only the HTL would actually render the markup, can't you just add the necessary classes to the explicit divs given in the HTL script (https://github.com/Adobe-Marketing-Cloud/aem-core-wcm-components/blob/master/content/src/content/jcr_root/apps/core/wcm/components/image/v1/image/image.html)?

Some component dialogs aren't using the fixed column layout

For instance, the Image dialog [0]; whereas the Text dialog [1] uses it (seems like dialogs with tabs aren't using it).

[0] https://github.com/Adobe-Marketing-Cloud/aem-core-wcm-components/blob/master/image/src/content/jcr_root/apps/core/wcm/components/image/v1/image/_cq_dialog/.content.xml (vs

[1] https://github.com/Adobe-Marketing-Cloud/aem-core-wcm-components/blob/master/text/src/content/jcr_root/apps/core/wcm/components/text/v1/text/_cq_dialog/.content.xml#L10-L14)

Describe versioning schema for the component parts in the repository

All components below https://github.com/Adobe-Marketing-Cloud/aem-core-wcm-components/tree/master/content/src/content/jcr_root/apps/core/wcm/components have a version in their path.

Unfortunately it is nowhere documented how stable those versions are (for future upgrades). While semantic versioning is quite well documented for Java Code (namely by https://docs.oracle.com/javase/specs/jls/se7/html/jls-13.html) this is not documented for scripts or dialog definitions.
If someone now derives from those components, how stable are those? What would increase the version: Adding a new feature (backwards compatible) and new properties or just change the behaviour (non-backwards compatible). What about renaming of HTL templates?
It is also important for overriding TouchUI dialog definitions, can we rely on stable identifiers here?

Editor clientlibs categories are not versioned

The editor clientlibs categories [1] are not versioned; they are explicitly made part of cq.author.editor to be automatically pulled into the AEM authoring editors UIs.

The issue comes arises in v2, when the editor clientlibs deviates from v1; in this scenario, both clientlibs will be loaded to unknown effect.

Oddly, the image component's editor category is versioned (core.wcm.components.image.v1.editor)

content/src/content/jcr_root/apps/core/wcm/components/image/v1/image/clientlibs/editor/.content.xml

Unversioned editor clientlibs (cq.authoring.dialog)

content/src/content/jcr_root/apps/core/wcm/components/form/text/v1/text/clientlibs/editor/.content.xml
content/src/content/jcr_root/apps/core/wcm/components/form/button/v1/button/clientlibs/editor/.content.xml
content/src/content/jcr_root/apps/core/wcm/components/form/options/v1/options/clientlibs/editor/.content.xml
content/src/content/jcr_root/apps/core/wcm/components/list/v1/list/clientlibs/editor/.content.xml
content/src/content/jcr_root/apps/core/wcm/components/form/container/v1/container/clientlibs/editor/.content.xml

cq-wcm-sightly-extension dependency not available

  <dependency>
        <groupId>com.adobe.cq.sightly</groupId>
        <artifactId>cq-wcm-sightly-extension</artifactId>
        <version>1.3.4</version>
        <scope>provided</scope>
    </dependency>

In commons-testing/pom.xml can not be resolved

https://repo.adobe.com/nexus/content/repositories/public/com/adobe/cq/

The parent POM cannot be retrieved when running the build from the reactor project

The parent POM relative path should be specified for each module depending on it in order to be able to run the build process from the reactor.

Example for component change from v1 to v2, how does it impact package release version

Is there an example explains when a core component's version should change from v1 to v2, and in that case how the package version number increase?

Incorrect spelling - sortOrder node list settings options in List dialog

The node

/apps/core/wcm/components/list/v1/list/cq:dialog/content/items/tabs/items/listSettings/items/column/items/sortOreder

should be spelt

/apps/core/wcm/components/list/v1/list/cq:dialog/content/items/tabs/items/listSettings/items/column/items/sortOrder

Support picture element for the image component

Currently the image component is relying on a lot of javascript for the adaptive image rendering. At least optionally the image component should give out picture elements (https://developer.mozilla.org/en/docs/Web/HTML/Element/picture) instead. The browser support is meanwhile pretty good.

Update README.md

Hi,
first of all: Thanks for providing the aem core wcm components!
The other thing (as mentioned in the title):

<dependency>
    <groupId>com.adobe.cq</groupId>
    <artifactId>core.wcm.components.all</artifactId>
    <type>zip</type>
    <version>1.0.2</version>
    <scope>provided</scope>
</dependency>

and

<subPackage>
    <groupId>${project.groupId}</groupId>
    <artifactId>core.wcm.components.config</artifactId>
    <filter>true</filter>
</subPackage>

are not working when included in the pom.xml.
What worked for me was:

<dependency>
    <groupId>com.adobe.cq</groupId>
    <artifactId>core.wcm.components.all</artifactId>
    <type>zip</type>
    <version>1.0.4</version
</dependency>

and

<subPackage>
    <groupId>com.adobe.cq</groupId>
    <artifactId>core.wcm.components.all</artifactId>
    <filter>true</filter>
</subPackage>

Please continue with your work on this project and thanks in advance!

[Image] Image map not supported

Although the inplace editor of the image component does allow to maintain an image map (https://github.com/Adobe-Marketing-Cloud/aem-core-wcm-components/blob/master/content/src/content/jcr_root/apps/core/wcm/components/image/v1/image/_cq_editConfig.xml#L69) this is not considered during rendering. I.e. the HTL script does not include any logic to include an image map (i.e. usemap attribute or map elements).

Explain how list item renditions can be added

The old foundation list component had the option of configuring list item renditions ("displayAs"-property).

The core list component doesn't have that option, so I assume this is something that needs to be added by a developer. It would however be good to document the best practices around implementing this feature.

I can imagine overwriting the "item.html" and putting in some logic to render the list items differently according to a dialog setting, or even according to the list item (Page) that is rendered.

AdaptiveImageServlet uses web rendition in case of a fileReference - it should (at least in some cases) use the original

https://github.com/Adobe-Marketing-Cloud/aem-core-wcm-components/blob/da012e690e33d33051df268233eb92f5d0e11423/bundles/core/src/main/java/com/adobe/cq/wcm/core/components/internal/servlets/AdaptiveImageServlet.java

This servlet uses the web rendition (usually 1280x1280) as the source for the resized image.

This is not correct, as it can happen that we need an image wider than 1280px.
This was also a very annoying problem with the ootb adaptive image component in foundation.

Solution:
Use the original image

The original image can be very large in size though.
A consideration could be to use the original only if an image with a width larger than 1280 is requested. However, you will notice the quality of the 1280 image requested through this servlet is a lot worse than the 1281 image.

Major package version increase of model API packages in 1.0.5-SNAPSHOT

In the master branch / 1.0.5-SNAPSHOT the major part of the package versions of the two API packages

com.adobe.cq.wcm.core.components.models
com.adobe.cq.wcm.core.components.models.form

breaking backward compatibility when deploying this new version to an instances with code compiled against 1.0.4. this is e.g. the case with AEM 6.3 and the included we.retail sample content - once 1.0.5-SNAPSHOT is deployed the bundle com.adobe.cq.sample.we.retail.core is stopped because it depends on com.adobe.cq.wcm.core.components.models.form v13.0.

was this done by intention? keep in mind that the interface are not only used by sightly templates, but by java code from other OSGi bundles as well. is it planned to publish multiple OSGi bundles with the latest and older implementations of the API packages which can be deployed in parallel?

Text: The IPE config for paraformat is invalid

Although the text component's editConfig has some rteplugins configured, e.g. "paraformat" in https://github.com/Adobe-Marketing-Cloud/aem-core-wcm-components/blob/master/content/src/content/jcr_root/apps/core/wcm/components/text/v1/text/_cq_editConfig.xml#L20, this option is not provided in the according in-place editors toolbar. See also this scren

Empty placeholder should display component's title

The empty template of components shouldn't hard-code the text to display, but use the component's jcr:title property instead.

Otherwise, if multiple components extend that component, they all display the same placeholder text:

For e.g. this is where the "List" placeholder text is hardcoded:
https://github.com/Adobe-Marketing-Cloud/aem-core-wcm-components/blob/master/list/src/content/jcr_root/apps/core/wcm/components/list/v1/list/templates/emptylist.html#L17

Image: Include a last modification date even in publish image urls

To allow to set a very long TTL for image urls it would be beneficial if at least optionally the publish URL (https://github.com/Adobe-Marketing-Cloud/aem-core-wcm-components/tree/master/content/src/content/jcr_root/apps/core/wcm/components/image/v1/image#url-formats) includes a last modification date of the component's node as well (similar to what we have on the author already). That way it is assured that the URL changes whenever the image changes (which will automatically invalidate the cache entry)

Explain how we should proxy the vX components

I checked the Wiki section and it's empty.

How should we proxy these v1 v2 v3 components? I believe we should not use the versioned components directly.

Also, what happens if v1 exists and v2 introduces new changes in the clientlibs and v3 too?

Image component displays title only if isDisplayTitlePopup is false

https://github.com/Adobe-Marketing-Cloud/aem-core-wcm-components/blob/master/content/src/content/jcr_root/apps/core/wcm/components/image/v1/image/image.html

<span class="cmp-image--title" data-sly-test="${!image.displayPopupTitle && image.title}">${image.title}</span>

This should obviously be:

<span class="cmp-image--title" data-sly-test="${image.displayPopupTitle && image.title}">${image.title}</span>

Unit testing classes are not available in jar

Couple of java class files from unit testing src/test/java are not available, few of them are from
com.adobe.cq.wcm.core.components.context
Can't use classes from this package, they may not be available at adobe repo as well its not included in jar file as well

Core component dialogs should use new FileUpload resourceType

A new resourceType has been introduced to present a Coral3-ready version of the dialog FileUpload. That is, in place of the previous Granite.FileUploadField clientlib that modified a granite/ui/components/foundation/form/fileupload. The new resourceType is cq/gui/components/authoring/dialog/fileupload

Release 1.0.6

There is quite a lot of fixes applied since 1.0.4. Would it be possible to have a release there?

Don't use SLF4J logger together with String.format

Since SLF4J comes with support for parameterized messages (https://www.slf4j.org/apidocs/index.html). That should be used rather than String.format(...).
Some wrong usages of String.format(...) can be seen in https://github.com/Adobe-Marketing-Cloud/aem-core-wcm-components/blob/master/bundles/core/src/main/java/com/adobe/cq/wcm/core/components/internal/servlets/AdaptiveImageServlet.java#L203, https://github.com/Adobe-Marketing-Cloud/aem-core-wcm-components/blob/master/bundles/core/src/main/java/com/adobe/cq/wcm/core/components/internal/servlets/AdaptiveImageServlet.java#L209,
https://github.com/Adobe-Marketing-Cloud/aem-core-wcm-components/blob/master/bundles/core/src/main/java/com/adobe/cq/wcm/core/components/internal/servlets/AdaptiveImageServlet.java#L418 and https://github.com/Adobe-Marketing-Cloud/aem-core-wcm-components/blob/4de23b51987cedf509f3b7e161756f6edcf9f23e/bundles/core/src/main/java/com/adobe/cq/wcm/core/components/models/impl/v1/ImageImpl.java#L245.

/apps/core/wcm/components/page points to the wrong super type

The /apps/core/wcm/components/page component points to the wrong supertype:

<?xml version="1.0" encoding="UTF-8"?>
<jcr:root xmlns:sling="http://sling.apache.org/jcr/sling/1.0" xmlns:cq="http://www.day.com/jcr/cq/1.0" xmlns:jcr="http://www.jcp.org/jcr/1.0"
    jcr:description="Core WCM Text Component - Sightly"
    jcr:primaryType="cq:Component"
    jcr:title="Core WCM Text Component"
    sling:resourceSuperType="core/wcm/components/text/v1/text"
    allowedParents="[*/parsys]"
    designDialogPath="core/wcm/components/page/v1/page/cq:design_dialog"
    componentGroup="Core"/>

The correct super type should be sling:resourceSuperType="core/wcm/components/page/v1/page".

Form components are hidden

I see these form components are under group .core-wcm-form , they are not available for drag and drop options. It may be meant for drag and drop options.

Image: NPE in case an asset was referenced not having a dot in its name

In case an asset is referenced in an image component whose name does not contain a dot, this leads to an NPE

...
Caused by: org.apache.sling.models.factory.PostConstructException: Post-construct method has thrown an exception for model class com.adobe.cq.wcm.core.components.models.impl.v1.ImageImpl
	at org.apache.sling.models.impl.ModelAdapterFactory.createObject(ModelAdapterFactory.java:609)
	at org.apache.sling.models.impl.ModelAdapterFactory.internalCreateModel(ModelAdapterFactory.java:335)
	at org.apache.sling.models.impl.ModelAdapterFactory.createModel(ModelAdapterFactory.java:223)
	at org.apache.sling.scripting.sightly.models.impl.SlingModelsUseProvider.provide(SlingModelsUseProvider.java:126)
	at org.apache.sling.scripting.sightly.impl.engine.extension.use.UseRuntimeExtension.call(UseRuntimeExtension.java:72)
	... 115 common frames omitted
Caused by: java.lang.NullPointerException: null
	at com.adobe.cq.wcm.core.components.models.impl.v1.ImageImpl.initModel(ImageImpl.java:148)
	at sun.reflect.GeneratedMethodAccessor129.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:498)
	at org.apache.sling.models.impl.ModelAdapterFactory.invokePostConstruct(ModelAdapterFactory.java:792)
	at org.apache.sling.models.impl.ModelAdapterFactory.createObject(ModelAdapterFactory.java:607)
	... 119 common frames omitted

The reason is the extension always being extracted from the asset's node name (https://github.com/Adobe-Marketing-Cloud/aem-core-wcm-components/blob/master/bundles/core/src/main/java/com/adobe/cq/wcm/core/components/models/impl/v1/ImageImpl.java#L128). See also the related ticket #38. The recommended fix here is similar: Always derive the extension from the mime type!

[Form] Form show/hide capability

It is common requirement to be able to show/hide a form field on the basis of values of other fields (e.g. showing a textbox to input email id if send email checkbox is selected). This feature is present in WCM form foundation components (/libs/foundation/components/form). However, it is missing from core components version (/apps/core/wcm/components/form).
It would be a really nice feature for core form components, as there could be more customers looking to upgrade from old form foundation components (non Touch-UI based).

Support version diffing

Currently all new component don't support the version diffing being described in https://docs.adobe.com/docs/en/aem/6-2/author/page-authoring/working-with-page-versions.html#Comparing%20with%20a%20Previous%20Version%20-%20Touch%20UI. Are there any plans on supporting that feature which is in my opinion pretty crucial for bigger sites (e.g. for doing reviews).

Image: Document under which circumstances which image URL is requested from the server

Obviously the image components supports different server-side generated renditions of the same image. It is not clear to me though from the documentation when which size is being requested from the client.
I tried to resize my browser window below one of the allowed width and still the image is requested with the selector for the largest allowed width, so there must be some other criteria which determine which rendition is requested (except for the width of the browser window). Please outline which criteria that is (and how to influence that, if possible).

Document the URL format for the image component

The Image Component allows the clients to dynamically request the width of the image, depending on the container width, by relying on a URL format that contains selectors.

This information should be documented so that efficient dispatcher rules can be configured for the component.

Document javascript logic and necessary markup for the image component

As the image component relies on some javascript to dynamically modify the DOM (to request the most appropriate image renditions) the necessary markup attributes for this javascript logic should be documented. This is especially important as otherwise extending from this component may easily lead to wrongly placed markup (compare with #30 (comment))

The image component should allow only raster images

Although the drop configuration allows SVG mime types (https://github.com/Adobe-Marketing-Cloud/aem-core-wcm-components/blob/master/content/src/content/jcr_root/apps/core/wcm/components/image/v1/image/_cq_editConfig.xml#L7) the according servlet cannot deal with vector images. Also the markup is not appropriate for SVGs.
Please disable dropping/selecting vector images. For that you need to adjust the droppingConfiguration as well as the mime types in the upload component (https://github.com/Adobe-Marketing-Cloud/aem-core-wcm-components/blob/master/content/src/content/jcr_root/apps/core/wcm/components/image/v1/image/_cq_dialog/.content.xml#L29)

Image: Cropping does not work for images having a width smaller than 1280

AEM by default creates a web rendition named cq5dam.web.1280.1280.jpeg. This rendition only has a width of 1280 pixels if the original was at least 1280 pixels wide as well (because for the web rendition it will never upscale). For smaller assets the web rendition has also a smaller width (but still the rendition node name stays the same).

The AdaptiveImageServlet incorrectly assumes that the web rendition always has a width which can be extracted from its rendition name (https://github.com/Adobe-Marketing-Cloud/aem-core-wcm-components/blob/master/bundles/core/src/main/java/com/adobe/cq/wcm/core/components/internal/servlets/AdaptiveImageServlet.java#L244) and takes that as scaling factor for the cropping.

This does in general not work for assets having a web rendition which is smaller than 1280 pixels (because the original is smaller than 1280 pixels), because even for those the a scaling factor is assumed as if the web rendition would be 1280 pixels wide.

That leads to an incorrectly calculated scaling factor (https://github.com/Adobe-Marketing-Cloud/aem-core-wcm-components/blob/master/bundles/core/src/main/java/com/adobe/cq/wcm/core/components/internal/servlets/AdaptiveImageServlet.java#L256) which in turn may lead to exceptions like the following

21.06.2017 08:07:39.843 *ERROR* [0:0:0:0:0:0:0:1 [1498025259838] GET /content/we-retail/language-masters/de/jcr%3acontent/root/responsivegrid/image_1943936200.img.1500.png/1498025259784.png HTTP/1.1] com.day.cq.wcm.core.impl.WCMDebugFilter Exception: (x + width) is outside of Raster
java.awt.image.RasterFormatException: (x + width) is outside of Raster
	at sun.awt.image.ByteInterleavedRaster.createWritableChild(ByteInterleavedRaster.java:1245)
	at java.awt.image.BufferedImage.getSubimage(BufferedImage.java:1202)
	at com.day.image.Layer.crop(Layer.java:1569)
	at com.adobe.cq.wcm.core.components.internal.servlets.AdaptiveImageServlet.resizeAndStream(AdaptiveImageServlet.java:263)
	at com.adobe.cq.wcm.core.components.internal.servlets.AdaptiveImageServlet.doGet(AdaptiveImageServlet.java:145)
	at org.apache.sling.api.servlets.SlingSafeMethodsServlet.mayService(SlingSafeMethodsServlet.java:270)
	at org.apache.sling.api.servlets.SlingSafeMethodsServlet.service(SlingSafeMethodsServlet.java:346)
	at org.apache.sling.api.servlets.SlingSafeMethodsServlet.service(SlingSafeMethodsServlet.java:378)
	at org.apache.sling.engine.impl.request.RequestData.service(RequestData.java:552)
...

Need an imagetext core component

I used the WCM Foundation imagetext component instead, but would like to have used a Core equivalent.

Deploy released artifacts to Maven Central and/or https://repo.adobe.com

It would be very handy to have those artifacts not only downloadable as GitHub release but also from Maven Central and/or from the Adobe Maven Repository.

Page thumbnail upload image not working

Page thumbnail upload image from page properties is not working. nothing happens after clicking on "Upload Image" and selecting an image. no indication of any error in browser console and it seems no upload request is being made to AEM.

reverting to v1.0.4 fixes this issue.

Smart Image : Multiple calls in Firefox and IE

In smartimage there seems to be 2 image requests going - first call for image without rendition and the second call for image with viewport specific rendition. First call does not get any response status and Response size is 0B while the second call gets a response status as 200 and response size is as expected. This issue is seen in IE and Firefox.

Url of first call - /content/project/us/en/pages/_jcr_content/root/my_page/par/responsivegrid/image_1.img.jpg

Url of second call - /content/project/us/en/pages/jcr%3acontent/root/my_page/par/responsivegrid/image_1.img.1200.jpg

Provide option to display image captions from the Content Policy configuration

Image: in case we always want to display the title (caption) below the image, we always have to manually enable that in the dialog.

https://github.com/Adobe-Marketing-Cloud/aem-core-wcm-components/blob/master/content/src/content/jcr_root/apps/core/wcm/components/image/v1/image/image.html

It could as well be an option in the design dialog, so we can in 1 place for the entire design enable display of the caption, without having to check the checkbox over and over again.

Potential unclosed resources in AdaptiveImageServlet

https://github.com/Adobe-Marketing-Cloud/aem-core-wcm-components/blob/da012e690e33d33051df268233eb92f5d0e11423/bundles/core/src/main/java/com/adobe/cq/wcm/core/components/internal/servlets/AdaptiveImageServlet.java

Several times IOUtils.closeQuietly() is used outside a finally block, so it could be possible that inputstreams are not closed.

[List] Allow custom sources, sort orders and filters to be defined

https://github.com/Adobe-Marketing-Cloud/aem-core-wcm-components/blob/be656c09ea43ea80b37e0727399aa48de3e43c8a/bundles/core/src/main/java/com/adobe/cq/wcm/core/components/models/impl/v1/ListImpl.java

As you can see, the options are now hardcoded. In most cases you will definitely want to reuse the existing options, you will probably only want to add a few more sources. And probably also a few more ways of sorting the list.

I think we can easily facilitate this with the OSGi framework - They can be separate components that are gathered and used by the List-component.

Broken link to the Package Manager documentation

The current link to the Package Manager documentation is broken due to the applied Markdown formatting - see #12.