Adding -x to the shebang will make bash output everything that is going on, helps with debugging

Giving a variable as a parameter to a function, if you just give the variable name it will be treated as a string value and that will be passed to the function. I ended up encapsulating it as "${var}" since the value was a string. If your value is not a string you probably need some other solution.

Comparing a variable to a string is best achieved with the following syntax: if[ "${var}" = "foo" ]; then Notice the space between the brackets and the values inside.

Using grep to pick something out of a list of processes requires an extra step in which you remove the grep itself from the list. ps -e | grep -v grep | grep searchstring Otherwise grep might find its own search process, which is of course not the desired effect.

Hopefully this will save you some time in scripting.

I noticed that the hook_block_view was called one to many times. Looking at the front page, I saw that the, now removed block was still there. The block admin page, however, did not show it. This was to be expected as there was no info available for it.
It was possible to configure the block though. Either through typing the correct url, or through the small gear on the top right side of that block.
Both clearing the cache and turning the module on and off have failed to remove this phantom block, which had no implementation but was still around. Deinstalling the module was the only way to clear it out of the block table (aside forma custom sql query of course). Since my module did not have any custom information in the database this was not a problem. However if your module does have such information, deinstalling it will remove all that data. Since my module was available for deinstallation leads me the believe that this is by design. Keep this in mind when building your modules.

Even after the block has been removed from the blocks table, it was still visible. Further research led to the Context module. The block was added to the display via a context reaction, and it seems that context does not check if a block is still available. And so the hook_block_view of my module was called with the delta of the old, non-existing, block. Opening the reaction interface for context does not show that the block is part of it, because, I assume, it is not defined. In the database however it is still present. Saving the context with the phantom block without making any changes does remove it from the database, and has removed it from the front page as well.

For a project at work I needed to parse some XML. The xml contained several entries of entries. Only part of the information given for each entry was actually needed by the software. Therefor the object used did not have a property for each field in the entry. Just doing the follow code will not work:


[currentObject setValue:(id)elemValue forKey:objProperty];


This will raise an exception as soon as an attempt is made to set a property that does not exist. Wrapping the setter in a check to see if the object has this property will solve this problem. Using responseToSelector a test can be made to see if the object reacts to a selector


if ([currentObject responseToSelector:NSSelectorFromString(objProperty)]) {
[currentObject setValue:(id)elemValue forKey:objProperty];
}


This should do it. Except it doesn’t completely. If your object has a function that is named like objProperty, responseToSelector will return true, because your object does response to it. Its just not a property that is set-able, but instead, a method. Actually, reponseToSelector only controls for function. Since synthesizing a property creates a method with the name of the property, it works for detecting properties as well. To avoid getting an exception on setting values for keys. Make sure that objProperty does not contain a value equal to a method in currentObject that does not represent a property.

NSXMLParser requires a NSData object to init with data. Following the conversion cod eI found on Apple’s site I did the following:


NSData *xmlData = [NSData dataWithBytes:[xml dataUsingEncoding:NSUTF8StringEncoding] length:[xml lengthOfBytesUsingEncoding:NSUTF8StringEncoding]];


Passing the xmlData through to the parser ended in me getting an error 4, which means document empty. I tried everything. Printed out the xml string to see it was full, compared length of data and string, releasing the parser. Still error 4. For the heck of it I tried giving the parser a nil for data. That gave an error 5. Trying to give an empty NSData object also gave error code 4. After 3 hours spent in google and stack overflow I was not even a small step further.

I really didn’t know what to do when, while scanning all these pages I saw a piece of code of converting the string to data without giving the length. for the heck of it I decided to try this:


NSData* xmlData = [xml dataUsingEncoding:NSUTF8StringEncoding];


What do you know it worked. No idea why. Naturally. I wanted to know what the length of the data object was now. I was fully expecting it to be bigger than original. To my surprise it was the same length as the string. The same length I was giving it in the first call.

Why this now wrks I have no idea. The first and the second calls should give the same results, yet somehow they don’t. If you got this problem, then converting without giving the function a length. Good luck and happy programming.

Solr is a “popular, blazing fast open source enterprise search platform from the Apache Lucene project”. Drupal search has traditionally been less then adequate. Using Solr to index and search you Drupal site is therefore quite helpful.

To start, download the Solr package (link) and the Solr drupal module (link). the current standard distribution is Solr 1.4 and Drupal 6.
Unarchive the tar files in a location that is reachable from your server.

We will assume that tomcat is installed in /opt/tomcat

In the Solr package there is an example application. That is the Solr application we are going to use. If you can write your own, you probably don’t need this tutorial.

Step 1:
Copy the example application, found in the solr package under example/webapps to the tomecat webapps folder which should be /opt/tomcat/webapps. when copying the file rename it to something other the solr. this will enable you to have multiplie solr installations running under one Tomcat container. We will assume the app is renamed new_solr_inst. If you are in the tomcat root folder the command should like like this:
cp /path/to/solr/package/apache-solr-1.4.0/apache-solr-1.4.0/example/webapps/solr.war webapps/new_solr_inst.war

Tomcat will pick up the war file and open it automatically after a restart.

Step 2:
In the tomcat root folder create a folder to hold your Solr configuration and data.
mkdir new_solr_inst
Copy the example app configuration into that folder
cp -R /path/to/solr/package/apache-solr-1.4.0/apache-solr-1.4.0/example/solr/* new_solr_inst

Step 3:
You need to replace the original schema.xml and solrconfig.xml with the ones provided by the drupal module. Copy these two files to your Solr configuration folder. Assuming you are currently at the tomcat root folder
cp /path/to/solr/module/schema.xml new_solr_inst/conf
cp /path/to/solr/module/solrconfig.xml new_solr_inst/conf
The Solr app is now ready for use.

Step 4:
The last step is needed to inform Tomcat about the app and its settings. Go to conf/Catalina/localhost and create the file new_solr_inst.xml. In that file fill the following content:

Step 5:
You need to restart tomcat
/opt/tomcat/bin/shutdown.sh
/opt/tomcat/bin/startup.sh
And your Solr should be running. There are three tests we can use to check everything went well.

• Tomcat has opened the war file. There is now a folder new_solr_inst in the webapps folder of Tomcat.
• Solr has made a data directory in the Solr home folder (that is /opt/tomcat/new_solr_inst)
• In your browser go to the Solr app http://domain:tomcat_port/new_solr_inst and you should see a welcome screen

If all is well you are ready to combine this Solr installation with your Drupal

Step 6:
Activate the Apache-Solr module and go to the Solr module settings page admin/settings/apachesolr
Assuming tomcat and drupal are running on the same server fill in localhost as the host name, fill in the port tomcat is running on and solr path should be your app name in the tomcat webapps folder. In our case is it new_solr_inst.

Save the settings. Drupal should inform you that a connection is made with Solr

Notes

• It is not nessecary to put the app configuration in the Tomcat root folder. you can probably (though I have not tested this) place it anywhere you want. you do need to make sure that the environment tag in the Tomact configuration file (the one in the conf/Catalina/localhost folder) is pointing to the right place.
• If you make changes to the schema you may need to dump all the indices Solr has made. you can do this via the Drupal admin interface for the Solr module.

global $user;
$user->sid;

In any case the session id can also be read from the cookie:

$_COOKIE[session_name()];

Drupal, like most CMSes uses cache intensively to speed things up. In a production site that is exactly what you what. However when developing, cache can cause you much pain.

After a long break I have resumed my side project in django. Last night I came upon a problem. When testing a page outside django, the page was rendered correctly. When it was rendered through django the javascript files were not located.

An interesting talk about secret software and why it should not be allowed in the public sector