Have you checked what is actually being persisted in the repository. The RTE will reformat HTML entered in the source edit option at times. Are you sure that the editor isn't changing your HTML before it's persisted? 

Dispatcher does not handle this by default. There are multiple ways of dealing with the problem but the cleanest way, and the method that the product supports best is Closed User Groups. See http://docs.adobe.com/docs/en/aem/6-0/administer/security/cug.html for documentation. Also see http://www.sli...

So to make this work your "partial HTML pages" must be complete AEM pages. I am assuming that by partial pages what you mean is that your Angular app is including basially and HTML chunk - say a div or a collections of div, but not a fully qualified page with html and body tags. So for example:/cont...

I don't believe there is any existing standards that have been articulated in the way you want. The capacity of a publish server is very dependent on the application deployed on it. So the maximum number of pages a publish server that makes heavy use of the query API will be different than for one t...

The first thing to be clear on is are your users leveraging on time/off time or Activate Later - these are different features of the tool and would potentially fail for different reasons. on time/off time is a value that you set in a page's Page Properties, once set you actually publish the content ...

The system doesn't necessarily provide a way to query that. The relationship between a page and client lib is dependent on what the template of the page includes and what the components included on the page. Are you trying to understand what pages to flush from dispatcher cache? Typically best pract...

That usually indicates that you are trying to run the install on JDK8. JDK8 isn't support until SP1 is installed. This means you have to run the initial install on JDK 7, then install SP1, and then you can run on JDK 8. 

I agree that /etc is the appropriate place to store the data, one recommendation though to better fit usage patterns in /etc would be to add an additional path to allow better application of security and template use - so /etc/sitedata/project/site. This keeps the top level of /etc less cluttered an...

You did it right, the ignoreURLParameters setting ignores the query string and caches the page as if the query string wasn't in the URL. Normally the ignoreURLParameters is used to impact query parameters that don't impact the HTML to be returned, but rather impact the display client side or are use...

Rewriting the query string to a selector in Apache is the right way to make the requests cachable. Changing it back to query string with /etc/maps is bad idea in my opinion - your code that the renders the pages should look to pull the information out of the selector instead of the query string. Her...