[wp-trac] [WordPress Trac] #26879: Hello, new users. Here is an Error.

[WordPress Trac]

#26879: Hello, new users. Here is an Error.
-------------------------------------------------+------------------
 Reporter:  mrtortai                             |       Owner:
     Type:  enhancement                          |      Status:  new
 Priority:  normal                               |   Milestone:  3.9
Component:  Upgrade/Install                      |     Version:  3.0
 Severity:  normal                               |  Resolution:
 Keywords:  has-patch 2nd-opinion docs-feedback  |
-------------------------------------------------+------------------

Comment (by mrtortai):

 > 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 visually 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. There correct place for these seems to be, "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!

--
Ticket URL: <https://core.trac.wordpress.org/ticket/26879#comment:7>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform