Lichtman Consulting

This is a guest post by Nathan, our resident Drupal expert. With luck, it will be the first of a series of posts with a more technical nature than we usually write about here. You can read more of Nathan’s work here: http://bomshteyn.com.

We are starting a new series called Drupal hacks and solutions. This is going to be a useful collection of how-to’s and code examples, based on our experiences.

I am sure every Drupal developer out there has his own ways of styling Drupal (which as http://bomshteyn.com/2010/01/03/should-you-use-wordpress-or-drupal/ discussed is not always an easy task), we are just going to write up the cases that we encountered and solutions we used.

As always there is an easy way to do something and a proper Drupal way of doing the exact same thing. Whenever possible we try to do it the Drupal way, and would advise you to do the same, but i have to admit thats not always the case, and i would sometimes insert a SQL query into a template instead of properly using a drupal function of some sort.

It’s almost a year now since I started working on our first Drupal site; over time I have learned, and continue to learn, new “proper” ways of programming in Drupal and working “with it” versus “around it”.

As you work on a project you have a problem and find a solution, but by the time you get around to the next project and encounter a similar or even same problem (the latest project we were working on was approximately 400 of programming hours) you no longer remember how you solved it last time. In theory you could just open the last project’s code and find the solution, but sometimes its easier said then done, first you have to remember in which project you had this issue and second since an issue in Drupal could be fixed on so many levels (core, theme, modules….), where to look becomes an issue by-itself.

So here we are faced with a case of our own that needs a solution.

Our first urge was to create an internal wiki where we would write down this type of stuff for future use – knowing first hand how hard it is to find an up-to-date solution to some very common problems in theming Drupal. Plus the fact that we always wanted to give back to the open source community of Drupal. We decided to do it as a blog category on our site so that it would be searchable – not just internally but by the whole ever growing Drupal community. As a starting point we will give you an example post, so that you know what to expect.

How to add a custom login box into your Drupal theme

You will probably want to show this only for non logged in users so here is an example of the code you would use:

<?php
if($logged_in){?>
// put some code here
<?php } else {?>
<?php  global $user; ?>
<form action=”<?php print $front_page.’user/login/?’.drupal_get_destination();?>” method=”post” id=”user-login”>
<label for=”edit-name”>username</label>
<input type=”text” name=”name” id=”edit-name” value=”" tabindex=”1″/>
<label for=”edit-pass”>password</label>
<input type=”password” name=”pass” id=”edit-pass” tabindex=”2″/>
<input type=”hidden” name=”form_id” id=”edit-user-login” value=”user_login” />
<input type=”submit” name=”op” id=”edit-submit” tabindex=”3″ value=”Submit” alt=”Submit” />
<p>Forgot <a href=”/user/password”>password</a>? &nbsp; Or <a href=”/user/register”>Create New Account</a></p>
</form>
<?php }?>

The following blog entry describes the solution to an issue encountered by Jeremy and Nathan in moving data from an old website to a new one. Based on a brief search for a solution, it looks like many other people may find a use for the (admittedly rather crude) code that we wrote to solve the problem. We hope this helps!

We’ve recently had to convert data from an old custom-built shopping cart, to a new website based on Drupal and Ubercart. The old website had approximately 5000 products, with a data structure that was completely unlike the one used by Drupal to store data. We initially tried using the Drupal data loader module, but as other people have discovered, it isn’t necessarily a good fit for loading Ubercart product data, particularly when the products have images, or – and this is especially the case – custom data fields.

You can download a copy of our script here.

In the end, we put together a custom php script to pull data directly from one database to another. The script is fairly crude, but it may be useful to somebody trying to import data into Ubercart from another non-standard system.

As a result, I will link a copy of the script below. Please bear in mind that a) we accept no responsibility  whatsoever for its use (i.e. back up your databases first!!!), and b) while we have documented our assumptions, this is a crude script that is specifically designed for our particular needs. Be that as it may, you may be able to find a use for this.

Additionally, it was a pain just getting a list of the Drupal and Ubertcart tables that needed to be looked at in order to do the data conversion. The list below may be useful to you as well.

How it works:

The old shopping cart had two relevant tables: a category listing (hierarchical), and a products table, which included some customer specific fields, as well as a single url to a product photo.

