WordPress.org

Make WordPress Core

Opened 3 years ago

Last modified 10 months ago

#26879 reopened enhancement

Friendlier welcome when installing WordPress

Reported by: mrtortai Owned by:
Milestone: Future Release Priority: normal
Severity: normal Version: 3.0
Component: Upgrade/Install Keywords: needs-testing ux-feedback needs-flow has-patch needs-screenshots
Focuses: ui Cc:

Description

When you first install WordPress, the very first interaction you have with WordPress is an error - by design.

The message is, "There doesn't seem to be a wp-config.php file....". The page title is "WordPress > Error". For new users to WordPress, this is an intimidating message suggesting that they have done something wrong.

This page hasn't been updated for a while. This ticket provides a more welcoming first page for new users.

Summary of Changes:

  • Replaced error message with a more friendly message.
  • Changes page title from "WordPress > Error" to "Welcome to WordPress [version number]"
  • Changed HTML div name from #error-page to #wp-welcome-page. Updated associated CSS.
  • Added WordPress png and svg logo to top of page.

Please see attached screenshot of before and after.

Attachments (26)

Before.png (108.4 KB) - added by mrtortai 3 years ago.
Current WordPress welcome screen.
After.png (133.5 KB) - added by mrtortai 3 years ago.
Proposed New Welcome Screen
26879.patch (21.6 KB) - added by mrtortai 3 years ago.
Patch #26879
After-revised.png (119.8 KB) - added by mrtortai 3 years ago.
After screenshot revised to shorten text based on feedback.
26879-2.patch (21.4 KB) - added by mrtortai 3 years ago.
26879 Version 2
26879-3.patch (6.6 KB) - added by mrtortai 3 years ago.
Welcome To WordPress Page 26879-3.png (119.7 KB) - added by mrtortai 3 years ago.
Screenshot of Welcome Page 26879-3.patch
setup-config Page 26879-3.png (141.7 KB) - added by mrtortai 3 years ago.
Screenshot of setup-config Page 26879-3.patch
26879-4.patch (9.2 KB) - added by noam@… 3 years ago.
26879-4.patch
Before Table Prefix Empty Error.png (91.1 KB) - added by noam@… 3 years ago.
Before Table Prefix Invalid Error.png (92.2 KB) - added by noam@… 3 years ago.
After Table Prefix Empty Error.png (102.7 KB) - added by noam@… 3 years ago.
After Table Prefix Invalid Error.png (103.4 KB) - added by noam@… 3 years ago.
26879-5.patch (11.1 KB) - added by mrtortai 3 years ago.
26879-5.patch
WordPress Login.jpg (54.3 KB) - added by mrtortai 3 years ago.
26879-6.patch (11.5 KB) - added by mrtortai 3 years ago.
26879-7.patch (11.4 KB) - added by mrtortai 3 years ago.
26879-8.patch (11.1 KB) - added by mrtortai 3 years ago.
26879-9.diff (11.7 KB) - added by Hanni 3 years ago.
Promised edits to some of the wordy bits.
26879-10.diff (11.8 KB) - added by Hanni 3 years ago.
Attempt at amalgamating the two different approaches to the initial wp-load.php text. It's a bit wordy and i think I made it worse.
26879-11.diff (10.7 KB) - added by mikeschroder 3 years ago.
Cleanup, error logo removal, small text tweaks.
26879.diff (13.0 KB) - added by nacin 3 years ago.
26879-12.diff (12.3 KB) - added by seanchayes 18 months ago.
Patch refresh
26879-14.diff (11.9 KB) - added by seanchayes 15 months ago.
26879-15.diff (176.3 KB) - added by extendwings 15 months ago.
26879-16.diff (12.6 KB) - added by extendwings 15 months ago.
Remove wp-includes/functions.php.orig

Download all attachments as: .zip

Change History (76)

@mrtortai
3 years ago

Current WordPress welcome screen.

@mrtortai
3 years ago

Proposed New Welcome Screen

@mrtortai
3 years ago

Patch #26879

#1 @johnbillion
3 years ago

  • Component changed from General to Upgrade/Install
  • Keywords 2nd-opinion added
  • Version changed from 3.8 to 3.0

Congrats on your first patch mrmortai!

I really like the idea of making this screen more inviting, but your patch is definitely too wordy. Let's keep it short and to the point.

@mrtortai
3 years ago

After screenshot revised to shorten text based on feedback.

#2 @mrtortai
3 years ago

Hi @johnbillion, thanks for the feedback.

Attached is a revised patch which has been wordsmithed down to 3 sentences. The source of the wording is the http://wordpress.org/ homepage.

Please see the After-Revised.png screenshot.

@mrtortai
3 years ago

26879 Version 2

