Friday, July 17, 2015

AEM Link Checker: fixing broken links that aren't broken.

If you run into a broken-link situation in AEM that leaves you scratching your head, this is why it happens and how to fix it.

Problem: When using AEM, you may notice that it automatically checks links and will not publish a broken link. In some ways, this is great, since AEM self-monitors and corrects for issues, but when you know the link is correct and it won’t let you write it, then there’s a problem.

Here are 4 types of links that I’ve written that have thrown errors:
  1. href="tel:123-456-7890"
  2. href="*|FORWARD|*"
  3. href="http://www.facebook.com/sharer/sharer.php?u=*|URL:ARCHIVE_LINK_SHORT|*"
  4. href="http://twitter.com/intent/tweet?text=*|URL:MC_SUBJECT|*: *|URL:ARCHIVE_LINK_SHORT|*"
Each of these are valid for different reasons, but will not resolve for the link checker because it either isn't recognized as a link (#1 and #2) or it is recognized as a link but AEM can’t resolve it for some reason (#3 and 4 end with Mailchimp variables, used in email newsletter templates).

With some research into the issue, I’ve found a couple of solutions. This is assuming that the link is indeed correct, should be published, and should not be rewritten by AEM.
  1. If the link has a special prefix (ex: #1 and #2)
    • Update the “Day CQ Link Checker Service” in the Web Console Config manager.
    • Add “tel:” and “*|” to Special Link Prefixes
      • When AEM comes across a link with this prefix, it will not check or rewrite it
      • Included by default on this list: javascript:, data:, mailto:, #, <!—, ${
  2. If the link has variables that will have post-processing (#3 and #4)
    • Add  x-cq-linkchecker=“skip” to the a tag
    • When AEM comes across a link with this information, it will not check or rewrite it
    • This code is most likely to be written at a component level and very unlikely at a author level; although it could be written on any link you can edit with HTML code
Exclusions by prefix patterns and explicit skips seems to be the best solution to address links that are going to occur frequently on the site and likely to cause errors. The link checker can be also turned off at a system (global) or page (local) level.

More information about the Link Checker:

Thursday, December 19, 2013

Changing page properties


I'm attempting to add an additional field to page properties for both the web UI and the sidekick.

Web UI

Web UI page properties exist at this path:
wcm/core/content/sites/bulkproperties/items/content

If I want to add a specific field, I would want to dig deeper to the tab and column to situate the field:
wcm/core/content/sites/bulkproperties/items/content/items/tabs/items/basic/items/col1/items

I think I can duplicate some of this in my local app, but am not sure. I will have to try the sling:resourceSuperType to see if I can modify this. I don't want to modify it in the WCM since this is core information for the entire install of AEM.

I also found a way to restrict the tags, it's on this same node. Again, doing it on the WCM will affect all content on the install, so I don't want to do that here.

Editing the WCM instance does NOT add it to the page properties dialog in the sidekick.

Sidekick

The page property dialogs for the sidekick are here:
libs/foundation/components/page/dialog [cq:Dialog]
libs/foundation/components/page/tab_basic [cq:Panel]

Dialog contains items that reference the tab panels.

TRIAL: I've copied both items to my app/component/page folder and made adjustments to test the addition of a new panel to the dialog. I've removed all other parts of the dialog with the assumption that the component/dialog should be picking up the rest since the parent node "page" is has a resourceSuperType pointing to the original resource.

RESULT: Copying these two folders and essential child nodes to the app's component/page folder appears to disable the page properties feature in the sidekick.

OUTCOME: Fail.

Software development -- from a designer's perspective

I am traditionally a front-end web designer/developer, so diving head-first into AEM development is a bit of a stretch for me. I get how the HTML and CSS fit together. I get how to take apart my pages and put them back together. I know how to design a page and make it user friendly -- I don't know how to think in terms of software development though.

Hence this post. A helpful page I just found on ways to think about working with the Java Content Repository: David's Model: A guide for content modeling

In brief, seven simple rules:

  • Rule #1: Data First, Structure Later. Maybe.
  • Rule #2: Drive the content hierarchy, don't let it happen.
  • Rule #3: Workspaces are for clone(), merge() and update().
  • Rule #4: Beware of Same Name Siblings.
  • Rule #5: References considered harmful.
  • Rule #6: Files are Files are Files.
  • Rule #7: ID's are evil.

Things I'm looking for


  • Working with images
    • Accessing different versions from the DAM
    • Accessing image properties from the DAM
    • Creating modal view with image properties displayed
  • Working with tags
    • Deactivating tags
    • Categorizing tags
    • Restricting tags by project/app NOT by user
    • Treating some tags differently than others (major categories vs. supporting)
    • Adding new tags on the fly by user
  • Adjusting page properties
  • Optimizing software
    • Initial heap sizes
    • CRXDE packages
    • Adding nodes to CRXDE view
  • Links to resources
    • user-written blogs
    • forums
    • Dev Day docs

Working with tags

For this particular project, I want to create custom tags that can be used to organize my site content in AEM. I've figured out how to add new tags and I've figure out how to deactivate existing tags. However, AEM is not actually disabling these tags! I still have a lot of junk tags in the system that came with the AEM install. Instead of deleting these, I'd like to discover a way to either hide these or to restrict them to a specific area of the install.

Also, when assigning tags through the web UI, tags that are hierarchically organized get cut off. This is frustrating, as a tag like "Asset: Orientation: Horizontal" and "Asset: Orientation: Vertical" both look like "Asset: Orientation". Not good Adobe.
Need to look into restricting namespaces to specific sites, this might be the key.