[UX] Make the default home page path required

[quinnanya]

On /admin/config/system/site-information, the default front page field is pre-populated with home, which generates the a layout, containing a feed of promoted posts. But the instructions beneath that field say:

Optionally, specify a relative URL to display as the front page. Leave blank to display the default content feed.

If you clear out home and leave it blank as per the instructions, the home page seems to be your user account (e.g. /user/1).

---

Translation update

Strings to be replaced:

• Default home page becomes Path to use for the home page

  ---

PR by @BWPanda - backdrop/backdrop#2690

MOST RECENT PR - 01/02/22 PR by @BWPanda and @stpaultim https://github.com/backdrop/backdrop/pull/3891

[klonos]

Thanks for taking the time to report this @quinnanya 👍 ...I was able to reproduce this, but unsure what the "default content feed" mentioned in the help text is, nor what we should be redirecting to.

@jenlampton ??

[laryn]

Hi @quinnanya! Agreed, that is strange behavior and/or misleading instructional text.

Just to add, if you are not logged in, the front page becomes the login form in the case that you blank out the front page field.

I would guess as a user that this should just keep 'home' in place in that field if someone blanks it out (or behave as if it were 'home' if blank).

[klonos]

@laryn if we were to "lock" things to home, I would expect things to work like so:

• have a check in place for when the field is left blank, and in that case have it default to home
• have the help of the text field be:

Optionally, specify a relative URL to display as the front page. If left blank the URL will default to home.

I am still unsure what the default behaviour should be though, and I cannot remember how this worked before.

[klonos]

...it seems that as it is now, the promoted view is being used. The description of that view is:

Provides a list of promoted content. Used by default on the front page.

If this view is disabled, the home page main content area is rendered blank. So I think that this should also be implemented:

• check if the promoted view is disabled && if the home page path has not been set to something that exists. If that is the case, then throw a message in the front page. Something like:

It seems that the default Promoted content view that is used by default on the front page has been disabled, and at the same time no other valid URL has been specified to be used as the home page.

[klonos]

...noting that if you set the home page to a path that is not valid, we throw this validation error when saving the form in /admin/config/system/site-information:

The path 'xyz' is either invalid or you do not have access to it.

I have not checked the code to verify if home is set as a hard-coded exclusion, of if the validation considers paths provided by disabled views as still being valid.

Anyway, I think we might be getting somewhere here 😄

[laryn]

@klonos The home path is a default Layout, which can be disabled or edited.

[klonos]

...you are right @laryn. The promoted view does not offer a page, only a block and feed. The block is used in the home layout, and disabling the view renders the block broken:

[klonos]

This is a serious UX bug, that should be fixed as soon as possible. I am adding the milestone candidate so that it does not slip under the radar again.

[jenlampton]

unsure what the "default content feed" mentioned in the help text is, nor what we should be redirecting to.

Back before we had he home page layout, the "default content feed" was /node, and that's what Backdrop/Drupal used for the front/home page.

Perhaps we should revert to this behavior? If no value is entered into this field on this form, we save 'node' in the config file.

Or, we could change the help text:

Optionally, specify a relative URL to display as the front page. Leave blank to display the default content feed.

Could become:

Enter a relative URL to use as the home page. For example: home or about/history.

@klonos can you open a separate issue about disabling the promoted block? That one's less critical :)

[klonos]

Seems that we need to account for situations where whatever page (as in single specific node), view (or rather page display of a view), or layout that have been set as home page get deleted/unpublished/disabled. Perhaps warn "this is being used as the home page" when attempting these actions on those things? Not entirely sure at this point; I need to test various use cases, but lets handle the originally reported use case first.

@jenlampton yes, separate issue for the promoted block.

[jenlampton]

How about a separate issue for all the things mentioned in your last comment (promoted block being one of them) and a simple asap fix for this issue, as noted above?

[klonos]

Yep, that too 🙂

[jenlampton]

no PR, so removing milestone.

[ghost]

I've looked into this and, from what I can see, the default value of the 'Default front page' field was changed from node to user in an effort to make the node module optional.

