WordPress.org

Make WordPress Core

Opened 3 years ago

Last modified 3 months ago

#16379 new task (blessed)

Better UI for doing "Page on Front"

Reported by: markjaquith Owned by:
Milestone: Future Release Priority: normal
Severity: normal Version: 3.1
Component: Posts, Post Types Keywords: needs-patch
Focuses: administration Cc:

Description

http://grab.by/grabs/132427e6c1166ed3e4d8214959b9568a.png

This is the existing "Page on Front" UI. The process is as follows:

  1. Create a "Front" Page
  2. Create a "Blog" Page
  3. Select the "Front" Page in the "Front Page" dropdown
  4. Select the "Blog" Page in the "Blog Page" dropdown.

1 and 3 make sense. If you want a page on front, then you obviously need to create a page to live there, along with its content, and then designate it. But the "Blog" page is just a dummy. It's sole purpose is to create and maintain a URL for your blog. So why not just have something like this?

Blog URL: http://example.com/ {input box}

If a page exists in the URL they type, it gets used. If not, we create one on the fly as a dummy. This seems a more natural way of doing it. You don't care about the dummy page — you just want to choose an appropriate URL for your blog.

Attachments (25)

front-page-options.png (14.3 KB) - added by mmuro 3 years ago.
Front page concept
front-page-options-lessbloat-v1.jpg (110.0 KB) - added by lessbloat 23 months ago.
Alternate UI concept
front-page-options-lessbloat-v2.png (63.0 KB) - added by lessbloat 22 months ago.
Collapsed the static options until they are selected.
16379.patch (6.1 KB) - added by SergeyBiryukov 22 months ago.
16379.2.patch (13.3 KB) - added by SergeyBiryukov 20 months ago.
16379.2.png (35.3 KB) - added by SergeyBiryukov 20 months ago.
16379.3.patch (13.3 KB) - added by SergeyBiryukov 20 months ago.
16379.4.patch (12.9 KB) - added by SergeyBiryukov 19 months ago.
16379.5.patch (13.0 KB) - added by SergeyBiryukov 19 months ago.
Refreshed after [21856]
16379.6.patch (13.0 KB) - added by SergeyBiryukov 19 months ago.
Refreshed after [21872]
16379.7.diff (13.5 KB) - added by lessbloat 19 months ago.
16379.8.patch (13.5 KB) - added by SergeyBiryukov 19 months ago.
16379.8.updated.patch (13.5 KB) - added by lessbloat 19 months ago.
16379.diff (20.5 KB) - added by nacin 19 months ago.
16379.2.diff (21.9 KB) - added by nacin 19 months ago.
16379.3.diff (21.9 KB) - added by nacin 19 months ago.
Moves post_name outside of edit-slug-box.
16379.4.diff (21.9 KB) - added by nacin 19 months ago.
Fixes the second post_status notice
16379.5.diff (544 bytes) - added by ryan 19 months ago.
Quick fix for screen notice
16379.6.diff (6.2 KB) - added by nacin 19 months ago.
16379.9.patch (534 bytes) - added by SergeyBiryukov 18 months ago.
16379.10.patch (23.7 KB) - added by lessbloat 18 months ago.
16379.11.patch (24.1 KB) - added by lessbloat 18 months ago.
16379.12.diff (24.2 KB) - added by DrewAPicture 18 months ago.
16379.12-refresh.diff (24.2 KB) - added by DrewAPicture 18 months ago.
16379.revert.patch (28.8 KB) - added by SergeyBiryukov 17 months ago.

Download all attachments as: .zip

Change History (153)

comment:1 johnbillion3 years ago

  • Cc johnbillion@… added

comment:2 garyc403 years ago

Just my guess, but I think the user has to create a page manually for blog posts not only to maintain the URL, but also to add it to the navigation menu and have support for current page highlighting.

comment:3 follow-up: markjaquith3 years ago

garyc40 — that's fine. I'm saying that we can automate the creation, not do away with the dummy page concept.

comment:4 in reply to: ↑ 3 garyc403 years ago

Replying to markjaquith:

garyc40 — that's fine. I'm saying that we can automate the creation, not do away with the dummy page concept.

I get your point now. Makes perfect sense. As soon as there's a milestone for this ticket, I can work on a patch if you don't mind.

comment:5 in reply to: ↑ description mikeschinkel3 years ago

  • Cc mikeschinkel@… added

Replying to markjaquith:

1 and 3 make sense.

Any reason why 1 and 3 shouldn't also have a streamlined process? Every time I launch a site I have to go through the same process for both front page and blog page. Why not streamline it for both; sounds like your approach would allow one that already exists to be use anyway?

comment:6 follow-up: markjaquith3 years ago

Any reason why 1 and 3 shouldn't also have a streamlined process?

Because you're not choosing a dummy page. You're choosing a real page, with real content. So you have to create the page and its content anyway. Not so with the Blog dummy page.

comment:7 in reply to: ↑ 6 mikeschinkel3 years ago

Replying to markjaquith:

Any reason why 1 and 3 shouldn't also have a streamlined process?

Because you're not choosing a dummy page. You're choosing a real page, with real content. So you have to create the page and its content anyway. Not so with the Blog dummy page.

That feels like an arbitrary distinction.

I guess the question is, how often does someone use the when the are initially setting up a site vs. how often do they use it for an existing site? My guess (which could be wrong) is that +85% of the time they are doing it upon initial setup with the actual page has not yet been created. Why not create it for them as a placeholder if its not already there, or associate with one that's already been created?

Again, it just seems arbitrary to make that distinction and in the 100% of the use-cases that I have it would be helpful if I could just go and configure front page+post list page and it would create the pages for me.

Of course either way you decide it's still trivial effort, it's just an annoyance that should be annoying IMO.

comment:8 in reply to: ↑ description markmcwilliams3 years ago

