D4.6.8 to D6.10: Set up a development site

If you haven't already, set up a development space on the server that hosts your current site. Three years ago, a statement like that would turn me into a deer in the headlights. Let me help you.

1. Development Domain: Ask your hosting service to set up another site directory on your account using either a domain that you will use for development or something like dev.examplesite.com. It needs to be a separate directory (NOT a drupal site folder).
2. Database: Ask your hosting service to set up another database. Using the same db username and login makes it easy.
3. Export/Import your Data: Either ask your provider to do this or use the database management service they provide to export all structures and data from your current D4.6.8 site into a sql file. I use phpmyadmin. You don't need to know sql to do this however, phpmyadmin must be installed and configured on the hosting service in order for you to use it with your db. One you have the export, import the sql file into the new development database.
4. Download/Upload Drupal: Use whatever tool you have been using to upload files to your site. I use Filezilla and the hosting service control panel. Filezilla doesn't always create the sub-directories in a multi-directory upload so watch out for that. I simply downloaded all the files from my D4.6.8 site to my local drive and then uploaded them to the new domain directory.
5. Configure the Site: Change the site directory name from your old domain name (unless you are still using default, then just leave as default). Then update the settings.php file to the correct database name and URL.
6. Go Look at Your Duplicate Site: Go to your new site and you should see an exact duplicate of your current site.

CAUTION: Because both your old site and your new one are on the same server, you will need to be cautious when upgrading PHP and MySQL. "Drupal requires a web server, PHP 4 (4.3.5 or greater) or PHP 5 (http://www.php.net/) and either MySQL (http://www.mysql.com/) or PostgreSQL (http://www.postgresql.org/). The Apache web server and MySQL database are recommended; other web server and database combinations such as IIS and PostgreSQL have been tested to a lesser extent. When using MySQL, version 4.1.1 or greater is recommended to assure you can safely transfer the database."

D4.6.8, however, does not run in PHP 5.2. The install.txt file says it will run in PHP5 or higher but that was not the case for me. I had to revert back to PHP 4.4.7. The MySQL upgrade to 5.0 worked fine. For technology requirements, check out Requirements.

D4.6.8 to D6.10: Clean up your dev site

This part of the process requires you come to the realization that many, if not all, third-party modules that you used to create your site are not available for D6.10 because the developer stopped working on it OR it got integrated into D6. It is also the time to clean up. The objective for this process is to convert your site into a D4.6.8 default site. Below are the steps I did to clean up my site for the transition from D4.6.8 to D6.10.

Site Data

Nodes: Go through all your nodes and delete all the nodes you don't need to keep. I had nodes from the events module that weren't needed anymore, so I dumped them.

Content types: I had two types of content that were obsolete going forward: events created with flexinode and disknodes. The events I could loose but the disknodes I couldn't. When I get to D6, I will have to find a way to address the nodes that were once disknodes. I will start with using the core upload module as a replacement to starters.

Site Structure

Theme: Revert to the default Bluemarine theme.