Since our node module is still required then I think it's fine to set 'node' as the default (as @jenlampton suggested). I also noticed a field below the 'Default front page' field ('Number of posts on front page') that's only displayed when the 'Default front page' is node. However this only happens on saving the form, so it's not obvious that it's there (unless you scroll back down after saving to notice it). I've changed this to use #states instead so that it appears straight away when 'Default front page' is blank (i.e. node).

Finally, I saw a few places where config_get('system.core', [SOMETHING]) was used, even though $site_config = config('system.core'); is defined at the top of the function. I've therefore changed these to $site_config->get([SOMETHING]) instead.

PR: https://github.com/backdrop/backdrop/pull/2690

[ghost]

From my understanding of https://backdropcms.org/user-guide/adding-milestones-issues I'm allowed to add the milestone. Correct me and remove it if I'm wrong.

[stpaultim]

We just had a question in the forum that is very much related to this discussion. https://forum.backdropcms.org/forum/adding-menu-block-front-page

A user listed node/2 as their home page and then added a block to the home layout and was surprised that their block did not show up on node/2 (which is their home page).

This is because if you set a custom home page path at admin/config/system/site-information - the page will now use whichever layout is specified for that page, NOT the home layout. There is nothing in the UI to make this clear.

A confusing alternative, would be to go to the home layout and set a visibility condition to use the home layout on node/2, but if you do that - you don't get the content of node/2 because the home layout does not have a Main Page Content block and it is NOT possible to add one.

I think that in this situation, most of us would use a existing content block in the home layout and this is probably the best solution in most cases. However, I think we should do something to help reduce the likelihood that users might waste time on either of these other very sensible alternatives, neither of which work as one would expect.

1) Is there a reason why the Main Page Content block is not reusable on the Home page layout? 2) Can we at least provide some help text on admin/config/system/site-information to indicate that if a user sets the home page here they will override the home layout and instead use the layout for the path they suggested?

• • • • • EDIT - - - - - -

I did not see the existing PR. Maybe I should spin my suggestions off into new issues so that we can resolve the existing PR first?

Just found:

• [ ] #2636 | Main page content block not available for the Home page layout.

[stpaultim]

@BWPanda - I think that the PR accomplishes the functional part of this issue, however there was also an issue with the help text. I suggest that we take the changes proposed by @klonos and add another line to help the user understand the layout implications of changing this setting.

Old help text:

Optionally, specify a relative URL to display as the front page. Leave blank to display the default content feed.

Proposed help text:

Optionally, specify a relative URL to display as the front page. If left blank the URL will default to home. The front page will use whichever layout is currently associated with this path.

[stpaultim]

@BWPanda - I hope I'm not stepping on toes. I wanted to see if I could simply submit a new PR based upon yours. It appears to have worked. We can leave both for now, since there is yet no agreement on my suggested change in help text.

My PR is the same as @BWPanda but with some additional changes to help text.

[ghost]

@stpaultim Not at all, that's why I removed my assignment 🙂

[stpaultim]

Hmm, can't get the sandbox to work.

[jenlampton]

The sandbox is working now, but the PR still needs work.

We are setting the default value for the home page setting to node in this PR, but the description text was changed to say Optionally, specify a relative URL to display as the front page. If left blank the URL will default to home. The front page will use whichever layout is currently associated with this path. These two things are in conflict with one another.

We may need a helper function to find and set the default value for home page. It should go something like this:

1. Check if there is a layout with the path home and set that as the default.
2. If not, set the default to 'node`.

After that, the description text will need another update. Thoughts:

• we can remove the word optionally.
• A relative URL we call a Path

Specify a path to use for the home page. If left blank, the system will use a layout at the path '/home' if it exists. If not, the the default content feed at '/node' will be displayed.

[docwilmot]

Specify a path to use for the home page. If left blank, the system will use a layout at the path '/home' if it exists. If not, the the default content feed at '/node' will be displayed.

Bikeshedding: can we just skip the path business and say:

Specify a path to use for the home page. If left blank, the system will display the home layout if it exists, or an unformatted list of content if it does not.

[indigoxela]

