Server: Ability to Remove unneeded shipped apps

[My1]

One thing I have noticed which is a little bit annoying is that you cannot remove many if not all of the included addons, for example the First run wizard or the LDAP backend.

it would be awesome to be able to remove them so 1) some space can be freed up 2) the list of installed addons is getting a bit tidier.

[MorrisJobke]

some space can be freed up

It's only a few KB or some MB (server is in total 40 MB)

the list of installed addons is getting a bit tidier.

You need to do that on every update because those apps are shipped with the server and would be added again on every update.

I would avoid doing this, because the benefit is really low and the needed code is quite a lot. Also if you really want to do it: delete them from the apps folder after the install process. But be aware, that the code signature is not valid after this anymore.

cc @rullzer @nickvergessen @karlitschek @schiessle @ChristophWurst @juliushaertl for opinions

[karlitschek]

In theory I agree. The actual zip should be as small as possible. But core functionality has to be in the zip file. The first run wizard is a good example. I'm also not sure if the benefit is soo big that is justifies restructuring everything. But good idea in the long term

[My1]

well true, the discussion about "what is core" will be a thing, and one Idea that could be done would be

a) marking the apps that arent totally needed as optional, and let the user decide right there what is needed (similar to what some other CMS installers can do)

b) on update, if a certain optional app is there, update it, if it isnt, then dont.

some of the applications I would consider absolutely needed would be for example the log reader and the update announcement

[MorrisJobke]

b) on update, if a certain optional app is there, update it, if it isnt, then dont.

That's easier said than done, because then we need to put more logic into the updater to determine what to extract and what not. This is a lot of logic I really try to avoid, because code that is not there could not break. And the benefit of saving some hundert kilobytes in trade for a lot of potential bugs during update is something I don't want to accept.

some of the applications I would consider absolutely needed would be for example the log reader and the update announcement

Those two apps are an example of what others also think are apps that are NOT needed by them, because they use configuration management and an external log viewer anyways ;) It's super hard to draw a line and thus we need to decide where it is and that always incorporates compromises.

[blizzz]

With @MorrisJobke's last statement as good conclusion I think we can close it, since the usefulness is doubtful, as described, and the effort big.

[acsfer]

Is there a way to completely disable core apps and the ability to enable them from the WebUI (so, remove it from the Apps listing)? Because even if the app is disabled, it can be enabled at any time by a single click.

[MorrisJobke]

Is there a way to completely disable core apps and the ability to enable them from the WebUI (so, remove it from the Apps listing)? Because even if the app is disabled, it can be enabled at any time by a single click.

Remove them from the apps/ directory. Only another verification of the cores code signature will cause then a warning. Also keep in mind, that if you remove force enabled apps like "files" or "workflow_engine" then server will misbehave.

[acsfer]

Wouldn't a configurable option be a good "option" here?

'disabled_apps' => [
    1 => 'recommendations',
    2 => 'serverinfo'
]

Then a simple check $config->getSystemValue('disabled_apps', []) in the apps listing to not display those explicitly configured.

The idea/problem solved here is to give more power to sysadmins and less power to NC admins, not reduce the ZIP size.

[MorrisJobke]

Wouldn't a configurable option be a good "option" here?

In general more options are just hiding complexity and making the whole product less maintainable. If you really want to remove this app, then delete it right after the deployment. I would vote against another option here.