#3 @nacin
3 years ago

  • Milestone changed from Awaiting Review to 3.9

Going to take this off the good-first-bug report as mrtortai is already on it. :-)

I think this is a great improvement! There are some things I'd probably change. Here's a rundown.

  1. I'd drop the version number. It isn't important. Let's just invite them to WordPress. I like my Howdy's and emoticons, but I'd probably simplify the title to just "Welcome to WordPress!" (Same for <title>).
  1. The widow ("imagine" on its own line) is killing me. I'm wondering regardless if we can merge the first two paragraphs (or perhaps all three). Or, we need to change something like widths or padding.
  1. wp_die() is a generic function used for a lot of error messages. I don't think we need to change #error-page to #wp-welcome-page. It would be nice, but it's not necessary and this is really the rare situation where it's not an error, not the standard use case.
  1. The same thought applies to the WordPress logo. We don't need to overly imply ownership or responsibility over an error message — it's better to not put the logo on them. We can pass this logo directly into wp_die() (and leave the CSS in wp_die() for when it is passed) for this one situation.
  1. We probably still need to include some kind of help information regarding wp-config.php. There's a link to the Codex there, for example, a poorly-worded explanation that it doesn't always work, etc.
  1. I'd also try to ditch the border/underline below the h1. After the next pass, though, I'll ask a designer to look at it.
  1. There's no need to patch minified files. That gets handled on build. There's also no need to patch RTL files. Those are also generated automatically on build. See also the *other* repository, http://develop.svn.wordpress.org/trunk, and the Grunt tasks there.

#4 @DrewAPicture
3 years ago

  • Keywords docs-feedback added; good-first-bug removed

#5 @SergeyBiryukov
3 years ago

The message is, "There doesn't seem to be a wp-config.php file....". The page title is "WordPress > Error". For new users to WordPress, this is an intimidating message suggesting that they have done something wrong.

I've seen a user confused by this at least once, so +1 to making this page more friendly.

#6 @siobhan
3 years ago

This is awesome! I hate that page. You're totally right that it's off-putting to users. Thanks for opening the patch and giving it some love. I've got a few suggestions for text changes:

  1. Ditch the reference to "the core software" - that's quite a WP community way to talk about WordPress to distinguish the product from the rest of the community projects. It's not how a user would think of it.
  1. Ditch "welcome to the family" - it creeps me out a bit. I want to have a website, not join a family.
  1. I agree with nacin that some sort of explanation of setting up wp-config is important. However, we can make this a bit more user-friendly.
  1. I'm a bit concerned about linking to the Codex page. It's instantly scary (with the big red warning signs) http://codex.wordpress.org/Editing_wp-config.php That's more of a documentation flaw though. I know that you can only link to the documentation that we provide you with :(
  1. The preemptive error message on setup-config.php feels like it's in the wrong place (the "if for any reason this automatic file creation doesn't work...etc etc"). We're expecting that the user read that text, and absorb and remember it in case something goes wrong. However, it's more likely that the user will glance over it, fill in the database details, and not really think about it. It's when something actually goes wrong that they should get the information about how to fix it, not beforehand.
  1. I'm leaning towards removing "if you want to run more than one WordPress in a single database" (after table prefix on setup-config.php) as that seems like a more advanced technique and that person would already know how to install WP. That's just a thought that I'm throwing out there.
  1. Maybe at the end of the install process we could have some sort of call to action for people to get involved that links to the make site?

Here are some suggestions. Feel free to peck at it to get what you want:

wp-load.php

WordPress is web software you can use to create a beautiful website, blog, or almost anything you can imagine. WordPress is built by hundreds of volunteers, and there are thousands of plugins and themes available to transform your site.

Reading back through this, I was thinking that if I'm installing WordPress, I'm already aware of what it is (i.e. I'm setting up my blog or whatever). It might make more sense to use this space to have a sort of teaser. Here's a suggestion for an alternative direction:

wp-load.php

In just a few minutes, you'll be all set up with WordPress and ready to create your own corner of the web. Transform your website with the thousands of plugins and themes available from right within WordPress. Write your blog, build your first website, launch your business, share your photos with your friends. You can do just about anything you can imagine.

setup-config.php

Before getting started, you need to configure WordPress. That means providing some information about your database. This information is available through your web host. If you don't have it, you'll need to get in touch with them. Here's what you need:
Database name
Database username
Database password
Database host
Table prefix
Once you fill in this information, WordPress will create a configuration file called wp-config.php. This connects WordPress with your database (that's where your content, settings, photos, and all that good stuff is stored).

#7 @mrtortai
3 years ago

1) (Nacin) I'd drop the version number. It isn't important. Let's just invite them to WordPress. I like my Howdy's and emoticons, but I'd probably simplify the title to just "Welcome to WordPress!" (Same for <title>).

Done.

2) (Nacin) The widow ("imagine" on its own line) is killing me. I'm wondering regardless if we can merge the first two paragraphs (or perhaps all three). Or, we need to change something like widths or padding.

