Updates directory

So how is the updates directory used? I have the latest version of concrete5 and did the upgrade through the dashboard. The system works fine. If I delete the files in the updates directory then the system doesn't work.

So are the files in the updates directory used going forward? That seems a little weird to me.


View Replies: View Best Answer
weyboat replied on at Permalink Best Answer Reply
The concrete folder in the updates package that is refereed to by your root/config/site.php file like this
define('DIRNAME_APP_UPDATED', 'concrete5.5.2.1');

will be used instead of your root/concrete/ folder,
all the files in the root folders except the concrete folder are still used,
If the update package just overwrote your existing package you would lose all your themes addons and files,
By leaving the original concrete folder in situ, you are able to "roll back" to a previous version,
I hope that kinda makes sense..
footndale replied on at Permalink Reply
I would think the updates would go in the \concrete directory structure sense this the location for core files.

Having the core go to the updates sturcture makes little sense. Decrease performance and uses more disk space that is not needed.
weyboat replied on at Permalink Reply
Some people do in fact delete the root concrete directory and replace it with the updated one, the system isn't slowed down by reading the updates/concrete/ folder because it just ignores the root/concrete one,
If you are concerned about storage space on the server then you do have the option of replacing the root/concrete one,
Many of us prefer to be able to roll back if we detect a problem with a recent update or incompatibility with our themes or addons,
The choice is yours but be careful that you don't break your database...
footndale replied on at Permalink Reply
I can see both ways. The good part is the code still only maintains two levels, Core and Custom.
pendragn replied on at Permalink Reply
Hmmm..it makes sense from the viewpoint of "I want to be able to rollback"...but in practice, it is not the best way, in my opinion.

The /concrete directory should be the "active" one.....the "rollback" directory should be the OLDER version, moved to a "rollback" directory or something.....as it stands now, I have to tell my site maintainers to go to the /updates/x.x.x.x directory and use that....but OH NO! we had to rollback, so now I have to tell them to use some different x.x.x.x directory after the next few updates.....hard to maintain!

The /concrete directory should ALWAYS be the active one, otherwise one has to "know" what the active one is at any given point.

I guess this could be fixed by moving/deleting/sym-linking directories, but it becomes "not as easy" if you have to do that.
surefyre replied on at Permalink Reply
Symlinking isn't best, anyway... think of the poor Windows users.

OK that's long enough thinking time.

I just realised also that as I think of the /concrete directory as the 'system core' I'm incorrectly copying stuff out of there into /single_pages and /blocks to base stuff off from time to time. This means that I'm creating stuff based on possibly incorrect versions (like V5.4.x) of code at the time of creation where really I should be basing it off /updates/concrete_some_version_x.x.x.x.x/blocks/whatever.

That's highly counterintuitive to me, also.

It'd be nice to at least see 'delete older updates' in the dashboard to wipe out e.g. 5.5, 5.5.0, 5.5.1, 5.5.2, and older versions where you're happy with the way your site's running.

I have some small sites that are over 1/4GB in size which is ridiculous and you really shouldn't need to SSH into the server to go find and delete the cruft to e.g. keep your backup files sizes sensible. As a platform C5 should be doing it or allowing the admin to with ease via the dash.
bw1 replied on at Permalink Reply
Sorry to bring this old thread back... I don't like to do that, but I actually searched for and found it based on myself thinking the same thoughts.

Pendragn and surefyre both bring very valid points to the table -- the same that I was thinking.

I'm guessing the "If it's not broken, don't fix it." mentality applies a lot to this situation, but I have caught myself pulling files to override out of the wrong (/concrete) directory many times, even knowing that there was an updated version in /updates/x and just not thinking.

I really like the idea of /concrete always being the current, active version, and I'm guessing that if you were to start from scratch, that would be the case?

Just wondering if there is any thought to address this in the future.

springer replied on at Permalink Reply
I am having an issue with my hosting organization, in that they say I have excessive directories in my account. When I follow their method of checking this, I find all the previous update directories in their listing. So, if I was to weed out unneeded directories, can i just delete those associated with previous updates prior to the current one? How about the first update in the updates directory, or the original install files? IF the latest update has everything I need do I need to keep the original?
exchangecore replied on at Permalink Reply
There's actually a little bit of discussion about this in the 5.7 github. If you guys would care to share ideas / concerns: