Deactivated plugin still being used with Grav 1.7

1

I have this plugin installed : enovision/grav-frontend-edit-button: GRAV CMS Plugin - Frontend Edit Button (github.com)

I wanted to deactivate it, so I went to the yaml file that has the name of the plugin and turned the enabled property to false, cleared the cache, but the plugin is still being used.

enabled: false

Disabling the same plugin was working great with 1.6. I am using 1.7.7 now.

I created an issue for that plugin, but it seems to me that deactivation should be handled by Grav itself, not the plugins (it should be Grav’s responsability to be able deactivate code that is broken or not needed, shouldn’t it?)

Hope you could help me understanding and fixing this issue.

Regards,

Maxime

2

@mathmax, Using Grav 1.7.7, I’ve installed the plugin, but cannot reproduce the issue.

When enabling/disabling plugin in ‘/user/config/plugins/frontend-edit-plugin.yaml’ (or ‘/user/plugins/frontend-edit-plugin/frontend-edit-plugin.yaml’ in absence of the former config file) the following happens:

  • enabled: false
    no button shown and debugger does not get activated in onPluginsInitialized()
  • enabled: true
    button is shown and debugger gets activated in onPluginsInitialized()

What tells you it is still working when using enabled: false?

3

@pamtbaau Thank you for your reply.

After I connect to the admin and go back to the frontend of my website, the button added by the plugin is visible on the top right end corner of each page (see attachment).

Capture_frontendEdit
Capture_frontendEdit876×604 26.6 KB

4

@mathmax, Cannot reproduce that either…

Steps:

  1. set enable: true in ‘/user/config/plugins/frontend-edit-plugin.yaml’ using file editor.
  2. browse to home page
    • button is visible, debugger activated in onPluginsInitialized()
  3. set enabled: false in ‘/user/config/plugins/frontend-edit-plugin.yaml’ using file editor.
  4. browse to Admin and login
  5. browse to home page of site
    • no button visible, debugger not activated in onPluginsInitialized()
5

Strange, I followed the same steps, button is still here…

step4: I was already loging after step 1 (to be able to see the button), so I did not need to login again to the admin. Should I log off and login again? Instead I just cleared the cache.

Step5: Have you tried to browse a few pages of the website? Doesn’t the button reappear?

How do you see if the debugger is activated or not?

6

@mathmax,

Step5: Have you tried to browse a few pages of the website? Doesn’t the button reappear?

I’m using a fresh install of Grav 1.7.8 (just upgraded few minutes ago) and browsed both ‘home’ and ‘typography’. Button does not reappear.

Questions:

  • Does the cache of your browser get cleared when you browse a page?
  • What’s the path of the config file you are editing?

How do you see if the debugger is activated or not?

You need to have XDebug installed and activate debugging in your code editor (e.g. VSCode).

7

Yes, I did I checked in a new InPrivate window

user\plugins\frontend-edit-button\frontend-edit-button.yaml

What else can I do to investigate?

8

@mathmax, Does the site perhaps contain file ‘/user/config/plugins/frontend-edit-button.yaml’, or a config file for specific environments like localhost?

9

Indeed it has! And that fixed my problem, thank you. :blush:
Sorry for the time to install and try the plugin…
Questions:

  • is there some change in Grav 1.7 causing the files in user/config/plugins to have priority over the conf files directly in the plugins directories? It’s good to be able to override the configuration of a specific plugin, but I am wondering why this configuration suddenly started to apply after I upgraded… I had forgotten I had this file there.
  • does the file in user/config/plugins completely replace the file in the pluging folder if it exists, or does only the configuration specified inside the file override the configuration of the plugin? In other words, does the ovverride apply on a per-file basis or per-property basis?
10

@mathmax, Would you mind sharing what I can improve in all my posts to get more emphasis on file ‘/user/config/plugins/frontend-edit-plugin.yaml’? :innocent:

  • Settings in config files in ‘user/config/plugins’ have always had priority over ‘user/plugins/…’
  • As said in the docs about Configuration:

    • In chapter System Configuration about ‘/user/config/system.yaml’:

      Any setting in this file with the same structure and naming will override the setting provided in the default system configuration file.

    • In chapter Plugin Configuration about configs in ‘user/config/plugins/…’:

      The YAML file that exists within the plugin’s primary directory will act as a fallback. Any settings listed there and not in the User folder’s copy will be picked up and used by Grav.

      And also:

      Most plugins will come with their own YAML configuration file. We recommend copying this file to the user/config/plugins/ directory rather than editing configuration options directly to the file located in the plugin’s directory. Doing this will ensure that an update to the plugin will not overwrite your settings, and keep all of your configurable options in one, convenient place.

11

This was pretty clear, but I missed the path for some reason. Sorry about that :sweat:.

Instead of copying the whole file like advised by the documentation, I would prefer to only copy the settings that I want to change (in this case enabled: false). Thank you.

12

If you were to use Admin, keep in mind, that saving settings will still save all the values present in form

13

@Karmalakas, Good addition to the above and also an annoying ‘feature’ of Admin…

14

This is almost the only thing I always found annoying with the Admin… it messes up also the YAML FrontMatter of the pages (changing the attributes order, the format of the value, adding default values, etc.). This causes file changes which you don’t want when files are kept under a version control system. It defeats a bit the strength of a flat file CMS which is to keep everything under revision control…

16

I guess you can avoid saving of each value (at least to some extent) with toggleable: true

17

Sorry, I am not sure to understand how toggleable could help the issue where the admin is generating attributes for default values / reordering attributes / changing formats.
I found this in the documenation:
Reference: Blueprint Form Fields | Grav Documentation (getgrav.org)
Are we talking about the same toggleable?

18

Probably the same :slight_smile: If you look at common field attributes, there’s:

toggleable: add a checkbox that will toggle the enabled/disabled attribute of the field

If this is true, checkbox is rendered at the left of the field. If checkbox is not checked, the value is not saved to frontmatter (I assume same for configs). Only if checkbox is checked, then value is saved.