Drupal/Ubercart, on the other hand, uses a large number of tables to represent the same data. This is because products use the same node-based system as the rest of Drupal, in addition to a number of product specific tables.

In addition, product images are dealt with using Drupal’s file cacheing system, which is relatively complex in nature. All in all, our data goes from two tables to approximately nine (depending on your specific needs) in Drupal.

The script has some handling – very buggy still – in place for keeping track of the current position in the old database. This means that you can run the data conversion in small chunks, checking at each point to see how well it is doing. You can also set how many records to convert each time. In order for this to work, a very simple table to track the record pointer needs to be added into the old database.

We did not cover the conversion of product categories, since typically there are a much smaller number of categories than products, and in addition, the Drupal data loader does a reasonably good job of loading them.

List of tables involved:

• node – in Drupal, everything is a node, including products. Each new product record will need a corresponding node of the correct type.
• node_revisions – this table contains much of the actual textual data (i.e. product description text) involved in displaying the node.
• content_type_product – if you need to create custom fields for your Ubercart products, the data will go here. Our code in this section will probably not map directly to what you’re working on.
• uc_product – where the product records “live”. There will be one record here for each of the product nodes.
• uc_product_stock – contains stock-related data (i.e. how many of the product you have on hand etc) for products.
• files – each product image needs to have a record in this table, which stores the file names and locations – but does not map these images directly to the product records (you need another table for that!).
• content_field_image_cache – this is the mechanism that ties a product image to the underlying product. We didn’t really try to work with Drupal’s actual cache mechanism, so after you have loaded the products, you may want to clear the cache.
• term_data – this is where product category information resides, based on Drupal’s vocabulary / hierarchy system. We hacked the solution in a fairly inelegant way – by doing a category name lookup to retrieve the term id.
• term_node – a connection table between a term (i.e. a product category) and a node (in this case the products).

Base assumptions:

• We assumed that the old and new websites both have mysql databases.
• Both databases will probably have to be on the same server (or at least one of them needs to be externally accessible if that isn’t the case)
• The script should be uploaded and run from the new website’s location.
• We assumed that there is only one product image per product – although this would be fairly easy to modify.
• We manually added our categories to the new website
• We manually moved product images across – there are comments in the script where you could automate this though.
• Error checking is extremely rudimentary; if this scripts hits a problem it just stops.
• If you hit data conv snags, the fastest way to proceed is to restore your backup database, reset the pointer record, and start over.

Nathan forwarded me this link from Mashable, with the subject line prefaced with the word “HUGE”.

From what I can tell, it looks like Microsoft is finally starting to put together the pieces of an overall web strategy: determine what Google would like to do and put roadblocks in their way. Hence the previous Yahoo deal.

Its obvious far to early to see if this helps them out. I’m fairly sure though that it means search engines will be displaying a lot more “current” or trending data pulled from profiles and micro-blogging posts.

I just had an interesting email exchange with one of my newer staff, a friend from university who worked for [insert name of company] for a number of years. Aforementioned anonymized company being a Fortune 500 company that is in the IT industry. I’ve got stuff with their logo on it in my office.

The conversation began when he asked if he could use a goto statement (in PHP code!) for error handling.

Bearing in mind that this is somebody who is extremely familiar with both Object Oriented and good coding practises, I realized that there must be an interesting story underlying this.

His response to my query for more info is informative:

Tease all you want — I’ll lean on the weight of nine years of experience at [big company name], where (gasp) gotos were ubiquitous (almost exclusively in error handling code, but still).

To clarify further: I actually wasn’t aware that PHP had a goto statement (see: php.net/goto – they have the nice xkcd cartoon in the comments). I’ve been coding in PHP for a long time.

There’s two methods that I usually use to handle errors in PHP code, in case you’re wondering:

1. Make sure that code that can crash is encapsulated in a nice neat function. Check return values of function calls inside the function. If necessary, stick an “@” before function calls that tend to crash in a messy manner. Then return useful info about the final state from the function itself, and check things out higher up in the stack.

2. Stick try/catch code around code that can crash. If necessary, subclass error classes and put in nice handlers for them.

In both cases, make sure that the error level for reporting is appropriate, and that we don’t output actual error messages back to the end user. Where useful, put in logging, and possibly put in code to email error reports back to admin.