Replying to markjaquith:

1 and 3 make sense. If you want a page on front, then you obviously need to create a page to live there, along with its content, and then designate it. But the "Blog" page is just a dummy. It's sole purpose is to create and maintain a URL for your blog.

In some respects I'd disagree that 1 and 3 made sense, it all depends on the purpose of your front page yes, and how you want to display things right? If you had a custom Page Template, which didn't require any text input, you've effectively got a dummy front page here. Now I don't know how we could use the front-page.php template, I suppose I need to get my head around how it works! :)

If a page exists in the URL they type, it gets used. If not, we create one on the fly as a dummy. This seems a more natural way of doing it. You don't care about the dummy page — you just want to choose an appropriate URL for your blog.

I was thinking out loud the other day in #wordpress-dev before @nacin pointed me in the direction of this ticket (which I couldn't initially find) on possibly using the new CPT Archives we introduced in 3.1? I think it makes perfect sense, not fully sure how it could be executed, so that we can retain backwords compatibility (as @nacin also pointed out to me!) -- Anyway, thought I'd just air my thoughts!

comment:9 nacin3 years ago

Related, some kind of notice/warning on the posts page being edited: #17470.

mmuro3 years ago

Front page concept

comment:10 mmuro3 years ago

  • Cc fuzzboxer@… added

I have added a concept for what I think the front page settings need to be. While I like the new process, getting rid of the dropdown all together seems to make things more complicated than it needs to be. Instead, I'd have a checkbox next to the Posts page that, when checked, would display the new page input.

comment:12 chipbennett2 years ago

  • Cc chip@… added

lessbloat23 months ago

Alternate UI concept

comment:13 husobj22 months ago

  • Cc ben@… added

lessbloat22 months ago

Collapsed the static options until they are selected.

comment:14 follow-up: jane22 months ago

  • Keywords needs-patch 3.5-early jane-likes added

I asked Dave to make it so the dropdowns only show if static page is selected and to change "Front" to "Home" to better reflect how most people talk about their sites (per the wireframe he just uploaded). I would like to see what he mocked up replace what we have now.

