Not through the WCMUtils API - if you needed that implementation you'd have to write your own inheritance logic that not only walks up the tree and gets the property value, but also returns the level. It wouldn't be the complicated - you'd have the same inputs as the WCMUtils method, but instead of ...

I believe those are tag libs from the Adobe Consulting Service AEM commons project - although in the latest versions I believe they changed the URIs. Are you sure you deployed the AEM Commons bundles to you new instances? I'd say there are two possibilities - either the bundles containing those tag ...

Ah - out of the box there is no way to achieve your requirement - you'd have to create a new workspace and put those tags in that workspace. Or you'd have to extend the tag input widget and add the filtering capability. 

You don't want to use the tagsBasePath property - you want to use the namespaces property. It's an array of strings representing the namespaces you want to be displayed. See http://dev.day.com/docs/en/cq/current/widgets-api/index.html?class=CQ.tagging.TagInputField for details. You wold set the prop...

To my knowledge there is no dispatcher limitation. I have run files with some very long names through dispatcher (much longer than 256 characters). What version dispatcher, what version of Apache, and what OS. 

I think primary challenge there is the algorithm for how you link the customer's needs to the data. I think duplicating that will be hard to do no matter what framework/platform you implement this on. I don't think AEM is going to provide you any help with that part of the solution. Building a solut...

First question to ask is are you sure that the content isn't being cached in the dispatcher incorrectly - what happens if you go directly to the app server (assuming you are using dispatcher). Have you examined the underlying content nodes in each environment. Specifically are you sure that componen...

Generally you need to specify any value that you want to be different than the default. It is possible that the service you are configuring is was never changed from any of the default values which is why when you look in felix it appears as though only the value you specified changed. The behavior ...

That's why you monitor the queue and only add the next items to the queue once the queue is empty. If you just dump everything on the queue immediately it will block up your ability to publish. But if you add and item to the queue, and then wait until it's empty normal publishing isn't impacted beca...

What about dispatcher. I assumed they were replicating everything in order to get dispatcher to delete the items as well. If you just delete the parent node wouldn't you also need to run a script to get dispatcher to delete the cached versions?