Here are some notes that might be helpful if you're experiencing problems getting desktop effects to work in Ubuntu Intrepid Ibex 8.10, after enabling dual monitor or dual head support. In my case, the problem is the Intel driver not supporting a high enough texture size. This is not yet fixed in 8.10, but should be at some point. Here is the link: The problem is that compiz is checking GL_MAX_TEXTURE_SIZE and failing if the value is not as high as the Virtual Screen size that's set in xorg.
Requirements: basic css, image editing, basic theming The Fivestar module provides a tidy little voting widget that allows users to vote on nodes. It also provides a CCK field of the type “Fivestar Rating”, which can be used to rate a node on multiple criteria. One of my pet projects, Hill Bomb, requires just this functionality. It's a maps-mashup site for downhill riders, for example skateboarders or mountain bikers, to upload details and maps of awesome hills around the world. places a friendly popup request for IE6 users to upgrade their browsers. By placing a simple conditional comment linking to some JavaScript in your page.tpl.php, visitors using the outdated and buggy IE6 web browser will see a small roll-down on the top of their browsers, “nagging” them to upgrade. After clicking the roll-down, a new browser window opens with links to other recommended browsers: IE6 is a horrible blemish on the web and is the cause of millions of hours of wasted developer time: the sooner we get rid of it, the better.
The Drupal coding standards docs are a great reference for developers, but there's also an automated way of checking your code: the Coder module. Here's how it works: 1. Install Copy to sites/all/modules and enable the usual way. Now you have a new link in Navigation: 2. Choose reviews Click that link, then select exactly what you want the Coder module to do on this page: 3. Targets Select what you'd like to review, there are many different options:
Here's a small one-line usability fix for all module developers, that I think will be a huge help to users. In the early stages of a project, I'm often playing around with quite a few new modules: testing them, seeing if they meet my requirements, installing and uninstalling. After downloading a module, the sequence of steps is always the same: Copy to /sites/all/modules Enable at /admin/build/modules Configure all exposed settings Use!
If you're using the Devel module while developing with Drupal, you may have enabled the “Switch users” block which is great for troubleshooting and configuring permissions. However, if you accidentally use it while your site is in maintenance mode (offline), then you may notice a problem: it won't let you back to the path /user to log in again. The solution is to use the mysql CLI, phpMyAdmin or the database manager of choice to directly empty the sessions table.
Recently there was a bit of heated discussion on the development mailing lists (the good kind!) about module developers doing proper releases. The jist of it being that some modules never get a proper release tagged, and exist as a constantly changing ‘dev’ version that is mostly stable but at any time could contain showstopping bugs as new features are constantly added to the tree. Sure, you may argue that using a dev or release candidate on your site is bad practice, but often they are very stable (it completely depends on the maintainer) and necessary to use.