Webinar: Increase Online Sales with Persuasive Content through Magnolia CMS’ Shop Module

I will be moderating a Magnolia CMS webinar for the Open Source Magnolia Shop Module developed by fastforward and maintained by fastforward and magnolia. You can see a fully JCR based shop solution in action – join us for this great event!

Thursday, April 25, 2013
5:00 PM – 6:00 PM CET (11:00 to Noon, EDT)

register here >

---

Creating unique online storefronts that are secure, integrated with back-office inventory and catalog management and also easy for customers to use, is a challenge for any e-commerce integrator. The Magnolia CMS Shop module is a toolkit that adds e-commerce functionality to Magnolia CMS and makes it possible to enhance shop pages with compelling content that attracts new customers and increases sales.

Some of the key benefits of this integration include:

• Products, product categories, prices and currencies are managed in Magnolia CMS’ AdminCentral.
• All data is stored in the Data module except shopping carts in their own workspace.
• Developers can get started quickly by using the default website structure containing shop, product detail and shopping cart pages.

On 25 April 2013, Ulrich Scheidegger, co-founder and managing director of fastforward websolutions and one of the developers of the Magnolia CMS Shop module, will present a webinar on creating Magnolia CMS-powered e-commerce websites without needing to add or run other shop software. This webinar will demonstrate how to build unique, branded online storefronts that are tightly integrated with Magnolia CMS’ intuitive editing and administration tools.

The webinar will be moderated by Ruben Reusser, CTO at headwire and expert in KonaKart e-commerce integrations. This webinar is extremely useful for Java and CMS developers of all levels, as well as IT professionals and system integrators interested in e-commerce solutions.

Device Detection Problems in AEM5.6 on Windows 8

When exploring AEMs default website geometrixx or geometrixx-media with a Windows8 device that has a touch screen (some of the newer laptops on the market for example)  you are either forwarded to a .tablet.html page (geometrixx) or the mobile site (geometrixx-outdoors). This seems to be a problem with the device detection that is part of AEM5.6. A tool called BrowserMap is used to perform a client slide test to determine your type of device and then you are redirected based on your device and a set of settings on the site.

The documentation from Adobe on how to set up your site for device detection can be found here

To see what AEM thinks your device is, you can go to http://localhost:4502/etc/mobile/browsermap/detect.html – with a Windows 8 Laptop with touch screen and Chrome you will get something like this as the output:

As you can see, the detection thinks the browser is running on a tablet.

Looking at the /content/geometrixx/jcr:content/cq:siteVariant node and the /content/geometrixx_mobile/jcr:content/cq:siteVariant node they both have a cq:variantFamily property with the value ‘geometrixx’. For the main website the media property is set to ‘browser, oldBrowser, highResolutionDisplay’, for the _mobile site to ‘smartphone, tablet, highResolutionDisplay’ – for whatever reason, this is not a String Array property but just a comma separated list and the node type is nt:unstructured – cq:siteVariant is the actual name that the browser detection is looking for.

What’s interesting to me is that on geometrixx, a selector called tablet is added and the browser stays on the same page while the setup in geometrixx-outdoors seems to be the same but there the browser is redirected to the mobile version of the site.

You can force AEM to use a specific device and bypass the BrowserMap detection by adding the parameter device=[device group name] to the URL. The supported device groups by default are:

• smartphone
• tablet
• highResolutionDisplay
• browser
• oldBrowser (the latest version of Firefox is considered an oldBrowser)

The BrowserMap library is available on github at https://github.com/raducotescu/browsermap. The testpage that’s available within AEM is also available online at http://raducotescu.github.com/browsermap/index.html – the library in AEM seems to be a bit more up to date since it can detect IE10 on Windows 8 (although it thinks that it does not have touch capabilities) – the one on github just reports it does not know the browser.

On the bright side, geometrixx-media does not need the browser detection since it’s a responsive design based website. I highly recommend going that route.

Adobe CQ (AEM) Debug Filter

As outlined in the security doc for AEM, you should turn off the debug filter on your production instances. When searching the docs, however, I had a hard time actually finding the options for the debug filter.

There is a class called DebugFlag that enumerates all the options for this filter:

http://dev.day.com/docs/en/cq/current/javadoc/com/day/cq/wcm/api/DebugFlag.html

the 3 values supported are layout, mdev and mdevc – layout outputs information about every cq:include on the page (path, selector, resource, component), mdev and mdevc output what mobile device AEM thinks the browser is. If you add debug=mdev to the page, the output is right there on the screen, if you use mdevc, the output is a html comment.