$requires in plugin.php

[samcoppock]

does listing a plugin in a different plugins plugin.php $requires variable have any effect on the code execution?

does it cause the required plugin to be loaded first or the migrations from the required plugin to run first

[LukeTowers]

@samcoppock that's the idea, see https://github.com/wintercms/winter/blob/develop/modules/system/classes/PluginManager.php#L955-L961. You should be careful about relying on load order however. Is there something specific you're trying to accomplish?

[samcoppock]

Well as you know we had a number of rather serious issues some caused by the customisation of our winter instance.

We have mostly fixed most of them

However I have yet to fix the recursive plugins issue ( that's a lot of refactoring after all ).

There is also still the matter of the migrations failing due to it attempting to put relationships on tables which have not been made yet.
and also the last remaining change to the winter modules folder code appears to be a fix for the recursion issue so i expect to be able to get rid of that after our plugins have been refactored to remove circular dependencies.

which is why i wanted to know what effect declaring dependencies for plugins had on the load order.

[mjauvin]

Did you check the source code to find out what the requires affect relating to the loading order and other aspects? If you could open a PR to the docs repo once you find out, that would definitely be helpful.

[LukeTowers]

Circular dependencies will never be supported. What may help in your specific case would be if Winter had support for squashed migrations: https://laravel.com/docs/9.x/migrations#squashing-migrations, but adding said support could be somewhat complicated as it would by necessity have to only be supported on a project level, not a plugin or module level.

The easiest way forward for you if you're just trying to make your current project able to be spun up on new databases would probably be to generate a SQL file from your current production schema (including the system_plugin_versions and system_plugin_history table contents) and require devs to populate their database from that SQL file before running any migrations on a fresh database.

[samcoppock]

Circular dependencies will never be supported. What may help in your specific case would be if Winter had support for squashed migrations: https://laravel.com/docs/9.x/migrations#squashing-migrations, but adding said support could be somewhat complicated as it would by necessity have to only be supported on a project level, not a plugin or module level.

The easiest way forward for you if you're just trying to make your current project able to be spun up on new databases would probably be to generate a SQL file from your current production schema (including the system_plugin_versions and system_plugin_history table contents) and require devs to populate their database from that SQL file before running any migrations on a fresh database.

We already use SQL files dumped from the current prod environment to make it work.
But we should not have to do that and if all of our copies of the database are lost for any reason we would have a problem ( believe me that could realistically happen )

Also I mentioned that the winter modules folder still has one instance of custom code which appears to be a fix for the recursion error we sometimes get which will be a problem in the future if no one in the team knows about it.

I thought of making a git patch for it but that would be a very fragile solution, all it would take is for the relevant file to get moved, or the relevant lines to move to a different file in a future winter version and it will break.

The fact that I have to ask these questions shows how much of a problem issues like these can be if the current developer lacks the knowledge of the changes which caused them.

Which is why I am keen on fixing them.

[LukeTowers]

Definitely fix the circular dependency issue that is causing that patch to be required, if I recall correctly it completely bypasses the sorting by dependency logic which will cause you issues in the future. However given the state of your current project and the upgrade path for what you have in place now it probably is the most reliable to go the approach of squashed migrations in a SQL file (where the structure is retained but not the content if possible unless the content is required for your code to function).

The simple approach is to document that squashed file in your README, the longer term less thinking required approach is to add support for running squashed migrations to Winter so that it gets auto-applied when running artisan migrate.