Third-party Modules: If you are using third-party modules to create the layout of your site, it is time to turn those off. Face the fact that your site will not be able to look exactly like it did before without some work. I was using the Views and Front modules to create my homepage. I did not delete the view (as of this moment, I haven't looked to see if my old views still work in Views2).

Menus and Blocks: Many of my menus and blocks were created using third-party modules. I simply turned them off. I took it down to the default navigation and site home link to get around. For example, I was using the Article module for my "Articles" link in the primary area. I checked and a D6 version of Article module is not ready (as of today) so this goes away.

Modules

By this time, maybe you have disengaged several modules just with the clean up process. I went through my modules and not only turned off all third-party modules but also the core modules I didn't need. Remember, modules take up php memory. While transitioning, it is best to be as streamline as possible so you don't get the white screen of death (which by the way did happen when reinstalling my updated third-party modules).

Once you have turned them off, go ahead and delete them from your server (FTP or control panel will be your tool at this point). Remember, no third-party module created for D4.6.8 will work in D6 so just give it up. CAUTION: Make sure you are logged into the dev site directory on the server. You don't want to delete the wrong set of modules.

Another reason for the deletion process is, newer versions of Drupal want you to put your third-party modules in the site directory. So, the only modules you should have left showing in your admin>modules are the following:

Aggregator Archive Block Blog Blogapi Book Comment Contact Drupal Filter Forum

Help Legacy Locale Menu Node Page Path Ping Poll Profile Queue

Search Statistics Story System Taxonomy Throttle Tracker Upload User Watchdog

D4.6.8 to D6.10: Upgrade One at a Time

Assuming you have completed the clean up process suggested on the previous article, you are ready to start upgrading. The following process may seem overwhelming but once you get into it, the process becomes easier (its all that practice you get).

Go Get the Drupal Installs

Go to the DO list of Drupal releases. Locate the following releases and download them to your local drive:

• D4.7.0
• D4.7.3 (cog.rusty did not include this one. I did this incremental step to get practice and to test the waters.
• D4.7.7
• D5.0
• D5.2
• D6.0
• D6.10

Unpack/Unzip and Upgrade

I assume you have a tool to unpack tar.gz files. I use the latest version of WinZip. The key here is to see the upgrade.txt file (I tried finding just the right set of directions on DO but did not succeed. Believe it or not, I simply followed the instructions in each Dversion. If you want to read some more about the upgrade process, there are several pages on DO that you can reference. For example, Upgrading from previous versions.

Tip

The instructions tell you to delete the "files" and "sites" directory and then reload them. For me, I never deleted the "files" directory and didn't seem to matter. As for the sites directory, my sites directory only had my settings.php file. I simply used the control panel interface provided by my hosting service, and edited the two lines (db location and url) by copying those lines from my backup copy to the new one.

D4.6.8 to D6.10: Add Modules

Now you are ready to add the custom and D6 third-party modules you need. Coming from the world of D4.x, you need to be aware of something. The location for files and modules has changed.

Module Upload Location

Unlike D4, the D6 practice is to create a module directory either within your /sites/sitename directory or your /sites/all directory. Modules that will be shared across multiple sites can go in /sites/all directory. Modules that customize that specific site typically go in the /sites/sitename directory.

NOTE: If you are going to run multiple sites from your Drupal installation and you share the third-party modules across all the sites, then understand that upgrading the module will affect all sites using the module. In most cases, this will be okay. Just remember to check all your sites after the upgrade.

Files Location

Just like with modules, you want to create a files folder to hold your documents and images. If you choose to store docs and images in the /sites/all/files location, you will probably want to use a sub-directory or file naming process that helps you distinguish between the docs and images associated with specific sites. The path you use when calling the docs and images would be /sites/all/files/documents (assuming you call your doc directory documents). Or you would use /sites/sitename/files/documents for docs stored in the site specific directory.

NOTE: If you choose the /sites/sitename directory to store your files and images, please know that if you ever change the name of the directory (e.g., from default to examplesite.com), you will break all your links. Because, instead of looking for /sites/default/files/documents, the html needs to look for /sites/example.com/files/documents. Using the /sites/all approach is more efficient in the long run.

Module Dependencies

This isn't new, however, instead of simply having module dependencies, you also have PHP5.2 dependencies. PHP5 has been out for a while but if you have been hanging around in D4, it hasn't really been an issue. Now a lot of the cool stuff depends on PHP5.2. Depending on how many D4 legacy sites you have on your server, remember, it is the lowest common denominator that you need to worry about. D4, from my trials, doesn't run in PHP5.2. So until you get all your D4 sites into D6, you won't be able to add the cool modules that require PHP5.2. See my notes on D4.6.8 to D6.10: Upgrading to PHP5.2 to see what I am doing about juggling D4 and D6 sites.

D4.6.8 to D6.10: Clean URLS

When I first starting using D4, I saw many issues regarding clean urls and recommendations not to go there just yet in Drupal. So I didn't. Now that I am in D6 and clean urls shouldn't be an issue, I switched.

I didn't switch until I understood that clean URLs are similar to aliases. Meaning, if some other web site was linked to one of my unclean URLs, that link would still work. I must have read a dozen posts on DO looking for this answer. So I did a little testing and tada, everything is okay.

Clean URLs and Views

When I switched on clean URLs and tried to create or update a view using Views 2.4, the view features that let you set up the parameters of the view didn't work. You can see the error below. For now, I am toggling between clean and unclean URLs when I need to create a view. UPDATE: I don't know exactly how it happened but this issue has solved itself. See http://drupal.org/node/427542#comment-1494620 for more details.

Clean URLs and book outline

When I switched on clean URLs and tried to use the node book/outline feature, I get this error. The issue with views has been resolved but the book outline has not. So whatever fixed the views issue is not the cause of the book outline issue. See issue http://drupal.org/node/428792

D4.6.8 to D6.10: Views1 for D4.x to Views2 for D6.x

Converting

If you are like me, you relied on views to create your menus and lists. Unfortunately, you won't be able to reuse your D4 views if you go straight from D4 to D6.

Let me clarify. There is a feature in Views2 that allows you to convert your old views. I tried this but is didn't work. I got the following message:

user warning: Table 'idcm6.view_exposed_filter' doesn't exist query: SELECT * FROM view_exposed_filter WHERE vid = 3 ORDER BY position ASC in /home/idcmi/idcminnovations.com/html/sites/idcminnovations.com/modules/views/includes/convert.inc on line 443.

I can't say for sure if the following idea would work but maybe, if you walked through your upgrade and included view updates along the way, maybe it would help. I don't know.

Views2 GUI

Wow, what a change. Once you get the hang of it, the new Views2 is pretty cool. There are some tutorials available to help. Start here http://drupal.org/node/395064 with an introduction. The views help can also be found at http://views-help.doc.logrus.com/. Lullabot has new training video out called "Learning Views for Drupal."

D4.6.8 to D6.10: Secondary Menu not Working

When I upgraded from D4.6 to D6.10, I noticed that secondary menus weren't showing up. I assumed I had just forgotten to turn something on so I didn't worry about it. Upon upgrading another installation from D4.6 to D6.11, I realized that secondary menus weren’t showing on the second upgrade either. This meant I needed to investigate further. To make a long story short, the variable table had the wrong value for menu_secondary_links_source. To know what this means and how I came to this conclusion, please read the process below.

Basic Verification Process

When I discovered that the secondary menu was not showing up, I first looked at the various settings required to make the menu work.

• Check the Theme - Make sure the theme in use has been programmed to show a secondary menu. You can determine this several ways. One way is to open page.tpl.php in a text editor and do a search for "$secondary_links." If you don't find it, the theme will not show the secondary menu. If you do, carry on to the next step.
• Create Menu Item - Assign a menu item to the secondary menu via admin > site building > menus. Themes are typically configured not to show the secondary menu area unless an item has been assigned to the menu.
• Turn on Secondary Menus - Verify that the theme configuration is set to show the secondary menu via admin > site building > themes > configure. There are two places where secondary menus can be set, in global settings and in the configuration settings for the specific theme.
• Check other Themes - When one theme doesn't show the secondary menu, try another, so you can rule out a potential theme issue versus another type of issue. Garland is one of Drupal’s default themes and is set to show secondary menus. This is a good testing option.

After performing these processes, I took testing to another level.

Other Testing Processes

I am lucky because I have several sites in various states that allow me to compare configurations and assess what is different about one site versus another. This comparison option is at the core of the testing steps listed below.

• Check other Sites - Open another site using the same installation of Drupal and a different database. Enable a secondary menu and see if it works. If it does, the problem probably isn't the installation of Drupal. In my case, the sites I had created after upgrading the Drupal installation to D6 were operating correctly.
• Check the Theme Variables - The next step was to pick a theme, open the page.tpl.php and replace $secondary_links with $primary_links to determine if the theme was failing due to the value of the variable or whether is was something else. The menu bar for the secondary menu appeared on the screen with the primary menu links showing. Conclusion, the theme was fine. $secondary_links was the problem, it wasn’t getting assigned a value. Why?
• Check the Database - Remember, the Drupal installation works, the theme works, the only difference between the site with issues and the other sites that worked is the database. What data is used to ultimately assign a value to $secondary_links? I reached out to the developers on the #Drupal IRC and was guided to http://api.drupal.org/api/function/template_preprocess_page/6 (thank you Heine), which led me to http://api.drupal.org/api/function/menu_secondary_links/6 where it showed this line of code:
  if (variable_get('menu_secondary_links_source', 'secondary-links') == variable_get('menu_primary_links_source', 'primary-links')) { .
  I went hunting in the database for menu_secondary_links_source and secondary-links. I confirmed that the menu table contained an item called secondary-links so there was data to be had. I then looked for menu_secondary_links_source in the variable table and that’s when I found the problem. This variable had been set to s:0:""; when it should have been s:15:"secondary-links";. I updated the database to the correct value, ran cron.php, and that’s what fixed it.

Observation About menu_secondary_links_source

In my investigation, I discovered that the sites that I had set up after the upgrade, didn’t have menu_primary_links_source or menu_secondary_links_source variables and they showed the secondary menu just fine. I wonder why? Also, the original D4 database didn’t have these variables either. So where did it come from and why aren’t they present in each database? If I ever find out, I will update this article.

Also, this issue was present in two of three D4 site upgrades. Only one of the three was working. Luckily, it had the correct value for the menu_secondary_links_source variable. If it hadn’t I would have been back on the IRC asking for tips on how to find the correct value.

Conclusion

When something doesn’t work, keep digging. The forum issue I opened when I was starting my investigation is located at http://drupal.org/node/472362. I posted it when I realized that the variable value wasn’t being set right. A summary of what is here is included. When you find the answer to your issue, please share it so we can all learn from your triumphs.

D4.6.8 to D6.10: Upgrading to PHP5.2

When I started the process of upgrading my site, I assumed I might have an issue with MySQL and PHP versions. In fact, it was this concern that slowed my initial start. After reading the varies INSTALL.txt files, I saw that upgrades shouldn't be an issue. So, I upgraded and as it turns out, both sites run ok on PHP 4.4.0 and MySQL distribution 3.25.

Knowing, however, that there were modules in D6 that needed PHP5.2, I ventured forward and upgraded both MySQL and PHP to their latest stable versions. I assumed I would be okay with the upgrade because the INSTALL.txt in D4.6.8 says "Drupal requires a web server, PHP4 (4.3.3 or greater) or PHP5 (http://www.php.net/) and either MySQL (http://www.mysql.com/) or PostgreSQL (http://www.postgresql.org/)."

Well, the MySQL upgrade went okay but not the PHP upgrade. My D4 site bugged out. I honestly don't recall the error but it was fatal. My host provided quickly backed me down to PHP4.4.7 and my D4 site came back. Obviously, if I wanted to continue to have access to the D4 site (for quick references to old data), I would need to do one of three things:

• Stay at PHP4.4.7 and forgo the PHP5.2 modules that I wanted
• Say good bye to my old site
• Move my old site to another server configured to run it

I chose the last option. After I got my D6 dev site to the point where I didn't mind the public seeing it, I started the launch process. These are the steps I took.

• I create d4.idcminnovations.com and moved the D4 site from idcminnovations.com to d4. D4 doesn't have an option to put the site into maintenance mode (from what I can see) so I went to access control and said that anonymous couldn't see the site anymore. That way, visitors would accidentally find my old content.
• I copied the dev D6 site from cindymccourt.com to idcminnovations.com and allowed both domain to link to the same database.
• I started the process of setting up a local host on one of my pc's at home. I have two (one that has a local setup for D6 and now the second has a setup that will run D4).
• I used FTP and copied Drupal to the D4 localhost. I exported the database using phpmyadmin.
• On my localhost, I used a local version of phpmyadmin and created a database. Unfortunately, there is a 2mg limit on the file size you can upload using phpmyadmin. Not knowing if or how I could increase that limit, I proceed to manually upload the D4 database. I simply open the sql export in Notepad and copied the sql statements, a few at a time, to the SQL window in phpmyadmin and clicked GO.
• I changed the settings.php file to point to the new database and updated the userID and password. I also changed the url setting to be http://localhost/drupal.
• At first the login page didn't work. I looked for solutions, could find them, and closed the browser out of frustration. I came back a few minutes later, reopened the browser and launched the site. Tada! login worked. Don't ask me why. So, the lesson here is, trying closing and opening the browser.

The next step is to remove the D4 site completely from my server and request my provider upgrade server to PHP5.2. Of course, I still need to disconnect cindymccourt.com from the idcminnovations.com database AND I need to make a new dev site for my current D6 site but I will do that tomorrow.

D4.6.8 to D6.10: PHP Memory and Drupal

There is a good chance you know this already but the default memory setting for PHP on the server is too small to run a Drupal site that has multiple modules.

When this site was D4.6.8, I had to increase the memory setting for PHP on the server. Fortunately, my service provided allows for this. I assume it is because I have a virtual server at Prohosters/Carpathia. When I upgraded to D6, I had to increase my PHP memory. We bumped it up to 32MG to give me enough wiggle room. I have the option of going to 64MG but decided to wait.

PHP upgrade process

I just updated to PHP5.2. You may recall I delayed updating until I had my old D4 site on another server before breaking it with an update to PHP5.2. Anyway, we just did the update over night and apparently, the process reset the PHP memory back to its default. I awoke to a fatal error, not enough memory. My provider set it back to 32MG immediately upon advising them of the situation.

So, when updating to PHP5.2, two things to watch out for:

• Make sure that all applications on your server using PHP can operate with the version you are going to.
• Make sure that the memory setting isn't reset to default when you need more.