Skip navigation


warning: Creating default object from empty value in /var/www/vhosts/ on line 33.

Mark Boulton pulls together some of his thoughts and concerns regarding CSS grids and how they could (or, maybe, should) be created.

Your rating: None


Set the image quality per ImageCache preset!

Through ImageAPI, you can set the quality of images ImageCache produces. But since ImageAPI allows you to set only one global value, any image produced by ImageCache ends up in the same quality. If you want to have the highest-quality images in a photo gallery while having lower-quality images elsewhere, you are stuck.

This module allows you to override ImageAPI's quality setting and set image quality per ImageCache preset. Unfortunately, since ImageAPI does not let other modules hook into / alter the process, you need to apply the supplied (unobtrusive) patches to the following modules for this module to work:

  • imageapi.module
  • imageapi_gd.module
  • imageapi_imagemagick.module
  • imagecache.module

The patches basically only add optional arguments to existing functions so the modules would function as normal (as far as I am aware).
The patches, as well as an instruction on how to apply them / which version of ImageAPI / ImageCache to use, are found in README.txt.

Please remember to always flush the ImageCache cache every time you change the setting, if you want to see the effect immediately.

Development of this module was sponsored by Comic Relief UK

DISCLAIMER: As always, use it at your own risk. If you encounter any issue, please report through the issue queue. The developer or the sponsor cannot be held accountable for any of the damages which the module / patch may cause.

Your rating: None

View settings

The Views Dynamic Fields module provides a filter for use with Views module. This filter allows the user to pick and choose which fields to display for a rendered instance of a view for that user. This provides a customized view instance for each user.

read more

Your rating: None

There are a couple of coupon modules that I found and tried for Ubercart 2.x. However, I found that they are either too fancy, or hard to understand. Normally, a coupon (as advised by Ubercart) are relying on line items, here I take a different approach.

In this module I treat a coupon as a product node with a negative price. This gives several good things:

  • Since a coupon is a node (because products are nodes), you can have a themable page for a coupon, so you can print it out
  • Stock can be used to check if the coupon is (un)available
  • The coupon is attached directly to the order, so you don't need to mess around with the line items - the sum that goes to Paypal is already discounted (somehow with the line items the order lifecycle was quite obscure to me)

The other coupon modules that I've tried and didn't adopt are:

I'm looking forward to Drupal 7 and Drupal Commerce module, so if anyone is interested to take over the development of this module, you're more than welcome!

Your rating: None

Privatemsg advanced

The PM adv module extends the Privatemsg core module.

What exactly makes Privatemsg advanced?

Please read the FAQ in the documentation.

Additional modules

This module also contains the module Privatemsg advanced views.

The PM adv views module extends the Privatemsg core module with extra views functionality.


The PM adv module: Privatemsg
The PM adv views module: Privatemsg, Views

If used version 2 of the Privatemsg core module must be enabled its submodule Block user messages.


The PM adv module cooperates with the modules


From the date on which the Privatemsg module realizes the functionalities of PM adv and PM adv views, is not necessarily this project.

Your rating: None

This is a simple module that adds a checkout pane to the ubercart checkout page to force the user to agree on the site's terms and condition.

You can configure the terms and conditions path.

Configuration screen is at Store administration -> Configuration -> Terms and conditions.

The checkbox label (and link) is themable.

This module has also lightbox2 support. If enabled, it will open the terms and conditions on a lightbox2. You can configure width and height of the lightbox.

Notes for themers and lightbox2:

The module appends a ?format=lightbox2 to the configured path so you can customize the page look (remove sidebars, headers, etc.) of the term and conditions page when viewed within lightbox2.

Refer to Lightbox2 - Howto add a lightbox to your images and other content for further explanations.

This is a replacement for Global Terms and Conditions. I have taken some ideas from it, but simplify the module a little bit and added lightbox2 support. The author of this contribution has agreed to forward further support and comments to this module.

Supported by Infomagnet Ltd.

Your rating: None

Dear all,

I thought it would be very helpful if I would bring it up here.

Our situation is that we are moving a large, multi-user knowledge management Portal into private beta. While we wish to have a "live" version of the site, with content creation, file upload , image upload and addition etc, we wish to maintain active development on several aspects of functionality.

In general, developing functionality, modules, etc, will require modification of the attached database, creation of nodes, views , content types etc on the "Development" version of the site.At the same time that users are adding nodes, content, etc to the "Production" live version of the site.

This would seem to make the advice "record and replication of what you've done" a little impractical. If you design a series of modules and nodes, replicating the node/content is not necessarily trivial. If you design portions of the site based on the node structure (nids or tids etc), and those numbers are taken by the action of users on the "live site," replicating the work can clearly NOT be trivial in many situations.

How do people handle issues such as these in "live, dynamic production environments?"

One solution that comes to mind is to link both live and production versions to the same database, with very frequent automated backup of the db, such that "if anything breaks" because of db changes, the database can be quickly reverted to a previous state (and the broken database etc then inspected). Is this practical?

What other strategies are out there?

Here's my current process:

  1. Dump Mysql production database.
  2. Over-write my development site's database with my production site msyql dump file.
  3. Install the new module/functionality/configuration option code on my dev server.
  4. Reconfigure the module's admin settings on the dev server via the admin interface on the dev site.
  5. Write down - by hand - the module setting changes I've made on the dev site (so that I can replicate them on the production site)
  6. Push the module code changes to production.
  7. Log into the production site, replicate the module setting changes I've just made on the dev site.

This just seems like a lot of work. And what if I don't configure the module settings just the same way on the production site as I did on my dev site?

I really love Drupal, but until I can convince my organization that there are solid ways to test and deploy modules from dev to production, I need to go for other CMS or options.



Kerala Drupal

Your rating: None