-
Tue 27th Jul '10(article)
-
Sun 4th Jul '10(article)
-
Wed 30th Jun '10(article)
-
Wed 30th Jun '10(article)
-
Tue 27th Apr '10(article)
- 1 of 5
- ››
I recently undertook a migration from oscommerce to ubercart. The scope of this migration was limited to the transfer of products (and categories) - I didn't try and migrate customers and previous orders.
There are several different PHP accelerators to choose from, but according to wikipedia "APC is quickly becoming the de-facto standard PHP caching mechanism as it will be included built-in to the core of PHP starting with PHP 6".
I recently put together a new development webserver in a virtualbox virtual machine, and as I was setting it up I thought I'd take the opportunity to test how much difference APC actually makes to a simple Drupal site.
This is going to be a more philosophical post than usual, with not a code snippet in sight. I'd like to share some thoughts on the motivations for, and benefits of, submitting patches (I'm talking about Drupal, but this could just as well apply to other open source projects). In case it's not obvious, the title is a reference to the ghostbusters theme tune!
This week I found myself trying to debug some code used in an autocomplete CCK widget on a Drupal site. Because this is code is AJAX and doesn't follow the normal pattern of a full themed drupal page load, many of the unglamorous but useful debugging techniques such as dumping arrays and objects as drupal messages or JS alerts are no help; the only message or alert I was seeing a lot of was a 500 error dialogue.
For my recent post comparing compression methods for database dumps I had some very simple data, and wanted to present some very simple charts. None of the many charting modules for drupal seemed to be simple enough for me, so I borrowed some code I found on the web and made my own drupal module.
I like to have automated daily database backups set up on my servers - for those hosting relatively small sites, the database dumps can usually be compressed down small enough to be sent as an e-mail attachment by the cron script which does the database dump. This is a really simple and cost-effective way of having offsite backups which provide daily snapshots of sites which are easy to access if anything goes wrong.
I haven't used shared hosting for quite a while, but for a few sites I've worked on recently an account on a shared host seemed the best choice in terms of how much disk space and bandwidth they'd get for a very small cost.
One obvious problem with shared hosting though is the lack of control; I was careful to choose a package which provided up-to-date versions of apache, php and mysql but subversion was not installed, and the version of vim on the server didn't have support for some basic things like syntax highlighting.
I was recently doing some work in a hotel, and when I came to commit my changes back to my central subverson repository using git-svn, I got an error message that looked a lot like this:
Committing to http: //example.com/top_secret_svn_repo/trunk ...
RA layer request failed: Server sent unexpected return value (400 Bad Request) in response to MKACTIVITY request for '/top_secret_svn_repo/trunk/!svn/act/7cc9df3f-2956-3669-8f25-45c093142061' at /usr/lib/git-core/git-svn line 3347
Some of Drupal's CCK modules such as filefield and imagefield have support for a neat Upload Progress meter.
You may have seen a message in the status report of your Drupal site saying something like... "Upload progress not enabled - Your server is capable of displaying file upload progress, but does not have the required libraries. It is recommended to install the PECL uploadprogress library (prefered) or to install APC."
Here are some useful configurations for bash, vim and screen. Every time I have to set myself up on a new machine, I end up copying these files from a machine where I've already got an account. I thought perhaps it'd be easier to put the settings on a webpage. If anyone else finds these useful, that's a bonus.
(snippet, not the whole file)