The progressive menu display was supposed to be done before (#15205) but as of 3.4 it's not there.

comment:15 saracannon22 months ago

  • Cc sararcannon@… added
  • Keywords changed from needs-patch 3.5-early, jane-likes to needs-patch 3.5-early jane-likes

+1

comment:16 sabreuse22 months ago

  • Cc sabreuse@… added

comment:17 Ipstenu22 months ago

A 'posts page' meaning 'A default archive-esque page that will list your most recent posts' makes sense to me. But if I step back and look at that from a new user I would wonder 'Posts? I made posts already. What's this post 'page' mean?'

There's a gap there. Front page is pretty explanatory (I was talking to Andrea on Sunday or Friday about it) but there's no way right now to make that connection being 'posts page' and 'page that lists recent posts'

Maybe just call it 'Recent Posts Page'?

comment:18 in reply to: ↑ 14 ; follow-ups: chipbennett22 months ago

Replying to jane:

...and to change "Front" to "Home" to better reflect how most people talk about their sites

IMHO this will only lead to further confusion. It is (perhaps unfortunately) well-established in WordPress that "home" refers to the Blog Posts Index, and "front page" refers to the Site Front Page.

Yes, it's inconsistent with the terminology most people use outside of WordPress. But we are stuck with this convention. (See also: query conditionals, is_home() vs is_front_page(), etc.)

Unless we want to change the internal convention for this terminology, I think we should stick to home referring to the blog posts index, in all contexts.

comment:19 in reply to: ↑ 18 ; follow-up: mikeschinkel22 months ago

Replying to chipbennett:

It is (perhaps unfortunately) well-established in WordPress that "home" refers to the Blog Posts Index, and "front page" refers to the Site Front Page.

I would debate that it is "well-established", at least the point of clarity and understanding. I've been working with WordPress professionally for 3+ years and I still get confused by this terminology. God help someone who doesn't live-and-breath WordPress to be able to understand it as it is currently applied.

Jane's suggestion makes a lot of sense IMO as those who pay enough attention to already understand it will certainly read the articles explaining how things have changed.

comment:20 in reply to: ↑ 19 chipbennett22 months ago

Replying to mikeschinkel:

Replying to chipbennett:

It is (perhaps unfortunately) well-established in WordPress that "home" refers to the Blog Posts Index, and "front page" refers to the Site Front Page.

I would debate that it is "well-established", at least the point of clarity and understanding. I've been working with WordPress professionally for 3+ years and I still get confused by this terminology. God help someone who doesn't live-and-breath WordPress to be able to understand it as it is currently applied.

By well-established, I am referring to how the terms are used in core.

Jane's suggestion makes a lot of sense IMO as those who pay enough attention to already understand it will certainly read the articles explaining how things have changed.

And I counter that this change will only make things more confusing, especially for developers, by introducing even more conflation of the terms home and front page; primarily, conflation of home as site front page as opposed to blog posts index.

comment:21 andrea_r22 months ago

Just to toss in something I see from many new users with this setting - if the theme uses a home.php to present something other than a list of recent blog posts, the user almost always tries to set a specific page as the home page. Some going so far as to making a page called "home". (possibly this could be a reserved name?)

If the home.php has a bunch of widget areas, the user is confused that settings a static page as home overrides this. (Yes, I am aware of when to use home.php versus front-page.php, I'm just reporting user confusion.)

comment:22 meliko22 months ago

  • Cc melissachoyce@… added

comment:23 in reply to: ↑ 18 lessbloat22 months ago

Replying to chipbennett:

IMHO this will only lead to further confusion.

You're right. I could definitely see this new terminology as confusing for developers.

But what about the average user? Who uses the phrase "Front page" anymore? It's like this setting got lost in the late-nineties ;-)

If we're talking solely about what is best for the average user, I'd vote to make the swap to "home page" and for the time being let developers figure it out (with the hope that we could formalize better terminology down the line).

With that said, I'd rather not throw the baby out with the bath water on this one. If changing "front page" to "home page" is a true blocker, let's just keep it as "front page" and get the inline "Create a new page" functionality committed.

comment:24 follow-up: chexee22 months ago

I had an idea a while ago about this.

What if we added "Set as Blog Page" and "Set as Home Page" as action links on the "Pages" screen?

http://chx.mx/40343D3E0N2u2l2n0P2r/Screen%20Shot%202012-07-10%20at%2011.18.41%20AM.png

This would make "Home Page" or "Front Page" a property of a page you can set, rather than a global setting that is completely separated from Pages in the admin, despite the fact that you need to create certain pages in order to use this setting.

Pros:

  • More discoverable
  • Better mental model than current approach
  • Keeps the user in one part of the admin
  • Prevents to user from trying to set a Front Page before having the pages available
  • Seems like it would be faster.

Cons:

  • Clutters the Pages screen for a setting that will probably only be set once.
  • There are probably more, but I haven't thought of them yet

Alternative, but similar solutions:

  • Rather than having action links, add a setting on the "Edit Page" screen and the "Quick Edit" settings. Would reduce clutter, but keep the same mental concept. Would also reduce discoverability.

comment:25 in reply to: ↑ 24 Ipstenu22 months ago

What if we added "Set as Blog Page" and "Set as Home Page" as action links on the "Pages" screen?

To reduce clutter, could we make it conditional? If 'a static page' is checked, then they show up?

SergeyBiryukov22 months ago

comment:26 SergeyBiryukov22 months ago

  • Keywords has-patch added; needs-patch removed
  • Milestone changed from Awaiting Review to 3.5

16379.patch is a first pass at implementing the UI shown in front-page-options-lessbloat-v2.png.

_dropdown_pages() in options-reading.php is a simplified version of wp_dropdown_pages(). Tried to use that one first, but couldn't find a decent way to make it return the lists with different attributes if no pages are currently published (the patch handles #15208 as well).

Didn't touch "Front" vs. "Home", as that seems controversial to me too.

Replacing "Posts page" with "Recent posts page" (from comment:17) makes sense to me though.

comment:27 follow-ups: WraithKenny22 months ago

  • Cc Ken@… added

How about "Blog home page" and "Site home page" (also "Network home page"). These are clear, especially when juxtaposed.

Also, the page template and conditional tags are confusing. Those should be deprecated and is_blog_home(), is_site_home() and blog-home.php, site-home.php should be introduced.

comment:28 in reply to: ↑ 27 martythornley22 months ago

  • Cc marty@… added

Replying to WraithKenny:

How about "Blog home page" and "Site home page" (also "Network home page"). These are clear, especially when juxtaposed.

Also, the page template and conditional tags are confusing. Those should be deprecated and is_blog_home(), is_site_home() and blog-home.php, site-home.php should be introduced.

I like this idea of "types" of home pages. This could be extended to post types, sections, etc... What if is_home() was just modified to take an optional variable, so you could do is_home( 'site' ), is_home( 'blog' ), is_home( 'my_post_type' ).

is_front_page() could just stay as is and be deprecated?

The only problem with any of these, whether is_home( 'blog' ) or _is_blog_home(), or even the idea of assigning a "blog" page relates to the discussion about renaming the "Posts" menu item to "Blog", discussed here: http://core.trac.wordpress.org/ticket/20956

There are reasons why it does not make sense to just force the word "Blog" on the posts section. Some would call it news, etc... For me, that would be another reason to keep it something versatile like is_home( 'something' ), or instead of is_home( 'blog' ), you could just do is_home( 'posts' )?

comment:29 in reply to: ↑ 27 SergeyBiryukov22 months ago

Replying to WraithKenny:

Also, the page template and conditional tags are confusing. Those should be deprecated and is_blog_home(), is_site_home() and blog-home.php, site-home.php should be introduced.

Related: #10158, #18705

comment:30 mmuro22 months ago

I agree with Jane, here. I think Home Page is better terminology than Front Page because it's something very common and seen in a lot of menus all over the web.

comment:31 follow-up: saltcod22 months ago

  • Cc saltcod added

Only related to a tangent at the end here, but I've also found the front-page.php template to be unintuitive. Every time I go to make a new homepage template, I'll create a new file called page-front.php before realizing my mistake and changing it to front-page.php.

comment:32 in reply to: ↑ 31 markjaquith22 months ago

Replying to saltcod:

Only related to a tangent at the end here, but I've also found the front-page.php template to be unintuitive. Every time I go to make a new homepage template, I'll create a new file called page-front.php before realizing my mistake and changing it to front-page.php.

page-{foo}.php is the template for the "foo" page.

comment:33 WraithKenny22 months ago

We can move the relevant, but tangent, Terminology discussion here: #21237

comment:34 nacin21 months ago

  • Type changed from enhancement to task (blessed)

comment:35 follow-ups: lessbloat21 months ago

Been toying with several additional concepts for this. Here's the latest (props to tddewey for iterating on this with me):

http://davemart.in/wp-content/uploads/2012/07/static-frontpage-v3d1.png

Thoughts?

Last edited 21 months ago by lessbloat (previous) (diff)

comment:36 hd-J21 months ago

  • Cc jeremy@… added

comment:37 in reply to: ↑ 35 bootsz21 months ago

  • Cc bootsz added

Definitely liking the latest concept, lessbloat. I love how everything is spelled out in plain English, making it much easier for new users to understand what each setting does.

In general, I feel this issue of the "dummy page" is equally applicable to Custom Post Types & their archive pages (although probably less urgent). Is there a related / separate ticket for that already?

comment:38 markoheijnen20 months ago

  • Cc markoheijnen added

comment:39 in reply to: ↑ 35 bootsz20 months ago

Replying to lessbloat:

Been toying with several additional concepts for this. Here's the latest (props to tddewey for iterating on this with me):

Thoughts?

A few additional thoughts on the latest version:

1) This version omits the default radio button for "Your latest posts". I'd be in favor of leaving it in, as I think it helps newer users understand the difference between the two settings. Thoughts?

2) The post page is now set by entering a slug, rather than a page title. This definitely makes more sense, BUT if we're still going to list the page_for_posts page under Pages, then the title will matter, and trying to automatically convert the slug to a title might not be the best option. If we can get to a point where we're no longer displaying it as a "Page", however, then I think this solution works. It's just a matter of knowing how/when that will change.

