Collection consept in C5 - The next thing this CMS must have

Permalink
The composer is really really important part of C5 but their is big missing part - "Manage area" section for repeatable page types (posts, gallery projects, team and so on)

The UI pattern is very simple and popular in CMS. Table list items [page name - type - ect] + for each page list item you have buttons "view - edit - delete". On the top of the list you find big "ADD" button (add post for example)

In C5 you find this pattern only in addons like "problog" for posts "vivid store" for products "Teal Estates" for estates. In wordpress, joomla, drupal this is the main pattern. Also in "next generation site builders" like wix, weebly, squarespace you find this pattern.

My idea is under "Sitemap" - add new single page menu item named "Collections":
step 1: "+ Create collection" - select a name "blog posts" and "page type" "blog entry"
Step 2: click OK
Step 3: See a table view - her you can "view - edit - delete" pages - and "ADD page".

When you click on "edit" you will edit the page in composer form (You see only the composer form - you dont go to the page itself with the gear icon) + back - cancel - save icons.

This "Collections" is only "another" view of the same content structure you see in page search or in site tree but in more organize and easy to manage way.

The design will be like : "Page Search" dashboard/sitemap/search.

I want to add this idea to github, i hope other users think like me about the benefits of this.

Summary: MVC + Inline editing + composer + collection manager will be Perfect

siton
 
ob7dev replied on at Permalink Reply
ob7dev
Isn't that kind of what 'Page List' does?
siton replied on at Permalink Reply
siton
JohntheFish replied on at Permalink Reply
JohntheFish
siton replied on at Permalink Reply
siton
Thanks, but i thinks addon is bad solution because this is very handy feature for most of the sites.

My idea is without any special setting - simple simple simple! (One collection for one and only one page type - no filter by, no combinations, "beneath this page" or any extra setting). Also like this the big "add" button will named "add $page_type_name", and its really easy to know by code "ok, the user want to add blog_entry" - get this page type.

If you remove collection nothing is happening in the Database (this is only table view mode).

Collection "page Type" its enough without any pyrotechnics - you solve 3 main pages in sites (blog, projects, team) and a lot of simple and usefull page types ("food_recipes", "testimonial-page" "job_entry" "news_article" and so on)

Of course if you want more control for unique data like today you can work with single pages and controllers or find more complex addon.

Only in the future - the topic list of specific "page-type" could be useful in collection view as extra top menu bar (all, topic1, topic2).
mesuva replied on at Permalink Reply
mesuva
My advice would be to look for ways to enhance the existing Page Search page, including ways to link to it.

Having a way to list pages of a particular type, but only with some features available would be frustrating I think. It would be a recreation of something that already exists.

I do see the benefit of being able to present simple lists of pages for management purpose, but it's worth keeping in mind that concrete5 does have a focus on 'front-end' editing over the process of managing all content in the backend. If someone wants to edit or delete and existing blog post for example, they can browse to the page, search for it with the intelligent search, or use the sitemap or site search.

I think the point you are making is that there isn't a clean/simplified way of listing page types, and then listing pages of those types for quick management. I think a list of pages might be more _familar_ to users of other systems, but I don't think it would actually make finding a page to manage any quicker - there are already multiple ways to quickly find a page.

So instead of creating a whole new section, here's a quick suggestion:

For context, the other day I discovered that from the 'Flat View' of the sitemap, you can select 'Search Pages', which then sends you to the Page Search page in the dashboard, with the parent page already selected.

What I found from looking at the code is that the search page can actually be linked to with pre-configured options, you can pass them as GET arguments. You can filter by all sorts of things.

So as a simple way to get something running you could create your own dashboard page (via a package) that quickly linked to show pages filtered to show a particular page type, all you'd need to do is create links like:

/index.php/dashboard/sitemap/search?ptID=11&field%5B%5D=type&submitSearch=1
This brings up all the 'Portfolio Project' pages in the demo install, it's just a case of changing the 11 to the page type ID.

I'd say it would take no more than an hour to create a simple dashboard page that list the page types with links to these filtered views. This then provides a handy way to quickly list pages of a particular type without having to play around with the filter options, but it's using all the built in functionality to handle the actual page listing and editing.
siton replied on at Permalink Reply
siton
mesuva,

This tips are great but not intuitive and dont give real solution. Not all the editors will thinks about this - i talk about solution to all users (new and advanced).

I Disagree - WIX and Weebly are pure "inline - editing" "drag and drop" " website builder, no coding skills" tools. But agiannnnnnn for collection of pages (a lot of pages with same template layout) it easy to manage, edit, add from table view mode - so they decide to use table mode for this features. Like C5 premium blogs Addons choose this solution.

This is not something that Conflicts Concrete5 consepts (The composer is also like this - its not really "inline" editing)
mesuva replied on at Permalink Reply
mesuva
Well if you're absolutely convinced that this would be beneficial, you should look to put together a prototype as a package.

Because concrete5 add-ons can install new dashboard pages, you can create all the new functionality you think is needed without worrying that it won't be accepted in github.

Then you can share the add-on - if there is group agreement that the new features are worthwhile in the core, it won't be wasted effort - you'd only have to move a few files around and do a couple of re-names to create a pull-request for the new functionality - the code would basically be the same for new dashboard pages whether it's in a package or in the core.

If it doesn't get accepted, you can still then use your package, share it on github, put it on the marketplace, etc.