Comments (13)
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.
Your way is a good solution but the condition for checking if there is any config available should be earlier IMO.
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.
Related Issues (20)
- Wrong TYPO3 dependency in ext_emconf HOT 1
- TYPO3 Extension Award - Best Documentation 2021
- Add support for video files: .youtube and .vimeo HOT 12
- Add support for PHP 8.1
- Cropping / Imagemanipulation does not work in Frontend HOT 3
- Remove usage of constant TYPO3_MODE
- Unable to send test email from install tool due to exception of ext:filefill HOT 3
- Moved DomainResource not found HOT 1
- Not able to render EXT:...images with fluid in backend context
- Undefined array key "tableName" HOT 12
- Console commands not available in TYPO3 v11
- Command typo3cms cleanup:flexforms results in Exception HOT 1
- Support for TYPO3v12 LTS HOT 4
- Placeholder for large images HOT 3
- Error Message in TYPO3 v12 HOT 12
- Call to undefined method Doctrine\DBAL\Result::fetchColumn() HOT 12
- placeholder.com discontinued HOT 5
- Compatibility with Symfony 7 HOT 3
- Compatibility with TYPO3 v13 HOT 1
- Image Builder not functional in v12 HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from filefill.