One of the greatest things about the Drupal CMS is that it can support *any* look and feel you want it to in a just click of a button. Or at least it can once you have the theme you want designed and "Drupalized".
Themes/designs are a very unique part of a web site, because they they simulataneously are "just" a wrapper for the content on your site - while at the same time being *the* main element which keeps your site from just being a bunch of text splattered on a page (screenshot of this page without an active theme).
So, the visual design of your site is one thing in itself, but it's only a beginning, and in a proper site construction a theme should start out literally as a 'pretty picture', mocked up in Photoshop for easy experimentation/changes.
What happens after this stage in theme development is an entirely different case altogether, because now we're moving from a 'pretty picture' to working code, which will affect browser compatibly (do Internet Explorer 7 users see your page as a blob?), download speed, and usability (does the link to the contact page not work for Firefox users?).
The coding stage is where expertise and testing become necessary in order to keep a your design from becoming a nightmare in terms of usability, compatibility, and flexibility.
So, a good theme is not coded to not just look like the pretty picture you started out for one browser, but to also:
look and behave correctly across a wide variety of web browsers - now and for the future
be flexible enough to provide future customization and extensibility. Having a theme that falls apart or cannot support at least minor revisions to the layout will be very limiting later on if you need to change things up.
Resouces Design resources: HigherVisibility Theme Library Hundreds of high quality themes, for dozens of categories. Browse and brainstorm - themes available in raw format, or professionally Drupalized
In addition to the U.S. and international markets which HigherVisibility serves, we also have a non-virtual home in the Sacramento area, which gives us and our clients more opportunities for the kind of personal face time that isn't always an option when communicating thousands of miles away.
So, if you're in the Sacramento area and are looking for world class web design, online community building, blogging tools, or intranet development - all done with the best open source tools available contact us.
(This article is made specifically for showing how to get raw content into Drupal, but the methods below can likely be adapted for other use cases [we also imported a list of users using these techniques for instance].)
Importing raw content into Drupal, can be, well let's just say it's not always easy. In two years of experience with Drupal we've imported a MoveableType site, a Blogspot site, content from one Drupal site to the other, and now raw data from a csv file (raw meaning that it did not come from some other CMS/website), and we've used everything from custom scripts, several different Drupal modules along the way including import-exportapi.module, userimport.module, nodeimport.module, WordPresstoDrupal.module.With the exception of the WordPresstoDrupal.module we've been mostly disappointed with the results of our experiments with the Drupal based import options. That said, this may not be the best method to start off with if you can find a ready-made solution that works for you, since it is somewhat time consuming.
Besides being a somewhat complex thing to begin with, the issues around importing content into a Drupal installation are exacerbated by the wide array of variables any point and click solution has to contend with. It's impossible for any module developer to be able to keep up with the number of different/custom Drupal content types for even one version of Drupal, let alone for all new versions of Drupal.
In short, for the serious site-operator/Drupal developer getting raw content imported to Drupal is always going to be a problem because one size is never going to fit all (the 'bad' side of such a customizable platform). This is important to understand in order to fully appreciate the workaround below, which is not particularly easy or fast, but is 99.9% reliable from a data integriy standpoint.
"How's that," you say? Well, because the following method does not actually "import" anything at all, at least not in the traditional sense that most people think of when adding new content into a database. With this method you'll create complete Drupal nodes with SQL, which you will then simply place it in your existing database. Nothing is automatically calculated, scripted, or extrapolated - which is exactly why this method is not easy or particularly fast, but also why it is precise:
In brief: Create two separate sql import files. One for the "node" table of your database, and another for the "node_revisions" table. The last step will be to update the "sequences" table to let the system 'know' about the new content.
(these "node" and "node_revisions" tables are used only for certain module based content types not for cck nodes - though you could adapt these instructions to create new cck nodes by figuring out what tables you need to populate and using the techniques below)
This past Sunday (1/20/07) we launched the second generation HigherVisibility site. Like all of the sites we make, we used the most modern best practices and technology to assemble it, including:
Drupal 5.0 with absolutely no changes/hacks applied to any of the code or modules. As you can see from the site, committing to not using hacks on the Drupal "core" files does not mean sacrificing customization. Since we did not modify Drupal's core files in any way, upgrading to new versions of Drupal will be mostly a drag and drop process for us. Additionally, since we use the cvs versioning system we'll be able to track changes in Drupal core as we update and see exactly what the differences are from version to version.
In addition to the core Drupal 5 modules, we also have the following contributed modules actived:
So you've got an Xtemplate that you need to convert to the PHPTemplate format because you've found out that the Xtemplate has become a third rate citizen at Drupal.org? (many modules don't support Xtemplate themes anymore, Drupal.org doesn't consider it a "supported" format, and "theming" Xtemplates is much harder than with PHPTemplates)
Well, no problem.
With a little work it is relatively easy to convert your Xtemplate into a much more compatible, supported, and extensible PHPTemplate. In fact, there's a very good handbook page at Drupal.org about this issue which I came across and have used to convert several of my own Xtemplates.