I was just looking through the architectural changes in 5.6 myself and was wondering about this too! My initial reaction was "why bother?", as well, the js and css folders from the 5.5 "core" (aka /yoursite/concrete/js and css) folders are not included in 5.6's new core folder...

K so right after I wrote that message, one thing occurred to me where it could be useful. (This is purely a stab in the dark at the moment, just a best guess).

When you override a core class (copying from the /concrete directory to the same directory in the root), you basically have to override the whole class. It seems like, and I haven't tested this out yet, this might be a way to make it so that you can just override specific methods/properties of a base call instead of the entire thing? Thoughts? I'd bet there is other stuff too, just a thought.

That makes senses that you could do that, but I would hesitate to do so as now a developer can end up with just one extra override location to remember.

Wouldn't it make more sense to have the changes made to the /yoursite/concrete/libraries etc. files done instead in /yoursite/libraries etc. files?

So, for example now /yoursite/libraries/backup.php file would contain:



Instead of /yoursite/concrete/libraries/backup.php file containing that (that file would contain what it used to have, which currently now the 'core' directory file has).

This way, if a developer cares to override an entire class they can, but if they want to override a single method they can do that too and it would all be in the same location making tracking down changes easier?

Also, I see that not all files in /yoursite/concrete/libraries have even had the new change made/a copy of them made in the new 'core' directory. This is very confusing... A little documentation or other light shed on this would be awesome!

Side note, I LOVE the large volume of comments in the new 'core' directory files :)

Didn't think of that. Totally valid. I'd hate to be looking through (potentially) 4 files to track down an override.

I guess if we followed the golden rule of never. ever. touching. anything in the /concrete directory, it would make things easier (go convention over configuration!) - but of course thats the hoping everyone follows the golden rule... which of course is bound not to happen.

I'm interested to hear feedback from someone who knows better and/or documentation on it.

And seconded on the amount of comments w/ the latest release. Seems like everything about C5 is headed in the right direction.

@bolder: This is in fact the reason the change was made (so you can override just one function of a core class instead of having to override the entire file/class). There was a discussion a while back about how the Kohana PHP framework does things this way and it makes it *way* easier to modify just what you need in the core system.

It's one of those things that doesn't seem like a big deal but actually makes overriding things in the system much better and more precise -- and opens the door for having different things override different parts of the same core file.

@Landson -- one of the nice features of C5 is how you rarely need to override core files. This is a big win over other systems, and in fact it's *much* easier to see what's been modified in a C5 site because of it (just look through the override folders at the top-level of your site, as opposed to running some crazy recursive-directory-diff on the entire core system folders to see what files have been changed from the default install).

-Jordan

This is where I first heard of the changes.

http://www.concrete5.org/community/forums/customizing_c5/extending-...

I'm new to developing in C5 so I don't have any ingrained notions of how things used to work so I love the new architecture and think it really puts C5 ahead of other CMS's.

I also think it was a bold move to essentially re-write a successful project like C5 simply because it became clear that this was the right way to move forward. I am amazed at how few serious bugs there are in 5.6 considering the enormity of the changes.

It's actually not that big of a change because all the existing code out there still uses the underlying core stuff the same. It's just gotten another layer of indirection inserted in between the two (if that makes sense).

If, on the other hand, they had changed the names of all the classes that theme/block/controller code needs to use (like if you had to change all your theme code from $a = new Area to $a = new C5_Area_Model), *that* would be enormous and would probably kill the platform :)

To an ex-Classic ASP, PHP newbie, it seems an enormous undertaking when you add in the changes to the permissions model as well.

Yeah, I hear ya. To be clear: it *is* a big undertaking for the people that have to maintain the core system. But it doesn't require any thought from the people that use the system (whether that be designers/developers building sites, or people maintaining content on their site).

The advanced permissions and workflow overhaul on the other hand... those seem like enormous undertakings for sure!

Sorry, I was always referring to the core team's undertaking. To do all that without really affecting the way users interact with their site is a remarkable feat. I'm still trying to get my head around all the advanced permissions stuff and I haven't ventured into the workflow yet. Although I really like the new features, I can see a lot more support calls to the developers from users who have to implement them on their sites and can't figure it out. It's intuitive when you watch a demo video but then in real life, you have to hold all these scenarios at once in your head. Kind of like a dream of a dream of a dream... at some point you just can't hold it all.

Yep, and that's where documentation comes in... which has unfortunately always been severely lacking with C5. Hopefully that changes over time.