[wp-trac] [WordPress Trac] #21665: Allow non-editable pages to be classified & organized as "System Pages"
WordPress Trac
wp-trac at lists.automattic.com
Mon Sep 10 15:46:32 UTC 2012
#21665: Allow non-editable pages to be classified & organized as "System Pages"
------------------------------------------------+--------------------------
Reporter: bootsz | Owner:
Type: feature request | Status: new
Priority: normal | Milestone: Awaiting
Component: UI | Review
Severity: normal | Version:
Keywords: dev-feedback has-patch ux-feedback | Resolution:
------------------------------------------------+--------------------------
Comment (by bootsz):
Replying to [comment:4 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.
--
Ticket URL: <http://core.trac.wordpress.org/ticket/21665#comment:28>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software
More information about the wp-trac
mailing list