Ecommerce used to be the preferred ecommerce solution for Drupal before Ubercart came into the picture. We recently worked on upgrading a Drupal 5 site with Ecommerce to Drupal 7 with Ubercart. The challenge with this upgrade was that the source data existed only in the D5 database and the corresponding code to programmatically access the ecommerce data was in D5 as well while the destination tables existed only in the D7 database with the corresponding code existing only in the D7 database. The solution we went with was to go for a full SQL query based migration to copy over the Ecommerce data from its tables to the Ubercart tables.
The default behavior of drupal_redirect_form in Drupal 6 is to redirect the user to $_GET['q'] when an explicit redirect location is not set in $form_state['redirect']. So any form submission from a Drupal page with additional querystrings like in a paginated form (for example admin content listing forms or admin comment listing forms) will result in the querystrings being lost. This can be frustrating when you administer content from such forms as you have to click the pager link and go back to the previous page after form submission. This can easily be fixed by adding a submit handler for the form in question and setting form_state redirect correctly.
The default comment moderation system in Drupal 6 is crude at best primarily because of the limitation of the admin comment listings. The information that is shown by default are 'Subject', 'Author', 'Posted in', 'Time' and 'Operations'. Now the main objective of comment moderation is to reject spam comments. None of these fields give any information about whether the comment is a spam comment or not and you will have to view each comment by going to the edit view of the comment and then approve or reject the comment. This is a very laborious and frustrating process. You have three options to solve this problem and get a better comment administration interface - one is to create a comment view, another is to alter the default comment administration form and the third is of course a custom solution for comment administration.
APC or Alternative PHP Cache (APC) is a free and open opcode cache for PHP. APC allows for caching of opcode generated during PHP script parsing and execution by the Zend engine. If you are using APC 3.1.9 and you are using the default configuration you might run into the error where most PHP requests will return a warning message "PHP Warning: Unknown: Unable to allocate memory for pool. in Unknown on line 0"
One of the Drupal sites we maintain had recently started slowing down considerably in spite of the site mostly being static and in spite of boost set up on the server. On examination of the site we found that two things were happening on the site. One was that the site was being crawled indiscriminately by rogue crawlers. This we solved using the DDOS deflate script and setting DDOS deflate to run every 10 seconds. The second problem was that there were some bots which were continuously sending POST requests to /comment/cid/reply pages. For this we had to come up with a workaround.
In Drupal every path in the site goes via index.php and goes through some Drupal menu. However to make the Drupal application behave live a typical static website in terms of URL architecture sometimes clients request for adding slashes to the end of virtual direcotry paths. At the same time slashes would not look good at the end of virtual file paths. There is an easy way to do this using apache htaccess rules
Sometimes we get requests to update Drupal sites and get it done in less than 5 hours. If we take the Drupal update through the full fail-safe set of steps for Drupal updates we will never be able to complete updates in less than 5 hours on a site we don't maintain. For such sites when the cost of the site going down may not be too high for the site owner it might not be too big an issue if the update is run on a hit or miss approach. We normally do not recommend such an approach but this should work on most small sites without any issues.
Keeping the Drupal core and contributed modules up-to-date (at least on the security updates) is one of the essential steps for keeping a Drupal site safe and secure. Running updates of Drupal modules is usually a straightforward mechanism on a Drupal site that is done right. However what will you do if you do not know how things have been built? What will you do if some of the custom modules used are tied down to specific versions of some contributed module? What if there were custom changes on the site. Here is how you can run updates on a Drupal site almost completely safely.
When you want to move a Drupal site from one hosting server to another you have to ensure that the site works the same way on the new server as it used to work on the old server. There is no real fool proof way of doing this other than to meticulously document all the custom aspects associated with setting up the site and verifying it on the new server. The following is a checklist of information you have to collect before you move your Drupal site from one server to another.
Checklist: Migrate from one server to another
If you own a VPS or a dedicated server or a hosting server which allows you to have shell access then you can easily set up your own git server with as many users and as many repositories as can be stored in the space on your server. All you need to do this is a bit of system administration skills and a hosting server that allows you shell access. Read on to see how you can set up your own git server.