FluxCP 2.0

[secretdataz]

• Now using Composer to handle dependencies. Supersedes Composer-ing components #210.
• Now using PSR-4 autoloader to handle class loading. No more requires_once hell.
• Also used filp/whoops to handle errors and exceptions instead of Flux's own handler.
• FluxCP no longer expose unnecessary information in production environment unless configured to.
• Moved some environment-specific settings into .env file. Provides more flexible developer experience.
• Breaks every single existing themes and addons. Updates required are minor since modules and themes haven't been restructured.

[mazvi]

I don't really like using composer. prefer the website that is configured as it is currently using php. then import sql. connection settings in php and done.

try to see cms like wordpress they work easily without having to do composer in the installation.

[sanasol]

I don't really like using composer. prefer the website that is configured as it is currently using php. then import sql. connection settings in php and done.

try to see cms like wordpress they work easily without having to do composer in the installation.

That's the way for writing code like from 2010 maybe, but not now.

Updating dependencies twice for a lifetime doesn't look good.

If we want keep legacy-way, then we should not update anything then and just freeze anything except must have updates which is harder to implement every year.

Also that's reason to keep away new contributors since they using PSR/Composer/Docker/CI while we dont provide support for it. Best we can do is Requirements list with PHP 5.2 included(7.4 EOL this year FYI).

[mazvi]

Actually it is possible from the developer side to use composer, but the final result sent to github should only be the final file and mysql only.

So users only need to do a git pull and upgrade/import sql if needed, such as updating ratena.

[secretdataz]

Actually it is possible from the developer side to use composer, but the final result sent to github should only be the final file and mysql only.

So users only need to do a git pull and upgrade/import sql if needed, such as updating ratena.

It's a bad practice to track dependencies on version control especially when you have a dependency management tool available.
Let's not duplicate history of our dependencies and make our repo grow significantly larger in size, shall we?
You should do a research why you shouldn't commit vendor or node-modules directory into a VCS.