Account created on 21 September 2015, almost 9 years ago
#

Recent comments

There is an issue with proposed resolution item #3. While this module does attempt to decrypt data that was encrypted with mycrypt, the openssl decrypt method fails to decrypt the data with errors like:

error:03000082:digital envelope routines::invalid key length

I have attempted this in multiple environments and this seems pretty consistent.

Applied #16 and this helped me greatly. Recently upgraded to PHP 8.2 and was getting 500 errors.

Specifically, I was having issues due to the fact that the core Drupal 7 system module's system_entity_info function was being called and this helps skip past that.

So for anyone wondering, I was experiencing issues where upon enabling brotli the generated CSS and JS broke on our site.

The fix for this was similar to the linked issue in the topic. Find the .htaccess files in the advagg_js and advagg_css folders and modify the rewrite rules as follows:

RewriteRule \.js\.gz$ - [T=application/javascript,E=no-gzip:1,E=no-brotli:1]]

RewriteRule \.css\.gz$ - [T=text/css,E=no-gzip:1,E=no-brotli:1]]

UPDATE: Even after applying this update, in Views updating something and saving the View seemed to cause a total Redis meltdown. I'm not sure if Views does not trigger this or what.

So I want to put out there that patch in #21 dramatically helped us for the most part.

I've done review of how many keys we've had open and I've seen us in the 2.5 mil key range. Our system was always locking up with Redis (which as an FYI was an AWS ElastiCache managed service, not something running on localhost) warnings until it completed when we flushed Drupal cache. This solution helped us for the most part.

We found that even by upping the number of deletions and scanned it was taking a long time and consuming a ton of memory -- more than our typical server needs. We had to add in some lines where deleteByPrefixUsingScan could extend the memory allocated to run, and to set drupal_set_time_limit to 0 so that it had unlimited time to delete everything.

With this the site never became unusable even when we were flushing cache. Overall this was an improvement for us.

Production build 0.69.0 2024