Yes, that hanging "imagine" looked odd. I combined the first two paragraphs which looks better.

3) (Nacin) wp_die() is a generic function used for a lot of error messages. I don't think we need to change #error-page to #wp-welcome-page. It would be nice, but it's not necessary and this is really the rare situation where it's not an error, not the standard use case.

I restored to the previous #error-page. Having a unique id/class on the first page would be nice in case you want to make further design changes to the welcome page in the future.

4) (Nacin) The same thought applies to the WordPress logo. We don't need to overly imply ownership or responsibility over an error message — it's better to not put the logo on them. We can pass this logo directly into wp_die() (and leave the CSS in wp_die() for when it is passed) for this one situation.

The logo is now passed through wp_die(). Through the setup process, the user may hit a number of different error pages (Can't select database, Error establishing a database connection) so I added the logos to these pages as well for consistency.

I was not sure about passing CSS through wp_die()? Right now, the CSS lives in /wp-inclues/functions.php

5) (Nacin) We probably still need to include some kind of help information regarding wp-config.php. There's a link to the Codex there, for example, a poorly-worded explanation that it doesn't always work, etc.

The "Need Help" codex link has been restored to the setup-config.php page. The Codex page (http://codex.wordpress.org/Editing_wp-config.php) needs some serious love. I made a first attempt at updating that document. :)

6) (Nacin) I'd also try to ditch the border/underline below the h1. After the next pass, though, I'll ask a designer to look at it.

Ok.

7) (Nacin) There's no need to patch minified files. That gets handled on build. There's also no need to patch RTL files. Those are also generated automatically on build. See also the *other* repository, ​http://develop.svn.wordpress.org/trunk, and the Grunt tasks there.

Ah yes, thanks!

8) (Siobhan) The preemptive error message on setup-config.php feels like it's in the wrong place (the "if for any reason this automatic file creation doesn't work...etc etc"). We're expecting that the user read that text, and absorb and remember it in case something goes wrong. However, it's more likely that the user will glance over it, fill in the database details, and not really think about it. It's when something actually goes wrong that they should get the information about how to fix it, not beforehand.

Agreed. The correct place for these seems to be the, "Sorry, but I can’t write the wp-config.php file." page. That page already has a similar, more direct message: "Please create the wp-config.php manually and paste the following text into it." So I've removed the original message.

9) (Siobhan) I'm leaning towards removing "if you want to run more than one WordPress in a single database" (after table prefix on setup-config.php) as that seems like a more advanced technique and that person would already know how to install WP. That's just a thought that I'm throwing out there.

I remember when I first saw this message many years ago, it did inform me of the ability to run multiple WordPress installations in a single database. So for me, it did served an informational purpose.

Changing the default table prefix is a common security recommendation. Perhaps we should add some text to nudge the user to change the prefix?

10) (Siobhan) Ditch the reference to "the core software" - that's quite a WP community way to talk about WordPress to distinguish the product from the rest of the community projects. It's not how a user would think of it. Ditch "welcome to the family" - it creeps me out a bit. I want to have a website, not join a family.

The "core software" and "welcome to the family text" is from the http://wordpress.org homepage. I like your suggestions Siobhan! I did "peck at it" a little but I'll defer to you. I'm certainly open to more suggestions!

The welcome page so far is looking much better!

Last edited 3 years ago by mrtortai (previous) (diff)

@mrtortai
3 years ago

@mrtortai
3 years ago

Screenshot of Welcome Page 26879-3.patch

@mrtortai
3 years ago

Screenshot of setup-config Page 26879-3.patch

#8 @mrtortai
3 years ago

  • Keywords needs-testing added

@noam@…
3 years ago

26879-4.patch

#9 @noam@…
3 years ago

The 26879-4.patch removes inconsistencies between /wp-admin/css/install.css and _default_wp_die_handler()'s inline CSS resulting in better alignment between the error pages.

It also makes two additional error pages more user friendly:
"Table Prefix field should not be empty" and
"Table Prefix field can only contain numbers, letters, and underscores."

Additional before/after screenshots are attached.

Last edited 3 years ago by noam@… (previous) (diff)

#10 @mordauk
3 years ago

Just going to chime in to say this is wonderful. Carry on.

@mrtortai
3 years ago

26879-5.patch

#11 @mrtortai
3 years ago

26879-5.patch is attached.
Small margin adjustment for small screens.
A little language cleanup/simplification throughout the install.

#12 @mrtortai
3 years ago

