Updates - Why the Whole Enchilada?
Permalink
Just curious...
If only the core files (i.e. those within the concrete directory) are needed/utilized in an update, then why are all the root-level (empty) directories included in the update as well?
Sure, empty directories don't take up much disk space, but why include the clutter? It's just that much more "stuff" to sift through and/or ignore when traversing directories during development.
Or am I missing something? Are these directories used in some way? In my experience, it's just the mirrored directories at the web root level that are used for overrides.
Anyone have an idea why this might be?
Thanks,
-Steve
If only the core files (i.e. those within the concrete directory) are needed/utilized in an update, then why are all the root-level (empty) directories included in the update as well?
Sure, empty directories don't take up much disk space, but why include the clutter? It's just that much more "stuff" to sift through and/or ignore when traversing directories during development.
Or am I missing something? Are these directories used in some way? In my experience, it's just the mirrored directories at the web root level that are used for overrides.
Anyone have an idea why this might be?
Thanks,
-Steve
Thanks for the reply, dojodesign, but perhaps you misunderstand my question. Either that, or I'm missing something. I know full well that core C5 files can be overridden by placing copies in the top level mirrored directories. I've overridden numerous files.
However, my question pertains specifically to the recently revised update process whereby an entire C5 installation is copied into the "updates" directory (which resides at the top level).
After updating, it's still the top level directories that override the C5 system files - not the corresponding directories within the update installation. Am I making sense? I still don't understand the purpose of any of the directories besides the "concrete" directory in an update installation.
Any help or insight appreciated,
-Steve
However, my question pertains specifically to the recently revised update process whereby an entire C5 installation is copied into the "updates" directory (which resides at the top level).
After updating, it's still the top level directories that override the C5 system files - not the corresponding directories within the update installation. Am I making sense? I still don't understand the purpose of any of the directories besides the "concrete" directory in an update installation.
Any help or insight appreciated,
-Steve
i vote to only update changed files
I like the way it works now. I'd guess it's a lot more stable this way.
By copying the entire directory, it's just as good as if you had gone, downloaded it and uploaded it yourself. What you may lose in nuisance, we gain in stability.
If the automatic downloads start including only part of the update, then what's to say that it won't end up missing something? So everyone tests the beta build, it works great, the update rolls out, then it breaks everyone's site because a file was missing.
Downloading only the changed files seems to be even worse. After 20 updates, you may end up with 20 levels of directories with various versions of various files. I like the way it works now. It's clean, it's easy, it's stable ... all we need is a way to easily remove the old versions if we end up updating a lot
By copying the entire directory, it's just as good as if you had gone, downloaded it and uploaded it yourself. What you may lose in nuisance, we gain in stability.
If the automatic downloads start including only part of the update, then what's to say that it won't end up missing something? So everyone tests the beta build, it works great, the update rolls out, then it breaks everyone's site because a file was missing.
Downloading only the changed files seems to be even worse. After 20 updates, you may end up with 20 levels of directories with various versions of various files. I like the way it works now. It's clean, it's easy, it's stable ... all we need is a way to easily remove the old versions if we end up updating a lot
> I like the way it works now. It's clean,
> it's easy, it's stable
I tend to agree. I like the ease with which you can "roll back" to a previous version. I can see that it's also a boon if you're running multiple sites from a single core, as different sites can be running different versions.
HOWEVER, my point seems to be getting lost. None of the directories besides the "concrete" directory seem to be used/needed - at least, they aren't used for file overrides - so why include them?
-Steve
> it's easy, it's stable
I tend to agree. I like the ease with which you can "roll back" to a previous version. I can see that it's also a boon if you're running multiple sites from a single core, as different sites can be running different versions.
HOWEVER, my point seems to be getting lost. None of the directories besides the "concrete" directory seem to be used/needed - at least, they aren't used for file overrides - so why include them?
-Steve
Hi Steve,
I guess that's what I was referring to when I said that "what you may lose in nuisance, we gain in stability". It seems like it's better to keep the blank directories, and thereby keep the automatic updates identical to the normal downloads, then to maintain a separate archive that lacks the blank folders. The update script could remove them after upgrading, but it still seems like that would have the potential of possibly backfiring at some point ...
I guess that's what I was referring to when I said that "what you may lose in nuisance, we gain in stability". It seems like it's better to keep the blank directories, and thereby keep the automatic updates identical to the normal downloads, then to maintain a separate archive that lacks the blank folders. The update script could remove them after upgrading, but it still seems like that would have the potential of possibly backfiring at some point ...
Well, I guess ease of maintenance for the core team is as good a reason as any. I just wish it didn't have to clutter my aging brain. I get dizzy seeing so many like-named folders. ;-)
-Steve
-Steve
Ahh sorry. I misunderstood.
Attached is an image showing my directory structure after updating from 5.4.0.3 to 5.4.0.5.
So my question is, why install anything but the "concrete" folder, as it seems to be the only one used after an update. That is, the system files are referenced in the new C5 installation in the "updates" directory, but file overrides are still done using the top level directories. So why include a bunch of seemingly superfluous clutter in the update?
-Steve
So my question is, why install anything but the "concrete" folder, as it seems to be the only one used after an update. That is, the system files are referenced in the new C5 installation in the "updates" directory, but file overrides are still done using the top level directories. So why include a bunch of seemingly superfluous clutter in the update?
-Steve
There's still one thing I don't understand, and that is, what's the long term plan for updates? Currently, it seems that once one performs an update, then the "concrete" folder in the "updates" directory is used henceforth, and the "concrete" folder in the root directory is never used again.
So does that mean when Concrete 5.9.1.7 comes out I'll still have 5.4.0.3 in my root? Will there ever be a time when the root copy will be updated? Perhaps when Concrete6 comes out?
-Steve
So does that mean when Concrete 5.9.1.7 comes out I'll still have 5.4.0.3 in my root? Will there ever be a time when the root copy will be updated? Perhaps when Concrete6 comes out?
-Steve
This will let you edit the files while keeping the original copy. Placing files in these top directories overrides the base concrete directory.
Its also better for the times you upgrade the concrete version.