comment:40 simonwheatley20 months ago

  • Cc simon@… added

comment:41 SergeyBiryukov20 months ago

16379.2.patch is an attempt to combine the UI from http://cl.ly/image/0x0W1C0C0z3v and static-frontpage-v3d1.png, as discussed in the dev chat.

Screenshots: 16379.2.png

SergeyBiryukov20 months ago

SergeyBiryukov20 months ago

comment:42 follow-ups: lessbloat20 months ago

This is shaping up nicely. Nice work SergeyBiryukov! A couple things:

  • When you initially click "Show a page instead of your latest posts", the second option should be checked by default: http://cl.ly/image/2A1e38413O47
  • Immediately clicking "Show latest posts on a separate page" after "Show a page instead of your latest posts" without saving first results in a bunch of PHP errors: http://cl.ly/image/053G2h0E2W2L as $pag_for_posts isn't set.
  • _dropdown_pages() doesn't appear to do anything with the "selected" parameter.
  • In _dropdown_pages() the "selected" equals get_option( 'page_on_front' ). Do we need to do some validation on this to make sure that the page that was previously set as get_option( 'page_on_front' ) still exists.
  • Last, we need to duplicate this functionality in the customizer's "Static Front Page" section.

comment:43 viniciusmassuchetto20 months ago

We are working in a plugin that does exactly what the ticket is proposing. Still need some shaping and a good name before a release.

SergeyBiryukov20 months ago

comment:44 in reply to: ↑ 42 SergeyBiryukov20 months ago

Replying to lessbloat:

  • Immediately clicking "Show latest posts on a separate page" after "Show a page instead of your latest posts" without saving first results in a bunch of PHP errors

Thanks, fixed in 16379.3.patch.

  • _dropdown_pages() doesn't appear to do anything with the "selected" parameter.

It's passed to Walker_PageDropdown via walk_page_dropdown_tree():
http://core.trac.wordpress.org/browser/tags/3.4.1/wp-includes/post-template.php#L1106

Working on the other points.

comment:45 follow-up: leogermani20 months ago

  • Cc leogermani added

Hi all,

I really like the work going on on this ticket. No doubt its a good improvement.

Nevertheless I would like to continue the discussion with those who think we could have an alternative for the dummy pages. I had a discussion on wp-hackers recently that ended up in a plugin to demonstrate how this could work (https://github.com/vmassuchetto/wordpress-force-front-page/) - I beleive it could be an add_theme_support thing.

Anyways, this is not the place to discuss it, and Im not sure if it should be a ticket or a thread on wp-hackers, so I decided to drop a line here because I saw I could find some people withe similar ideas,

cheers

comment:46 in reply to: ↑ 45 helenyhou20 months ago

Replying to leogermani:

Nevertheless I would like to continue the discussion with those who think we could have an alternative for the dummy pages.

That would be a separate discussion, perhaps #21665. This ticket is focused on improving/enhancing the existing UI.

comment:47 emzo19 months ago

  • Cc emzo added
  • Version changed from 3.1 to trunk

comment:48 helenyhou19 months ago

  • Version changed from trunk to 3.1

Version number indicates when the enhancement was initially suggested.

SergeyBiryukov19 months ago

comment:49 in reply to: ↑ 42 SergeyBiryukov19 months ago

16379.4.patch is the refreshed and revised patch.

Replying to lessbloat:

Fixed.

  • In _dropdown_pages() the "selected" equals get_option( 'page_on_front' ). Do we need to do some validation on this to make sure that the page that was previously set as get_option( 'page_on_front' ) still exists.

We don't currently validate that in options-reading.php. Walker_PageDropdown can handle zero 'selected' value.

There's a related block in wp_delete_post() which deletes the option when deleting the page:
http://core.trac.wordpress.org/browser/tags/3.4.2/wp-includes/post.php#L2052

Looking into customizer integration.

SergeyBiryukov19 months ago

Refreshed after [21856]

SergeyBiryukov19 months ago

Refreshed after [21872]

comment:50 scribu19 months ago

  • Keywords 3.5-early removed

lessbloat19 months ago

comment:51 follow-up: lessbloat19 months ago

Made a few minor tweaks in 16379.7.diff:

  • If you have zero pages, or only the "sample page", show the "Add new page" option by default.
  • When "Add new page" is selected, if title entered equals same title of an existing page, just use the existing page vs. creating a new page with the same title.
  • If 'page_on_front' option is currently set, select it from select#page_on_front instead of defaulting to "-- Select --".
  • Changed "New page title:" to "titled:".
  • Changed "Posts page title:" to "Page title:".

SergeyBiryukov19 months ago

comment:52 in reply to: ↑ 51 SergeyBiryukov19 months ago

Replying to lessbloat:

  • If you have zero pages, or only the "sample page", show the "Add new page" option by default.

Some more tweaks in 16379.8.patch:

  • When "Add new page" is selected, if title entered equals same title of an existing page, just use the existing page vs. creating a new page with the same title.

I did the same in 16379.patch, but then thought it might be better to just always create a new page as requested. Either way is fine for me though.

comment:53 follow-up: lessbloat19 months ago

Went through and updated/retested 16379.8.patch. Looks good. Definitely an improvement on the current setting. Here's a quick comparison of the improvement (from a new users perspective):

Old way:

1) Select "A static page" radio button
2) Click on the "Front page" drop down
3) Realize you haven't created any pages yet
4) Go to pages
5) Create a new "Home" page
6) Create a new "Blog" or "News" page
7) Go back to settings -> Reading
8) Select "A static page" radio button
9) Select "Home" from the "Front page" drop down
10) Select "Blog" from the "Posts page" drop down
11) Click "Save Changes" at the bottom of the page

