Problem/Motivation

I'm often logged into production sites and development sites. And sometimes I go to flush caches using the admin toolbar links on my development site...only I accidentally use the wrong browser tab, and flush caches on a production site.

On some production sites this can cause downtime or at the very least a lot of slowdown and pain for users.

Would you accept some work to develop the following feature:

A way to toggle on/off a confirmation form on the cache flushing routes provided by this module.

The way I see it is that most sites don't really need this, but the ones that do can toggle the confirmation form to be used on their production site(s) only.

Then you still get the functionality that users is used to, in that the links are still there in the admin toolbar, but they see a confirmation page, which will give them a bit more time to think about what they are doing, and would probably not be the normal flow of things, so they'd hopefully stop and notice that it's not their development site!
On the development site, nothing would change, the links would still trigger an immediate cache flush.

Let me know if this feature might get accepted, and we can work on some code if it would.

Comments

steven jones created an issue. See original summary.

steven jones’s picture

steven jones commented
Title: Feature idea: optional form confirmation for flushing caches » Feature idea: optional confirmation form for flushing caches
dydave’s picture

dydave commented

Thanks a lot Steven (@steven jones) for suggesting this new feature and providing some details on its implementation! 🙏

Please allow me to try taking a different perspective at the stated requirements:

I'm often logged into production sites and development sites. And sometimes I go to flush caches using the admin toolbar links on my development site...only I accidentally use the wrong browser tab, and flush caches on a production site.

OK, so what we usually do for that is:

  1. Use Config Split with splits per environment (local, dev, stage, preprod, prod, etc...).
     
  2. Use Environment Indicator installed with configured colors, labels, etc... for all splits except prod (disabled). So for example on the dev site the toolbar will be green, on stage blue, etc...
     
  3. Disable the admin_toolbar_tools module on the prod site (/for the prod split):
    If caches need to be cleared, it can be done on the core system performance page (admin/config/development/performance) and/or by enabling manually the admin_toolbar_tools module, flushing the cache, then disabling it again, or of course, with drush commands.

This type of setup is very standard (I "think"), since these modules are all meant to work very well together:
config_split, toolbar, admin_toolbar, admin_toolbar_tools and environment_indicator
Overall, everything can be done with configuration through the backend without requiring any custom code.
Additionally, the Config Split module is very common to any project with multiple environments, so you might already have it on your site.

We would rather recommend this type of setup, if you would like to ensure the type of issues described in the IS should not even occur.

On some production sites this can cause downtime or at the very least a lot of slowdown and pain for users.

All the more reasons to:

  1. Prevent users from being able to perform a flushing operation "easily" on the prod site:
    ==> Disable the admin_toolbar_tools module for the prod split (provided by config_split).
     
  2. Make it obvious the environment is *not* PROD, by highlighting the admin toolbar with a flashy color and a clear label of the name of the environment (provided by environment_indicator).

Would you accept some work to develop the following feature:

A way to toggle on/off a confirmation form on the cache flushing routes provided by this module.

Sure! Why not?! 😅
OK for a config switch on/off for this feature, but I would recommend doing everything with JS:
Adding a small JS behavior which would attach a click event listener to the flush links to pop a JS confirm() dialog, just to block the action on the client side.

Very little changes would be needed to implement such a feature, so development should not be too much of a problem.

Let's see if this feature gets a bit more attention or traction and potentially consider whether it should be integrated to project's code base or should sit somewhere else (in its own project repo, for example).

However, once again, I am really not convinced this would be the correct way to approach the initial problem.
I would personally strongly recommend looking at more radical solutions, completely preventing a certain action from being performed on a specific environment.

Once again, thank you very much for your interest in the module and suggesting this feature.
I hope I was able to provide a few elements of answer and would be glad to have your feedback on the recommended approach.

Feel free to let us know if you have questions or concerns on any aspects of this comment or the project in general, we would surely be glad to help.
Thanks in advance! 😊

steven jones’s picture

steven jones commented
Status: Active » Fixed

Thanks for your considered response.

I've decided to go with the cheap and cheerful suggestion of a JavaScript confirmation on cache rebuild etc. I reckon this will cover off my use-case where I want it to be quick and easy to do if you need to, but with a little more friction to make you stop and think.

As such I've made it into a little contrib module: https://www.drupal.org/project/admin_toolbar_tools_confirm

Now that this issue is closed, review the contribution record.

As a contributor, attribute any organization that helped you, or if you volunteered your own time.

Maintainers, credit people who helped resolve this issue.

dydave’s picture

dydave commented

Thanks a lot Steven for your kind reply and mostly for your great contribution! 🙏

Thank you very much for taking the time to develop this new feature and for sharing your code with us. 😊

I certainly agree with your approach, looking at a small, easy, cheap, non disruptive feature, but that still does the job. 👍
Glad you found the suggestion of going with JS helpful.

I've updated the module's project page to add the Admin Toolbar Extra Tools Confirmations module to the Complementary modules section, so hopefully other users could find it more easily. 👌

I've taken a quick look at module's code and it looks very nice, great job! 🥳
I haven't had the time to test it though, but will be glad to report back when I get a chance to give it a spin.

In any case, feel free to let us know at any time if you have more suggestions, ideas or encounter any issues with the module, we would definitely be very happy to help.
Thanks again very much! 😊

Status: Fixed » Closed (fixed)

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