I am updating a multisite Drupal 6 installation. To the best of my knowledge, the only difference for Drupal 7 is that instead of the site_offline D6 variable the maintenance_mode variable is used in D7.

On Debian stable and later, you can sudo aptitude install drush and then just use it immediately after that.

Note: I recommend su webuser (or sudo -s followed by sudo -s -u webuser) before you run any non-testing drush commands, where webuser is the user which owns your web-exposed files (e.g. Debian’s default is, I think, www-data). I’ve seen a lot of recommendations to run drush as a super-user, but that does not make sense, and may actually cause problems with file ownership.

One last thing before we start: if your drush seems to work fine but hangs when untarring modules – check this solution.

1. Run some innocent command in drush to see if it produces any PHP warnings/errors you may want to fix before running actual update: drush @sites core-status. In my case, all the sites had the CacheRouter module for in-RAM caching with a server daemon back-end, which was not initialized properly when drush bootstrapped Drupal from the command line. In my case, the only working solution was to edit settings.php files of every site to comment out the CacheRouter configuration for the period of update. If you get no warnings/errors, proceed to the next step. Note: I was running drush from the Drupal’s root (directory which has top-level index.php and .htaccess files), but this should also work if you run from sites/ or even sites/sitename.
2. Here would be several more steps – copying your production website(s) to a dev-server (if you do not have one already), performing an update on the dev-server first to see if anything breaks and needs fixes, then migrating updated website(s) from the dev-server to production server. Drush actually has tools to simplify all of these procedures. However, the websites I was updating were not critical, and short downtime was not a problem, so I was updating live websites. Modify these steps as you see fit to make the process more reliable.
3. Backup databases of all your sites. With drush: drush @sites sql-dump --result-file --gzip. This puts backups somewhere into the home directory of your webuser. Backups are named with a human-readable timestamp. Of course, you can also create a manual Backup and Migrate backup, or use phpMyAdmin, or just mysqldump.
4. Backup your site’s files. This step might be unnecessary, as drush seems to backup modules it is upgrading. I would still recommend making a backup, e.g. with tar -acf multidrupal.tar.bz2 html, where html is the directory containing your multisite Drupal’s root index.php.
5. Put the websites into maintenance mode and clear all caches; see the D7-specific note above: drush @sites variable-set site_offline 1 ; drush @sites cache-clear all.
6. The actual update! The easiest way would probably be to drush @sites pm-update, but I haven’t tested that and used a process which I understand better, and which seems more reliable to me (if anything goes wrong). If in your drupal root you have sites/site1 and sites/site2, then run:
   
drush site1 pm-updatecode
drush @sites updatedb
drush site2 pm-updatecode
drush @sites updatedb

   The pm-updatecode command only updates files, and does not run database update. So with these commands I am first updating modules from site1, then running database update on all sites, then update modules of site2, and run database update on all sites again. Running drush @sites updatedb multiple times, even when there are no updates, should be safe. Take note of any warnings/errors reported, you will want to fix them later, for example:

   WARNING: Updating core will discard any modifications made to Drupal core files, most noteworthy among these are .htaccess and robots.txt. If you have made any modifications to these files, please back them up before updating so that you can re-create your modifications in the updated version of the file.

7. Disable maintenance mode. Cleaning the cache seems unnecessary, as updatedb command does that. drush @sites variable-set site_offline 0.
8. Finalize: re-enable anything disabled before the updates, fix warnings/errors you noted during the update.

This worked well for me, and I hope it works well for you.

Symptoms