Hopefully, this is not too far out of scope for this Trac ticket. While cleaning up some of the CSS to ensure a consistent look across each install page and error page, I noticed inconsistent padding around the WordPress login form which has a top padding of 31px, right padding of 24px, bottom padding of 45px, and left padding of 24px.

The updated patch, "26879-6.patch", includes a small padding adjustment to the login form in wp-admin/css/wp-admin.css to add a consistent padding of 24px to all sides.

The attached "WordPress Login.jpg" screenshot illustrates this. (Left side of screenshot is pre-patch. Right side of the screenshot is post-patch showing consistent padding of 24px.)

Last edited 3 years ago by mrtortai (previous) (diff)

@mrtortai
3 years ago

@mrtortai
3 years ago

#13 @mrtortai
3 years ago

See ticket #12506 which removes wp-admin.css and splits the file into separate, smaller files. This caused a small issue with the latest patch (26879-6.patch) which required the wp-admin.css file.

26879-7.patch is attached which works correctly with #12506.

#14 @nacin
3 years ago

I believe the whitespace illustrated on the left side of "WordPress Login.jpg" is intentional. 24px all around is pretty constricting. Let's push independent changes into new tickets and keep the focus on the proposal here.

This ticket was mentioned in IRC in #wordpress-dev by nacin. View the logs.


3 years ago

#16 follow-up: @mrtortai
3 years ago

Hello,

Thank you. I appreciate the feedback.

26879-8.patch is attached which is tested against http://develop.svn.wordpress.org/trunk/src in order to make use of the latest changes from #12506

I believe the whitespace illustrated on the left side of "WordPress Login.jpg" is intentional.
24px all around is pretty constricting. Let's push independent changes into new tickets and keep
the focus on the proposal here.

I'd like to see this change (the login form on the left side of "WordPress Login.jpg" appears odd to my eyes), but I agreed that this should not be included within the ticket. 26879-8.patch has removed the change to the login form.

A few notes related to the 2014-03-05 IRC chat

Mar 05 03:05:37 +0000 2014 helen
background: aliceblue?
Mar 05 03:06:53 +0000 2014 nacin
I *think* the goal was to make the non-editable wp-config.php look neither writable nor disabled?

Correct. That was partly the reason, the other reason was to put a slight focus on the wp-config.php file contents.

Mar 05 03:18:01 +0000 2014 nacin
the way the logo was implemented is a bit weird
Mar 05 03:21:58 +0000 2014 nacin
the logo also lost top padding when compared to readme.html
Mar 05 03:22:43 +0000 2014 nacin
oh, funny
Mar 05 03:22:49 +0000 2014 nacin
the logo implementation is copied from install.css

Yup. :-)

Without the patch, the position of the white body in first install page, setup-config.php and error pages are completely different. This patch ensures that the position of the white body and the logo is consistent throughout the install process. The white body and logo placement in readme.html is slightly off only due to the presence of the scrollbar on the long page. #wontfix
However, it could be fixed by adding this to setup-config.php: body {overflow-y: scroll}

Most of the new CSS I added was simply to correct various little inconsistencies.
For example, body {} in install.css Line 6 includes -webkit-font-smoothing: subpixel-antialiased;
But body {} in the setup-config.php pages (wp-includes/functions.php Line 2194) did not.

Mar 05 03:12:16 +0000 2014 helen
i like where it's going though
Mar 05 03:15:02 +0000 2014 nacin
me too
Mar 05 03:16:03 +0000 2014 DH-Shredder
I'm a fan as well. A user's first experience being "It's broke," is less than ideal.

Thanks :-) I'm certainly open to more feedback and wordsmithing.

Last edited 3 years ago by mrtortai (previous) (diff)

@mrtortai
3 years ago

#17 in reply to: ↑ 16 @zodiac1978
3 years ago

Replying to mrtortai:

However, it could be fixed by adding this to setup-config.php: body {overflow-y: scroll}

overflow-y shouldn't be used with body (would cause a double scrollbar on legacy IE). It should be used with html instead of body.

#18 @mrtortai
3 years ago

Thanks for the info @zodiac1978! The only purpose of adding overflow-y: scroll; would be to correct the very slight logo and body position inconsistency between readme.html and the other install pages. Not a very real benefit for introducing overflow-y: scroll in my opinion.

#19 @Hanni
3 years ago

This has to be right up there for the best first bug report and subsequent patch(es), @mrtortai! Wow! :)

Please forgive my incoming wall of text, I have a great deal of thoughts about your wonderful ideas.

Some notes on the aforementioned thoughts as the text stands right now in 26879-8.patch:

wp-load.php
  1. My first thought, (underlined even further after seeing @siobhan's comment to that effect) refers to the last line of the wp-load.php text.

"We'd love for you to join a family", whilst perhaps appropriate (?) for the about page, feels too "in your face" for a user’s very first interaction with the software. It's a little too over-eager, over-friendly. I liken it to that rather uncomfortable feeling in a conversation with a new acquaintance who, whilst absolutely lovely, and well intentioned, is clearly trying too hard and thus making the situation needlessly awkward.

  1. Ditto with regards to “core software”. That’s jargon to an outsider, without a shadow of a doubt. How about just this software, or this project? Project may not be ideal, as it’s introducing yet another word / community specific thingamajig. I apologise for not having an alternative idea here.
  1. OK, I admit it, this is a ridiculous nitpick, but I’m bothered by the use of website and then merely two lines later (one sentence), “site”. This is an unnecessary inconsistency, IMHO.
  1. In the same vein as @nacin’s suggestion to remove the version number above, how about replacing “thousands” in “there are thousands of plugins and themes” with “countless”? It’ll stand the test of time better, and (to me at least) is a friendlier word. This may be a British, or just “Hanni” point of view, though.
  1. Button text could be shorter. Title case looks odd in this case with “Let’s Get Started!” What about “Let’s Go!” or “Let’s go!”. I realise this doesn’t have quite the same connotations so.. will mull this over a bit more. (OK, this is hilarious, I wrote this before clicking on the button, and now see that the next screen uses “Let’s Go!” in a far more appropriate context. This perhaps makes the above point moot). How about "Get Started?" It's less friendly, though.
setup-config.php

1." To get started, we need some information on the database" - what about “about” in place of “on”. This doesn’t read well to me. I actually would +1 for Siobhan’s overhaul of the sentence to “Before getting started, you need to configure WordPress.”

  1. “Table prefix (if you want to run more than one WordPress in a single database)” WordPress instance? The whole parenthesis is potentially redundant. Even more so when I go on to the next step and see the explanation there…. So, yes, this can explanation doesn’t need to be in two places.
  1. Is the wp-config explanation actually needed? What about displaying it only if something goes wrong? If it is needed then an alternative to "good stuff' could perhaps be found. I'm sorry that I'm struggling to think of one right now.
  1. “Need more help? We got it.” is another slightly strange sentence. Why not something like “You can find help here.” “If you need help, ..” or something...
  1. “Oops, the Table Prefix field should not be empty. “ Correct, it “shouldn’t” in terms of being good practice. But, also, in this case it “cannot” be empty. So, perhaps can't could be used instead here.

I'll go ahead and create the patches for the instances in which @siobhan and I are in agreement later on today. I'm happy to do more, if anyone else thinks any of the above proposals make sense.

This is fantastic, @mrtortai!

Last edited 3 years ago by Hanni (previous) (diff)

#20 @mrtortai
3 years ago

Hello Hanni,

Thank you for the great content feedback.

"We'd love you to join the family."

Yes agreed. A couple possible alternatives:

a) The description does not include any mention of WordPress being free or Open Source which is an essential part of WordPress. It would be a good idea to include a short paragraph here.

b) Just a smiley face here could be fun and welcoming: :-)

“core software”.

Very much agreed. That should be removed.

OK, I admit it, this is a ridiculous nitpick, but I’m bothered by the use of website and then merely two lines later (one sentence), “site”.

Good catch. Very much agreed as well!

how about replacing “thousands” in “there are thousands of plugins and themes” with “countless”?

"Countless" could mean many dozen and doesn't sound nearly as impressive as "thousands" in my opinion.

" To get started, we need some information on the database" - what about “about” in place of “on”. This doesn’t read well to me. I actually would +1 for Siobhan’s overhaul of the sentence to “Before getting started, you need to configure WordPress.”

The sentence, “Before getting started, you need to configure WordPress.” isn't very informative and "configuring WordPress" sounds hard. I like how the current sentence is very casual and makes the process sound easy. ("To get started, we need some information on the database").

“Table prefix (if you want to run more than one WordPress in a single database)” WordPress instance? The whole parenthesis is potentially redundant. Even more so when I go on to the next step and see the explanation there…. So, yes, this can explanation doesn’t need to be in two places.

Yes I would also vote to remove the parenthesis here.

Is the wp-config explanation actually needed? What about displaying it only if something goes wrong?

I do like the wp-config explanation here because personally I'd like to know what the installer does. Without the patch, there is a dark bold paragraph here warning about what to do if it the install, "doesn’t work". So the new version aims to be more friendly without hiding the explanation of what the installer does.

“Need more help? We got it.”

I actually quite like that :-)

“Oops, the Table Prefix field should not be empty. “ Correct, it “shouldn’t” in terms of being good practice. But, also, in this case it “cannot” be empty. So, perhaps can't could be used instead here.

Good point!

I'll go ahead and create the patches for the instances in which @siobhan and I are in agreement later on today.

Sounds great! Thanks for the help!

@Hanni
3 years ago

Promised edits to some of the wordy bits.

@Hanni
3 years ago

Attempt at amalgamating the two different approaches to the initial wp-load.php text. It's a bit wordy and i think I made it worse.

#21 @Hanni
3 years ago

OK, my apologies for the delay. Here are a couple of patches.

wp-load.php
  1. I hesitated over the capitalisation of Open Source, but followed the examples set by the wordpress.org/about/ page.
  1. I've changed thousands to countless; at this point in time one could perhaps think that the user is aware of WP, as they are installing it. Regardless there are a few points to make here:

a) Thousands is a conservative estimate, I believe,
b) It sounds a little.. boasty? This doesn't fit with the general humble tone of most WP copy.
c) Again, countless will stand the test of time.

  1. Generally speaking smiley faces are both abused and over-used to the point of becoming both redundant, and replacing proper sentences, so in this case I'd vote for avoiding use of a smiley face on this page if at ll possible.
  1. Played around about with is built which felt strange / awkward tense-wise (but i may be confusing between English and French), and therefore tried is built and maintained, which, whilst wordier, seems to sit a bit better.
 setup-config.php:


  1. I removed the somewhat superfluous sentence about getting started as it's repetitive - the button on the proceeding page is "Let's Get Started!", implying that by clicking on that, you're, well, getting started. So to be then told we need blah blah so you can get started seems a bit off or illogical. Perhaps.
  1. Now to the main text, proposing something along the lines of

"OK! We'll need some information about your database.


This information is available through your web host. If you don't have it, you'll need to get in touch with them. Here's what you need:"

So, most people just need to know which information they need, not the immediate explanation about what happens if it goes wrong - they'll naturally skip over the whole paraprah if it's too long, so splitting it up here. if something does go wrong, or they're confused, they'll re-read all information naturally, IMHO. In short, I'm trying to make sure the important bit is read.

I hesitated over changing here's what you need to here's what you'll need, but in the end decided aginast it as there's a you'll need in the previous sentence.

  1. Got rid of number 5 - table prefix (the host won't usually provide / dictate the table prefix so this could be confusing - pointed out by @DH-Shredder)
  1. In all places, Need more help? We got it. Has been changed to "Need more help. Check out our documentation."

In this case an alternative could have been "Codex" but In an idea world one day it won't link to the codex; documentation is a familiar word, and will be useful should the link point somewhere else one day. Codex seemed to jargon-y.

  1. So, I ran into a dilemma, and did a bit of grepping to see what generally seems to happen with the codebase. I wanted to separate out the text a bit, and noticed that <br /> tags had been used within one single PHP tag instance in the proposed patch, but couldn't find at quick glance (?) cases of this happening elsewhere within the codebase. HTML seems to generally be separated out from any echoed text.

Unfortunately, this led to creating a couple of extra translatable strings of text (I created two new paragraphs, each of one line, effectively, to avoid using a br tag.) This leads me to needing help and input from those who know what they are doing with such things:

a) It creates extra translation strings. Boo. However, it avoids including HTML in a translatable string, which seems to be something WP avoids.
b) Aware that with the first version of wp-load.php, and indeed with the links to the documentation the reverse is happening - an a href is being included in a translatable string. To my uneducated eye, I suspect this is something of a different case, as, at least the docs link could go to a translated version of the codex page (shudder). So, in short, I did the best with the little knowledge I have, and some kind help from @DH-Shredder.

At this point.. @vanillalounge - help?!

  1. Changed let's go to title case just for consistency with previous page, and, from what I can see, with buttons within WP generally. However, I notice that later on in setup-config the buttons aren't title case, so, it appears we don't have a "rule" here. It'd be nice to have some consistency, so, what's the opinion or consensus here?
  1. I replaced "good stuff" with paraphernalia, but this is going too far the other way, I think - from the overly simple / stands out for that reason to the overly complicated and standing out as too wordy. Where's the juste milieu here?
  1. Changed shouldn't to can't (in place of cannot which sounds a bit too formal). Then moved tale prefix can't be empty & please go back and try again onto the same line, as they are more closely related to each other than to then the help link. Nonetheless, this draws attention to the fact that they are two slightly staccato sentences, in close proximity to one another, so an option could be to use a semicolon here.

Also, if Table Prefix is being capitalised, perhaps it should be "Table Prefix"? This makes the sentence slightly less easier to parse, though, so I didn't do this.

Oh my! You reached the end of this wall of text! Phew! In which case...

