[#3831] - Configuration update.
- Closed
- 26 Jun 2014
- Medium
- Build: staging
- # 3831
- Diff
- bweston92:feature/config-resolver
- Failure The Travis CI build failed Details
User tests: Successful: Unsuccessful:
Unstable untested state, looking to discuss.
A configuration implementation with multiple resolvers. With there being
a JConfigResolverInterface it will allow people to create their own
where the may want to load from a internal url etc.
Allow for .env.php in configuration directory to load environmental
variables such as J_DEBUG and J_HOST. This means you can create a git
repository and not have to commit the configuration.
This is untested and needs tweaking but I'm just trying to get people
started on improving the configuration system. The current one makes it
really hard for developers to use git tracked projects using Joomla to
have separate configuration. I have tried to keep it as much in tact as
possible with the JFactory::getConfig method.
Basically what I have so far in my repository is a command line installer which checks to see if a database exists or not and if not it creates it with the SQL files provided from the installation folder. This saves the whole manual installation process whenever I deploy a new instance of my app.
Part of deploying means that I want to be able to just click a button and for it to work like magic. Using for example Fortrabbit I would be able to setup some environment variables like J_DEBUG and J_DBTYPE etc that means the configuration is never in the applications repository but I'm able to set everything up and use the application without worrying about the manual installation process.
I understand it's not required for 99% of end users, I have currently had to hack together a version for my application to work this way and the reason for my PR is to try make it a bit more native.
To be honest the fact that JConfig class is instantiated twice is bazaar there should be a repository instance for configuration.
—
Sent from Mailbox for iPhone
On Wed, Jun 25, 2014 at 11:06 PM, Thomas Hunziker
notifications@github.com wrote:
Travis fails due to syntax errors. Please fix it and make sure your code works (eg test it) before you propose it.
If you only want to discuss something, please open a thread on the CMS development mailing list.
I'm not yet sure what the problem is you try to solve, but it may be me.
A bit confusing to me is that there are no variables such as J_DEBUG or J_HOST. There is a constantJDEBUGif you mean that. It's set based on the config (JConfig) propertydebug. For the host there isn't even a constant. It's taken directly from the config file.
I'm not sure I understand what the problem is with the current configuration.php file where all this settings are stored in a very simple way, manageable within the global configuration manager in the backend.What is the problem with your git tracked projects? The configuration.php by default isn't tracked, it's part of .gitignore. Obviously you don't want to track it on a public repo.
Reply to this email directly or view it on GitHub:
#3831 (comment)
Sounds a bit similar like what JoomlaTools did with their Joomla console project?
Do you know that? See: https://github.com/joomlatools/joomla-console
I'm still not sure why you need to change the config part for a CLI installer. All you need to do to install Joomla is dropping the SQL files into the database and creating the configuration.php file. Your install script can take the needed data from wherever you want it.
Keep in mind that the code to load the configuration is executed on each pageload. It should be as fast as possible.
I will just do it as you've just said, make the installer write the config file, basically I was hoping tha the configuration file was never written, using my PR I could just set environment variables in Fortrabbits control panel an it just magically works. I have managed to achieve this by writing my own little script on startup but looked ugly, I suppose I could just do what you said and write the actual configuration file from the variables on installing from the CLI.
Will close when on my machine.
—
Sent from Mailbox for iPhone
On Thu, Jun 26, 2014 at 8:41 AM, Thomas Hunziker notifications@github.com
wrote:
Sounds a bit similar like what JoomlaTools did with their Joomla console project?
Do you know that? See: https://github.com/joomlatools/joomla-console
I'm still not sure why you need to change the config part for a CLI installer. All you need to do to install Joomla is dropping the SQL files into the database and creating the configuration.php file. Your install script can take the needed data from wherever you want it.Keep in mind that the code to load the configuration is executed on each pageload. It should be as fast as possible.
Reply to this email directly or view it on GitHub:
#3831 (comment)
| Status | New | ⇒ | Closed |
| Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2014-06-26 08:02:21 |
Travis fails due to syntax errors. Please fix it and make sure your code works (eg test it) before you propose it.
If you only want to discuss something, please open a thread on the CMS development mailing list.
I'm not yet sure what the problem is you try to solve, but it may be me.
A bit confusing to me is that there are no variables such as J_DEBUG or J_HOST. There is a constant
JDEBUGif you mean that. It's set based on the config (JConfig) propertydebug. For the host there isn't even a constant. It's taken directly from the config file.I'm not sure I understand what the problem is with the current configuration.php file where all this settings are stored in a very simple way, manageable within the global configuration manager in the backend.
What is the problem with your git tracked projects? The configuration.php by default isn't tracked, it's part of .gitignore. Obviously you don't want to track it on a public repo.