Further suggestions for configureability

[mdeweerd]

"Moved" from Yii extension

Could you consider adding:

Url/Server dependent configuration; Debug configuration based on Url option? I currently do stuff like this in my 'index.php':

// Determine debug mode depending on site name or get parameter (secret_dbg_key in this example):

$prodtest=(preg_match('/^expressiontocomparewith?$/',getenv('HTTP_HOST'))>0);

$debugmode=!$prodtest&&(preg_match('/^localhost([:\/].*)?
$/',getenv('HTTP_HOST'))>0)||isset($_GET['secret_dbg_key']);

$isProduction = $prodtest||(preg_match('/^([^\/].*)?prodsite.com/',getenv('HTTP_HOST'))>0);
if($debugmode) {
    defined('YII_DEBUG') or define('YII_DEBUG',true);
    defined('YII_TRACE_LEVEL') or define('YII_TRACE_LEVEL',5);
}

and similar for the configuration where I have

if(!CliCheck::isCli()) {
    // Could be: $host = $_SERVER['HTTP_HOST'];
    // I used in my setup:
    $host = getenv('SERVER_NAME');
} else {
    $host=gethostname();
}
/** Check if there is a site configuration */
$siteconf = dirname(__FILE__).DIRECTORY_SEPARATOR.$host.'_common.php';
if(file_exists($siteconf)) {
    $siteconf=require($siteconf);
} else {
    $siteconf=array();
}

which loads a configuration file based on the host name. "CliCheck::isCli()" checks if it is run from the command line or not. '$siteconf' gets merged with the default/common configuration.

[tonydspaniard]

We could brainstorm to figure out what is the best way to actually add this to the main configuration file... I believe is a good idea but didn't think yet on the best approach.

I would like to get rid of all those configuration additions who make the bootstrap index.php file so unreadable, we need to think to implement them within Yiinitializr structure. What are your thoughts?

[mdeweerd]

Ok, I have to better "imagin" Yiinitializr.

While we are at it, we can also think about:

• configuration caching because there is no need to re-read the configuration files each time.
• Clearing the cache on certain updates (I use the date of a file in the runtime directory as the seed for the assetManager in order to force updates on the client side) -> maybe we can do something in the configuration.
• Keep in mind test.
• Keep in mind bootstrapping the database.
• Keep in mind loading libraries (Zend, ez that I find in some templates, or GeoJSON that I use) or setting options that are not currently settable in the configuration file (e.g., CHtml::$liveEvents);
• Keep in mind that some options may rely on others. Example to allow my IP in 'xweb' logroute when the debugkey is set:`

if($debugmode) {
    if(isset($_GET['secretdebugkey'])) {
        $config['components']['log']['routes']['xweb']['allowedIPs']=array( isset($_SERVER['REMOTE_ADDR'])?$_SERVER['REMOTE_ADDR']:'127.0.0.1');
    }
}

• Keep in mind use of 'yiilite' (and influence of debug setting).

[mdeweerd]

• theme support!

[mdeweerd]

Observations:

• In the configuration structure, there is only one way to initialise Yiinitializr. Yiinitializr can not have different configurations accross configurations. Yiinitializr's configuration is related to the project. Example of consequence: Yiinitializr should not know about the path for Yii because that is a machine dependent setting (the location of yii is different on my development machine than on other machines).
• Fix a priority and configuration file naming and/or new configuration array structure. The configuration can be dependent on: -- Machine -- Domain / Url (localhost/site1 should give other configuration than localhost/site2, and even mydomain.com/backend) / Port -- User -- [I exclude local path] -- Server type [? should we add this? At least anticipate that we can] -- "context type": console, test, web

The file REGEX would be: ({$machine})?({$partialdomain}(@{$relpath}))?({$port})({$user})?({$servertype}_)?({$contexttype}).php

Theme specific configuration is in the theme path with same rule.

So, valid names, lowest precedence first, for machine 'server1', url 'www.github.com/2amigos', user 'mdeweerd' (I did not mention port in the example, I added it later), config.php [default file first] github.com_config.php [url before machine] server1_com@2amigos_config.php [machine before user, after Url] server1_github.com@2amigos_config.php server1_github.com github.com_mdeweerd_config.php [user after server only] server1_mdeweerd_config.php
server1_com_mdeweerd_config.php server1_github.com_mdeweerd_config.php

Implementation: get list of files in configuration directory matching regular expression using known machine properties. Then order the configuration files, then "merge" them with the required precedence.

In 'config.php', we could allow a special entry like this with the same naming rules: array( 'configs'=>array( 'github.comconfig'=>array(/* config /), 'server1_mdeweerdconfig'=>array(/ config *), ) );

Yiinitializr removes 'config' from the array to keep compatibility with 'Yii'. File 'server1_mdeweerd_config.php' settings have priority over 'server1_mdeweerd_config' array.

-> this allows flexibility in configuration.

• Define a means to define 'globals'. Globals may impact choices in configuration files, so they must be read before the 'config' files.

So: globals.php XXXX_XXX_globals.php

with arrays: array( 'globals'=>array('YII_DEBUG'=>array('expression'=>'isset($_GET['specialdebugvar'])?1:0'),), );

• For caching, use the dates and names of the configuration files to create a hash key. We should cache 'globals' and 'config'.
• The path for 'yii' is set in 'config.php' type of file (with compatibility for yiilite).
• Library loading must be defined in the 'config.php' file type somewhere.
• We can allow 'post-' and 'pre-' eval expressions.
• To allow conditional values, we could have in 'config.php' :+1: array( 'conditionals'=>array( 'conditionname'=>array('conditionexpression',array()) ) -> We give a name to the condition so that the condition can be removed in a more specific configuration file by doing: array( 'conditionals'=>array( 'conditionname'=>null )
• Any Yiinitializr specific option is removed from the array we present to Yii.

[tonydspaniard]

I am for:

• configuration caching (great idea)
• clearing cache (there is a file written env.lock) that can be also used for that purpose
• tests are more for the codeception inclusion as a composer library.
• bootstrapping the database, shouldn't the different config files be used for that?
• loading libraries / I am not sure what you mean, as on the current boilerplates using Yiinitializr that is part of the configuration files too and would actually be better to use the lazy loading approach at all times (apart from certain required components -ie logging)
• I do not think it could be complex to provide conditional configuration settings on the file
• I am not sure if yiilite is within the scope of yiinitlizr
• theme support is not really a big thing and should be handled via the configuration files, not Yiinitializr itself. To tell you the truth, never used this feature even though I believe it maybe useful for other people

[tonydspaniard]

• _In the configuration structure, there is only one way to initialise Yiinitializr. Yiinitializr can not have different configurations accross configurations. Yiinitializr's configuration is related to the project. Example of consequence: Yiinitializr should not know about the path for Yii because that is a machine dependent setting (the location of yii is different on my development machine than on other machines)._

I disagree with it, Yiinitializr works with different configurations and settings (check http://yiinitializr.2amigos.us different templates and configurations). The example you provide is not compatible with current solution provided with Yiinitializr as Yii is another package downloaded with composer, it is part of the settings you need to configure.

[tonydspaniard]

If we do regex, wouldn't that increase complexity to the newbies?

[mdeweerd]

What I meant is that in the configuration structure, Yiinitializr itself should be configured in only one way. That is: there is only one configuration for Yiinitializr to know where to find the other configuration files.

[mdeweerd]

If we do regex, this is inside Yiinitializer. Newbie only has to respect the order of naming the configuration file or option. He only writes:

server1_mdeweerd_config.php

The regex is hidden.

[tonydspaniard]

Can we do that through one config file only? I meant through the settings of the configuration file of Yiinitializr?

Edit: I think we should do some kind of proposal (gist maybe?) Some of the ideas here I like them a lot

[mdeweerd]

We can allow it in one config file only too - we should be flexible. If you add 'configs' to the configuration file of Yiinitializr, this is possible.

array(
'configs'=>array(
    'default'=>array(
        'yii'=>'yiipath',
     ),
    'server1_mdeweerd'=>array(
        'yii'=>'otheryiipath',
        <restOfConfig>,
    ),
    'domain'=>array(
        'globals'=>array( 'YII_DEBUG'=>etc),
       <restOfConfig>,
   )
),
'Yiinitializr'=>....
)

[mdeweerd]

Let's try Gist ;-).

[mdeweerd]

I started a gist.

https://gist.github.com/mdeweerd/5475262

[mdeweerd]

Ok, I think I identified an important misunderstanding on my behalf: Yiinitiliazr sets up the project structure and does not serve project initialisation itself.

Waht I was talking about (in part based on your goal of getting rid of the configurations in 'index.php'), is the configuration of the Yii framework after is has been 'built'/'set up'. However, this is not incompatible as Yiinitializr should set up the flexible dynamic application configuration structure with the 'index.php' that supports it.

[mdeweerd]

• bootstrapping the database, shouldn't the different config files be used for that? What I mean is that automating the creation of the database (before applying migrations to create the tables) is currently missing, but probably not in the scope of Yiinitializr. If you take a CMS, it suffices to unpack the CMS on the target system, open the 'config.php' in a browser and you're able to set up the database from there. With Yii*, one can imagine that there are such routes that allow you to setup the database - either through a navigator or the command line, and that this configuration is then commited to the server specific configuration file.
• loading libraries / I am not sure what you mean, as on the current boilerplates using Yiinitializr that is part of the configuration files too. Based on my misunderstanding I guess, and if it is already there, that is ok.
• I do not think it could be complex to provide conditional configuration settings on the file. Not sure if you think it is complex or not complex - I think it is not too complex.
• I am not sure if yiilite is within the scope of yiinitlizr Maybe not in the scope of Yiinitializr, however one should consider an optimised installation.
• Theme support is not really a big thing and should be handled via the configuration files. Again, probably a misunderstanding regarding Yiinitializr. I have done some theming but it is not very well supported, i.e. do "theme" effectively, I had to extend some classes.

Anyway, if this discussion spurred some ideas and future results that is a good thing ;-).

[tonydspaniard]

Thanks for your input @mdeweerd, there are all good ideas

[mdeweerd]

@tonydspaniard I have set up a first project using Yiinitializr, so things are getting more concrete for me.

Feedback: It's probably not all Yiinitializr's fault, but I did spent some time trying to understand why my changes to 'dev.php' were not taken into account. This was due to several issues:

• env/dev.php is not used - instead it seems to be copied to 'env.php'. So I have to update 'env.php', but then how do 'env/dev.php' and 'env.php' keep in sync? -> 'env/dev.php' should be loaded
• I modified the 'gii' settings in 'common/.../env/dev.php', and then in 'common/../env.php' (following the discovery above). Too bad: my changes were still not taken into account! Why? Because 'frontend/.../env.php' had the same configuration and was overriding the changes in common. Suggestion: the default setup should have every configuration in one location only (i.e, mosty common). There is no issue with suggesting (=comments) the configuration in the other configuration files.

This also raised another possibility of improvement: to track where a configuration was coming from, I had to hack "Initializer.php". It'ld be nice if there are some helpers for debug.

Also, now that I see the use of Yiinitializr, I agree that my earlier suggestions are good ideas for Yiinitializr ;-).

Question:

• Is there already a method to automatically add the configuration of a package (i.e., automatically add an alias, an import)?

Question:

• I am somewhat concerned with configuration management. What happens if a package disappears from one of the repositories?

Now that I am using this and that I am getting into GIT at the same time, some pull requests will probably be coming in the future.

[Borales]

env/dev.php is not used - instead it seems to be copied to 'env.php'.

@mdeweerd I spent some time to figure it out to myself. env.php is generated only with the composer install command or with the composer update in case when env.lock is missing (with the absent corresponding config/env.php files).

I made a console command that removes all env.php and env.lock files in my project. And after that - I launch composer update to refresh my config files. That's not suitable for me...

To keep existing structure, I suggest to generate env.php content similar to the following:

// depends on Config::value('envlock')
return require(__DIR__.'/env/{env}.php');
// or make it dynamic
return require(__DIR__.'/env/'.Config::value('envlock').'.php');

This way - we can solve our issue with the "expired" config data.

https://github.com/tonydspaniard/yiinitializr-advanced/blob/master/common/lib/Yiinitializr/Helpers/Initializer.php#L190

What do you think, @tonydspaniard ?

[tonydspaniard]

@Borales what do you think if instead of doing so much changes we propose a new parameter to the command?

[Borales]

@tonydspaniard sure, we can do that, I was just thinking about BC. Your call

[tonydspaniard]

Adding a new parameter couldn't break anything IMHO... is just a new option case.

[Borales]

@tonydspaniard oh sorry, I misunderstood your previous comment. Sure, a new command parameter would be nice :)

[Borales]

@tonydspaniard did you mean a new command parameter to regenerate env.php configs?

[mdeweerd]

Very old ticket - no longer useful.