Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Do not use a plugin unless it is actually installed #9216

Open
tsteur opened this issue Nov 15, 2015 · 2 comments
Open

Do not use a plugin unless it is actually installed #9216

tsteur opened this issue Nov 15, 2015 · 2 comments
Labels
Bug For errors / faults / flaws / inconsistencies etc.

Comments

@tsteur
Copy link
Member

tsteur commented Nov 15, 2015

See #9201 (comment)

We should only use components, events, ... of a plugin when it is actually installed to prevent random errors. The installation of a plugin may take a while (between a few ms and up to days). Only once the plugin is actually loaded, activated and installed we should use it.

For example plugins won't be installed during tracker mode but if we use them there already even though they are not installed yet it will very likely break tracking. Also for non-tracker plugins it can prevent errors.

I tried to implement it recently but failed. Only hours afterwards I noticed the tests fail because we always assume plugins are uninstalled in TestConfig. While it's not hard to implement ignoring events, API methods and components of uninstalled plugins, making the tests work will be quite a bit of work from the looks.

Eg we need to add more plugins to the PluginsInstalled list in global.ini.php. Otherwise ./console won't show any commands. We need to add at least CoreConsole and TestRunner. Once this is done we will need to move some tests from Unit to Integration since they were placed in the wrong category. Once unit tests succeed the actual work begins as many tests only do ->loadPlugin('API') but it's not done by that. We also need to install them etc.

@tsteur tsteur added the Bug For errors / faults / flaws / inconsistencies etc. label Nov 15, 2015
@mattab
Copy link
Member

mattab commented Nov 18, 2015

@tsteur which milestone do you think we should schedule for? is it easy to change or rather non trivial?

@tsteur
Copy link
Member Author

tsteur commented Nov 18, 2015

It is trivial to implement and to make it kinda work for normal use but tests require lots of work. I don't think we can break much there but would rather target 3.X

@mattab mattab added this to the Mid term milestone Nov 18, 2015
@mattab mattab modified the milestones: Long term, Mid term Dec 5, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug For errors / faults / flaws / inconsistencies etc.
Projects
None yet
Development

No branches or pull requests

2 participants