Web Development

Thursday, April 12, 2012

Drupal site structure change couldn't be saved

We have a huge site structure in drupal 6. After we upgraded php 5.2.6 to 5.3.3, we got a fatal error when trying to access the site structure page:

Fatal error: Allowed memory size of 134217728 bytes
exhausted (tried to allocate 82 bytes) in .....

So we have to put this line in %drupal_home%/sites/default/settings.php:

ini_set('memory_limit', '512M');

This increased the drupal memory limit from 128M bytes to 512M bytes. Now we can see the site structure page. However, when we tried to make some changes, the changes are not saved and no error on the web page. Then we found this warning in the apache error log:

[error] [client xxx.xxx.xxx.xxx] PHP Warning:  Unknown: 

Input variables exceeded 1000. To increase the limit
change max_input_vars in php.ini. in Unknown on line 0, referer: https://yoursite.com/menu-site-structure 

So now we added this line to php.ini:

max_input_vars = 2000

This increased the max input variables from 1000 (default) to 2000, and this solved the problem.

Thursday, April 5, 2012

Debugging Drupal Source Code remotely in NetBeans

Configuring the Server:

1. Make sure PHP XDebug module is installed.
2. Add this section to your php.ini (i.e. /etc/php.ini). NOTE: make sure you put IP address of the client machine (the debugging computer) for the "remote_host", not the the server IP!

; xdebug config

xdebug.remote_enable=on

xdebug.remote_host=%client IP address%

xdebug.remote_port=9000

xdebug.remote_log=/var/log/xdebug.log

xdebug.idekey=netbeans-xdebug

3. Restart Apache (i.e. $apachectl graceful).
4. Run php -info. And you should see something like this:

xdebug support => enabled

Version => 2.1.4

...  

DBGp - Common DeBuGger Protocol => $Revision: 1.145 $

...

xdebug.idekey => xxxxx => netbeans-xdebug

xdebug.remote_enable => On => On

xdebug.remote_handler => dbgp => dbgp

xdebug.remote_host => xxx.xxx.xx.xxx => xxx.xxx.xx.xxx

xdebug.remote_port => 9000 => 9000

...

Configuring the Client:

1. Make sure PHP plugin is installed for the NetBean.
2. Start NetBeans and create a new PHP project (File->New Project). Select PHP Application from Remote Server and click Next.
3. Give the project a name and local location and click Next.
4. Setup the Remote Connection as appropriate for your server and click Next. Click the "Manage" button the set the remote connection by putting in the username and password. If you use SSH to access the server, leave the password field blank but provide the private key file.
5. NetBeans will construct a list of files it will download. Click Finish to download the files.

Debugging Drupal Remotely:

1. Make sure you open the port for Netbeans if you use Windows 7 and Vista.
2. In Netbeans, set the drupal project as the main project, then go to "Debug Project".
3. Enjoy debugging.

Tuesday, November 8, 2011

Self InclusiveTemplating in JSF 2.0

Page template is a nice feature in JSF 2.0. Combined with EL 2.2, it is so powerful that you can do self inclusive templating in a production environment. Here is an example:

1) client file - index.xhtml:



    <ui:composition xmlns="http://www.w3.org/1999/xhtml"

         xmlns:ui="http://java.sun.com/jsf/facelets"

         xmlns:f="http://java.sun.com/jsf/core"

         xmlns:h="http://java.sun.com/jsf/html"

         template="/templates/template.xhtml">



       <ui:define name="title">Page Title</ui:define>

<ui:define name="body">Page Body</ui:define>

   </ui:composition>

Here it is using the template.xhtml as the template, then define 2 elements "title" and "body" to pass to template.xhtml.

2) template file - template.xhtml:



<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" 

"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<html xmlns="http://www.w3.org/1999/xhtml"

            xmlns:h="http://java.sun.com/jsf/html"

            xmlns:ui="http://java.sun.com/jsf/facelets">

<h:head>

 <title><ui:insert name="title">Title</ui:insert></title>

 <ui:include src="/templates/header.xhtml"/>

</h:head>

<h:body>

  <div id="col2" class="clearfix">

   <div id="col2a">

    <ui:insert name="body">Body</ui:insert>

    <ui:include src="/templates/footer.xhtml"/>

   </div>

  

   <div id="col2b">

    <div id="nav-container">

      <ul id="nav-main">

               <ui:include src="/templates/submenu.xhtml">
        <ui:param name="submenu" value="#{sessionSupport.menuService.getSubMenu(currentSectionUrl)}" /> 
                  <ui:param name="level" value="1" />
              </ui:include>

           </ul>

    </div>

   </div>

</div>

</h:body>

</html>

The two "ui:insert" are the place-holders for page title and body, which are provided from the client file (index.xhtml); "ui:include" pieces are convenient to include a few html snippets to make the code clean and neat. Among them submenu.xhtml is the most interesting one.

