Right now, colorizer stores everything in the variables table, so if 1k groups customize their appearance, that's 1k extra variables (loaded out of cache and into memory every page load).

CommentFileSizeAuthor
#1 2481607-colorizer-database-1.patch6.01 KBhefox
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

hefox’s picture

mpotter’s picture

+++ b/colorizer.admin.inc
@@ -267,15 +267,7 @@ function colorizer_admin_form_submit($form, &$form_state) {
-    // Delete old files.
-    foreach (variable_get('colorizer_' . $instance . '_files', array()) as $file) {
-      @drupal_unlink($file);
-    }
-    if (isset($file) && $file = dirname($file)) {
-      @drupal_rmdir($file);
-    }

Not sure why the file deletion code was removed. Don't see it in colorizer_delete.

  • hefox committed 4773e5c on 7.x-1.x
    Issue #2481607: Use database storage instead of variables
    
hefox’s picture

Status: Needs review » Fixed

  • hefox committed 007c445 on 7.x-1.x
    Issue #2481607: Add the very necessary new .install
    

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.

PI_Ron’s picture

Hi Guys,

I've just updated to latest dev from 1.4 within my custom distribution.

I'm running some tests now on sites and custom colours stored in the database seem to be getting lost when update.php is ran. I could export the variables to a feature but I'm not sure that that will help if Colorizer is no longer using variable storage. Can you please provide some advice here?

I'm using radix subthemes / radix colorizer.

mpotter’s picture

I am not able to reproduce any problem here. The custom colors on our sites are retained with updates. If you can reproduce this somehow please open a new issue with more details.