management

`

When I was rebuilding www.lifeisaprayer.com in Drupal, I decided to use the testing domain new.lifeisaprayer.com. This presented me with a challenge, once I started working a bit more on the site, as I set up imagecache, the file system, the favicon, the logo, internal images in posts, images inserted into blocks, etc., into my /sites/new.lifeisaprayer.com/files directory.

If I simply renamed the directory to 'lifeisaprayer.com' and went live, I'd end up with tons of 404 errors. Currently, there's no easy way to switch the location of your files directory in Drupal. Lacking an easy method, it's time to get your hands dirty with a little SQL (I entered the following commands via phpMyAdmin, since my host doesn't yet allow SSH access):

• Update the files table (which is used by the system as well as imagecache):
  • UPDATE `files` SET `filepath` = REPLACE(`filepath`, `sites/OLDDOMAIN/files/`, `sites/NEWDOMAIN/files/`);
• Update the boxes table (which is used for all the block content):
  • UPDATE `boxes` SET `body` = REPLACE(`body`, `sites/OLDDOMAIN/files/`, `sites/NEWDOMAIN/files/`);
• Update the node_revisions table (all the node content is in here... you'll need to update both the body and the teaser fields):
  • UPDATE `node_revisions` SET `body` = REPLACE(`body`, `sites/OLDDOMAIN/files/`, `sites/NEWDOMAIN/files/`);
  • UPDATE `node_revisions` SET `teaser` = REPLACE(`teaser`, `sites/OLDDOMAIN/files/`, `sites/NEWDOMAIN/files/`);
• Update the users table 'picture' value (if you're using user pictures):
  • UPDATE `users` SET `picture` = REPLACE(`picture`, `sites/OLDDOMAIN/files/pictures/`, `sites/NEWDOMAIN/files/pictures/`);

Now make sure you clear your cache tables (I just used 'Clear caches' in my Admin menu), then empty your watchdog table (TRUNCATE `watchdog`;) and look for any 404 errors. If you find a bunch, there might be another field you need to update with your new filepath.

Hopefully Drupal core will be better able to handle file moving in version 7—I haven't studied that too much yet, but I've heard files will be treated more as 'first class citizens.' Until then, you can either have fun with the above MySQL queries, or you could use private file handling (which uses a path such as /system/files, and allows your file path to be whatever you'd like).

(One other solution is to set up a folder like /sites/sitename instead of /sites/sitename.com, and set up a symlink to the /sites/sitename folder... that's okay, I guess... but not ideal. It would be best if Drupal could handle this stuff (path aliasing, etc.) out of the box.).

I follow a lot of Twitter users among my accounts; probably somewhere around 400-500 different twitter-ers. Because of this, I often get some awesome links to tutorials, guides, how-tos, and general information; many links which I would miss otherwise, because they won't show up on reddit, digg, or other social link sites.

When Twitter users give high-quality, low-visibility links, users read their tweets and blogs more often than the users who spam their Twitter streams with tons of links to their own content. In my opinion, very few people can often and consistently write top-notch content on their own blogs. There are exceptions, but most bloggers are not professional writers, and therefore need to focus not solely on their own writings, but on others' as well.

For both my geerlingguy and MidwesternMac Twitter accounts, I usually just give one link to a new posting from my sites that I think might be interesting, whereas I might re-tweet or aggregate links to many other people's sites throughout the course of the week. Why? Because I think that will be more helpful to the people following my Twitter stream. And that, along with my ability to communicate with them via Twitter, is what will keep them following me.

I was browsing the Drupal Theme Garden a few days ago and was reflecting on how incredibly boring (if not ugly) a large share of the themes looked. Out of all the themes I viewed (over 50), I might consider using only 10 or so on a production site for a quick project that I didn't want to create a theme for.

Later on, I read this post on Steven Witten's blog [Acko.net] from 2007, and read through every single comment, because I am extremely interested in the issue of Drupal theming. If you are at all interested in helping Drupal be more themeable and appealing to designers, you must read the post linked to above. Go ahead - read it. I'll wait...

...okay, now that you're back,

A few of the comments in Steve's blog post deserve a mention...

From the blog posting itself: "Not enough Drupal people are savvy enough about theming and design to help out with even small tasks (like a banner) or even give quality tips and feedback on other work. The result is that theming and design receives little attention. Most contributed themes and sites could look a lot better, if they just themed it some more. And getting patches into core that give the defaults a little more oomph is tough, as they are often considered to be useless embellishments.

I use an RSS news reader application to browse stories from blogs and websites that I am interested in following. To stay in my news reader for more than a few weeks, a website must do two things:

1. Consistently offer 'meaty' and well-written posts.
2. Not 'spam' me with posts (i.e. no more than 2 posts a day, unless the content is really good or really interesting).

If you'll notice, none of my criteria include "Have many, many posts a day." The reason for this is simple: My time is valuable, and I don't want to waste it browsing through mushy, meaningless content—even if that time is only a second or two. A lot of people think they should post early and post often, sometimes re-blogging what others have already said, but this is not a good strategy for retaining site subscribers and readers, even if it helps your search-engine rankings a little. Signal / Noise ratio is probably the single determining factor in whether a site will succeed in gaining loyal followers or not.