New way:

1) Click the single "Enable a static front page" checkbox
2) Click "Save Changes" at the bottom of the page

Step one defaults to creating a new "Home" and "Blog" page for them (though they can change either name to whatever they'd like).

comment:54 in reply to: ↑ 53 DrewAPicture19 months ago

  • Cc xoodrew@… added

Replying to lessbloat:

Step one defaults to creating a new "Home" and "Blog" page for them (though they can change either name to whatever they'd like).

I really like the new workflow, it's much more streamlined. What do you think about adding an "Edit your front page" link to the resulting 'Options Saved' message?

comment:55 follow-up: ryan19 months ago

Use get_current_screen() instead of the $current_screen global. There is no need to esc_html( stripslashes() ) the data going to wp_insert/update_post(). They expect slashed data and will handle sanitization.

Last edited 19 months ago by ryan (previous) (diff)

comment:56 nacin19 months ago

In [22122]:

Remove unnecessary .tog class from checkboxes on the Permalink Settings screen. Designed originally for the admin color scheme choice (see [7259]), it causes vertical misalignment and lack of spacing between the checkbox and corresponding label. see #16379.

comment:57 in reply to: ↑ 55 ; follow-up: SergeyBiryukov19 months ago

Replying to ryan:

There is no need to esc_html( stripslashes() ) the data going to wp_insert/update_post().

That was copied from get_default_post_to_edit():
http://core.trac.wordpress.org/browser/tags/3.4.2/wp-admin/includes/post.php#L408

Last edited 19 months ago by SergeyBiryukov (previous) (diff)

nacin19 months ago

comment:58 in reply to: ↑ 57 ; follow-up: ryan19 months ago

Replying to SergeyBiryukov:

Replying to ryan:

There is no need to esc_html( stripslashes() ) the data going to wp_insert/update_post().

That was copied from get_default_post_to_edit():
http://core.trac.wordpress.org/browser/tags/3.4.2/wp-admin/includes/post.php#L408

But that's for prepping a post for display in the editor. _create_pages_for_reading_settings() is going straight to wp_update/insert_post().

comment:59 ryan19 months ago

And the update case should add_magic_quotes() on $page.

Last edited 19 months ago by ryan (previous) (diff)

comment:60 in reply to: ↑ 58 SergeyBiryukov19 months ago

Replying to ryan:

But that's for prepping a post for display in the editor.

Right, thanks.

comment:61 nacin19 months ago

Please test/review 16379.2.diff. Note the various @todo's that explore further edge cases than I've tried to address here.

nacin19 months ago

comment:62 SergeyBiryukov19 months ago

Editing the blog page slug results in notices on saving:

Notice: Undefined index: post_name in wp-admin/includes/post.php on line 1400
Notice: Trying to get property of non-object in wp-admin/includes/post.php on line 1402

#post_name disappears when editing the slug, probably because it's now placed in #edit-slug-box, which editPermalink() overwrites.

nacin19 months ago

Moves post_name outside of edit-slug-box.

comment:63 nacin19 months ago

Fixed in 3.diff.

comment:64 SergeyBiryukov19 months ago

Still see the second notice. $page is an array there, not an object.

nacin19 months ago

Fixes the second post_status notice

comment:65 ryan19 months ago

In [22127]:

Better UI for doing "Page on Front".

Props SergeyBiryukov, lessbloat, nacin.

see #16379

comment:66 ryan19 months ago

PHP Notice:  Trying to get property of non-object in /.../wp-admin/includes/post.php on line 1065

I think this is triggered by autosave.

ryan19 months ago

Quick fix for screen notice

comment:67 nacin19 months ago

Yeah, so, autosave.js also makes an XHR call to sample-permalink. I didn't catch that. The original patches from Sergey and lessbloat at least avoided the notice by confirming we had a current screen, so let's do that.

comment:68 nacin19 months ago

In [22129]:

Pass the screen context directly to get_sample_permalink_html(). see #16379.

comment:69 bradparbs19 months ago

  • Cc brad@… added

comment:70 nacin19 months ago

#22131, [22135] — show_on_front was not being set correctly to 'posts' when the checkbox was not checked.

nacin19 months ago

comment:71 nacin19 months ago

In [22136]:

Move the static front page saving routine to a single sanitize_option() callback for show_on_front. page_on_front and page_for_posts are now manually set by this callback, and not separately by options.php. see #16379.

comment:72 nacin19 months ago

[22136] was necessary because it got to a point where you couldn't set page_for_posts or page_on_front from this routine without options.php overwriting them. If you moved them to be updated first, then you wouldn't be able to avoid updating them at all, leaving the current value.

It also makes sense and is ultimately less of a hack.

comment:73 follow-up: nacin19 months ago

Remaining items:

  • The @todo in options-reading.php for determining whether we use a new or existing blog page.
  • The @todo on _show_on_front_reading_settings() which essentially means test the heck out of this.
  • The @todo in _show_on_front_reading_settings() for creating a 'context'. Might be helpful for the first @todo as well...

comment:74 in reply to: ↑ 73 lessbloat19 months ago

For page_on_front, if the user selects "Add new page", and the title they enter is the same as a title of a page that already exists we should just add another page with the same title.

My rationale:

First off, doing it this way shouldn't affect new users (unless they choose "Sample Page" as their title which is unlikely).

But let's say a user with 20 pages decides to add a static front page:

  • They go to settings -> reading
  • Click "Show a page instead of your latest posts"
  • The drop down at this point says "-- Select --"
  • Once they expand the drop down, they'd see all of their pages, so you'd think if they wanted to select an existing page, they'd just go ahead and select it.
  • But let's say they do select "-- Add new page --" and they enter the title of "Home" (when a page with the title of "Home" already exists), upon saving, the drop down would go ahead and auto-select the new "Home" page for them.

The only confusing part might be when they go to edit their static front page titled "Home", as there will be 2 in the listing, but they kind of brought it on themselves :-).

Thoughts?

Last edited 19 months ago by lessbloat (previous) (diff)

comment:75 follow-up: lessbloat19 months ago

For page_for_posts, I think we need to use the existing blog page if one exists.

Rationale:

  • First, doing this shouldn't pose a problem for new users.
  • For existing users with pages, there would be no way to select an existing page otherwise.

Thoughts?

comment:76 in reply to: ↑ 75 ; follow-up: nacin19 months ago

Replying to lessbloat:

For page_for_posts, I think we need to use the existing blog page if one exists.

Rationale:

  • First, doing this shouldn't pose a problem for new users.
  • For existing users with pages, there would be no way to select an existing page otherwise.

Thoughts?

So, that makes sense. But the @todo brings up a few other questions:

  • What if the existing page we find isn't published? Even if the user *can* publish pages (and they might not be able to), we probably shouldn't publish a non-published item. (3.4 only allows published pages to be selected.) At that point, we might need to settle for blog-2. We *could* show a conflict note if we detect one.
  • What if the existing page can't be edited by the user? That means they can't change the title or slug. If for some reason, the user can't *create* pages, I've already coded it so a dropdown shows of existing pages. We might need to do the same for when the user can't edit pages either.

comment:77 DrewAPicture19 months ago

Maybe I'm missing the logic here, but why not just supply the dropdown for each of the two options from the very start? If they want to create a new page that holds their latest posts, why can't they just select --Add New Page-- same as the first option? If you can't create new pages, hide the "add" option, if you can't manage options, you wouldn't be on the page in the first place.

comment:78 follow-up: DrewAPicture19 months ago

This just seems so much more straightforward:

Page on front:

  • Choose an existing page as "Home" or --Add New Page-- (with the permalink editor)

Latest Posts page

  • Choose an existing page or --Add New Page-- (with the permalink editor)

comment:79 in reply to: ↑ 78 ; follow-up: lessbloat19 months ago

Replying to DrewAPicture:

This just seems so much more straightforward:

To clarify, is this what you're proposing:

http://f.cl.ly/items/2l050b2F1D3y0y0C3p0Z/page-on-front-proposal.jpg

comment:80 lessbloat19 months ago

Also of note: The customizer still shows the older "page on front" setting. This will need to be brought in line with the current changes.

comment:81 in reply to: ↑ 76 lessbloat19 months ago

Replying to nacin:

the @todo brings up a few other questions:

  • What if the existing page we find isn't published? Even if the user *can* publish pages (and they might not be able to), we probably shouldn't publish a non-published item. (3.4 only allows published pages to be selected.) At that point, we might need to settle for blog-2. We *could* show a conflict note if we detect one.

Right, I don't think we should publish an existing non-published page without them knowing. My gut says that throwing an error would be the best approach. Something along the lines of "You'll need to publish your "blog" page before you can use it for your latest posts page.". Mostly because personally I'd never want my blog directory to be blog-2.

  • What if the existing page can't be edited by the user? That means they can't change the title or slug. If for some reason, the user can't *create* pages, I've already coded it so a dropdown shows of existing pages. We might need to do the same for when the user can't edit pages either.

Seems odd to me that a user could manage options, but not have access to edit pages. Regardless, should a user have access to settings, and not have access to edit pages, I'd just treat it the same as we're treating users who can't create pages (just don't show the "Add new page" drop down option). It seems like such an edge case, that I'd hate to see us add any more code than that to handle it.

Version 0, edited 19 months ago by lessbloat (next)

comment:82 in reply to: ↑ 79 DrewAPicture19 months ago

Replying to lessbloat:

Replying to DrewAPicture:

This just seems so much more straightforward:

To clarify, is this what you're proposing:

Basically, yes, but a better UI (closer to what we have currently).

I'm proposing something more like this:

http://f.cl.ly/items/1p0r0s3E0p1K0L0t3X1A/page-on-front-w-choices.png

comment:83 lessbloat19 months ago

One thing I just noticed, you can leave the page title blank, and it will successfully save (and add a blank selected line in the drop down). Not sure if that is intentional.

comment:84 Latz18 months ago

  • Cc wp_trac@… added
  • Keywords needs-patch added; has-patch removed
  • Severity changed from normal to critical

Current state does not actually work. Szenario:

  • Complete new WP installation
  • Settings >> Reading
  • Select "Show a page instead of your latest posts" checkbox
  • WP tells me: "Add new page titled: Home"
  • Yes, I want that page to be created so I click "Save changes".
  • WP show me an error box: "You must select a page to set a static front page."
  • Not exactly what the user expects. Page isn't created, neither.
  • So I still have to create the page manually.

Szenario 2:
Now I've created the page "Home" manually and want the posts on the page "Blog". So I select the "Show latest posts on a separate page" checkbox and click "Save settings". Surprisingly there is no dropdown menu for the page selection.

-> This time it seems to work, the page "Blog" is created. Did not expect that because the UI didn't tell me that the page is created automatically (in contrast to the Home page).

Weird.

comment:85 JerrySarcastic18 months ago

  • Cc fittingsites@… added