3) self inclusive snippet file - submenu.xhml:



<ui:composition xmlns="http://www.w3.org/1999/xhtml"

                   xmlns:ui="http://java.sun.com/jsf/facelets"

                   xmlns:h="http://java.sun.com/jsf/html"

                   xmlns:c="http://java.sun.com/jsp/jstl/core">

<c:set var="url" value="#{sessionSupport.breadCrumbs[level+1].url}"/>

<c:set var="requestURI" value="#{sessionSupport.requestURI}" />



<c:forEach items="#{submenu}" var="menuItem" varStatus="status">

       <c:choose>

<c:when test="#{sessionSupport.menuService.isSelf(menuItem, requestURI)}">

 <li class="active"><a href="#{menuItem.url}">#{menuItem.name}</a>

               <ul>

                  <ui:include src="/templates/submenu.xhtml">
     <ui:param name="submenu" value="#{sessionSupport.getSubMenu(

url

)}"/>
     <ui:param name="level" value="#{level+1}" />
                   </ui:include>

               </ul>

            </li>    

</c:when>

<c:otherwise>

            <li><a href="#{menuItem.url}">#{menuItem.name}</a></li>

</c:otherwise>

</c:choose>

</c:forEach>



</ui:composition>

The code loops through the menu items at the current level and then calls itself, passing the sub-menu of the next level as a parameter, and then goes on and on, until it walks through the whole tree structure.

Setting up JSF 2.0 and EL 2.2 on Glassfish v2

I am migrating our JSF 1.1 application to JSF 2. Since we are still running Glassfish 2.1.1, I can't use the latest version of JSF (2.1.3), which targets Servlet 3.0 containers like Glassfish v3. So I settled with JSF 2.0. One of the nice features of JSF 2.0 is the build-in page templating support, which is a big help to clean up those messy jsp files.

While setting up the templates, I found that we need to pass parameters to methods in the jsf/xhtml file. But this is NOT supported by default in Glassfish 2.1.1. Comes EL 2.2 for the rescue.

It is kind of easy to set up JSF 2.0 and EL 2.2 on Glassfish v2:

1) Add el-impl-2.2.jar in your project pom.xml (assuming you use maven), which will install two jar files (el-impl-2.2.jar and el-api-2.2.jar) in your WEB-INF/lib after build:

    <dependency>

      <groupId>org.glassfish.web</groupId>

      <artifactId>el-impl</artifactId>

      <version>2.2</version>

    </dependency>

2) Copy el-impl-2.2.jar and el-api-2.2.jar to %Glassfish_Home%/lib/

3) Download jsf 2.0 from http://javaserverfaces.java.net/, then copy jsf-impl.jar and jsf-api.jar to %Glassfish_Home%/lib/

4) Add "classpath prefix" in glassfish domain configuration file domain.xml (or you can use the Admin console: Application Server -> JVM Settings -> Path Settings -> Classpath Prefix):

<java-config classpath-prefix="${com.sun.aas.installRoot}/lib/jsf-api.jar${path.separator}${com.sun.aas.installRoot}/lib/el-api-2.2.jar"
...

You are all set to roll!

Saturday, August 27, 2011

Set up Apache for site maintenace

We want to set up the site maintenance page from 5am to 3pm on a certain day to do database upgrade. Then we want to test the site internally before opening to the public. This is what I would do in Apache configuration:

# rewrite condition1: 5am to 3pm
# rewrite condition2: allow only internal ip
# rewrite condition3: any database driven page (".dyn", ".jsp", or ".vm")

RewriteCond %{TIME_HOUR}%{TIME_MIN} >0500
RewriteCond %{TIME_HOUR}%{TIME_MIN} <1500
RewriteCond %{REMOTE_ADDR} !^255.255.0.0*$
RewriteCond %{REQUEST_URI} \.(dyn|jsp|vm)$
RewriteRule ^/(.+)$ http://my.site.com:80/sitedown.html [L,R]

Wednesday, August 10, 2011

Can't deploy / undeploy web applications on Glassfish

When we tried to publish a new web application to Glassfish (v2.1.1) this morning, we got the following mystic message:

CLI171 Command deploy failed : While redeploying, trying to stop the application in target server failed; Error Flushing ConfigContext com.sun.enterprise.config.ConfigContext: Url=$glassfish_home/domains/release/config/domain.xml, ReadOnly=false, ResolvePath=true, LastModified Timestamp=1312828827000, isChanged=false, Autocommit=false, isConfigBeanNull=false

It took us a while to realize that somehow domain.xml lost the write permission overnight, so Glassfish cannot add or delete the web application in domain.xml.

Glassfish team should hire someone who can write messages for a normal human being :)

How to start/stop all the cron jobs on Linux

Log in as root on the server:

All the cron jobs are defined in /var/spool/cron

To stop all cron jobs: /etc/init.d/crond stop

To start all cron jobs: /etc/init.d/crond start