Skip navigation

Perl module

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

Sean Gallagher

This Q&A is part of a biweekly series of posts highlighting common questions encountered by technophiles and answered by users at Stack Exchange, a free, community-powered network of 80+ Q&A sites.

Robert Harvey asks:

My team and I are rebuilding a site we developed around ten years ago, and we want to do it in Agile. After I've spent a lot of time reading (probably not enough), I am having trouble with the question of how to divide work between developers.

I'll be more specific and say that the site is divided into separate modules which don't have much integration between them. What is the best/most accepted way to divide the work between the developers?

Read more | Comments

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

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