#16379 closed task (blessed) (wontfix)
Better UI for doing "Page on Front"
Reported by: | markjaquith | Owned by: | |
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | normal | Version: | 3.1 |
Component: | Posts, Post Types | Keywords: | close |
Focuses: | administration | Cc: |
Description
This is the existing "Page on Front" UI. The process is as follows:
- Create a "Front" Page
- Create a "Blog" Page
- Select the "Front" Page in the "Front Page" dropdown
- 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 (29)
Change History (182)
#3
follow-up:
↓ 4
@
14 years ago
garyc40 — that's fine. I'm saying that we can automate the creation, not do away with the dummy page concept.
#4
in reply to:
↑ 3
@
14 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.
#5
in reply to:
↑ description
@
14 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?
#6
follow-up:
↓ 7
@
14 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.
#7
in reply to:
↑ 6
@
14 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.
#8
in reply to:
↑ description
@
14 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!
#10
@
13 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.
#14
follow-up:
↓ 18
@
12 years 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.
#15
@
12 years ago
- Cc sararcannon@… added
- Keywords changed from needs-patch 3.5-early, jane-likes to needs-patch 3.5-early jane-likes
+1
#17
@
12 years 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'?
#18
in reply to:
↑ 14
;
follow-ups:
↓ 19
↓ 23
@
12 years 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.
#19
in reply to:
↑ 18
;
follow-up:
↓ 20
@
12 years 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.
#20
in reply to:
↑ 19
@
12 years 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.
#21
@
12 years 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.)
#23
in reply to:
↑ 18
@
12 years 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.
#24
follow-up:
↓ 25
@
12 years 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.
#25
in reply to:
↑ 24
@
12 years 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?
#26
@
12 years 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.
#27
follow-ups:
↓ 28
↓ 29
@
12 years 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.
#28
in reply to:
↑ 27
@
12 years 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' )?
#29
in reply to:
↑ 27
@
12 years 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.
#30
@
12 years 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.
#31
follow-up:
↓ 32
@
12 years 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.
#32
in reply to:
↑ 31
@
12 years 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.
#35
follow-ups:
↓ 37
↓ 39
@
12 years ago
Been toying with several additional concepts for this. Here's the latest (props to tddewey for iterating on this with me):
Thoughts?
#37
in reply to:
↑ 35
@
12 years 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?
#39
in reply to:
↑ 35
@
12 years 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.
#41
@
12 years 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
#42
follow-ups:
↓ 44
↓ 49
@
12 years 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.
#43
@
12 years 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.
#44
in reply to:
↑ 42
@
12 years 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.
#45
follow-up:
↓ 46
@
12 years 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
#46
in reply to:
↑ 45
@
12 years 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.
#48
@
12 years ago
- Version changed from trunk to 3.1
Version number indicates when the enhancement was initially suggested.
#49
in reply to:
↑ 42
@
12 years ago
16379.4.patch is the refreshed and revised patch.
Replying to lessbloat:
- 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
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.
#51
follow-up:
↓ 52
@
12 years 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:".
#52
in reply to:
↑ 51
@
12 years 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:
- Use
selected()
function. - Only select "Add new page" if no other page is selected.
__( 'sample-page' )
is a translatable string:
http://core.trac.wordpress.org/browser/tags/3.4.2/wp-admin/includes/upgrade.php#L263- Sanitize
$_POST['page_on_front_title']
before searching for an existing page.
- 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.
#53
follow-up:
↓ 54
@
12 years 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).
#54
in reply to:
↑ 53
@
12 years 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?
#55
follow-up:
↓ 57
@
12 years 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.
#57
in reply to:
↑ 55
;
follow-up:
↓ 58
@
12 years 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
#58
in reply to:
↑ 57
;
follow-up:
↓ 60
@
12 years 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().
#61
@
12 years ago
Please test/review 16379.2.diff. Note the various @todo's that explore further edge cases than I've tried to address here.
#62
@
12 years 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.
#66
@
12 years 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.
#67
@
12 years 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.
#72
@
12 years 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.
#73
follow-up:
↓ 74
@
12 years 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...
#74
in reply to:
↑ 73
@
12 years 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?
#75
follow-up:
↓ 76
@
12 years 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?
#76
in reply to:
↑ 75
;
follow-up:
↓ 81
@
12 years 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.
#77
@
12 years 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.
#78
follow-up:
↓ 79
@
12 years 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)
#79
in reply to:
↑ 78
;
follow-up:
↓ 82
@
12 years ago
Replying to DrewAPicture:
This just seems so much more straightforward:
To clarify, is this what you're proposing:
#80
@
12 years 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.
#81
in reply to:
↑ 76
@
12 years 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 existing "blog" page before you can use it for latest posts.". 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.
#82
in reply to:
↑ 79
@
12 years 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:
#83
@
12 years 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.
#84
@
12 years 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.
#88
@
12 years ago
- Cc mdhansen@… added
I see the same as Latz. I also found a few other quirks noted below.
- In customizer you can set the front page and posts page to the same page without error or warning.
- After doing so return to settings->reading and notice it has the error, so I change the posts page to Blog and save.
- Notice it renamed both the front page and posts page to Blog.
This seems far more difficult and buggy that the previous UI.
#89
@
12 years ago
16379.9.patch fixes the issue outlined in comment:84 (scenario 1).
#90
@
12 years 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.
#91
@
12 years ago
I floated the idea of making some additional tweaks in UI IRC channel:
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?
#92
@
12 years 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
#94
follow-up:
↓ 97
@
12 years 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:
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):
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.
#95
follow-up:
↓ 96
@
12 years 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.
#96
in reply to:
↑ 95
@
12 years 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?
#97
in reply to:
↑ 94
@
12 years 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.)
#98
@
12 years 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.
#99
follow-up:
↓ 100
@
12 years 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)?
#100
in reply to:
↑ 99
@
12 years 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.
#101
@
12 years 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. :-)
#102
@
12 years 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.
#104
@
12 years 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.
#105
follow-up:
↓ 106
@
12 years 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?
#107
@
12 years 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.
#110
in reply to:
↑ 108
;
follow-up:
↓ 111
@
12 years 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.
#113
@
12 years 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.
#114
@
12 years 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.
#116
@
12 years 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.
#118
@
12 years 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
#119
follow-up:
↓ 120
@
12 years 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.
#120
in reply to:
↑ 119
;
follow-up:
↓ 121
@
12 years 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.
#121
in reply to:
↑ 120
@
12 years ago
Replying to F J Kaiser:
Have seen my reply above?
Yes. I was replying to the comment directly before mine about CPT support.
#127
@
11 years ago
Are people still interested in this ticket or have we moved on and keep the UI as it is?
#128
@
11 years ago
- Component changed from Administration to Posts, Post Types
- Focuses administration added
#129
@
10 years ago
Reviving to mention this great new UI proposal from @lessbloat: http://davemart.in/2014/10/27/wcsf-contributor-day-idea/
#130
@
10 years ago
@melchoyce @lessbloat i think that's a great idea, but i'd wager that a majority of the time, people who are using a static page on front also need to select a custom template for it. they will still have to go to the page listing, and edit the new page to select the custom home page template.
this doesn't feel like it'd save a ton of time without removing that step as well.
#131
@
10 years ago
people who are using a static page on front also need to select a custom template for it
That's why there's a "Edit $page" link right there. :)
this doesn't feel like it'd save a ton of time without removing that step as well.
I feel there are two problems the proposal above addresses:
- confusion in how to do it
- ease of use
Where "confusion" in my experience is the biggest one there. I've yet to run a single user test with someone that doesn't get confused by that small UI.
Note also that it makes the "blog" page implicit, transforming it from a needed page to a string you just type (and _can_ have an associated page to keep backward compatibility, or not).
Of course, I read this improvement as incremental. Personally I'd remove that piece of UI entirely from there and move it under the Pages administration, where it belongs logically. But that would mean more work, and might confuse some people that built an habit. So I'd start with this one first. :)
#132
@
10 years ago
In the last four years here have been many opinions on how to make the functionality of selecting a static front page simpler and more intuitive. IMO most of them make it for the new and average user even harder to understand what to do.
Maybe we should remember the WordPress mantra "Decisions, not Options." I would assume that the vast majority of users (if not every user) call their recent posts page "blog". Why not define "blog" as the default name for this page if a static front page is selected? This would simplify the UI a bit and free the user from understanding how to create a blog page, which seems to be the main problem.
Of course there will be some users complaining that they want to have a different name for the recent posts page but for this few users we could add a filter. If you want to change the name you should be able to do an add_filter() (and there will be various plugins within seconds).
#133
@
10 years ago
Well... That's exactly what the proposal above does: by default you see it suggests "/blog" as the default name, and they can edit it from there too. We can't take it away otherwise people will start wondering "where can I see my blog", so by showing where, we make it editable too. Win-win. :)
So: if you just switch the home page, you select it in the dropdown and automatically you get the blog at "/blog", and it tells you so. :)
This ticket was mentioned in Slack in #core-flow by ipstenu. View the logs.
10 years ago
This ticket was mentioned in Slack in #design by helen. View the logs.
9 years ago
#136
follow-up:
↓ 139
@
8 years ago
Just got here from the WP 4.6 wishlist post. +1 for a better front page settings UI.
WordPress is not a blog software anymore and I think most users are using a static page as front page rather than blog posts.
My idea would therefore be to remove the radio buttons completely and just include two select fields for the Front page and Posts page: https://cloudup.com/c78c-0U_T4k
For new installs WordPress could automatically create a static Home Page and a dummy Blog page (instead of the Sample Page) and set these two pages as defaults.
Bonus effect: A static home page instead of the blog posts for new installations would also reflect that WordPress is a fully fledged CMS now, not just a blog software.
If users want to display the latest posts on the homepage they can simply choose the blog page in the Front page setting.
#137
follow-ups:
↓ 140
↓ 143
@
8 years ago
I personally think that the "blog" page should be virtual, not a real page: it's exactly the same thing as the archives page, just that instead of being filtered by month, it's the latest posts. The option there would be the ability to change its name.
Doing that, will avoid having a "page" hanging around that is really used for the URL only, and confuses users by showing up in the page hierarchy with actual content apparently editable.
This will reduce also the need of such a double dropdown, since the only thing one will have to select is "what do you want to show on the homepage?", a single list, a single check, much much more intuitive. :)
#138
follow-up:
↓ 141
@
8 years ago
I also think that the dummy for the blog page is not perfect, but it is the way the system currently works. Not sure if that can be changed easily.
I agree with you that a single select field for the front page would be much simplier.
The setting for the posts page could be removed if the concept of a virtual page is possible. I think there should be a extra setting on the Permalink screen then which allows to enter the slug of the blog archive. It can default to /blog, similiar to the category slug which defaults to /category.
#139
in reply to:
↑ 136
@
8 years ago
Replying to ThemeZee:
For new installs WordPress could automatically create a static Home Page and a dummy Blog page (instead of the Sample Page) and set these two pages as defaults.
+1
#140
in reply to:
↑ 137
@
8 years ago
Replying to folletto:
I personally think that the "blog" page should be virtual, not a real page: it's exactly the same thing as the archives page, just that instead of being filtered by month, it's the latest posts. The option there would be the ability to change its name.
Doing that, will avoid having a "page" hanging around that is really used for the URL only, and confuses users by showing up in the page hierarchy with actual content apparently editable.
This will reduce also the need of such a double dropdown, since the only thing one will have to select is "what do you want to show on the homepage?", a single list, a single check, much much more intuitive. :)
Very much agree with this.
#141
in reply to:
↑ 138
@
8 years ago
Replying to ThemeZee:
I also think that the dummy for the blog page is not perfect, but it is the way the system currently works. Not sure if that can be changed easily.
Being intimately familiar with URL routing in WordPress, I do not see any reason why this could not be done. If a new query var name is introduced and recognized it would be very possible.
#142
@
8 years ago
Since there seems to be interest, I took some time, did a mockup, a quick review, and iterated. I just attached this second iteration here.
The idea here is to avoid double options and dropdowns with a full list of pages. The choice is one: either list, or one of the pages. So we can just visualize them, and show the matching URLs.
- Concept i2a shows this very streamlined approach, incorporating a wise suggestion by Mel to facilitate pages creation, making the initial usage of this page seamless. Of course, this is not the place to manage pages, but just facilitating the creation should be very impactful for first time users.
- Concept i2b is an even simpler approach, that makes a clearer distinction: yes we need a way to add pages, but this isn't the right place, so we just link the page from there. Simple, effective. This could be also considered a first step before doing i2a.
Also added an alternate "slim" view for the items. I feel it gets a bit limited in space, but might make the UI less overwhelming.
These two i2 mockups assume that behind the scenes we either have a "virtual" /blog
page, or a page that gets automatically created with the proper /blog
slug when necessary. Either approaches are fine to make this UI work seamlessly.
#143
in reply to:
↑ 137
@
8 years ago
Replying to folletto:
I personally think that the "blog" page should be virtual, not a real page: it's exactly the same thing as the archives page, just that instead of being filtered by month, it's the latest posts. The option there would be the ability to change its name.
Doing that, will avoid having a "page" hanging around that is really used for the URL only, and confuses users by showing up in the page hierarchy with actual content apparently editable.
This will reduce also the need of such a double dropdown, since the only thing one will have to select is "what do you want to show on the homepage?", a single list, a single check, much much more intuitive. :)
I disagree, quite strongly. In my experience, relatively non-technical clients think of the blog as a "page" on their website. I've also used it as a way to let clients name the blog page something like Latest News, set its slug, add a blurb to the page (with template support) add it to menus, and allow them to set a featured image for a banner or something on the latest posts page.
I would go so far as to say that custom post types should have the capability to create a dummy page of their own, and work the same way. I've even added this functionality to other post types on client sites myself, since it made it so much easier for the client to manage.
I've found that it's considerably more intuitive to manage the blog section of a website if it has some presence as a page, as opposed to some sort of invisible URL.
#144
@
8 years ago
I disagree, quite strongly. In my experience, relatively non-technical clients think of the blog as a "page" on their website.
I'm not sure... I think we agree actually. Exactly because users perceive "blog" as just another page, we need to present it as such. The design concept above does precisely that. :)
The detail of it being a "virtual" page or a real page, is an implementation detail. I suggested virtual because we already have other pages that do the same and aren't mapped anywhere (archives), but can easily be a "real" page that can't be deleted (or handled in a way that can be restored, given its importance).
This ticket was mentioned in Slack in #core-themes by helen. View the logs.
8 years ago
#146
@
8 years ago
(First time commenter on this ticket, and I've not read through all of the history, so please forgive my jumping in here.)
I've been experimenting with using a Select2 dropdown to take the place of the dropdown-pages
controls for Page on Front and Page for Posts. Latest state of the Customize Object Selector feature plugin is to prevent the “page on front” and “page for posts” from being able to be set to each other to begin with by excluding each other from each other's queries. These Select2 dropdowns also integrate with Customize Posts to allow for new pages to be created in the customizer, removing a block that users would experience otherwise if the page hadn't been created already. This is similar to what was addressed in #34923 for nav menu items, except it allows the page to be fully authored. Here's a short demo video: https://youtu.be/lDYN2cWczT8
There are some more screenshots on the plugin's PR: https://github.com/xwp/wp-customize-object-selector/pull/22
(Accessibility concerns with Select2 notwithstanding.)
#147
@
8 years ago
@westonruter I think your proposal is a good iterative improvement on the current double-dropdown approach. However, the design proposed above goes in an entirely different direction, simplifying and avoiding the two dropdowns entirely (plus aligning the panel design to the other panels, and maybe simplifying its accessibility too).
My suggestion here would be to either refine and implement the design concept i2 above – or another more radical simplification, if we have one – or if we want to go first to an improvement like the one in 'Customize Object Selector', then I'd split that out to a separate ticket to be worked on, in order to avoid burying the design that this discussion contains.
This ticket was mentioned in Slack in #core-themes by davidakennedy. View the logs.
8 years ago
This ticket was mentioned in Slack in #core-themes by helen. View the logs.
8 years ago
This ticket was mentioned in Slack in #design by melchoyce. View the logs.
8 years ago
#151
@
8 years ago
- Keywords close added; needs-patch removed
- Resolution set to wontfix
- Status changed from new to closed
Related: #38164
We have discussed this UI problem for over 6 years and didn't found any solution. Ticket #38164 seems to me to be a good solution and it has been actually realized and included in the core.
I'm quite happy with the solution and would say that this ticket is obsolete since we are talking about things that are no longer existent and the ticket can be closed.
#153
@
7 years ago
I think this is worth reviving. Not only is it mentioned in the 4.9 goals, I think there is some simple UI to figure out to get this in a state where it's easier to manage.
My opinion is that you:
- Choose the custom front-page option
- Select the page from the dropdown
- Enter a slug/permalink of the blog page
So the front-page (home) is a real page, but the blog isn't real and if a page already exists with that permalink/slug then it simply overwrites it/uses it for the blog page. It seems the most logical approach, no?
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.