Convert to Plugin

[jdamner]

In support of issue #12 I've updated so can be distributed as a plugin via composer.

Set plugin name etc at start of plugin file.
Added composer/installers as dep and set type to wordpress-muplugin.

[palmiak]

I like the idea of mu-plugin 👍

Just two questions - what would happen if someone would try install this in the theme?

Also what would happen in a scenario like this:

• user had this installed as a library
• after update it installed as a mu-plugin - will the library version be removed?

Let me be clear - I love the idea but I'm wondering wouldn't it be better to create a separate repo (even with compiled zips) of the mu-plugin version to be sure that we won't have any problems.

[jdamner]

Hey - thanks for a prompt response! One of the benefits of changing the project's composer.json to use composer/installers and ’type’ that means that it won’t affect any of the other use cases. So for example in any projects it’s used as a dependancy it will install exactly the same as it always has, unless you’ve specified in that project’s composer file that you want to setup the installation path to another folder. As an example, my composer.json for a project contains: "extra": { "installer-paths": { "web/app/mu-plugins/{$name}/": [ "type:wordpress-muplugin", "wpackagist-plugin/timber-library" ], "web/app/plugins/{$name}/": ["type:wordpress-plugin"], "web/app/themes/{$name}/": ["type:wordpress-theme"] }, "wordpress-install-dir": "web/wp" }, That tells composer to install anything that’s of type ‘wordpress-muplugin’ into web/app/mu-plugins/ . (And it makes timber a mu-plugin for my projects too!). If I didn’t have that ‘extra’ block then things would install just the same as they always have. There is an issue if you have this installed in /vendor/ and in /mu-plugins/ at the same-time, but composer shouldn’t let that happen so will only happen if someone manually installs it. That could quite easily be prevented by wrapping the whole project in an if statement that checks if the project already exists. I can create a pull request for that some time in the future too if you’d like? Adding the ‘Plugin Name’ etc comments at the top of the file doesn’t do anything outside of WordPress (that I’m aware of) - and since they’re the only code changes I’ve made I would say that there’s no chance of this affecting existing installations. I totally get your concerns though - Thanks James

…

On 7 Jan 2021, at 17:52, Maciej Palmowski ***@***.***> wrote: I like the idea of mu-plugin 👍 Just two questions - what would happen if someone would try install this in the theme? Also what would happen in a scenario like this: user had this installed as a library after update it installed as a mu-plugin - will the library version be removed? Let me be clear - I love the idea but I'm wondering wouldn't it be better to create a separate repo (even with compiled zips) of the mu-plugin version to be sure that we won't have any problems. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#41 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AADV5DZ3C6EXJWHPI4MHXCLSYXYENANCNFSM4VZI3NIA>.

[palmiak]

That's great to hear. Ok I will try it with the extra wrapper so it won't register twice and see if it works correctly.

[palmiak]

@jdamner just ❤️ for the documentations fixes.

[palmiak]

After merging I did one more test to saw some problems:

• if I were using this as a library after running composer update it installed into {theme}/wp-content/mu-plugins directory - which is correct because the composer was in the theme.
• the second thing - Bedrock has the autoloader that helps running plugins in folders. But it's not a standard.

I understand we could set it in composer but running composer update would be be breaking operation (which we don't want).

Overall - my plan is to have separate repositories:

• this will stay as library
• second as plugin (not mu-plugin) - to be sure it will work on every installation

So overall - I will remove update the composer update part and fix the documentation a bit.

[palmiak]

The plugin version is here https://github.com/palmiak/timber-acf-wp-blocks-plugin - could you test this?

using composer require palmiak/timber-acf-wp-blocks-plugin should work.