• running drush @sites pm-update results in normal execution up to after answering ‘y[es]‘; then drush seems to hang indefinitely (haven’t waited beyond about 10 minutes, maybe it does produce an error after a long while);
• running the same command with --debug shows that drush hangs when trying to untar the downloaded module.tar.gz archive; there are no errors/warnings, it just hangs with no CPU usage;
• trying to untar any of the modules downloaded from drupal.org manually is also unsuccessful: tar -xzvf module.tar.gz seems to do nothing, it also hangs with zero CPU usage/time and no warnings/errors;
• interestingly, if I create some test.tar.gz locally, tar does happily extract that;
• finally, running strace tar -xzvf module.tar.gz shows a number of unexpected lines, such as references to NSS and libnss files (I am only showing some of the lines of strace output, including the last line):
  

  open(“/etc/nsswitch.conf”, O_RDONLY) = 4
  read(4, “# /etc/nsswitch.conf\n#\n# Example”…, 4096) = 683
  open(“/lib/x86_64-linux-gnu/libnss_nis.so.2″, O_RDONLY) = 4
  open(“/lib/x86_64-linux-gnu/libnss_files.so.2″, O_RDONLY) = 4
  open(“/etc/passwd”, O_RDONLY|O_CLOEXEC) = 4
  open(“/usr/lib/x86_64-linux-gnu/libnss_mysql.so.2″, O_RDONLY) = 4
  open(“/etc/group”, O_RDONLY|O_CLOEXEC) = 4
  open(“/etc/libnss-mysql.cfg”, O_RDONLY) = -1 EACCES (Permission denied)
  open(“/etc/libnss-mysql-root.cfg”, O_RDONLY) = -1 EACCES (Permission denied)
  futex(0x7fd0816e8c48, FUTEX_WAIT_PRIVATE, 2, NULL

Analysis
strace output provided enough information to understand the issue and generate a workaround. Briefly, we see tar querying users and groups information. On the system where this problem was identified, MySQL is used as a name-service back-end. This is why we see references to mysql libraries in the trace. Apparently, tar is trying to resolve some user/groups information, but for some reason does not get what it is asking in a timely manner, or possibly never gets it and will only fail/proceed when the request times out.

Workaround
Not a solution, but works: tar -xzv --numeric-owner -f module.tar.gz. The --numeric-owner switch asks tar to use numeric file/directory owner information as-is, without trying to resolve the name of the owner. This works. I have not checked strace for the workaround, but I expect to see no MySQL/NSS references in it with the switch.

To actually be able to use drush with this workaround, I had to edit drush.inc somewhere under /usr/share/drush/; look for ‘tar ‘ string, and add --numeric-owner where necessary. Do not forget that -f has to be just in front of the archive filename, otherwise your edits will not work.

This is how to do that in Drupal 7 (Views 3):

1. edit the view which makes the block available (follow http://your.site/admin/build/views/viewname/edit)
2. in the Sort Criteria section (under Filter), look for and add Global:Random.

This is how to do that in Drupal 6 (Views 2):

1. edit the view which makes the block available (follow http://your.site/admin/build/views/viewname/edit)
2. in the Sort Criteria section, add the Random criteria.

It can’t be simpler than that.

In this post, I’m briefly reviewing 4 themes (atck, blueprint, framework, and zen), made specifically to serve as theme developer’s starting point. All 4 are listed with their features (as per Drupal project page of each one), with my personal “impressions” (not based on actual use experience, yet). There’s also my choice and order of preference for the 4 candidates at the end.

Advanced Theme Construction Kit (ATCK) (see also atck homepage and atck on-line layout builder tool)

1. WYSIWYG grid builder
A browser-based grid builder which produces starter code for a page.tpl.php file. The grid builder itself was originally built by Christos Constandinou and it uses a modified version of Yahoo Grids which is more flexible and easier to customize. With Christos’ permission (thanks, Christos!) it, and the supporting css, has been customized so that it works for Drupal themes and so that it is css3 valid. Access the builder online (FF only!), or download it and run it locally. [builder cannot be on Drupal.org because of MIT license]

2. style.css [separate download because of BSD license]
style.css contains only the css needed to support what the grid-builder outputs, as well as some general ‘resets’. The only modifications one should need to make here would be if they want to make their layout a fixed width and/or a different width (default widths are in %).

3. page-layout.css and template.php
These files are where the visual styling of the site happens. The source of these files is from a combination of code from the Hunchbaque theme and some changes/additions which I added in order to provide baseline settings I prefer and/or provide more granular settings. The beauty of these files is the simplicity of them – they include as little markup/styling as possible to avoid complexity, while at the same time putting many helpful tools/comments at your finger tips so that you can accomplish what you want.

4. page.tpl.php
A sample page.tpl.file is included as a reference for finishing your own page.tpl.php file using code output from the grid builder. Note particularly the variable names for the blocks, regions, menus, etc. (at this point the builder does not include those items)

5. fix-ie-6.css and fix-ie-7.css
These files are included for purposes of providing IE-only css to each of the respective versions. By using conditional comments like this we keep the main css files hack-free and atck css3 valid.

Impression: atck is very easy to make initial block layout from scratch (thanks to builder), it has separate fix-CSSs for IE6 and IE7, is very flexible even in complicated grids, and is code-documented.

Blueprint: theme for developers (also required: Blueprint CSS Framework)

* normalizes Drupal’s CSS to be consistent
* properly aggregates all blueprint CSS files into a single file when this setting is enabled
* put scripts at bottom of page for nice performance gains, read more: http://developer.yahoo.com/performance/rules.html#js_bottom
* flexible layout, from 1 to 3 columns, based on where you configure your blocks to show (left, centre, right)
* SEO optimization without the need for heavy modules and additional queries per page
o automatically adds META description to many pages, read more: http://googlewebmastercentral.blogspot.com/2007/09/improve-snippets-with…
o automatically adds META keywords if taxonomy exists on that node, read more: http://searchengineland.com/070905-194221.php
* better forum icons, http://drupal.org/node/102743#comment-664157
* improve forum display and performance, http://www.sysarchitects.com/node/70
* prevents duplicate form submissions with jQuery, read more
* shows the # of comments below a node since Drupal doesn’t do this by default (usability)
* highlight any comments by the author of the node
* adds a “you need to login / register” box below all comments if you can’t add a comment (usability)
* supports conditional comment subjects, if the setting is off it won’t show a chopped off title of the comment
* uses CSSEdit http://macrabbit.com/cssedit/ comments for grouping of styles
* lots of comments and theming tricks in template.php to learn from

Impression: blueprint has some not-really-theme-design-related features; blueprint is a whole framework with docs; it has single ie.css for fixes; it requires framework knowledge; blueprint’s css modifications aren’t easy (em-to-px and px-to-em conversions).

Framework theme: blank canvas for theme developers

# Framework gives general placement and formatting to basic Drupal elements
# Fixed width of 960px by default. Main column resizes between two-column and three-column layouts
# CSS file is highly organized, including a table of contents, colour codes, section flags, alphabetical properties, etc.
# Includes a list of CSS utility classes for easy content formatting
# W3C valid CSS 2.1 / XHTML 1.0 Strict
# Verified and tested with Firefox 3, Firefox 2, IE7, IE6, Safari 3
# Search in sidebar (as a block) and header (as a theme configuration option)
# Clean and simplified code and file structure
# Works nicely in mobile browsers
# The administration section is adapted from the default Garland theme

Impression: good and simple starting point; code-documented; has ie.css and ie-6.css fix files; far lighter and easier than blueprint, but less capable than atck.

Zen: starting theme for Drupal (plus online docs)

* Well documented php and css files.
* Lots of easy-to-access classes and ids for CSS developers.
* Classes on body include items like “logged-in”, “not-logged-in”, “front”, “not-front”, as well as the node type (“node-type-story”, “node-type-blog”, etc) for single node pages. This can allow CSS developers to do things like have a different colour for a given page item for non-logged-in users, have a larger header section on the front page, or put a different background colour on a given node type.
* Automatic (table-less) column resizing for 1, 2, and 3-column layouts.
* Separate layout.css file to allow for changing the type of column layout (holy grail, jello mold, etc).
* A print.css file optimizes print display automatically when sent to a printer — removes, sidebars and nav elements, optimizes font size, adds text to links showing href, etc.

Impression: code-documented plus extensive online documentation; has print.css; has sub-theming guidelines to simplify future support and enhancements of customized sub-themes (has a STARTERKIT sub-theme ready for customizations); also has “happy user testimonials” :). For one of the new Drupal-based projects I decided to try this one. Next in line are (in order of preference): atck for complex layouts *or* framework for simple sites, and blueprint isn’t quite to my liking (so far at least).

• Setup wizard for the free JW FLV Media Player (and the JW FLV Media Player itself)
• Flash Video in Drupal 5: A complete multimedia tutorial to the flashvideo module
• actual flashvideo module page on drupal.org

Intensively working with Drupal during the past two weeks, I find it to be an excellent tool, and also much more than a YACMS.

Now I think that Drupal is also a framework – providing invisible to developer caching, session handling, access control, theming, localization, and more. The minimal effort required to extend already huge Drupal functionality is to write your own module – and, if done right, your module will immediately benefit from all the bonuses Drupal provides.

But Drupal also really shines as a CMS! You can start with a free design theme, and without any PHP knowledge have your custom portal built within a week – with your own hands, if you desire! (Note: “within a week” is true, but only if you already know what exactly you should be doing; learning time is short, but it’s not within that same week.)

What makes Drupal so powerful? I’d say that beautiful core and numerous modules.

What Drupal has to offer?

In theming, it uses by default PHPTemplate engine. It’s simple – just HTML, with PHP tags inserted where dynamic content should go. It’s logical – you have separate layout files for the whole page, for blocks, for content (nodes), etc. That won’t be an exaggeration, if I say that Drupal themes support allows 95% of designs to be easily implemented. (5% go to static xHTML and ExpressionEngine )

You also have blocks in Drupal. Blocks might be the oldest component of almost all CMSs, but the power of Drupal is that you have full CSS control over blocks. And you can also individually control the HTML of any block – using the same PHPTemplate files, as for general Drupal theming!

CCK, content construction kit, is the candidate module for the inclusion into Drupal core. It allows you to actually construct content types the way you want. If you have a custom-designed web-site with several differently displayed sections – just create new content type for each section, and add only the information needed for each section’s content items! Then show your content, using theming. Or using contemplate module – which is a “visual editor for content display themes”. That’s purely point-and-click.

Views module is another shotgun in the powerful arsenal of Drupal. It allows you to build custom pages and blocks from the content and content types you have. And not a single line of PHP or SQL has to be written*. (*: if there is a view which fits your needs.)

If you decide to dive into some more details – grab the devel module, it greatly facilitates development for Drupal.

Choose Drupal. It’s strong, flexible (to the point that someone might call it a drawback), versatile, highly extendible, secure, and much more!

Here’s what I mean:

• user levels were changed to user roles – just like in Drupal
• now, instead of categories and just recently introduced tags, the word ‘taxonomy’ is used – which is a Drupal slang
• ‘widgets’ work just like ‘blocks’ in Drupal – even style IDs are assigned the same way, e.g. id=”widget subscribe_to_comments_widget”
• (add here the similarity you found yourself)

I wonder, what will be next. PHPTemplate support, as default theming engine?
Or no-backwards-compatibility policy?
Or, best for WP users, advanced Drupal-like caching and throttling techniques?

Please comment if you know of any other good high-quality technical Drupal introductions/descriptions.

i18n module
i18n: Getting the whole thing to work : http://drupal.org/node/81094
Patch: Translations of menu titles and descriptions: http://drupal.org/node/70919
Translated links: http://drupal.org/node/67814
i18n: menu not expanding with URL-Alias: http://drupal.org/node/80820

There was an alternative module to i18n, but I cannot find it at the moment.

Following the discussions, installation and administrative interface became much simpler, and thus easier for newbies. Other first-impression change is said to be the new default theme, which looks good as well.

I will surely check this new release out very soon, but for now you can try one yourself.

Update: beta-2 is available since November, 28, with over 160 bugs fixed.

Now there is a Drupal 6.x module available. It is in no way related to the migrate script(s) below.

The newest script version migrates from PHP-Nuke 6.5 to Drupal 5.x.
Download the latest version of the migration script.

In 2002 I set up a PHPNuke-6.0 – based portal. Eventually it died due to the lack of time investments and support from collaborators. Now, when time came to revive the project, I made a search and decided to use Drupal as a base CMS for the portal.
In order to migrate userbase from an old portal to the new Drupal-powered one, and following the topic at drupal.org, I found a script and its modification.
I used it to migrate only users, and made some cosmetic changes:

• added options for custom phpnuke table prefixes
• default user name is now = uname (login), not ‘temp_name’, as before
• I replaced hard-coded links to ‘migrate.php’ with links to $_SERVER['PHP_SELF'], so that if you rename the script you don’t have any problems with that
• now forum topics should not be promoted to the main page (changed 1 to 0 as hinted by Alexis)

Finally, I would like to thank both Karthik Kumar for the original script and Alexis Bellido for the 6.0_to_4.7 modification.

Update: Waldo updated the migration script.
Here are the changes:

• imports from (a security-patched) Nuke 6.5 -> Drupal 5.1
• imports story categories into Drupal taxonomy
• incorporates phpnuke “Contributor writes…” into story
• incorporates phpnuke admin story “note”
• imports polls (does not import record of who already voted. You can easily “close” old phpnuke polls via Admin page. I left them open.)
• imports poll comments
• imports *anonymous* comments for stories, fora, & polls
• imports anonymous forum posts
• filters BBCode to make semi-compatible with Drupal BBCode module
• uses Drupal 5.0 API, and must be run from drupal root directory (/drupal-5/, for example)

Thanks to Waldo for his work!

Latest update: Waldo sent the newest, improved version of the PHP-Nuke-2-Drupal conversion script. Here is Waldo’s description:

New Fixes:

• retain original user registration date & last visit 4/22/07
• fixed user migration bug which could result in screwed max_uid in session table 4/22/07
• store anonymous forum posts names in the log for future compatibility w/Drupal 6 7/16/07
• uses the “tidy” extension (if installed) in php 5.x to clean up the HTML of postings & stories 7/30/07
• bug fixes (possibly) related to drupal 5.2 where the fora had the wrong “changed” date resulting in misordered node lists. 7/30/07
• polls properly remember date of last comment 7/30/07

If you have the “tidy” PHP extension, it should close all open HTML tags and stuff in stories.

update: I added to the script some more debug messages in case something goes wrong (as recommended by me) – that pushed the version up to 0.03.

Also, now MySQL connection collation is set to utf8 before doing anything – this should fix the problems with non-English characters in the imported texts (especially accented/umlauted/etc characters). Thus I upped the version to 0.04. For reference and in case 0.04 doesn’t work for you, I keep the older versions as well.

Download the latest phpnuke2drupal-5.x-0.04-W.zip or the latest tar-gzipped version of the phpnuke2drupal migration script.

update: to import Reviews and WebLinks from PHPNuke to Drupal, have a look at this and this comments; you will need CCK, and might need CCK Link Field to import reviews/weblinks.

Previous (older) versions:
phpnuke2drupal-5.x-0.03-W.zip
phpnuke2drupal-5.x-0.03-W.tar.gz
phpnuke2drupal-5.x-0.02-w.zip
phpnuke2drupal-5.x-0.02-w.tar.gz
phpnuke2drupal-5.x-0.01 (VValdo’s huge improvements first appear here)
first version with my minor modifications

IMPORTANT: for migration to work you will need MySQL version to be >= 4.1.1. Earlier versions do not support the STR_TO_DATE() function, used in the migration script.

IMPORTANT: if you want to migrate forum entries from PHPNuke to Drupal, be sure to setup forum in your Drupal installation first – otherwise migration of forum entries will fail. See comments 13-17 below for user experiences.

If you do not get any help here, there is also a drupal.org migration thread. I will keep this page updated for as long as I get new information about the migration script.

If you encounter any problems during migration – just search/scan the comments, your problem might have been already solved by someone else.