|
Source: ONLamp.com Steve Loughran’s How to Own an OSS Project, part 1 and especially How to Own an OSS Project, part 2 bring up the always-relevant issues of security, transparency, and trust. In particular, the second entry asks a most insightful question: how can you trust the documentation?
It doesn’t help when the documentation suggests outdated practices which are, at best, dangerous and, at worst, completely wrong. (I’ve patched a few of these in Perl 5, myself.) Add to that active malice, such as a recent
dangerous answer to a novice question in comp.lang.lisp, or running obfuscated code outside of a locked-down sandbox, and it’s almost a wonder there aren’t more security problems related to source code posted on the Internet.
Source: ONLamp.com Thinking of trying the Drupal open source content management system? It’s a powerful platform, but the learning curve can be steep, even if you’re already comfortable with its underlying technologies: PHP, MySQL and CSS. As the volunteer webmaster for the Monterey County (California) Democrats, I’ve gotten deeper into this stuff than I ever anticipated, and believe me, I know that learning curve well. Here’s a list of some of the top gotchas. Some of them are just plain good web development practice, but they become especially important with Drupal, and even more so if you’re using the CiviCRM contact relationship management module.
Create a test site first, then deploy on your live site. Even experienced users find themselves with a site that has suddenly gone crazy or dead after an update, and you want to be fixing the problem on the test site, not the live one.
Backup up your site files and MySQL DB regularly! Especially before any significant changes, such as an update (within a major software release) or an upgrade (from one major release to another). Drupal provides automated update/upgrade tools, but you can’t always be sure they’ll work with your configuration. And if they don’t, you could be in serious trouble if you have no backup, as your DB might get corrupted. And remember to log in as the admin user (user 1) before doing the backup. It’ll make it easier to get back in control if you have to restore the site.
If you work on a Mac, remember that you may need to convert Mac carriage returns to Unix newlines before uploading a file. For example, if you dump a DB file to your Mac (as you might during a backup), restoring it may fail if you neglect to replace the carriage return (you can use this shell command in the Mac Terminal: tr ‘\r’ ‘\n’ UnixFileName.xxx)
Pay careful attention if you make any changes to settings.php or civicrm.settings.php (if you’re using CiviCRM). These files identify where your DB is and how to log into it, among other important details. Making a typo here is a common source of sites turning into blank screens.
Caches, cookies and session files are often sources of strange behavior. After updates and upgrades, or on occasion when the site is acting oddly, you may need to empty (not drop) your DB’s cache and/or session tables (you can use PHPMyAdmin, provided by many web hosts). You may also find that clearing your browser’s cookies and emptying its cache will fix some misbehaviors (such as not being able to log into your site).
When moving or copying your site files, keep track of the invisible file .htaccess. A missing .htaccess file (as can happen if you do a “cp *” shell command) will break the site.
Check that all your Drupal access permissions are in order. For example, if anonymous users don’t have access to nodes, they won’t be able to see any content.
When upgrading, make sure to disable all 3rd party modules first, and then re-enable them after the upgrade - checking that you have the latest, compatible version of each. Modules are a leading source of weirdness during upgrades.
If you upgrade CiviCRM, make sure you remove all previous CiviCRM files from the site’s modules directory (back them up first!). CiviCRM will search throughout that branch of the directory tree, and all kinds of confusion will result if old files are hanging around.
And pay careful attention to compatibility among your versions of Drupal, Drupal’s themes, 3rd party Drupal modules, CiviCRM, PHP, MySQL and Apache. Before upgrading, make a compatibility matrix to make sure everything you need will still work after the upgrade.
|
