Concrete5 directory structure enhancement
Permalink
A proposal for 5.4.2.
Please, do not use in production!
Don't you think the current directory structure is too complicated, especially to newcomer developers?
— Outdated core in "/concrete" directory.
— Updated core in "/updates/concrete{$APP_VERSION}/concrete" directory
For example, filepath to dispatcher:
"/updates/concrete5.4.1.1/concrete/dispatcher.php"
We can make things simpler:
— Only one directory for current core & updates — "/concrete"
— Current core — "/concrete/{$APP_VERSION}/"
Filepath to dispatcher:
"/concrete/5.4.1.1/dispatcher.php"
I've tested this on a sample project.
1) move /updates/concrete5.4.1.1/concrete/ to /concrete/5.4.1.1/,
you can delete /updates folder & all other folders inside /concrete
2) /index.php
3) /concrete/5.4.1.1/dispatcher.php
comment-out check for an alternate core
4) /concrete/5.4.1.1/config/base.php
P.S. i was having some troubles with __FILE__ constant, they have gone with Apache restart.
Please, do not use in production!
Don't you think the current directory structure is too complicated, especially to newcomer developers?
— Outdated core in "/concrete" directory.
— Updated core in "/updates/concrete{$APP_VERSION}/concrete" directory
For example, filepath to dispatcher:
"/updates/concrete5.4.1.1/concrete/dispatcher.php"
We can make things simpler:
— Only one directory for current core & updates — "/concrete"
— Current core — "/concrete/{$APP_VERSION}/"
Filepath to dispatcher:
"/concrete/5.4.1.1/dispatcher.php"
I've tested this on a sample project.
1) move /updates/concrete5.4.1.1/concrete/ to /concrete/5.4.1.1/,
you can delete /updates folder & all other folders inside /concrete
2) /index.php
#new upgrades will make changes to this file define('DIRNAME_APP_UPDATED', '5.4.1.1'); require('concrete/'.DIRNAME_APP_UPDATED.'/dispatcher.php');
3) /concrete/5.4.1.1/dispatcher.php
comment-out check for an alternate core
## Check to see if, based on a config variable, we need to point to an alternate core ## # require(dirname(__FILE__) . '/startup/updated_core_check.php');
4) /concrete/5.4.1.1/config/base.php
#if (defined('DIRNAME_APP_UPDATED')) { # $ap = ASSETS_URL_WEB . '/' . DIRNAME_UPDATES . '/' . DIRNAME_APP_UPDATED . '/' . DIRNAME_APP; #} else { # $ap = ASSETS_URL_WEB . '/' . DIRNAME_APP; #} $ap = ASSETS_URL_WEB . '/' . DIRNAME_APP . '/' . DIRNAME_APP_UPDATED;
P.S. i was having some troubles with __FILE__ constant, they have gone with Apache restart.
Personally I don't like the auto updater, so i do manual updates which just negates the updates folder,
I agree that updates/core/ is potentially difficult to discover, but the problem I see with this is that you'd have to make your entire concrete/ directory writable by the web server, which I considered sketchy. I also think updates/ is actually more auto-discoverable, but to each his/her own.
I think if you want to have as much control over the environment as you're suggesting, perhaps the auto-updates just aren't for you (as they aren't for mnkras.) That said, what do others think?
I think if you want to have as much control over the environment as you're suggesting, perhaps the auto-updates just aren't for you (as they aren't for mnkras.) That said, what do others think?
Well, i think only changed files should be transfered updated/moved/copied cause downloading the entire zip uses bandwidth and space, there would also be less of a chance for files to become corrupted and such, also would be slightly quicker for the auto update process. then i might even use the auto update ;) (probably not :P)
Thats my opinion on it, also the upgrade process needs to be a little refined.
like when upgrading past a version (5.4.0.5->5.4.1.1) sometimes the 5.4.0.5->5.4.1 doesn't fully run or something, and running the force upgrade only runs the 5.4.1->5.4.1.1 script so you have to open the config table and lower the APP_VERSION again to 5.4.0.5 to run the 5.4.0.5->5.4.1 upgrade again.
Mike
Thats my opinion on it, also the upgrade process needs to be a little refined.
like when upgrading past a version (5.4.0.5->5.4.1.1) sometimes the 5.4.0.5->5.4.1 doesn't fully run or something, and running the force upgrade only runs the 5.4.1->5.4.1.1 script so you have to open the config table and lower the APP_VERSION again to 5.4.0.5 to run the 5.4.0.5->5.4.1 upgrade again.
Mike
«the problem I see with this is that you'd have to make your entire concrete/ directory writable by the web server, which I considered sketchy.»
But now we have to make /updates folder writable, what's the difference?
«I also think updates/ is actually more auto-discoverable, but to each his/her own.»
In current structure:
1) We have useless /concrete subfolder inside /concrete{$APP_VERSION}.
2) We have outdated core without any sign of version number in it's name.
But now we have to make /updates folder writable, what's the difference?
«I also think updates/ is actually more auto-discoverable, but to each his/her own.»
In current structure:
1) We have useless /concrete subfolder inside /concrete{$APP_VERSION}.
2) We have outdated core without any sign of version number in it's name.
Found a better solution.
Now we have to make /updates & /config directories writable before update.
With this one only /concrete is needed for update.
1) /index.php still remains
2) add new file or edit existing one
/concrete/dispatcher.php
APPLICATION FLOW:
/index.php
->
/concrete/dispatcher.php
->
/concrete/{$APP_VERSION}/dispatcher.php
Now we have to make /updates & /config directories writable before update.
With this one only /concrete is needed for update.
1) /index.php still remains
<?php require('concrete/dispatcher.php');
2) add new file or edit existing one
/concrete/dispatcher.php
<?php #new upgrades will make changes to const DIRNAME_APP_UPDATED in this file define('DIRNAME_APP_UPDATED', '5.4.1.1'); require(DIRNAME_APP_UPDATED.'/dispatcher.php');
APPLICATION FLOW:
/index.php
->
/concrete/dispatcher.php
->
/concrete/{$APP_VERSION}/dispatcher.php
