Enabling plugin via command line works, but also does not work. How to enable?

[bencresty]

Hi,
When enabling a plugin that didn't change, but is running locally on another system now, it is not enabling in the cms settings when hitting 'enable'.

When running craft plugin/enable interactively and chosing these plugins the command says 'enabled {plugin} successfully', but when running the craft plugin/enable command again it's still in the list of disabled plugins and it's also still disabled according to the cms.

It's not giving any clue on what might be wrong and the plugin was working fine before and didn't change since. Only craft has been updated once in a while and the project was moved to another system.

I already checked if there was an issue with usages of casing in the classes of my plugins, but everything seems okay. Which doesn't surprise me as these were working fine for years in many Craft versions and still are to this date on the servers these are running on publicly.

I also ran the composer dump-autoload again, whithout any issue.

It would be nice to have some form of clue on where to look. So any advise would be welcome.

Currently using craft 3.9.10, but it has been like this for a while now, also with previous versions.

Any tips on where to look?

[brandonkelly]

Do you have the disabledPlugins config setting set in config/general.php, or via the CRAFT_DISABLED_PLUGINS environment variable?

[bencresty]

Which is an odd response after me telling you explicitely that I didn't do that. But leave it. That's why I wrote 'agree to dissagree'. There is an issue that needs to be solved now. I'm currently trying the uninstallation of feed-me route you advised. Which sounds good

[bencresty]

Yes, this did the trick. And after this I can now even enable and disable the plugin from within the UI, so that works too now. Weirdly enough I still cannot enable the local plugins, which was the original issue I started the tread for, but the feed-me one works now.

This is what I've done:

• your advise on how to remove and uninstall feed-me now (I needed to use the --force parameter as it wouldn't let me uninstall the disabled plugin otherwise)
• composer require craftcms/feed-me
• craft plugin/install feed-me
• craft plugin/enable feed-me

And than I just had the feed-me installed without needing to finish installation via the ui and the enable/disable on the feed-me work too now.

Now it's time again to see if I can fix the original issue with the local plugins not being enabled and/or installed.

I've just now tried to run just a 'composer install' to be sure everything in the composer.json is installed, but it says it doesn't have anything to install. The path to the plugins however never changed and is a relative path to a folder right inside the project folder which always have been and is still there. So I wouldn't know a reason to why suddenly it doesn't work no more, but the plugins should be installed now.

[bencresty]

Alright, some weird things happening here now while trying to fix the issue with the local plugins not enabling in the UI:

I tried more or less the same approuch as with the feed-me that worked there here now:

• craft plugin/uninstall sub-folder-name/plugin-name --> shows 'uninstalled successfully'

• However, at this point the plugin according to the UI is still on 'Disabled', which is weird, as I would expect this to say 'Not ininstalled' now, just like another plugin in the list that's currently not installed. But either way I continued:

• craft plugin/install sub-folder-name/plugin-name --> strangely enough shows that the plugin-name handle is not recognised, while it was recognised right before this, so I try this (without the sub-folder-name)

• craft plugin/install plugin-name --> now it says 'installed succesfully' (beats me, why, because before it needed the sub-folder-name to recognise the handle?)

• No change in the UI at this point

• craft plugin/enable plugin-name --> now it says 'enabled successfully', but the UI of the CMS still shows no change (still shows 'disabled'.

I'm sure it's me missing something, but to me this whole sequence doesn't make any sense to even remotely know where to look.

(BTW for the record again; I did a composer install to be sure, even a composer dump-auto-load, before all of this, although that shouldn't be needed at this point)

Conclusion for me at this point;

• The 'succesfully' message doesn't correspond to the findings when looking in the UI of the CMS. The UI of the CMS doesn't change a bit whatever I do and keeps saying these addons are disabled. Changing this to 'Enabled' from within the CMS itself doesn't work either, which was the issue it all started with.

Unfortunately I'm facing a tight deadline and a little bit out of ideas on what to try next honestly. I'm open to suggestions.

[bencresty]

Another thing to note: in the project.yaml these local plugins are already set to enabled: true. So these aren't disabled in the settings, and while they are installed according to the command line I wouldn't know why the CMS still thinks these are disabled (and don't use them on the pages)

[brandonkelly]

craft plugin/uninstall sub-folder-name/plugin-name --> shows 'uninstalled successfully'

sub-folder-name/plugin-name is not a valid syntax for specifying a plugin. Only the plugin-handle is supported here.

If you have a plugin installed in a subfolder, you must pull it into the main Composer installation using a path repository in composer.json:

"repositories": [
  {"type": "path", "url": "./sub-folder-name"}
]

and then run composer require package/name. Then you can install/uninstall/enable/disable it using its plugin handle, without any path leading up to it.

plugin/uninstall said the command was successful only because it first checks if a plugin is already installed with the exact handle you passed in, and if not, it will immediately abort and claim that it was successful:

cms/src/services/Plugins.php

Lines 586 to 589 in 759edf0

	if (!$this->isPluginInstalled($handle)) {
	// It's already uninstalled
	return true;
	}

I suppose we could make that more defensive by ensuring that $handle is actually a valid plugin handle first, and throw an exception if not.

[bencresty]

sub-folder-name/plugin-name is not a valid syntax for specifying a plugin. Only the plugin-handle is supported here.

It's been a while since I've worked with Craft, but again; this website worked fine before just as is. The only thing changed is that Craft was updated once in a while to new minor versions. And after that there never was any issue on the production server, still now there still isn't there. The problems now are only on the dev server.

If you have a plugin installed in a subfolder, you must pull it into the main Composer installation using a path repository in composer.json:

"repositories": [
  {"type": "path", "url": "./sub-folder-name"}
]

Yes, that's exactly how it was built and worked all this time.

and then run composer require package/name. Then you can install/uninstall/enable/disable it using its plugin handle, without any path leading up to it.

Also this I've already done long time ago, but for the sake of testing I did it once again. Didn't change anything to the composer.lock file, which shows it was already done.

plugin/uninstall said the command was successful only because it first checks if a plugin is already installed with the exact handle you passed in, and if not, it will immediately abort and claim that it was successful:

cms/src/services/Plugins.php

Lines 586 to 589 in 759edf0

	if (!$this->isPluginInstalled($handle)) {
	// It's already uninstalled
	return true;
	}

I suppose we could make that more defensive by ensuring that $handle is actually a valid plugin handle first, and throw an exception if not.

Yeah it would be expected that functions don't act like things worked great if in reality they couldn't even find the handle.

Anyway, it's still not working and stilll weird things are happening.

The plugins are installed fine with composer. No issue there and if composer says things were successful they were succesful, which also is proven by the fact that it didn't change anything to the lock file I would say.

When running a list to show the plugins' handles they are in the list just fine. (craft plugin/list). They show atm that they are not installed and not enabled. Which, again, is also not in sync with the project.yaml that says they ARE installed.

When running the command to enable them Craft complains that it doesn't recognise the handle, which makes no sense, because I use the right handle, which is proven by the fact that they show exactly like that in the plugins list.

"Failed to install plugin-handle: No plugin exists with the handle "plugin-handle" "

There is the issue.

[bencresty]

Alright, have it working now.
I needed to REMOVE my local plugins with composer, than UNINSTALL WITH FORCE the local plugins with Craft, than REQUIRE/INSTALL my local plugins again with composer and then INSTALL the local plugins with Craft.

Again; this is a clear indicator that two sources of truth is prone to errors. Situations like this would never occur when just having a single source of truth. Also during all this we encountered quite some other issues that didn't help debugging this:

• Craft shows 'successful', while it was not succesful, so that is a counter productive message
• Craft couldn't find plugin handles (at least that's what it told me), while the handles were perfectly fine known and never changed
• Crafts update/sync system gets messedup when things are out of sync. It is complaining when there are already database fields and when we remove the table it is complaining that there's no table. So either way we're quite fucked when things like this happen.
• The system of keeping project.yaml and database in sync often just doesn't work. All plugins were installed here just fine and the project.yaml said they were enabled, but still the system didn't work, the cms showed that these were 'disabled', which clearly was not the case, and nothing in the cms detected that the project.yaml and database weren't in sync and should be synced.

Again: the system shouldn't be out of sync in the first place. There should not even be a sync. There should be 1 single source of truth to have a reliable system. This is asking for trouble and caused already many headaches and issues here last years. These now were yet other issues being proof of that this system doesn't work and is very critical and prone to errors. And when out of sync things even get worse, because the system is not fixing things, is not capable of restoring things and is preventing us from getting the right messages to even know where to look. Yet another days wasted on a system that was just working fine before.
But it doesn't matter how many issues happen, you won't change your min whatever I say. So I'll leave it here.

I appreciate your help now so thanks for that. But honestly, truth is that these issues shouldn't have occurred in the first place and wouldn't if there was only one single source of truth.