How to automate Adobe CQ CRXDLite data ingestion?

Can we automate the data ingestion into Adobe CQ CRXDLite through any third party tool or using selenium webdriver api.

To find a mechanism to read data ( nodes and their properties) from CRX , here are the methods.


here we need to have method call(s) from the test cases that fetch this expected data. The data can be retrieved using one of the following methods:

   a) You can access the data from CRX in xml or json format  - You will need to pass the appropriate URL to the method and parse the response.
   b) You can access the data from your CRX instance using apache jackrabbit api



Further thoughts:
If we think deeper on this, its better to refrain from using selenium or web driver to read data from CRX  because the process will be slow, error prone and will require lot of exception handling.

 Adobe shipped inbuilt selenium automation test suite based on selenium RC along with adobe day cq5. solution is in the form of zip file. But If we need to modify java source file and rebuild solution how can we do that?Is there any way to automate adobe day cq5 using selenium webdriver or RC.

Here CQ generates dynamic html ids for the elements so 'id' should not be part of object location strategy. Using firebug we can find out that html elements have many other attributes like class, name etc. By making use of these attributes to locate the objects to get a solution.

 For elements with only ids , narrow down on them locating their parent elements and then select the element using a distinctive factor like index, copy text etc.

CQ Redirects based on 'Locale'

There are some cases when the user needs to be redirected to the main page of the website according to his browser default language settings. For eg: if the user locale is set to 'fr' , 'French' site should open; else default English version. Next possible requirement could be, if user selects the 'en' language link , the user should be redirected to ENGLISH site from the 'fr' locale.

Let us see how to go ahead with this:

We can go for two approaches to achieve this :

    1)  JSP Redirects , [Redirect by reading the HTTP Request parameters].
   
    >   Site root node as template /components/pages/redirect
    >    Within the content.jsp of this page call some business logic to perform
    >    Now use business logic to evaluate the accept-language header and then a redirect based on language with a default language in case the header value did not cover an available language node.
   
   
    2)  Apache HTTP rewrite rule , [By using mod_rewrite and redirect based on the Accept-Language header].
 
* Say, we have a request for the root URL / then redirect to the language version of a home page with a HTTP 301

* Remember home page root directory path is domain dependent

* Use country-specific redirect for international toplevel domains such as it, de, fr

* Now accept-Language with english: serve en.html

  RewriteCond   %{HTTP:Accept-Language} ^en    

  RewriteRule   ^/$     /en.html       

  * Accept-language=COUNTRYID or no Accept-Language header or anything else: serve <lang>.html

  RewriteRule   ^/$     /de.html       


Which approach is better ?

The second approach is better compared to first. The advantage of this approach is that it reduces the load on your CQ instance significantly, because Apache can handle all requests to "/" - which is typically the most popular URL for every site/domain.

Localization does not work with CQ 5.4? I18n.getMessage is not giving localized messages?

People reported when trying to localize Javascript validation messages through CQ.I18n.getMessage("<key>"); reply messages are always in English language however if we use fmt:message this seems returning correct language specific message.

Below code works fine.
<fmt:message key="auto_recharge_dayofeverymonth"/>

Below code not working
<script> alert("hi"+CQ.I18n.getMessage("auto_recharge_dayofeverymonth"));</script>

Above seems to be a CQ issue.

Let us see a temporary fix for this.

original
required: "Please enter email to proceed.",

Localized
All hardcoded messages should be in the i18n folder, map them into key- value pair and replace with below code.
required: '<fmt:message key="email_validation_text_01"/>',


Permanent fix can be done using setting up the locale for CQ.

We need to set locale on the top of the page. CQ.I18n.setLocale("en");


example code to validate,


<fmt:message key="Install Package"/> <input type="label" value="" id="pp">

  <input type="label" value="<%=request.getRequestURI().split("/")[3]%>" id="test">

<script>

alert(document.getElementById("test").value);

CQ.I18n.setLocale(document.getElementById("test").value);

var qpp = CQ.I18n.getVarMessage("Install Package");   //Message("Install Package");

document.getElementById("pp").value=qpp;

</script>

Hope this helps.

Search and Promote Queries

 

      What the difference is between staged/publish live URLs in Search and promote?

Staged is used for testing purpose and no need to push the items live for testing purpose.

So if actual live url is http://sp1012e47f.guided.ss-omtrdc.net/?q=beach, then staged URL would be,

http://stage.sp1012e47f.guided.ss-omtrdc.net/?q=beach

       Where the Re-directs are mentioned?

Redirects are mentioned in Business Rules as shown below

 

How to configure error document on webserver(dispatcher)

Use below table to do the work.

Link: http://dev.day.com/docs/en/cq/current/deploying/dispatcher/disp_install.html
Refer to the below table for configurations:

DispatcherConfig	Location and name of the co nfiguration file.
DispatcherLog	Location and name of the log file.
DispatcherLogLevel	Log level for the log file: 0 - Errors 1 - Warnings 2 - Infos 3 - Debug Note: It is recommended to set the log level to 3 during installation and testing, then to 0 when running in a production environment.
DispatcherNoServerHeader	Defines the Server Header to be used: undefined or 0 - the HTTP server header contains the CQ version. 1 - the Apache server header is used.
DispatcherDeclineRoot	Defines whether to decline requests to the root "/": 0 - accept requests to / 1 - requests to / are not handled by the dispatcher; use mod_alias for the correct mapping.
DispatcherUseProcessedURL	Defines whether to use pre-processed URLs for all further processing by Dispatcher: 0 - use the original URL passed to the web server. 1 - the dispatcher uses the URL already processed by the handlers that precede the dispatcher (i.e. mod_rewrite) instead of the original URL passed to the web server. For example, either the original or the processed URL is matched with Dispatcher filters. The URL is also used as the basis for the cache file structure. See the Apache web site documentation for information about mod_rewrite; for example, Apache 2.2. When using mod_rewrite, it is advisable to use the flag 'passthrough|PT' (pass through to next handler) to force the rewrite engine to set the uri field of the internal request_rec structure to the value of the filename field.
DispatcherPassError	Defines how to support 40x error codes for ErrorDocument handling: 0 - the dispatcher spools all error responses to the client. 1 - the dispatcher does not spool an error response to the client (where the status code is greater or equal than 400), but passes the status code to Apache, which e.g. allows an ErrorDocument directive to process such a status code.

Remember:
We need to configure 'DispatcherPassError' and 'DispatcherUseProcessedUrl' parameters.