Display warning when editing the page_for_posts page

[alexkingorg]

I recently ran into a situation where someone was very confused by the page_for_posts setting and why their page edits were not being respected. It occurred to me that this feature is not terribly well described in the UI for users that don't already understand what it does.

The attached patch will simply add a warning as an admin_notice when you are editing the page that is specified as the page_for_posts page.

I used a class of error for the admin_notice, but updated might be more appropriate.

[alexkingorg]

Add an admin_notice when editing the page_for_posts page.

[nacin]

Related, #16379 - Better UI for doing "Page on Front"

I like the idea here.

[isaackeyet]

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).

[bootsz]

This is a much-needed feature! I've found this to be a common cause of confusion among my clients. What needs to happen to get this patch added? I just tested it myself and it works as expected.

[bootsz]

​http://core.trac.wordpress.org/attachment/ticket/17470/17470.diff

OK, a disclaimer: This is my first patch ever, so please bear with me. This issue is something that I struggle with almost daily, so I couldn’t resist diving in.

As isaackeyet alluded to, this particular issue is really one instance of a larger problem, which is the current inability to distinguish between regular “content” pages, and pages that are used as placeholders for custom templates / dynamic content.

As a result, in putting together my first patch I've attempted to start looking at the big picture, and trying to set some kind of a foundation for the concept of "System Pages" as described by isaackeyet here: ​http://core.trac.wordpress.org/ticket/17470#comment:4.

The Patch:

Changes from alexking's original patch are essentially still in effect. The additional changes are as follows:

1) Setting a particular page as the "Posts Page" under Settings->Reading creates a new entry in wp_postmeta for the page's ID with the key "_system_page" and value set to "1".

2) Under the "Pages" tab, for each page displayed in the table WordPress will now check if the page has a "_system_page" meta value of 1. If it does, the "Edit" link is not displayed, allowing the using to only modify the Title and other basic attributes.

3) If the edit page happens to get accessed directly, the WYSIWYG editor is hidden (in addition to other irrelevant meta boxes).

So essentially, now instead of modifying behavior based on the value of “page_for_posts”, we have a meta key “_system_page” that can be applied not only to the page_for_posts, but also to any number of additional pages specified by a theme or plugin developer who need to create additional non-editable pages.

Next Steps:

1) UI changes to the Pages table & page editor to visually distinguish “system pages”, and possibly provide an explanation for why they behave differently.

2) Determine how developers to create additional system pages. My first thought was to extend the commenting convention on custom templates, to allow a developer to specify that a particular template should be treated as a “system page”.

My questions at this point:

• Are these changes extensive enough to warrant a separate ticket?
• Is something like this realistic to achieve for 3.5, or will it have to wait?

[SergeyBiryukov]

Related: #21665

[SergeyBiryukov]

#14314 was marked as a duplicate.

[helen]

What if we:

• Remove post type support for the editor, early enough that if for some reason a theme or plugin uses that content, they can restore the support and still have the editor. edit_form_after_title fires right before it checks for editor support, so it can happen at any point before that, realistically. We should probably keep editor support on if the content is not empty so a user can retrieve it if they need to.
• Display a message where the editor would have otherwise been if it's still turned off when we get there.

Are there perhaps other things we should hide? If I recall correctly, the page template also does not apply.

[SergeyBiryukov]

Replying to helen:

If I recall correctly, the page template also does not apply.

Yep: #15513

[helen]

17470.2.diff​ is a possible starting point that hides the editor if the content is empty and avoids the page template selector. A notice is printed at run time and existing JS moves it to the top, although I think it'd be fine displaying in place of the editor since by default the screen is pretty sparse. That can be done by adding the class inline to it. It probably makes more sense to hook that notice to the edit_form_after_editor action so somebody can remove it if they want. This is what it looks like:

I'd like to resolve this ticket one way or another in 4.2.

[helen]

17470.3.diff​ puts the notice inline via hook whether or not the content editor is enabled. Seems important to know this even if the editor is showing because the user previously had content in that page. Keeps it easy for a dev to unhook the notice or enable/disable editor support as desired.

[sc0ttkclark]

Replying to helen:

17470.3.diff​

+1 on this latest one

[helen]

In 31550:

Hide irrelevant UI and display a message when editing the page for posts.

Users are frequently confused as to why the content they've entered or the page template they've selected doesn't apply for this one page. Showing and saving items that don't do anything hurts trust.

Developers can elect to turn on the editor should they be using it for something. If the content isn't empty, the editor will show so that users still have access to their content.

props alexkingorg for the initial, long-suffering patch.
fixes #17470.

[DrewAPicture]

In 31551:

Ignore the internal-use function _wp_posts_page_notice() from parsing for the code reference.

See #17470.

[philiparthurmoore]

Hi @helen.

Replying to helen:

In 31550:

Hide irrelevant UI and display a message when editing the page for posts.

Users are frequently confused as to why the content they've entered or the page template they've selected doesn't apply for this one page. Showing and saving items that don't do anything hurts trust.

Developers can elect to turn on the editor should they be using it for something. If the content isn't empty, the editor will show so that users still have access to their content.

props alexkingorg for the initial, long-suffering patch.
fixes #17470.