I've also uploaded a second patch which uses the second, alternative direction for wp-load.php, just in case that should be preferred. I attempted to merge the two directions, so as to draw attention to free & Open Source, as @mrtortai pointed out that this wasn't currently mentioned.

Last edited 3 years ago by Hanni (previous) (diff)

#22 @mrtortai
3 years ago

Hello Hanni, thank you very much for the contributions and patch.

I replaced "good stuff" with paraphernalia, but this is going too far the other way, I think - from the overly simple / stands out for that reason to the overly complicated and standing out as too wordy. Where's the juste milieu here?

"Paraphernalia" is not a very commonly used word, and can have a slightly negative connotation.
(http://english.stackexchange.com/questions/114603/does-paraphernalia-have-a-negative-connotation).

Got rid of number 5 - table prefix (the host won't usually provide / dictate the table prefix so this could be confusing - pointed out by @DH-Shredder)

Good to see - I had the same thought that it wasn't necessary and that hosts won't generally provide this information, by I opted to leave it in. Happy to see it go :-)

In all places, Need more help? We got it. Has been changed to "Need more help? Check out our documentation."

Without making too general of a statement - no one likes to read documentation! Some people are actually averse to documentation. I personally did very much like, "Need more help? We got it." Anyone have some input or suggestions on this?

Then moved tale prefix can't be empty & please go back and try again onto the same line, as they are more closely related to each other than to then the help link. Nonetheless, this draws attention to the fact that they are two slightly staccato sentences, in close proximity to one another, so an option could be to use a semicolon here.

Looking at the Table Prefix error page, it looks much better without "Please go back and try again.". There is only one action to take on the page, and the button text is descriptive on the action to take. ("Try Again"). I suggest removing this sentence which also gets rid of the hanging "again" on the line by itself and then we don't need use a semicolon.

"If you don't have it, you'll need to get in touch with them."

Alternative suggestion: "If you don't have it, your web host can provide you with this information."
Or simply: "Your web host can provide you with this information".

"This could mean your host's database server is down."

I would avoid speculating too much. In the three bullet points directly below this sentence there is already a mention about checking that the database server is running. So I suggest removing the speculation that the server could be down.

@mikeschroder
3 years ago

Cleanup, error logo removal, small text tweaks.

#23 @mikeschroder
3 years ago

Attached 26879.11.diff:

  • A few whitespace and coding standards corrections.
  • Changed "(that's where your content, settings, photos, and all that paraphernalia is stored)" to ", where your content and settings will be stored", since we don't really store photos in the database anyway, and this is a bit more direct.
  • Removed logos from error pages
  • Re-added the message regarding not being able to write a wp-config.php because it's important for developers to know what happened, rather than just be told to create a file manually.
  • Added a couple paragraph breaks to the first page to break up the wall-o-text feel a little bit.

I did not touch the CSS, as it will likely need a design pass anyway, and there are more appropriate folks than myself to do so.

With the amount of times we're telling folks to contact their hosts, I'm not sure the help text to the right of "Database Host" is needed. However, if we change that to something like "Database host[name]", then it really points out how much we're repeating ourselves. The only message there that seems to (perhaps) be needed is the note regarding the prefix.

@nacin
3 years ago

#24 @nacin
3 years ago

  • Summary changed from Hello, new users. Here is an Error. to Friendlier welcome when installing WordPress
  • Type changed from enhancement to task (blessed)

26879.diff doesn't touch the language, just styles and implementation:

  • We need to properly reference stylesheets in the wp-admin directory. The hardcoded aspect won't cover it, as this error can be fired from any URL really. wp_guess_url() used to be used in wp_die(), see #17975. It received some significant improvements in [25396], including the actual link used on this page. westi cited issues with multisite in #17975 and I am not sure if that is sufficiently covered with other wp_die() usage. As a last resort, there is 17975.patch:ticket:17975.
  • I removed all style changes. The readme, install, etc. styles dictated by install.css are deliberate. For example, the logo should not be equally spaced at the top; it looks squished. Padding, margin, etc., were also carefully set by designers in 3.8 and shouldn't be touched here.
  • I made it so wp_die() wouldn't wrap $message in a <p> tag. I also removed $title arguments passed into wp_die() when they were the default "WordPress Error" string.
  • I'm not convinced about centered text. It's not really our style and there's no need for it here.

I'll go through the text soon. What we may do for 3.9 is make the initial screen a bit friendlier, but to be honest, few probably ever see wp-config.php, given one-click installers through hosts. (Anecdotally: An actual button-press download on wordpress.org is far outpaced by the number of new installs a day.) Landing on install.php is likely more common, so removing the "Welcome to WordPress" text from there may actually be backwards.

I'm setting this to a task as this is something we'd like to do, but it doesn't mean it'll all get done in 3.9.

#25 @nacin
3 years ago

  • Milestone changed from 3.9 to Future Release

I'm going to move this to future release. There is some great effort here so far but my comment from a few weeks ago raised a few concerns about whether setup-config.php is even the main entry point, and that install.php is sometimes the initial entry point so it similarly needs to reflect it is a welcome screen. Let's regroup after 3.9.

#26 follow-up: @valeriosza
3 years ago

Would not it be nice to have the login screen the option to choose the language?

https://i.cloudup.com/eosoR0q-nc-1200x1200.png

#27 in reply to: ↑ 26 @hardeepasrani
3 years ago

Replying to valeriosza:

Would not it be nice to have the login screen the option to choose the language?

https://i.cloudup.com/eosoR0q-nc-1200x1200.png

Don't you think it's more of a plugin material? Cuz most of the websites don't even allow their visitors to visit the back-end of the website.

But as a plugin, I'd love to see this in action - but not in the core :)

#28 @chriscct7
19 months ago

  • Keywords ux-feedback needs-flow added; 2nd-opinion removed

I'm a huge fan of this ticket's idea. I think if discussions started early enough, this could make the 4.5 release

#29 @mrtortai
19 months ago

Thanks @chriscct7. Certainly seems to be a lot of support for updating the install pages! :-)

