October CMS is a great system, but it relies on the installation of the Static Pages plugin to make it client friendly.

The Static Pages functionality needs to be incorporated into the core, so that placeholders and page variables etc can be used within CMS pages.

Having the two systems (CMS Pages and Static Pages) running side by side is just too confusing for everyone. Clients end up clicking the "CMS" menu option, when they should be clicking the "Pages" menu option.

The idea is to hide the CMS menu option from clients when Static Pages is installed.

Hiding CMS menu does the trick.

Only confusion (at least for me) comes from need to go into CMS pages area to create pages with dynamic URL (eg.: /blog/:page? , ...).

Problem here is, when my client wants to edit meta_title and meta_description (or generally SEO) for this dynamic pages.

I still have no good solution for this :(

I can create separate static page for eg. Blog with /blog URL to "fake" CMS page in Pages plugin, but there is still need for a CMS page with /blog/:page? URL which must be edited in CMS area.

@jan-vince It's almost like Static Pages was an after thought and it's just a shame that the CMS seems to rely upon the installation of this plugin to enable it to be client friendly.

I think October is just true to the original idea to make everything as simple as possible.

If there can be a plugin for something, why it should be in a core? I believe that many developers don't need Static Pages functions and are fine with CMS area (as I am with small websites).

Nothing is perfect, but with October I am enjoying my work again :)

I want to drag this one out of seeming retirement, I actually came to this forum just to raise this very issue. Frankly, no site is going to be organized into dynamic pages and static pages. Usually it's going to be a good mix of the two - and when a single subsection of pages have a mix of StaticPages and CMS pages, problems arise. Static Breadcrumbs not showing with CMS pages, for example - nested menu items have to be manually added to get both items to show. Don't even get me started on the variables under the hood being so vastly different between the two.

These two shouldn't just play nice, they should be merged. End users shouldn't have to ask why there are two types of pages - and like has previously been pointed out, hiding CMS pages from clients just causes further headaches - they can AND will eventually want to edit a page under the CMS section and want to know why they can't find it.

Frankly, I started out as a fan of the CMS, but the headaches described above have turned an otherwise fun project into a slow descent into Hades. Yes, there are different ways I could go about doing things if it was just for me, but at the end of the day we're developing sites that get handed off to clients/customers to use on their own, and we have to factor that into our decisions when choosing and working with this or any CMS.