This changeset has caused a UX regression, as some themes actually use the page content as introductory content for an index page (here's an ​example). Before WordPress 4.2, users were able to Edit the page that was used for posts, add in content, and have that easily displayed if the theme supported it.

Now, users have to do the following in order to add content into their posts page for themes that support it:

1. Go to Settings - Reading.
2. Remove the page as the posts page.
3. Add content into the page.
4. Re-assign the page as the posts page.
5. Now if a user has content in the page they can simply click Edit and they will be shown the content box.

Before, a user had to:

1. Click Edit.

There's no way to override this currently, looking at [31550]. Could there be a way to override this, at least by making the following code filterable:

if ( $post_ID == get_option( 'page_for_posts' ) && empty( $post->post_content ) ) {
	add_action( 'edit_form_after_title', '_wp_posts_page_notice' );
	remove_post_type_support( $post_type, 'editor' );
}

I don't see any way to add editor post type support for pages when this code in edit-form-advanced.php overrides the theme.

Also, the logic here creates the disparate UX that I mentioned above. Why not just always display the _wp_posts_page_notice, regardless of content being there or not, and have the content box always available? Seems much easier to deal with for themers who allow users to take advantage of this on the front end of their sites. Thanks.

[helen]

Replying to philiparthurmoore:

There's no way to override this currently, looking at [31550].

Per my commit message:

Developers can elect to turn on the editor should they be using it for something. If the content isn't empty, the editor will show so that users still have access to their content.

You can run add_post_type_support() again on any hook that precedes the post_type_supports( $post_type, 'editor' ) check. edit_form_top seems like a decent candidate out of the many that are there. Most, if not all, should pass the $post context. I would far rather hide an editor that typically does nothing for the front and leads users to wondering where that content is supposed to show up. Themes that do use it (and I have built them, so I am not pretending that nobody does this) typically need further explanatory text in the edit screen anyway, given that this expectation changes between themes, so a little extra code to be purposeful about this use seems perfectly reasonable to me.

[philiparthurmoore]

Thanks so much for the response, Helen. I will look into edit_form_top. I'm not sure why nothing was working for me earlier, but I trust that you have looked into this much more than I have. :) If I find this impossible I'll let you know; until then, thanks a ton for pointing me in the right direction.

[dougwollison]

Replying to philiparthurmoore:

Also, the logic here creates the disparate UX that I mentioned above. Why not just always display the _wp_posts_page_notice, regardless of content being there or not, and have the content box always available? Seems much easier to deal with for themers who allow users to take advantage of this on the front end of their sites. Thanks.

I agree, in fact once I saw the notice I decided it would be good to incorporate that on pages that would be setup as index pages for custom post types as well.

Honestly though I think this might be better as a hook on edit_form_top or some other action which would take care of adding the notice and disabling the editor if appropriate:

function _wp_maybe_disable_posts_page_editor( $post ) {
    if ( $post->ID == get_option( 'page_for_posts' ) ) {
        add_action( 'edit_form_after_title', '_wp_posts_page_notice' );
        if ( empty( $post->post_content ) ) {
            remove_post_type_support( $post->post_type, 'editor' );
        }
    }
}

This way the hook could be removed if desired rather than adding another hook that undoes the work. Minor difference but it feels more appropriate.

[helen]

Replying to dougwollison:

This way the hook could be removed if desired rather than adding another hook that undoes the work. Minor difference but it feels more appropriate.

Then removing the hook would remove both the notice and the show the editor, and you'd have to add the notice back if you still wanted it.

I really want to emphasize that hiding the editor is to avoid users wondering why content they're saving doesn't actually show up anywhere (which is the case for the majority of themes), and that the editor does show if they have content in there already so they don't lose access to it.

[dougwollison]

Replying to helen:

Then removing the hook would remove both the notice and the show the editor, and you'd have to add the notice back if you still wanted it.

True, I meant to write it as separate things, one for adding the notice (probably leaving it where it is now), and the hook to remove editor support, but for some reason didn't actually do that.

I really want to emphasize that hiding the editor is to avoid users wondering why content they're saving doesn't actually show up anywhere (which is the case for the majority of themes), and that the editor does show if they have content in there already so they don't lose access to it.

I understand and agree with the concept, I just think it should be a default hook instead of embedded into the core.

[philiparthurmoore]

For anyone else who comes across this, this following bit of code has been added to my themes and seems to do the trick.

<?php
/**
 * Static Front Page in Dashboard
 *
 * @see     function add_action
 * @see     function add_post_type_support
 * @see     function get_option
 * @see     function remove_action
 * @package Theme_Slug
 * @since   Theme Slug 1.0
 */
function always_enable_static_front_page_editor() {
	global $post_type, $post_ID;
	$post_ID = ! empty( $post_ID ) ? (string) $post_ID : '0';
	$page_for_posts = (string) get_option( 'page_for_posts' );
	if ( $page_for_posts !== $post_ID ) {
		return;
	}
	remove_action( 'edit_form_after_title', '_wp_posts_page_notice' );
	add_post_type_support( $post_type, 'editor' );
} // end function always_enable_static_front_page_editor
add_action( 'edit_form_after_title', 'always_enable_static_front_page_editor', 9 );

If there's a simpler way about this, let me know. Always open to suggestions.

[greenshady]

Replying to philiparthurmoore:

If there's a simpler way about this, let me know. Always open to suggestions.

Here's a slightly simpler version.

add_action( 'edit_form_after_title', 'my_enable_posts_page_editor', 0 );

function my_enable_posts_page_editor( $post ) {

	if ( get_option( 'page_for_posts' ) != $post->ID )
		return;

	remove_action( 'edit_form_after_title', '_wp_posts_page_notice' );
	add_post_type_support( $post->post_type, 'editor' );
}

[philiparthurmoore]

Replying to greenshady:

Replying to philiparthurmoore:

If there's a simpler way about this, let me know. Always open to suggestions.

Here's a slightly simpler version.

add_action( 'edit_form_after_title', 'my_enable_posts_page_editor', 0 );

function my_enable_posts_page_editor( $post ) {

	if ( get_option( 'page_for_posts' ) != $post->ID )
		return;

	remove_action( 'edit_form_after_title', '_wp_posts_page_notice' );
	add_post_type_support( $post->post_type, 'editor' );
}

Just saw this. Thanks so much!