CQ Stats Broken: Careful with that Extension Eugene

CQ Stats Broken: Careful with that Extension Eugene

Before I get into the details of the problem I want to discuss, I am going to give you my personal thoughts and opinion on what I think the current state of some of the "original" CQ tracking features are.  I also want to give a plug for CQ and Adobe's approach to CQ.  I am appreciative of both.

I was the Technical Lead for the second rewrite (why do it once, when you can do it twice) of the Corporate website of the company that employed me.  I am still amazed at the progress we made: 4k-5k pages, digital assets, EVERYTHING rewritten, cool features written, migrated, tested, debugged, published and soft launched in a mere 12 weeks, 8 weeks EARLY.  As much as it is a testament to our technical abilities (and long days - I slept under my desk one night - which is another story altogether), I have to admit a portion of this success stems from the logical architecture of CQ, the ease of extending OOTB components, creation of Services, and customizing just about anything.  A stark contrast the the Frankenstein mish-mash of CRX as storage and Vignette Portal as the front end, or WORSE  VAP/VCM.  Six letters I hope to never have to speak aloud again.

How many developers?  Two "back end" developers, one of which was on vacation in Asia for a month or more, 2 front end developers, and one CSS guru.  We released on CQ 5.4, and I had barely had my hands on CQ 5.3 a month before we started coding.  I can tell you CQ 4.2 is more similar to VAP than it is CQ 5.3.  The whole Apache Sling thing was something to wrap my mind around.  I believe my initial difficulty stemmed from the simplicity and logical structure of Sling.  I guess I kept expecting it to be more convoluted like the other frameworks I had worked with.

Next, we had started looking into some of the OOTB tracking features, and having released way early.  We were thinking of trying to implement some of them in a soon to come "upgrade" to our new release.

One month later in July, I'm standing in my parents back yard in Wilton Maine on summer vacation, and my boss Hans calls.  "Hey Mike, did you see that Adobe just purchased Day?"  I just about you know what a brick.  I sat down on the small grassy hill that was our back yard, panicked that Adobe would shelf CQ like I had seen happen to other great products.  Well, as you all know, the exact OPPOSITE happened.  Adobe made it central to just about everything they are doing.  Thank God.  But I digress.

When I got back from vacation, my boss and I had conversations about Adobe's other recent purchase:  Omniture - website Analytics.  The immediate question was - WHY would you use the OOTB stuff, when hopefully the really good Analytics would eventually get baked in.  This is my opinion, and I can imagine being a developer working on some of those tracking features, asking myself WHY would I bother writing a tracking feature when as part of the company that bought us out, we now have a mature tracking product.  Personally, I would stop.  I suspect that something akin to that happened.  Really, why would you bother when your company now has a more mature, tested product?

 

What is broken?  Well, one of the features was a custom extension related issue:  the Text/Image Component, and the Page Component which is a product bug.  Well, OK - it turns out it IS configurable, so maybe not a Product Bug.  I will discuss each individually, and what fix I used.  Both were rather simple to implement, well, after I figured out what was wrong.  First, let me describe the symptoms.

The CSS guy I am working with right now has been complaining about JavaScript errors for a while.  I had been putting it off, my feeling being, if we dont have a website, JavaScript errors are irrelevant.  Also, these kinds of issues I like to save as "filler" work.  Work that can be done when I am waiting for someone else to do some work before I can finish mine.

The Text/Image Issue

Chrome (on Ubuntu) pretty much buried the issue, and I never really noticed anything wrong.  On FireFox (running under Wine on Ubuntu) - the component editing features were gone.  No chrome around the components when you mouse over, no drag and drop of components.  However, and I am just stubborn enough to figure it out, you could still double click "just right" on the component and edit it.  You could NOT drag and drop components onto the page.  I wish I had saved the JavaScript error, but I didnt.  It was complaining about not being able to invoke document.getElement("<%= divId %>") in foundation/components/textimage/textimage.jsp.  My CSS guy was seeing the JavaScript NPE.

Turns out, the Text/Image component includes a script from the Image component to handle some tracking.  The key factor here is that the included stats Script expects a DIV to wrap the rendered image, and that div MUST have an ID.  The stats script relies on using the ID value from the containing Script in order to find the DIV (getElementById) and then collect the anchor tags, and add a click events to them.  What had happened is, whomever extended the OOTB Text/Image component removed the ID on the DIV.  So, the moral of this story is, when "decorating" a component with new functionality, be careful and understand the effects of changes you are making.

I simply added the ID back to the DIV that contains the image, and made sure the ID of that DIV was available as a variable to the tracking Script.

 

The Page Component Issue

Page impressions.  We thought they were cool, and had Omniture not come along, probably would have been invaluable.

This was is pretty simple to fix, but was pretty insidious to find.  The effects of it was a JavaScript error making a request to: http://localhost:4502/libs/wcm/stats/tracker.js?path=/content/page/path&_=1367380145960.  The result was a broken Authoring experience in FireFox.  Same issues as the problem stated above.

The JSP foundation/components/page/stats.jsp uses a class com.day.cq.wcm.core.stats.PageViewStatistics, which has as a configuration 'pageviewstatistics.trackingurl'.  This property, as it turns out, has a configuration in:  /libs/wcm/core/config.author/com.day.cq.wcm.core.stats.PageViewStatisticsImpl.  I did not fix it using this route, although it would have been a MUCH quicker fix.  What stats.jsp does is it generates the URL above, which as you can plainly see will NEVER function because your visitors are not running CQ on their local systems.

I fixed it by interrogating the implicit JSP request Object to determine the current request protocol, host and port, and construct this String myself.  This way I dont have a static configuration to manage across all of our environments:  one for each developer (7), DEV (2), DEV Test (2), UAT (2) and Production (5).  No thank you to static configuration.  I already extended the Page component to create a "foundational" Page component for our application - which makes it super simple to create new templates, and has been a huge time-saver for me and others.  Because I already extended Page, I simply copied the stats.jsp Script, and fixed the tracker.js URL in my local copy.

So, while this was not strictly a product bug, your mileage may vary using the OSGi Configuration of it.  It seems like alot of work to me, when it can be self-managing with a few lines of code.  Pick your poison, I guess.

This fully fixed the Authoring issues I was seeing in FireFox: no drag and drop, no chrome over the components when you mouse over, and probably other issues I don't know about.

Enjoy.

Share this post

0 Comments

comments powered by Disqus