there is a copy of the blog_entry.php file in the core. It's probably picking up from there. Look in root/concrete/page_types...

Really?

This must be a joke. Why should it do this? It's a specific! theme and there is a default.php and there is a rule "fallback default.php". So why are they doing this?

I didn't read it up but in the videos they are saying the fallback is default.php so I assume it's the only one... Anyway, there video overall isn't very good and is lacking some info.

The worlds a funny place sometimes.

@ mhawke ^^ Best Answer ^^ :D

The blog_entry.php file is just another part of what you get with the c5 core. You can always give a page type a name completely different from it's filename associated page type handle when adding them, such as a name like "Blog Entry" and a handle of "blog_page" which matches the filename. Simply avoid using the blog_entry page type "handle" and you should be good to go.

EDIT: That or just create a blog_entry.php file that matches your default.php to override the core blog_entry file ;)

I really didn't mean to be a smart-ass padomu but concrete5 is a very sophisticated, complex system and there are lots of good reasons why things are done the way they are. You've just started your journey here so please try to 'seek first to understand and then to be understood'.

I agree with enlil that blog_entry.php seems to inherit from the core template if it is not included in the theme, which is an exception (the only one I'm aware of) from using default.php when a page template is not in your custom theme. And also I'll add that in testing this out just now, I found blog_entry is displayed inside of view.php from my custom theme as if it were a single page. I'm not sure why blog_entry works this way, but if it's not written into the theming documentation now some mention of that probably should be added there along with a mention of why it works like this.

I still don't see why this matters, if you plan to have a blog and don't want to make a blog_entry.php because you want use default.php for the display, then just make a page template blog_post instead of blog_entry. Is that too simple a solution? Is it really necessary to berate the design of the theming system instead? Coming from a background in theming for Wordpress and Drupal (speaking of strange theming systems) I can tell you I find it way, way faster to make themes in C5, and the system is just simple and effective. If having to change the name of a page type is the sort of thing that makes you go crazy, clearly you haven't spent days trying to make preprocessing functions work in Drupal themes.

I'm willing to bet it lies along the lines of "area naming conventions" and due to the fact the page type, out of the box, contains areas outside the typical "main" and "sidebar" areas for the default.php file.

This way the core can carry along those areas inherantly like the others. Similarly, if i'm not mistaken, there should be "site name" and "header nav" areas in the header as well per naming conventions...

EDIT:
http://www.concrete5.org/documentation/developers/pages/themes-2...

And yes, this *should* be added to the documentation :)

@mhawke

I'm new to C5 but not to coding. I've worked with several PHP Frameworks and also have some experience as a Projectmanager. I'm just used to consistence! If I get told (in an official! Video about Theme Developing) that if a type isn't define the flalback is default.php I just don't expect this behaivour. Also in de Video they aren't using the line oh PHP which denies direct access to templates via URL.

I also see the Problem with the types and why they made a special fallback for blog. Probably they did it because it's a rather "complex" layout and a simple Fallback would be bad.

Anyway, maybe it would be better overall to just show an error if a type doesn't exist because it won't ever fit the actuall type which should have been used.

Also I don't get your answer. That's not an answer. They want to provide a quality product so they should be able to handle ciritcs and if they really did some stupid thing they can't just say, "you know, it's complex".

Basically I'm just complaing about the video.

The answer is this:

- application page_types do not use default.php. They use view.php.
- unless you are including it in your theme, then it is treated like a regular page_type.
- pb_post.php (ProBlog's page_type) behaves the same way.

Why do we use a custom page_type? Because we have specific application level controller actions needed in that page_types's controller file that do much more advanced things than simply displaying some content.

There is a general lack of understanding in the community: application level page_types do not follow the simple fall back default theming, they are treated like a single page.

Regardless, it's not "stupid", it's awesome. It provides a tremendous amount of application power while offering a generic theming ability.

What then would be the alternative ? 'guess' what style, layout, design and color's any given designer is using????? No....that's not possible.

The way it is, is in fact correct and flexible.

But I do agree there should be more clarity on the subject.

ChadStrat

That would make the basis of a useful howto.

Thanks for clarifying how this works RadiantWeb. Interesting stuff I noticed that the blog_entry.php worked this way but didn't see it was the case for all system templates. So that makes me wonder... if I make my own template for a system page type such as blog_entry.php am I overriding view.php or am I am overriding the system template blog_entry.php? Because I could start by copying blog_entry.php from the core with all the different areas, or I could just copy my view.php. The thing is if you just copy view.php with it's $innerContent that doesn't give you much chance to change the inner areas... so blog_entry.php must override system blog_entry.php then right?

Well I look forward to trying this stuff out... another option to consider also would be if you want something completely different just make a blog_post.php page type and start fresh.

I tried to add this information tohttp://www.concrete5.org/documentation/introduction/template-and-th... and instead of adding my post it made a new forum post under "Building with Concrete5". I guess that explains why all the documentation pages have 0 discussions under them. Any idea why it works this way? That really is a waste of opportunity to add to the documentation because in other systems the comments under the main documentation is often where you find the best information, because that's where you get either the corrections or clarifications.

Thanks a lot. :)