Make WordPress Core

Opened 12 years ago

Closed 9 years ago

#21665 closed feature request (wontfix)

Allow non-editable pages to be classified & organized as "System Pages"

Reported by: bootsz's profile bootsz Owned by:
Milestone: Priority: normal
Severity: normal Version:
Component: Posts, Post Types Keywords: dev-feedback has-patch needs-refresh
Focuses: ui, administration Cc:

Description (last modified by SergeyBiryukov)

We currently have no means of distinguishing regular “content” pages (pages that users can edit) and pages that are used as placeholders for custom templates / dynamic content.

As alexking mentions in #17470, users are often confused when they attempt to edit these "placeholder" or "dummy" pages only to find that the pages appear empty from within the page editor.

While his ticket concerned the "page_for_posts" page specifically, this issue is equally relevant to custom page templates that do not make use of user-generated content via the page editor.

isaackeyet proposed a solution in that ticket which introduces the idea of classifying such pages as "System Pages", which would offer a more limited set of options for how they can be changed:

Idea to solve this permanently as brought up in the UI chat July 10 2012:

  • Pages have a new, hidden meta field to indicate "System Page" or >something that better describes it. Pages are marked System Page when >WP is using it as a placeholder for a custom blog set up, or a plugin >can use it to indicate a page is used for a contact form (for >example).
  • Pages are highlighted with a meta description in the pages list, >indicating why it's there (created by? reason?)
  • Most importantly, these System Pages are grouped in the pages >filter to be excluded from the regular list, so the list may read >"All | Published | System Pages", which should be a better long term >solution for this ticket specifically (user confusion).

Attachments (1)

21665-v1.diff (4.7 KB) - added by bootsz 12 years ago.
Adds filtering for System pages to the Pages table, and adds support for classifying & storing system pages in the database via wp_options.

Download all attachments as: .zip

Change History (37)

#1 @knutsp
12 years ago

  • Cc knut@… added

+1

#2 @johnbillion
12 years ago

  • Cc johnbillion added

#3 @SergeyBiryukov
12 years ago

  • Description modified (diff)

#4 follow-ups: @scribu
12 years ago

The problem with custom page templates is that they're NOT supposed to be completely non-editable. Users should still be able to edit the slug at least, as well as the title. Also, some templates actually use the page content as well.

So, we'd need some sort of API for specifying this.

It could be another field in template's header:

<?php
/**
 * Template Name: Showcase Template
 * Description: A Page Template that showcases Sticky Posts, Asides, and Blog Posts
 * Supports: title, editor
...

Or a PHP function:

register_page_template( 'showcase.php', array( 'title', 'editor' ) );

The array would accept the same values as the 'supports' parameter from register_post_type().

Last edited 12 years ago by scribu (previous) (diff)

#5 in reply to: ↑ 4 @bootsz
12 years ago

Replying to scribu:

The problem with custom page templates is that they're NOT supposed to be completely non-editable. Users should still be able to edit the slug at least, as well as the title. Also, some templates actually use the page content as well.

So, we'd need some sort of API for specifying this.

It could be another field in template's header:

<?php
/**
 * Template Name: Showcase Template
 * Description: A Page Template that showcases Sticky Posts, Asides, and Blog Posts
 * Supports: title, editor
...

Or a PHP function:

register_page_template( 'showcase.php', array( 'title', 'editor' ) );

The array would accept the same values as the 'supports' parameter from register_post_type().

My initial idea was similar to the first option: Add another field to the template header where a developer can specify that the template is a "system page". I think your solution is better, however, because it would offer more flexibility. Some templates may need to offer more features than others, so it would be nice to be able to spell out exactly what features you want to support, much like we do with Custom Post Types.

I'm not sure which approach would be better in the long-run (template commenting VS. a PHP function), but I'd imagine going with the 1st option would be easier since it wouldn't require changing the way that custom templates are created & added.

#6 @meliko
12 years ago

  • Cc melissachoyce@… added

#7 in reply to: ↑ 4 ; follow-up: @helenyhou
12 years ago

  • Keywords ui-feedback removed

As it is at the moment, one can disable the editor for a particular page by doing remove_post_type_support( 'editor' ) on one of the add_meta_boxes actions (or earlier). One of my favorite tricks :)

Also, sometimes these are not user-specified page templates, but ones that a theme author (or plugin author) has defined using the template hierarchy instead. Cart checkout and that sort of thing come to mind. I don't think template tags would necessarily apply in all cases. Also, not sure about an API yet, since it is doable already. Would like to see the meta used and appropriate things added to the list table first and then can hash out all those details. The added "status" at the top to filter by and excluding from the regular list seem like the important bits UI-wise.

#8 in reply to: ↑ 7 ; follow-up: @bootsz
12 years ago

Replying to helenyhou:

As it is at the moment, one can disable the editor for a particular page by doing remove_post_type_support( 'editor' ) on one of the add_meta_boxes actions (or earlier). One of my favorite tricks :)

Do you have a code example you could point us to? :)

Also, sometimes these are not user-specified page templates, but ones that a theme author (or plugin author) has defined using the template hierarchy instead. Cart checkout and that sort of thing come to mind. I don't think template tags would necessarily apply in all cases.

Good point. We'd need to accommodate both custom templates as well as templates set up within the hierarchy.

Also, not sure about an API yet, since it is doable already. Would like to see the meta used and appropriate things added to the list table first and then can hash out all those details. The added "status" at the top to filter by and excluding from the regular list seem like the important bits UI-wise.

So next step: Wireframes?

#9 in reply to: ↑ 8 @helenyhou
12 years ago

Replying to bootsz:

Do you have a code example you could point us to? :)

http://snippi.com/s/y601ckg

So next step: Wireframes?

Nah, I think the UI is pretty well set for that screen already. Just needs code, and decisions.

#10 @scribu
12 years ago

"System Pages" sounds scary. How about calling them "Special Pages"?

@bootsz
12 years ago

Adds filtering for System pages to the Pages table, and adds support for classifying & storing system pages in the database via wp_options.

#11 @bootsz
12 years ago

  • Keywords has-patch added

Here's an initial patch: http://core.trac.wordpress.org/attachment/ticket/21665/21665-v1.diff

In this patch "System pages" are handled similarly to how posts are classified as "Sticky": The wp_options table stores a new option, system_pages, which contains an array of page IDs that have been labeled as System.

As of version 1, the only way to make a page a "system page" is to set it as the "page for posts" under Settings -> Reading. How we'll enable developers to classify other pages as "system" is TBD. Definitely looking for some additional input from a senior dev on that one.

Haven't yet tested on user permissions.

#12 @helenyhou
12 years ago

I think the flag would be better as a protected piece of post meta for each relevant post rather than a site option, e.g. with the key _wp_system_page or such.

#13 @bootsz
12 years ago

Replying to helenyhou:

I think the flag would be better as a protected piece of post meta for each relevant post rather than a site option, e.g. with the key _wp_system_page or such.

I had used post meta originally in the patch I posted under #17470, but when it came to actually implementing the filtering it seemed easier & less intrusive to follow the Sticky Posts protocol and go the options route.

Switching back to post meta shouldn't be an issue. Just wondering if there is a clear advantage to going that route? Would we ever have to worry about duplicate entries overriding one another?

Last edited 12 years ago by bootsz (previous) (diff)

#14 follow-up: @ryan
12 years ago

Themes/plugins can already remove UI elements from the edit page. WP already fires actions (lots) when loading the edit form. So it seems that themes already have what they need to customize the edit page for pages with given templates. We could add some convenience, but it already seems doable.

#15 in reply to: ↑ 14 @ryan
12 years ago

Replying to ryan:

Themes/plugins can already remove UI elements from the edit page. WP already fires actions (lots) when loading the edit form. So it seems that themes already have what they need to customize the edit page for pages with given templates. We could add some convenience, but it already seems doable.

Which is pretty much what scribu said.

#16 follow-up: @ryan
12 years ago

Let's just make template registration entirely programmatic and lose those headers.

register_post_template( 'foo.php', array(
     'name' => __('Foo Page'),
     'description' => __('Bringing pages full of Foo to your face'),
     'supports' => array( 'page' => array( 'title', 'editor' ) ),
) );

edit-form-advanced.php would use the capabilities from the template over the post type caps. Some care would be needed here since themes don't necessarily know what caps to use for arbitrary post types.

If we want a "Template/System Pages" filter in edit.php it could query based on _wp_page_template.

Last edited 12 years ago by ryan (previous) (diff)

#17 @ryan
12 years ago

For full CPT support, it may be easier to specify negative caps.

#18 in reply to: ↑ 16 @bootsz
12 years ago

Replying to ryan:

Let's just make template registration entirely programmatic and lose those headers.

register_post_template( 'foo.php', array(
     'name' => __('Foo Page'),
     'description' => __('Bringing pages full of Foo to your face'),
     'supports' => array( 'page' => array( 'title', 'editor' ) ),
) );

edit-form-advanced.php would use the capabilities from the template over the post type caps. Some care would be needed here since themes don't necessarily know what caps to use for arbitrary post types.

If we want a "Template/System Pages" filter in edit.php it could query based on _wp_page_template.

I like the looks of this. Aren't page templates specific to Pages though?

We also need to consider the "Page for Posts", which may require a slightly different treatment to achieve the same effect.

#19 @ryan
12 years ago

scribu reminded me that we only support page_template for the page post_type. I was momentarily deluded and thought we allowed CPTs to turn it on.

#20 follow-up: @scribu
12 years ago

"page for posts" is built on top of pages. It uses whatever template the page it's assigned to uses. So, that's two separate things right there.

We really need to figure out what the goal here is, before implementing anything.

#21 follow-up: @ryan
12 years ago

Also, this only goes into effect once a template is selected since we can't read minds. So the initial selection of the template will still be confusing. And once a template is added or changed the user could get a much different UI after saving. "All I did was set the template. Why did everything disappear?" Especially if the old template used content and the new one does not. "Where's my data? Why can't I change it?"

#22 @scribu
12 years ago

  • Keywords ux-feedback added

#23 in reply to: ↑ 20 @bootsz
12 years ago

Replying to scribu:

"page for posts" is built on top of pages. It uses whatever template the page it's assigned to uses. So, that's two separate things right there.

We really need to figure out what the goal here is, before implementing anything.

They're similar problems in that in both instances we sometimes have these "Pages" which are only really pages in the sense that they need to have a title and be able to be added to navigation menus, but aren't making use of the Page editor. Not sure if it's overly ambitious to try to tackle both via one solution, but it seems ideal.

#24 in reply to: ↑ 21 @bootsz
12 years ago

Replying to ryan:

Also, this only goes into effect once a template is selected since we can't read minds. So the initial selection of the template will still be confusing. And once a template is added or changed the user could get a much different UI after saving. "All I did was set the template. Why did everything disappear?" Especially if the old template used content and the new one does not. "Where's my data? Why can't I change it?"

That's a good point. I think the solution would involve showing some kind of message to explain why the editor isn't appearing. Which was one of the first proposed changes to "page for posts": http://core.trac.wordpress.org/attachment/ticket/17470/patch.diff

If possible, maybe even still show the editor with the page's content but have it grayed-out and not changeable, so people don't freak out and think their content is lost. And then just show a message like "The current page template does not support the page editor." or something like that.

Last edited 12 years ago by bootsz (previous) (diff)

#25 @scribu
12 years ago

This basically entails introducing a new type of object into users' brains. Just slapping a message on top doesn't cut it.

I guess when I said "goal" I meant UX. We need to figure out a good user experience: how the users interact with these objects in the admin and how it can combine with everything else, with minimal confusion.

Last edited 12 years ago by scribu (previous) (diff)

#26 @DrewAPicture
12 years ago

  • Cc xoodrew@… added

#27 @greenshady
12 years ago

  • Cc justin@… added

#28 in reply to: ↑ 4 @bootsz
12 years ago

Replying to scribu:

The problem with custom page templates is that they're NOT supposed to be completely non-editable.

I’ve been putting some more thought into this issue and keep coming back to your point here, which I think is key to properly identifying the problem. I started to wonder: why is it that we often end up with pages that are not editable? Well, here’s an example of one such reason from my own experiences:

Many sites I build use homepages that consist of 2 main components:

1) A rotating slideshow (w/ images and text).

2) A multi-column area featuring a combination of pure text, recent posts, contact forms, or any other number of features.

The challenge here is that these “sections” feature content that is modular / dynamic / repeatable / whatever you want to call it. With Pages, my only options for adding content are a single text editor and setting a Featured Image. This won’t cut it for a page like the one I’m describing. So instead, I’ll end up setting up some combination of a custom widget area(s) and/or Custom Post Types to handle the content, and then pull everything together via a custom Page template.

This works fine, but it causes confusion for users. If they’re logged in and viewing this page, they’ll click “Edit Page” expecting to be able to change the page’s contents. But instead they just see a blank text editor. They’ll need to remember that some of the content is located in a Custom Post Type, while other sections of the page are controlled via Widgets. This right here is in my opinion where the user experience is failing.

As a result, I’m wondering if this idea of “System Pages” may be too simplistic. For pages such as the one I've described, such a solution is really just a band-aid fix over a much deeper problem, which is that the idea of what constitutes a “Page” in WordPress might be too narrowly defined.

I’d argue that a proper solution would involve making Pages more flexible, so that more dynamic/repeatable content that is page-specific can be added & edited WITHIN the page editor, rather than scattered about within multiple other sections of the admin.

Could we allow widgets to also be added to a specific page, via some type of special page-specific widget areas that appear in the Page editor instead of the Widgets UI? What other types of content could we integrate into the Page editor?

So far the best solution I have found that accomplishes this is the Repeater Field for Advanced Custom Fields: http://www.advancedcustomfields.com/add-ons/repeater-field/. This to me seems like the kind of feature that could make Pages flexible enough to bring more content creation within the Page editor UI.

I realize that what I'm talking about does not address all cases, such as the “page for posts” or archive pages for Custom Post Types. Those types of pages probably do not need to accommodate anything beyond adjusting the Title & slug. Nevertheless, I think the need for more flexibility still applies.

Ultimately, we want to ensure that in all cases clicking “Edit Page” will lead to a useful & appropriate UI.

#29 @scribu
12 years ago

Now that's the kind of holistic thinking I was hoping for. :)

More thoughts:

The current incarnation of pages actually contains two concepts:

A) content pages = a standard, hierarchical custom post type

End-users are free to create arbitrary content pages, with no additional code required.

B) system pages

Each system page incorporates specific functionality and requires a custom template and possibly other custom code.

End-users can not create arbitrary system pages, because the value isn't in the content, but in the custom functionality.

*

Custom page templates fall somewhere between A) and B); it's custom code, but it can be used for multiple content pages.

#30 @scribu
12 years ago

Related: #16379

#31 @chipbennett
11 years ago

  • Cc chip@… added

#32 @DrewAPicture
11 years ago

  • Component changed from UI to Administration
  • Keywords ui-focus added; ux-feedback removed

#33 @DrewAPicture
11 years ago

  • Keywords needs-refresh added

#34 @jeremyfelt
10 years ago

  • Component changed from Administration to Posts, Post Types
  • Focuses admin added

#36 @helen
9 years ago

  • Milestone Awaiting Review deleted
  • Resolution set to wontfix
  • Status changed from new to closed

I still think about this from time to time, and I've come around to thinking we shouldn't do it. It's a nice idea given what people do with pages that don't have editable content, but I think developer education is more important than core routing around things they should be thinking about.

A lot of things can be solved via rewrite rules for pages that truly are "virtual" and content-less, or removing post type support for the editor and otherwise hiding various parts of the UI when you're editing a given page. I think that's enough. Could be a great blog post topic, though :)

Note: See TracTickets for help on using tickets.