The override system is one of the great architectural features of Concrete5 because it allows us to change the display of a block without changing its functionality or editing interface. It also provides a way to customize core blocks in a "safe" way that won't get overwritten the next time you upgrade the system (which can be a major hassle in some other CMS's I've used). Your custom template could be a small change to the markup, or it could be a complete re-design that displays the block data in a totally new way, using a custom CSS stylesheet or even your own javascript files.

The Page List "404" Problem

Before Concrete version 5.6.2, there was a problem when overriding core blocks that had their own view.css file -- the system would get confused and try to serve a non-existing view.css file from your top-level SITEROOT/blocks/ directory, which caused a 404 error on pages with that block. This most commonly occurred with the Page List block (because it is such a useful block that it winds up getting customized on almost every site, and (unlike the similarly-useful Autonav block) it does have a view.css file in its core directory, which is what triggers this error).

Here is a demonstration of this problem on a site running Concrete5.6.1:

1. I've added a "Page List" block to this page, and the web inspector's "Network" tab shows us that the view.css file in SITEROOT/concrete/blocks/page_list/ was properly loaded:
   

2. Next, I'm going to create a custom template adding a new home_page_test.php file to SITEROOT/blocks/page_list/templates/:
   

3. Now, if I reload the page (note that I have not chosen the new custom template yet), I see this:
   

4. Well, isn't that weird -- the system is trying to load a view.css file from my top-level SITEROOT/blocks/page_list/ directory. What happens if I actually use the new custom template?
   
   
   

So the mere existence of a custom template seems to throw off C5 and cause this 404 error. If you keep experimenting with custom templates, you'll see that this doesn't occur when the custom template is nested inside a sub-folder (e.g. SITEROOT/blocks/page_list/templates/my_template_name/view.php), nor does it occur if a plain old view.php file exists in the SITEROOT/blocks/page_list/ directory.

This problem is easy enough to fix by simply copying the SITEROOT/concrete/blocks/page_list/view.css file up to the top-level SITEROOT/blocks/page_list/ directory. But this assumes one is even aware of the problem in the first place (which I'm guessing a lot of people aren't). Furthermore, it is very inconsistent and adds one more piece of mental baggage to the already-complex (and not entirely intuitive) process of building a modern website.

The 5.6.2 Fix

As of Concrete version 5.6.2, this issue has been addressed. The new rule is very consistent and easy to explain:

If you create a custom template, the system will look for related assets (CSS and JS files) in the custom template directory.

This also means that if you don't have any CSS or JS files for your custom template, the system will not erroneously try to load those file (and hence not create a 404 error).

That's it! Easy to understand and easy to work with, just the way it should be.