comment:86 mmuro18 months ago

  • Cc fuzzboxer@… removed

comment:87 webord18 months ago

  • Cc bordoni.dev@… added

comment:88 MikeHansenMe18 months ago

  • Cc mdhansen@… added

I see the same as Latz. I also found a few other quirks noted below.

  1. In customizer you can set the front page and posts page to the same page without error or warning.
  1. After doing so return to settings->reading and notice it has the error, so I change the posts page to Blog and save.
  1. Notice it renamed both the front page and posts page to Blog.

This seems far more difficult and buggy that the previous UI.

Last edited 18 months ago by MikeHansenMe (previous) (diff)

SergeyBiryukov18 months ago

comment:89 SergeyBiryukov18 months ago

16379.9.patch fixes the issue outlined in comment:84 (scenario 1).

comment:90 MikeHansenMe18 months ago

Confirmed patch 16379.9.patch corrects the problem from comment 84.

You can select "Home" as the front page and also enter "Home" as the posts page without error on the readings page.

comment:91 lessbloat18 months ago

I floated the idea of making some additional tweaks in UI IRC channel:

http://f.cl.ly/items/2n00281s1w3w1W3U4040/page-on-front.jpg

It's just a proposal (and I know it's late in the game to be throwing out proposals like this), but I feel like using auto-complete instead of a drop down + title field combo would offer a better experience.

Thoughts?

comment:92 JerrySarcastic18 months ago

I agree it simplifies the experience considerably.

Question: Will new users (I mean the newest of the new) understand what is happening without a little explanation text? It might be a little *too* streamlined for those users. How about a brief prompt above the text boxes, like:

"Type the name of the page you want to use. If you haven't created it yet, just type in the name you want to use, and we'll create it for you."

Otherwise +1

Last edited 18 months ago by JerrySarcastic (previous) (diff)

comment:93 wonderboymusic18 months ago

  • Keywords has-patch needs-refresh added; needs-patch removed

lessbloat18 months ago

comment:94 follow-up: lessbloat18 months ago

I spent some time over the weekend working on this.

I just played around with things until I felt better about the implementation. 16379.10.patch is a bit of a departure from what we've got in trunk now. It actually brings us much closer to where we were in 3.4. Essentially, I've just replaced the "front page" and "posts page" drop downs in 3.4 with auto-complete text fields, and updated the copy a bit:

http://f.cl.ly/items/2f1N3c230p0u3x451I0D/page-on-front.jpg

I also added a message to the page used for "page_for_post", and removed the editor there (since it's always replaced by the latest posts loop):

http://f.cl.ly/items/1x0X190s1i0E3k2l2Z0R/edit_page_for_post.jpg

Please take it for a spin if you have a sec, and let me know what you think.

Happy to make any further improvements to this patch if we are happy with this direction.

comment:95 follow-up: husobj18 months ago

I have several sites where I have used the editable area on this page to provide content that can be displayed at the top of the post archive template.

Should that functionality be removed? I could envisage that other users may have also done similar things.

If so then I would like it to be easily hook-able to add back in the editor and potentially remove the message at the top.

comment:96 in reply to: ↑ 95 lessbloat18 months ago

Replying to husobj:

I have several sites where I have used the editable area on this page to provide content that can be displayed at the top of the post archive template.

I hadn't considered that. To be honest, I could easily be convinced to remove all tweaks to that page (leave it the way it is in 3.4). Alternatively, we could leave the editor visible by default, and still show the message - calling the message from a hook, so it could be turned off? Do you think having the message there is helpful?

comment:97 in reply to: ↑ 94 chipbennett18 months ago

Replying to lessbloat:

I also added a message to the page used for "page_for_post", and removed the editor there (since it's always replaced by the latest posts loop):

I don't think that this is a valid assumption. The Loop may be replaced, but $post->post_content itself can still be output directly. (And I don't think the use case in which a Theme does so is trivial, since it is a simple way to allow for user customization of the Front Page and the Blog Posts Index.)

comment:98 JerrySarcastic18 months ago

I think the message is helpful, regardless of whether the the post editor remains or not. I think it's a great reminder for new users who don't understand (or possibly just forget) that this is not a "normal" page anymore.

comment:99 follow-up: husobj18 months ago

I would vote for leaving the page as 3.4 with editor, but having a message which could be removed via a hook if required (or perhaps filtered so you could change the message - if message is blank, don't show)?

comment:100 in reply to: ↑ 99 DrewAPicture18 months ago

Replying to husobj:

I would vote for leaving the page as 3.4 with editor, but having a message which could be removed via a hook if required (or perhaps filtered so you could change the message - if message is blank, don't show)?

I like this approach as it sort of eases people into the right way of thinking about page on front. And +1 for a hook to filter to the message.

lessbloat18 months ago

comment:101 lessbloat18 months ago

Added a hook for the page_for_post message, and restored the editor in 16379.11.patch.

I also tweaked the message to read, "This page is set to display your latest posts. As a result, the main content for this page (as seen in the editor below) will not be displayed. Visit your reading settings to change the 'front page displays' option."

Copy suggestions welcome. :-)

Last edited 18 months ago by lessbloat (previous) (diff)

DrewAPicture18 months ago

comment:102 DrewAPicture18 months ago

16379.12.diff fixes a couple of notices on options-reading, adds some spacing on the sprintf's and switches single for double quoting in the edit-form-advanced message.

We should also maybe look at an informative message on the page set as static front page. It doesn't have the same caveats that latest posts page does but it still might help reinforce what's going on.

Edit: Just as an addition, I noticed that when I updated the page earmarked as 'latest posts', the updated message showed at the top then dropped below our new message, almost like they were jockeying for position.

Last edited 18 months ago by DrewAPicture (previous) (diff)

comment:104 Latz18 months ago

I think the most important things we should keep in mind are:

1.) inexperienced users should be able to use a static page without the need to ask anybody else. I can't count the times I answered a question on how to change the front page to a static page.

2.) it should be a single step process, not like in 3.4 where you have to realize that you have to create a page first before you can use it as the front page AND to create an additional page to be used for the posts. This procedure overstrains many users.