#30 @chriscct7
19 months ago

  • Keywords 4.5-early early added

#31 @ericlewis
18 months ago

  • Keywords needs-refresh added
  • Milestone changed from Future Release to 4.5

Would someone mind refreshing this patch? :D

#32 @DrewAPicture
18 months ago

  • Keywords docs-feedback early removed

@seanchayes
18 months ago

Patch refresh

#33 @seanchayes
18 months ago

I refreshed the patch. I took Nacins patch as the base to work from.

attachment:26879-12.diff

#34 @swissspidy
17 months ago

  • Keywords needs-refresh removed

This ticket was mentioned in Slack in #core by chriscct7. View the logs.


16 months ago

#36 @chriscct7
16 months ago

The refreshed patch has the version parameters on the 2 CSS included files hardcoded, which needs to be fixed

#37 @chriscct7
16 months ago

Also, there's a significant amount of HTML inside of the translated strings which should be inserted into the strings using something like sprintf so that the translators don't have to deal with it (looking at the wp-load.php file)

#38 @chriscct7
16 months ago

  • Keywords needs-patch added; has-patch 4.5-early removed

#39 @ocean90
16 months ago

In 36545:

Setup: Improve wording on the page for the database connection details.

See #26879.

#40 @seanchayes
15 months ago

I updated the patch with a piece of code I missed from the Nacin patch.
I refactored the translated strings portion in wp-load.php
I removed the hardcoded version string inadvertently left in from Nacin patch

I will upload 26879-14.diff

#41 @seanchayes
15 months ago

  • Keywords has-patch added; needs-patch removed

#42 @extendwings
15 months ago

In 26879-15.diff, added some i18n improvements and fixed typo in wp-load.php.

#43 @ocean90
15 months ago

  • Focuses ui added
  • Keywords needs-screenshots added
  • Milestone changed from 4.5 to Future Release
  • Type changed from task (blessed) to enhancement

Moving out of 4.5 since this ticket has no owner.

#44 follow-up: @mrtortai
15 months ago

@extendwings, it looks like a new file, wp-includes/functions.php.orig was accidently included in #26879-15

@extendwings
15 months ago

Remove wp-includes/functions.php.orig

#45 in reply to: ↑ 44 @extendwings
15 months ago

Replying to mrtortai:

@extendwings, it looks like a new file, wp-includes/functions.php.orig was accidently included in #26879-15

Thank you! It's fixed in 26879-16.diff.

#46 @ankevanreeth
11 months ago

I'm with Hugo Baeta on the Contributors Day, and noticed it has been while since there was a screenshot posted. Would somebody mind uploading one so we can have a look at where we're at?
Thanks

This ticket was mentioned in Slack in #design by ankevanreeth. View the logs.


11 months ago

#48 @noam@…
11 months ago

  • Resolution set to invalid
  • Status changed from new to closed

Hello,

I think the core objectives of this ticket of a friendlier welcome installation process has now been completed in other tickets as of WP 4.5.3. I think this can now be closed.

#49 @ocean90
11 months ago

  • Resolution invalid deleted
  • Status changed from closed to reopened

@noamcleanforestsolutionscom I disagree, there are a few points which haven't been resolved yet.

#50 @mrtortai
10 months ago

Hi @extendwings, would you like to add some some screenshots of your patch which is the most current one, as @ankevanreeth mentioned? Thanks!

Note: See TracTickets for help on using tickets.