Submitted by TheCarneyEffect on Mon, 07/09/2012 - 11:39
Drupal uses Drupal.behaviours as a replacement for jQuery.ready, but unlike jQuery.ready it can run multiple times during page execution or whenever new DOM elements are inserted into the document. This can be a problem when we want code inside the Behavior to run only once. This is important if you want to create a new instance of an object, for example. What I used to do in the past (for Drupal 6) was add a class to an element to know if the code had been processed or not:
Submitted by TheCarneyEffect on Mon, 07/02/2012 - 15:12
I think list items should, or have the option to, include zebra striping. For now, it easy enough to just override theme_item_list() and add that ourselves. Place the following code in your themes template.php file, remembering to change the hook to the name of your theme.
Submitted by TheCarneyEffect on Mon, 07/02/2012 - 14:27
I've created a custom field using the Field API and it works great. However, I want to use the Entity module and its Entity Metadata Wrapper to quickly access Entity data, including data from the new field I've created. If you try to access data from the new field you will see an error message similar to the below.
EntityMetadataWrapperException: Unknown data property field_example_rgb. in EntityStructureWrapper->getPropertyInfo() (line 339 of mysite\sites\all\modules\entity\includes\entity.wrapper.inc).
Submitted by TheCarneyEffect on Mon, 06/18/2012 - 11:30
Sometimes in Drupal I want to join together two forms, or in other words, prepend a form to another. For example, let say I have three user forms, all different but all contain the same fields to obtain the user address. One day I want to add an address lookup button in the address part of the form, but I'm forced to do the work on all three forms. What if I could create a separate form for just the address, then merge/add/prepend it to other forms. This way, I just need to change the address form and the changes would be reflected in all three of my forms. Here is an example:
Submitted by TheCarneyEffect on Wed, 04/11/2012 - 10:29
Sometimes, we need to get node information about the current node we are viewing. In Drupal 6, it was always recommended to use menu_get_object() rather than node_load() to get the node object - the node object has all the information about the node. The reason being that during the inital page request to the node, the node object is cached statically in the function menu_get_item(), a function used by menu_get_object(). So the next time we call menu_get_object(), we are in fact getting a cached version of the node object, making it much faster than node_load().
Submitted by TheCarneyEffect on Tue, 02/21/2012 - 12:04
I've been using the AJAX Framework in Drupal quite a lot lately, and it's always been fairly steady going, but recently my code has become more and more complicated. I thought it was time to find a good way viewing all those PHP arrays and objects during AJAX calls, so I can see how they are changing and if my code was doing what it was supposed to be doing. FirePHP is what I ended up using and below describes how I got it working with Drupal.
Submitted by TheCarneyEffect on Mon, 02/13/2012 - 13:05
Although it's very easy to create new content types in the admin section of Drupal, sometimes it's good to do this programmatically to make your brain feel a lot more clever.
Lets pretend we are creating a module called jobs, and in that module we have an install file called jobs.install. The first thing we do is add our hook_install() function that does the following steps:
Submitted by TheCarneyEffect on Thu, 01/05/2012 - 14:21
The cool thing about Drupal is that it adopts a modular approach. This is great because it enables me to override functionality in a controlled way with the use of those hook thingy-ma-jigs you keep hearing about. As a result, it’s harder for me to break something, and also makes life easier when upgrading code.