I could verify this odd behavior (/user is the default site_frontpage if nothing's set).

Out of curiosity I checked, when this came in. It was Drupal Issue #375397: "Make Node module optional.", commit b3cf0681

This isn't something we need to consider in Backdrop, the Node module is and should be required. So the PR looks reasonable to me (set default value back to /node).

It's marked as "needs work" only for wording reasons.

Just to revive this stalled issue. :wink:

[klonos]

• we can remove the word optionally.

👍

• A relative URL we call a Path

also 👍

Specify a path to use for the home page. If left blank, the system will use a layout at the path '/home' if it exists. If not, the the default content feed at '/node' will be displayed.

Sound good 👍 ...my only suggestion would be to replace "content feed" with "content listing".

[klonos]

...I just saw @docwilmot's suggestion, and I like it better:

Specify a path to use for the home page. If left blank, the system will display the home layout if it exists, or an unformatted list of content if it does not.

[klonos]

...turns out I had a sandbox on my local for this. Here's where I am so far:

I believe that providing the user with options is much better UX than having them read lengthy help text, which explains what they need to do manually. I might clean up that version on my local (it is from before #3764 got merged), and push it as a PR, to see what people think.

[indigoxela]

@klonos Nice try to derail this issue... :laughing:

No, seriously, do we really need a new/different UI here? The site frontpage setting doesn't change often, in many cases not at all.

The main reason for this issue is that several people (including me) found it odd that the default value is "user" when nothing's set. Setting the default back to "node" makes sense for Backdrop. I don't think anyone had trouble with the user interface for that value. Or is that the case?

@BWPanda I think, there's an inconsistency in your PR. When the value is empty, the number of posts can be set, but not if the value is "node".

A screenshot for comparison:

[klonos]

No, seriously, do we really need a new/different UI here?

Nope. That's simply how I leave notes/thought-trails to myself in various issues. Then, after the PR gets merged and the issue closed, I file new follow-up issues. Sorry, I didn't mean to derail nor imply that any UI change should happen as part of this issue here.

[ghost]

When the value is empty, the number of posts can be set, but not if the value is "node".

Fixed, and PR updated. Thanks @indigoxela!

[ghost]

Ok, so I added the preferred new help text, however it wasn't accurate until I also added the new feature that @jenlampton suggested re. changing the blank homepage to be home if the Home layout exists, or node if not.

So the latest PR now does the following:

• If the frontpage setting is saved as empty and the 'Home' layout exists and is enabled, sets the homepage to home, otherwise sets it to node.
• Always displays the value of the frontpage setting field (even if it's home or node.
• Changes the help text for the frontpage setting to:

  Specify a path to use for the home page. If left blank, the system will display the home layout if it exists (home), or a list of promoted content if it does not (node).

• Only displays the 'Number of posts on home page' setting if the frontpage setting is node (using States API).

https://github.com/backdrop/backdrop/pull/2690 ready for testing again.

@stpaultim I popose closing your PR in favour of my updated one so it's easier for testers/less confusion.

[indigoxela]

Only displays the 'Number of posts on home page' setting if the frontpage setting is node (using States API).

Doesn't that mean that the setting is inaccessible if the value is empty and the home layout is missing? (Which means that node would be the default.)

Personally, I don't like such complex hidden logic (it's this or that (home or node), you'll never guess...). It can be so incomprehensible for users. But I don't want to start an extra discussion for that.

[ghost]

Personally, I don't like such complex hidden logic...

Yes, that's why I made the frontpage setting field show the value after you save the form with a blank value (previously it would remain blank if the value == 'node'). Now, you can see what the value is, and at that point it will correctly show (or not) the dependent field (this is, BTW, the same as the current behaviour - that dependent field is only shown/hidden after saving the form).

[indigoxela]

Yes, that's why I made the frontpage setting field show the value after you save the form

Many thanks for your explanation. I did some testing in the sandbox:

• Went to admin/config/system/site-information
• Removed home and saved
• home was back after saving
• Set the value to node (set a value for displayed items) and saved
• Node and chosen item value was saved correctly
• Set the value to home and saved
• Went to admin/structure/layouts and disabled the "home" layout
• Went to / - 404 not found
• Went to admin/config/system/site-information home was still set
• Saved without changes - home was still set (although the layout is still disabled, frontpage is still 404)
• Removed that value (empty) and saved - value switched to node

Ehm... to be honest, I had some WTF moments. But I'm no UI specialist. :wink:

[ghost]

Thanks for the testing @indigoxela. That all sounds like it works as designed.

The reason for the 404's is simply because if you set the homepage to something (e.g. node/4) and then delete that content (e.g. delete node with ID 4), the homepage setting isn't going to automatically update to something else. You're natually going to get a 'page not found' error. If you were expecting something different, then I believe that'll be a separate issue/feature request...

[indigoxela]

That all sounds like it works as designed.

I didn't question that :grinning:, but is it really better UX?

My three main problems with that solution seem to be:

1. I don't think it's smart to hardcode something that can be disabled / deleted (like the "home" layout)
2. I find it weird to fill out form items a user has emptied (that's not how I'd personally deal with default values)
3. I find it weird that the form lets me save "impossible values" without nagging or any hint (home is inaccessible - layout is disabled - not a new problem)

Again, I'm no UI expert, so these are only my personal concerns.

[indigoxela]

A quick update regarding point 3 from my previous comment (can save disabled layout, unpublished node).

This message explains it actually (I deleted layout "foobar"). "The path 'foobar' is either invalid or you do not have access to it."

The validation function should not check if I (the admin) have access, but if visitors have access. That's nothing that has been introduced with this PR, so it could be ignored here (follow-up issue?).

[klonos]

But I'm no UI specialist. 😉

I ain't one either ...but here's how I'd expect things to work ideally, as an end user:

• If I try to delete the node, or view, or layout that's set as my home page, there should be a warning, to let me know that I'll be getting 404s until things are fixed (new home page specified in admin/config/system/site-information). I understand that this is a separate issue though.
• If I leave the home page field empty, and that is changed to something that works as a fallback "behind the scenes", then I'd expect the success message on the form submit to be letting me know that this has happened (in other words, that whole "Removed home and saved -> home was back after saving" is a UX WTF).

follow-up issue?

Yes, expect one or more follow-ups if all things that I consider WTFs are not addressed as part of this issue here 😅

[stpaultim]

In this comment (and comments following) I suggested a change to the help text to help users understand that if they set a new path, the "home" layout may no longer be used.

While this is not directly related to the user vs node default (it is related to the title of this issue "sort out issues with setting the default home page"), we are changing the help text in this PR already and I think adding this line would be really helpful to users to understand what is happening.

NOTE: The home page will use whichever layout is currently associated with this path.

I think that it will be VERY easy for users to not understand that even if they have an active home layout, changing this value will also change which layout is being used. If you change this value, then the ACTIVE HOME LAYOUT may no longer have any effect.

Do I need to open a new issue and submit a new PR for this or is there any chance of getting this added?

[stpaultim]

"Removed home and saved -> home was back after saving" is a UX WTF

Well this not be optimal, it is not clear to me that this is a major UX problem because: (EDIT on 02/04/2021: I misunderstood this earlier. I agree that this is a UX WTF)

1) What does a user expect to happen if they remove the default value for the home page and don't replace it. It seems to me that the most obvious result is that the default action would return (that's why it's the default). It doesn't really make any sense to me why someone would remove "home" and not replace it and expect anything different to happen.

2) If a user does remove "home" and not replace it, we have help text that explicitly says what will happen If left blank, the system will display the home layout if it exists (home) and one can easily see that the path is 'home' again.

None of this is to suggest that adding a status message that says something like "You have set your page to ___" is a problem. But, I'm not sure it's required for a reasonable UX.

[indigoxela]

It seems to me, that this issue is currently a little too wide for an easy solution. My first impression (almost done) might have been wrong.

Maybe it helps to split it into several (sub-)tasks?

• Switch the default fallback from user back to node - which would actually need less than the current PR already has
• Improve form validation to check for anonymous instead of admin access to potential frontpage setting (follow-up?)
• Elaborate an easy to understand UI (same or another follow-up?)

[stpaultim]

Maybe it helps to split it into several (sub-)tasks?

In the interest of simplification, I've broken my related, but different, concern about the help text into it's own issue. I still think it would be great if that issue could be merged with this one, but if there are any objections or concerns, we now have a different issue for that. #4839

I am fine with the core change in this PR as it is which is to use the "home" layout if available and if not, to use the "node" path.

[philsward]

Question: how many here have used the default "page display" provided by Drupal/Backdrop?

With well over 50+ sites under my belt on Drupal, not a single one is left to "node" and I don't think the home page layout for BD should use this either.

Yes, I realize it's a placeholder, yes I realize it's supposedly "friendly" for new users, but it's only worthwhile for the very first time someone new installs Backdrop.

The home page should be ready to add/edit home page content out of the box.

It always bugged me that I had to go override the home page on EVERY Drupal install. It should be as simple as clicking edit, adding/changing content and saving.

By having the list of pages, it's actually more confusing to new people because they have to now learn how to get rid of it.

Ideally, the install profile should ask: "How do you want your homepage to look?" With one option showing the "old" way and the other option of a page that is ready for homepage content. Add telemetry to the mix and measure how many people use one over the other, then promote the winner down the road.

[indigoxela]

@philsward we're currently trying to narrow down the purpose of this issue. It seems to me, your comment further enhances the scope. :wink: You know - the wider the scope the less likely is a solution.

[philsward]

@indigoxela sometimes you have to take a step backwards to view the whole scope, so you can figure out what actually needs fixed.

My point is that the entire homepage experience is really confusing all the way around. By understanding how we address the overall UX problem of how the homepage is expected to work, we can better guide the user on how to change the default homepage path.

What I would like to see, is a homepage experience where very few people ever have to change that default system setting and they only need to because they have a very specific reason for changing it. I.e they know exactly what they're doing.

By approaching it from this angle, we can better inform someone about what happens if it does get changed.

This issue while very valid for the "blank" scenario, still doesn't fix the fact that the OOTB experience is extremely confusing, even for experienced Drupal users where every single one of them is expecting to have to go change it. Instead, it should very rarely be changed because the OOTB experience is the most ideal for most situations.

[indigoxela]

@philsward I agree, the whole UX regarding setting site_frontpage has issues and needs some loving care.

But the initial scope of this issue (see issue description) is that the default value - if not set - is user instead of node (a change we inherited from early D8). That would be an easy fix.

Fixing the "whole scope" is a huge task and I expect lengthy discussions, which means that the simple default value task won't get fixed for a looong time. I hope I could explain my suggestion to use sub-tasks a bit better now. :wink:

UX discussions tend to get out of hand and that might block the simple switch back to default node - like it is/was in D7.

[philsward]

@indigoxela no worries. Just playing devil's advocate and making sure we aren't tackling low hanging fruit that might end up changing later due to larger discussions.

Blank = /node is probably fine for now. Not a fan of it for long term though.

[ghost]

A few of us were discussing this after the dev meeting, and it was suggested that in Backdrop, unlike Drupal, you generally shouldn't need to change the homepage path on the System Information page. It should stay as home and you could/should instead tweak the Home layout to do what you want (display a specific node, add additonal blocks, show a view, etc.).

In that case, I propose moving the homepage field on the System Information page into a collapsed fieldset (maybe called 'Advanced Settings'?) that, when expanded, displays a warning above the homepage field pointing people to the Home layout and saying that editing this field changes how Backdrop works and therefore should only be done if you know what you're doing.

[stpaultim]

This issue has a very ambiguous title which I think is blocking progress, because with this title the goals are not clear.

I've opened a META issue that addresses the broader issues surrounding the home page. I'm going to open another new issue with the suggestion that @BWPanda mentioned in his last comment AND change the name of this issue to reflect the goals of the attached PR.

Actually, I added the suggestion by @BWPanda to Improve Help Text Regarding Default Home Page Path since I think it's very similar or compatible with the goals of that issue. @BWPanda you can open a new issue if you prefer.

Changing the default front page from user to node.

[stpaultim]

"Removed home and saved -> home was back after saving" is a UX WTF

In an earlier comment, I suggested that this wasn't so bad. Relooking at PR, I agree that this is very confusing. The field is not required and it appears that the user can delete the home page path, but then it is automatically added back without explanation. This was confusing for me and I assumed the PR was broken until I reread the earlier discussion (and noticed my earlier comment).

@indigoxela said:

Switch the default fallback from user back to node - which would actually need less than the current PR already has

It seems to me that this earlier goal was a step in the right direction. This discussion has gone lots of new directions and MANY new issues have been opened. I'd be inclined to make the original small step forward and then proceed with another issue.

Putting this on agenda for next weeks DEV meeting.

[herbdool]

Looks like it needs more discussion.