Just wanted to post these instructions for my own sanity, and so I wouldn't lose them as I've used them numerous times over the past year. Thanks Jeff for the original post:
http://www.midwesternmac.com/blogs/geerlingguy/moving-your-drupal-files…
Today I was setting up a shopping cart with Ubercart and Drupal 7 and I noticed that I was getting two registration emails. One from the Drupal user module that said:
Today I needed to add the newest version of jQuery (1.7) to a custom Drupal 7 theme that I was building. I initially used the jQuery Update module and hacked the replaced version of jQuery with the version I needed. I know, this was not the best practice, but this was a rush job and I was in a hurry (don't hack the core, or any contributed modules for that matter!). Everything was working fine until I wanted to add a new field to a content type and the form quit working in the admin overlay, which was using the Seven theme. Crap!
I recently ran into an issue where I wanted to use a views page as a tab for nodes of type 'course'. I added the view page like normal, providing my path of: node/%/course-list.
Next, I added my menu item entry as a 'menu tab'.
Perfect, except that the menu tab was displaying on every node when I needed it to only display on one node type.
Today, while working on an interactive kiosk, I needed to disable the text selection highlighting. After a few searches I discovered this was possible using CSS.
In order to run a Drush Script from a cron job, you'll need to setup a valid Drush Site Alias. Otherwise, cron will not bootstrap the site correctly and you'll be missing most of Drupal's API functions.
We have a website that updates numerous nodes nightly with an uploaded XML file. This XML file is then processed with Drupal's batch api, and when the XML file is uploaded manually, the script works perfectly. However, in real life, this XML file is uploaded programmatically by a script running on another server. Programmatically, the file gets uploaded and the batch begins properly, but on the successive redirects, the batch fails. This is because, the pseudo browser window from our publishing script closes.
We had a Drupal 7 site setup with a default calendar instance that was displaying content of type 'event'. Due to the limited number of events this site would promote, it was decided to change the navigation from the standard 'Next/Previous' to use drop down menus where the user could choose the month/year they wanted to view.
Today's project required me to fine tune Drupal's standard book module. Basically, I needed to limit the choices in the 'Book Outline' area to only display books that the user was the author of. Unfortunately, Drupal's default permissions don't allow for this. Either the user can administer all outlines or none, nothing in between.
Today I was working on an intranet site using Open Atrium. Our client wanted to post their employee handbook on the intranet using the atrium notebook module. The problem is that, by default, all authenticated users are able to post a handbook item. Obviously, this wouldn't work with an employee being able to modify the employee handbook online.