Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.I don't understand why the bot cache is reloaded on cron. I've not seen a need for it. And the reload from the database is causing $conf variables set in settings.php to be lost. This removes the cache reloading.
| Comment | File | Size | Author |
|---|---|---|---|
| #6 | bot-vars-2631114-6.patch | 2.13 KB | douggreen |
| #5 | bot-vars-2631114-5.patch | 1.99 KB | douggreen |
| #2 | bot-vars.patch | 1.36 KB | douggreen |
Comments
Comment #2
douggreen CreditAttribution: douggreen as a volunteer commentedComment #3
Morbus Iff@douggreen: A normal Drupal webpage has the variable cache reloaded every page load. The always-on bot, however, is always-on, and the cache is NEVER reloaded. Thus, if someone goes to the Drupal site to add a new channel for the bot to join (or ANY other bot configuration), the always-on bot will NEVER see that configuration, because the variables have been cached in memory for, literally, forever. Requiring users to restart the bot for every configuration change, especially for large bots like Druplicon (which take about 30 minutes to rejoin all channels), is not palatable.
Comment #4
douggreen CreditAttribution: douggreen as a volunteer commentedOK. We need a better way to do this, because the current way loses settings.php $conf values.
Comment #5
douggreen CreditAttribution: douggreen as a volunteer commentedAttached is a new patch that maintains the variable reloading, but does it only for the bot_variables. It also won't lose any bot conf settings variables that aren't in the database. This solution fails, if a variable exists in the database and in settings.php because, in bootstrap, settings.php variables override database variables, but with this solution, database variables will override settings.php variables. But this is still better than the current solution, which completely loses all settings.php variables.
Ideally we need a hook to intercept before the variables are first loaded, save those in a global, and then the current variable_initialize() would work if it was passed the saved variables.
Comment #6
douggreen CreditAttribution: douggreen as a volunteer commentedAttached patch is almost identical, just with a changed function name and comment for better readability.