comment:105 follow-up: ocean9017 months ago

  • Keywords punt added; jane-likes removed

11 days without any reaction; the patch needs another refresh (options_reading_add_js should be an own JS file). If it's still planned for 3.5 we should get this into core before RC.

But it seems like this needs some more discussion and also work to include it into the customizer. What about a revert of [22127] and a retry in 3.6?

comment:106 in reply to: ↑ 105 DrewAPicture17 months ago

Replying to ocean90:

But it seems like this needs some more discussion and also work to include it into the customizer. What about a revert of [22127] and a retry in 3.6?

Seems to me this is the sanest approach, it doesn't feel like we quite have it.

+1 for revert + punting it to 3.6.

comment:107 nacin17 months ago

  • Keywords needs-patch revert added; has-patch needs-refresh removed
  • Priority changed from normal to high
  • Severity changed from critical to normal

We tried an intuitive new thing here and had it done early. It ended up not working well. That's not what we expected, but it's okay. We can try again. The autocomplete UI shows good progress. It's just too late to run with it now. ocean90 is right. Even two weeks ago, we were way too late to pivot here.

I see the need to revert [22127] [22129] [22135] [22136] to accomplish this.

comment:108 follow-up: SergeyBiryukov17 months ago

16379.revert.patch reverts the mentioned changesets.

comment:109 nacin17 months ago

In 22653:

Revert page on front changes. Reverts [22127] [22129] [22135] [22136]. see #16379.

comment:110 in reply to: ↑ 108 ; follow-up: nacin17 months ago

Replying to SergeyBiryukov:

16379.revert.patch reverts the mentioned changesets.

I did a straight revert using svn merge -c-REV. Anything else here?

I also added a light gray color for select[disabled], as putting a color on select itself overrides the browser style.

comment:111 in reply to: ↑ 110 SergeyBiryukov17 months ago

Replying to nacin:

I did a straight revert using svn merge -c-REV. Anything else here?

Nope, [22653] seems enough.

comment:112 nacin17 months ago

#22489 was marked as a duplicate.

comment:113 nacin17 months ago

  • Keywords revert punt removed
  • Milestone changed from 3.5 to Future Release
  • Priority changed from high to normal

I do this with a heavy heart.

comment:114 F J Kaiser17 months ago

After trying to understand the current behavior (what is it supposed to do) for a pretty long time, I was (gladly) pointed at this ticket.

Here're my 0.2 cents:

If one selects (in the current UI) "A static page" and selects nothing from the drop-downs, then WP automatically resets it to "Your latest posts" without any further notice why this happened. When I got a home.php and a front-page.php file in my theme, then I'd expect WP to use them by default, not only if I've created and selected a page for it. This simply isn't needed in every case (front page with just a title and a searchform for e.g.), so why force it? Or at least tell - in some admin notice - that there has to be a real site instead of just moving to a setting the user never made by himself.

Last edited 17 months ago by F J Kaiser (previous) (diff)

comment:115 navjotjsingh17 months ago

  • Cc navjotjsingh@… added

comment:116 Latz16 months ago

3.5 is out, time to re-animate the discussion.

I would like to bring up a new idea for the UI element:

http://jqueryui.com/resources/demos/autocomplete/combobox.html

The user can select a page from the drop down list, can enter some characters to narrow the selection down and can create a new page. Something for everybody.

comment:117 johnbillion16 months ago

  • Cc johnbillion@… removed

comment:118 pbearne15 months ago

  • Cc pbearne@… added

Hi Guys

I have been working on getting custom page types into the available pages for the homepage in this ticket #19958

It seem that any UI change could do with this change and maybe a way to display the page type that been selected.

Paul

Last edited 15 months ago by SergeyBiryukov (previous) (diff)

comment:119 follow-up: helen15 months ago

We need to make the UI simpler, not more complex with more choices. I would imagine that CPT support for the homepage would be a filter for developers, not a default behavior. We can see what turning on such an option would do to the UI if it happens, but I don't think we need to accommodate it until then.

comment:120 in reply to: ↑ 119 ; follow-up: F J Kaiser15 months ago

Replying to helen:

We need to make the UI simpler, not more complex with more choices.

Have seen my reply above? I already tried to simplify it automating most of the choices depending on what is present in the Theme.

If one selects (in the current UI) "A static page" and selects nothing from the drop-downs, then WP automatically resets it to "Your latest posts" without any further notice why this happened. When I got a home.php and a front-page.php file in my theme, then I'd expect WP to use them by default, not only if I've created and selected a page for it. This simply isn't needed in every case (front page with just a title and a searchform for e.g.), so why force it? Or at least tell - in some admin notice - that there has to be a real site instead of just moving to a setting the user never made by himself.

comment:121 in reply to: ↑ 120 helen15 months ago

Replying to F J Kaiser:

Have seen my reply above?

Yes. I was replying to the comment directly before mine about CPT support.

comment:122 jleedy14 months ago

  • Cc joseph@… added

comment:123 pauldewouters14 months ago

  • Cc pauldewouters@… added

comment:124 jazbek13 months ago

  • Cc j.yzbek@… added

comment:125 pauldewouters6 months ago

  • Cc pauldewouters@… removed

comment:126 atimmer6 months ago

  • Cc atimmermans@… added

comment:127 Latz4 months ago

Are people still interested in this ticket or have we moved on and keep the UI as it is?

comment:128 nacin3 months ago

  • Component changed from Administration to Posts, Post Types
  • Focuses administration added
Note: See TracTickets for help on using tickets.