Deactivate per host without uninstalling about filefill HOT 13 CLOSED

If you recommend to not use "filefill" in any production environment then it would be nice to maybe update documentation with statement that this extension is not supposed to be installed on any staging and production instances.

Also maybe good to change the doc part:

"Simply install the extension with Composer or the Extension Manager.
composer require ichhabrecht/filefill"

to

"Simply install the extension with Composer or the Extension Manager.
composer require --dev ichhabrecht/filefill"

Tnx.

from filefill.

Hi @w010,

If you have a composer installation you should require filefill in dev-context only. Other than that I don't see any solution to enable/disable an already installed extension in the TYPO3 eco system.

from filefill.

That also won't work as expected, it will disable whole package and would ask to add/delete database columns on every db check when switching databases. So extension must be enabled always - but not doing anything on ApplicationContext == Production. Is that possible? Or do you use it in your projects on live servers?

from filefill.

I don't know anybody who use the extension on their live system. Me neither. If the extension isn't available on the live system there aren't any database fields, are there? You would deal with the database fields on your dev systems only.

from filefill.

I need the database to be always 100% consistent with definitions from git-versioned source, when doing import/export of systems and automatic deploys. To not make any additional operations before local or remote use of a project. I need 100% full automatic solutions. If it'd be one project sometimes to work on, then ok, I can just install the ext. But I need to integrate such fetch mechanism as a standard steady solution into a few dozens of maintained projects in a number of stage environments, so I need this to be bulletproof to not have to think about it.
Ok, I'll try to figure that out somehow.

from filefill.

Hi @w010,

If you have a composer installation you should require filefill in dev-context only. Other than that I don't see any solution to enable/disable an already installed extension in the TYPO3 eco system.

Activating in composer by installing in dev-context is ok for local instance but what with some staging instances where installing dev packages is not a good idea?

from filefill.

@w010 You can configure it just for your Development/Staging instances with a condition around your configuration:

if (TYPO3\CMS\Core\Core\Environment::getContext()->isDevelopment()) {
    $GLOBALS['TYPO3_CONF_VARS']['EXTCONF']['filefill']['storages'][1] = [...];
}

from filefill.

@schliesser

Your way is a good solution but the condition for checking if there is any config available should be earlier IMO.

Look here: https://github.com/IchHabRecht/filefill/blob/master/Classes/EventListener/ResourceStorageInitializationEventListener.php#L41

Before the condition to check for configuration there is at least few methods that looks like they are no not so CPU light. Maybe its good to first check if there is any configuration like !empty($GLOBALS['TYPO3_CONF_VARS']['EXTCONF']['filefill']['storages']) instead checking for specific configuration which can be done later.

This way it will be as light as possible.

from filefill.

That's my point. I thought about this solution too, but it seems to check condition a bit too late, second thing is that occurs in more places - FileProcessing slot, ResourceFactory slot (and also formEngine.nodeRegistry, but ok, these are not that important)
So it would be perfect if that check runs as first thing in every key point - before doing anything else to minimalize its impact on performance and potential security (by the rule what doesn't run, is usually more secure)

from filefill.

Guys, all checks that are done are concerning to configuration. Please do not forget that configuration can be done on two ways for filefill: either in the storage record OR in global environments. I still recomment not to use filefill in any production environment. It is meant to be an extension helping to setup development system very easily. I guess we can close this ticket as the problem/question in this issue was solved already. Thanks for your understanding!

from filefill.

Will you merge if I do that?

from filefill.

To be honest I do believe every developer should be able to decide whether an extension is required on a system or not. As I told, I think it's not necessary to install it on a productive system. But it might be required on a staging system to ensure all files available. So i would not just recommend to install it on dev systems only, but install the extension where needed. I truly think this issue described in this ticket is a very special one. So to be honest I don't see any reason to change the README file.

from filefill.

I think having PackageStates.php versioned, consistent between dev/stage/master branches, and autodeployed to corresponding server on push is not a special case at all, rather standard automatized workflow in business. Modifying extensions list manually on one target environment to have a functionality on demand, just to have the PackageStates suddenly restored to previous state when someone pushes to git, is really not a serious option.

from filefill.