Changing package type to 'wordpress-muplugin'

[jedrzejchalubek]

I'm considering changing package type in composer.json file to wordpress-muplugin. This will enforce Bedrock to install framework as "not to turn off". It has a lot of sense, as the assely created themes absolutely requires framework.

Do you have any thoughts about this?

• [x] Change package type to wordpress-muplugin in composer.json file
• [x] Update framework/theme bootstrap checks to look for defined constans

[marcwieland95]

Yes, the idea about moving assely framework into a mu-plugin is good and useful. But there's a technical limitation:

WordPress only looks for PHP files right inside the mu-plugins directory, and (unlike for normal plugins) not for files in subdirectories. You may want to create a proxy PHP loader file inside the mu-plugins directory - https://codex.wordpress.org/Must_Use_Plugins

Using a proxy file isn't a good solution, maybe also not possible with composer - I don't know for sure.

This is a useful discussion in the roots forum: https://discourse.roots.io/t/composer-mu-plugins/1326/2

Bedrock is using an autoloader for mu-plugins, maybe this could be used: https://roots.io/bedrock/docs/mu-plugins-autoloader/

[marcwieland95]

Just checked the usage as a mu-plugin. With Bedrocks autoloader it seems to work without proxy file. The compatibility function inside the theme needs some adjustments this way. We can check if a constant is defined instead of the is_plugin_active function.

if (! defined('ASSELY_FRAMEWORK_DIR') ) {
   ...
}

[jedrzejchalubek]

Yeah, Bedrock take care of autoloading mu-plugins. However, I don't know how this would behave in other stacks (Wordplate etc). Maybe we should not care about it at all 😈

The is_plugin_active function doesn't work for mu-plugins, so as you mentioned, we need to rely on something else (constans are good proposition).

[marcwieland95]

Haha. Maybe we can add a note in the documentation to add the Bedrock Autoloader file manually when using other stacks.