It's safe to remove concrete 5.5.1 folder inside update folder?

Permalink
after i download and install update to concrete5.5.1, i notice that /updates/concrete5.5.1 still in there.
it's safe to delete concrete5.5.1 folder?
how can i remove that?
why it didnt take place old concrete core?

mkharisecario
View Replies: View Best Answer
JohntheFish replied on at Permalink Reply
JohntheFish
No!!!

The updates folder is now used for the core code instead of the old concrete folder.

config/site.php will have a little note at the end that the core uses to decide to use the code in 'updates'. This is so the version of C5 in use can be regressed by simply editing or deleting the note in config/site.php and retrieving a database backup. Further new C5 versions then have their own folders within updates

So best to just leave it alone.

(If you really want to delete it, you would need to copy the code from updates to the old concrete folders and then edit the config. There may also be some other odds and ends that would need tidying up that I don't know about.)
mkharisecario replied on at Permalink Reply
mkharisecario
Thanks, John.
but, if new C5 version have their folders, does we still need /concrete folder?
can't i remove one of them? let say old /concrete instead of /updates/concrete5.5.1?
If there is another update (ex concrete5.5.2), can I delete the old one (concrete5.5.1)?
andrew replied on at Permalink Best Answer Reply
andrew
You still need the original concrete/ folder, but all that's processed in the original concrete folder is a few lines that basically tells concrete5 to look in the new spot.

If you want to consolidate some things you can do this:

1. Remove the concrete/ folder from your web root.
2. Move updates/concrete5.5.1/concrete into your web root.
3. Remove the line that says

<?php define('DIRNAME_APP_UPDATED', 'concrete5.5.1');?>


From config/site.php. That will default concrete5 to looking back into the regular concrete/ directory (which is now 5.5.1, since you moved it.) Since you've you already upgraded once you followed these steps your site should be exactly as it was before.
mkharisecario replied on at Permalink Reply
mkharisecario
Thanks! It works...
Now I can get my free space again :)
cringer replied on at Permalink Reply
When I install concrete5, and I need to make changes to the code, I duplicate the part of the /concrete/ directory structure that I'm changing into my website's root, and place the changed file there, not in the /concrete/ folder. I had assumed that reason for this was so that my changes would not be overwritten when I installed an upgrade.

But, now I see that upgrades are installed in ...
/updates/concrete5.x.x.x/concrete/.

If I need to to make changes in the updated version, do I put those overriding files (and their paths) in the root of the version in the updates folder ...
/updates/concrete5.x.x.x/ ?

If that's true, what's the point of the overrides? Shouldn't I just update the core, since new versions are in their own directory?

I have a lot of sites that need to be upgraded. I want to do this correctly.

Thanks,
playhouse replied on at Permalink Reply
I know this is an old thread..but it really helped. I have around 50 c5 clients now and each time we do an update we blow out the server space ... sites are sitting at around 120MB each.

To conserve space we need to manually do what is suggested in this thread.

Just curious as to why C5 doesnt just replace the /concrete folder on update? Im guessing there is a logical reason :-)
JohntheFish replied on at Permalink Reply
JohntheFish
The only folder within updates that you need to keep is the one that contains the currently active version of concrete5. This is usually the most recent, but its advisable to check config/site to make sure.

As an intermediate step, you could rename the updates version you are thinking of deleting to have a prefix 'old_' . If the site stops working, you can then rename it back. If the site continues to work, then you can delete the 'old_' version.

The reason for creating new folders for each update is to enable failed updates to be undone.
mnakalay replied on at Permalink Reply
mnakalay
Before you do an update you are very strongly advised to do a database backup.
Now let's say you do that, then you go through the update but something goes wrong and your website is broken.

All you would have to do is delete the new Concrete folder in the update folder, bring back your database backup, and everything is back to normal the way it used to be.
Now if during the update, instead of putting the new files in the update directory, Concrete just deleted the original concrete folder to replace it with the new one, rolling back the changes would be a pain. You would have to download an old Concrete5 version matching your old version, delete the concrete folder, uploading the new one, then bringing back your database update.
playhouse replied on at Permalink Reply
Thanks for the replies guys... It still doesnt eliminate the top heavy nature of updating without manually moving things around. :-)

I do recall seeing thread somewhere about running all sites off one core... anyone else doing this with success?
Deladroid replied on at Permalink Reply
Deladroid
I heard about this once too and forgot. It would be interesting to be able to run multiple sites off of one core- and I would benefit as I have more than one C5 website client on my server. Saving space is definitely a plus (and why I'm here reading this).
katz515 replied on at Permalink Reply
katz515
Three questions:

- Are you running those sites on VPS or dedicated server that you have a SSH access to?
- Can you make symbolic links?
- Is it Apache server, and do you know how to edit vhost.config file via SSH & vi?

If all of above answer is yes, you can do a single core.
(I don't know how to properly set-up on other web servers but apache).

I wrote some how-tos here (also submitted to How-Tos section here)
http://en.katzueno.com/2014/05/21/multiple-concrete5-installs-apach...

Cheers.
Deladroid replied on at Permalink Reply
Deladroid
I'm on a windows server, but may consider moving the C5 instances to Apache. Thanks for the How-to on single core!