Make WordPress Core

Recent Updates Page 2 Toggle Comment Threads | Keyboard Shortcuts

  • Konstantin Obenland 6:14 pm on May 14, 2015 Permalink |
    Tags: ,   

    Dev Chat Summary, May 13 

    Agenda, Slack log.

    Editor (#)
    @azaozz has been looking at the “WordPress integration” parts the last couple of days, a lot of things that can be improved there. It removes some of the oddities, like running the post content through wpautop() before outputting it in the textarea, but only when TinyMCE is expected to be loaded, etc. @iseulde is working on the mobile toolbar and is hopeful she can get a patch ready this week. By next week’s meeting they want to have the mobile toolbar working (except in iOS), as well as #31655, #30949, and maybe #31441 in.

    Admin UI (#)
    @helen has largely been working on prepping things (tickets, examples, links, etc.) for Thursday’s UI meeting. More about the meeting (including agenda) can be found here: https://make.wordpress.org/core/2015/05/11/weekly-core-ui-meetings-for-4-3/

    Network Admin UI (#)
    Recap of Multisite office hours: https://make.wordpress.org/core/2015/05/12/multisite-office-hours-recap-may-12-2015/
    Things they want to have done by next week:

    • Mockups for the Edit Site / Add New Site improvements by @hugobaeta.
    • Having more flows posted to Make Flow for the network admin, via @sofiarose @kraft, and @ubernaut.
    • Get some decent progress on `WP_Site` and `WP_Network` with @jjj.

    Partial Refresh (#)
    Weston hopes to add initial integration between Menu Customizer and Partial Refresh this weekend. Due to client projects he’ll have to work on Concurrency _concurrently_ with Partial Refresh so he doesn’t hold up Menu Customizer. By next week Partial Refresh should be abstracted enough for the Menu Customizer to work with.

    Menu Customizer (#)
    @voldemortensen, @celloexpressions
    Now that it’s object-oriented they’re ready to start ramping up work. They’ll be going through github issues and come up with the next milestone for possibly the end of the week. By next week they’re planning on getting lazy-loading of both all menu item controls and the add-menu-item panel done, as well as better error handling for duplicate menu names and the like.

    Better Passwords (#)
    By next week, Mark wants a HTML, CSS, JS working demo of the password setting UI, and tickets for that and all other items on their hitlist. If there’s time beyond that, they could knock off one of the easier ones like notifying users of their password/e-mail changes.

    Accessibility component update (#)
    There’s been a ton of work done on the List Table class and associated areas. Joe has a set of 10 tickets with patches that he’d like to see committed by next week: #32150, #32254, #32255, #32028, #32152, #32147, #32189, #31654, #32253, #32170.

    Build tools component update (#)
    QUnit update seems to have gone off without a hitch. There are 7 npm dependencies that need to be updated. 6 are ready to go. grunt-sass needs a bit more digging in. This week, @jorbin is going to update the build tools roadmap he wrote up after WCSF and then pester a lead (likely @helen) to give it a read so that it can finally be published.
    Not exactly build related, but test related: Bug scrub identified that we don’t have any tests for nav menus, especially around the classes we add. @johnbillion has agreed to write some tests there so that we can fix all the bugs around that.

    Favicons (#)
    Support for managing favicons seems like a rudimentary thing, and its absence in core does seem odd to some. We still need plugins to handle favicon and other media icons in the admin, there is currently no good way for users to do that. We’ve been talking about adding support for a favicon manager for a long time ( #16434 ), let’s make 4.3 the release that finally adds it. @johnbillion volunteered to lead the feature for 4.3, with help from @brandondove, @kraftbj, @sofiarose, and possibly @dh-shredder.

    Next chat will be on May 20, 2000 UTC

  • Jeremy Felt 11:22 pm on May 12, 2015 Permalink |

    Multisite Office Hours Recap (May 12, 2015) 

    Multisite office hours are held every Tuesday at 20:00 UTC in #core-multisite.

    4.3 Release Objectives

    Our objectives for 4.3 can be split between UI/UX and back-end core. Here’s what we’re working on along with who is assigned or expressed interest in the past.

    Network Admin UI:

    1. Capture mobile flows and find areas to improve. @sofiarose, @kraftbj, @ubernaut
      • See last week’s office hours recap for a list of flows we’d like to capture
      • @hugobaeta has posted some desktop flow
      • This objective will likely mirror some of what the Admin UI group is doing. We’ll know more about individual opportunities as we dive in deeper.
    2. Combine scheme/domain/path in Add New Site and Edit Site workflows. @hugobaeta
      • When adding a new site, you should be able to just type the site’s new address without worrying about where to put each of the individual parts. https://wordpress.org should split into a scheme of https, domain of wordpress.org, and path of /
      • If an admin email is added that does not belong to an existing user, a user will be created with the site’s name and the user’s email address. There should be an opportunity to provide the user’s username and email in this scenario.
      • Related tickets: #22383, #31240, #14172, #14215
      • @hugobaeta will be working on some mock-ups
    3. Improvement of network upgrade workflow (ajaxify)
      • The current network upgrade process cycles through sites 5 at a time and processes the database upgrades. After each set of 5, the page refreshes and the next 5 are loaded. If one encounters an error, the entire process is stopped to await manual interaction. This should be something handled nicely via ajax.
      • Related tickets: #11869, #18292, #22589, #24922, #26056, #31405
      • @boren has posted a Mac/Chrome network upgrade flow

    Multisite core:

    1. Provide validation for domains, paths, emails. @boonebgorges, @johnbillion, @jeremyfelt
      • The combined scheme/domain/path objective above relies on the validation of domains, paths, and emails. There are several quirky restrictions in multisite that would be nice to clear up. The first step is to establish validation functions so that we can write tests and then change the results as needed.
      • Related tickets: #17397, #18777, #20019, #19724, #21994, #15936, #16126, #17904, #26784
    2. Introduce WP_Site, WP_Network, WP_Site_Query, WP_Network_Query. @johnjamesjacoby, @earnjam, @rmccue, @jeremyfelt

    If you’re interested in your name being attached to one of these objectives, please leave a comment here or a ping in #core-multisite.

    There may be room for more, or reason to swap one of these with something else once we start progressing. Let’s keep the list about this size for now so that we have something consumable. We’ll continue to revisit these objectives weekly throughout the cycle.

  • Konstantin Obenland 10:25 pm on May 12, 2015 Permalink |
    Tags: ,   

    Devchat Agenda for May 13 

    Here’s the agenda for tomorrow’s Dev Chat in the #core channel on Slack.

    Time/Date: May 13 2015 20:00 UTC:

    1. Feature Updates
      1. Editor – @azaozz / @iseulde
      2. Admin UI – @helen
      3. Multisite Admin UI – @jeremyfelt (if available)
      4. Partial Refresh – @westonruter
      5. Menu Customizer – @celloexpressions / @westonruter / @voldemortensen
      6. Passwords – @markjaquith
    2. Component Updates
      1. Accessibility – @joedolson
      2. Build tools – @jorbin
    3. Site Icon feature proposal – @obenland
    4. Open Floor – Looking for dev feedback on a ticket? Use this part of the meeting to let us know!

    Recommended reading:

    • Nick Halsey 3:09 pm on May 13, 2015 Permalink | Log in to Reply

      I can’t make the meeting, but regarding site icons, if that feature does happen it should really go in the Customizer. Specifically, the “Site Title & Tagline” section should be renamed to something like “Site Identity” and icons should be added there after the two existing options. Seeing as those options are all used in browser contexts (and usually, but not always in the theme for title & tagline). In the process all three options should be previewed in the browser as well as the Customizer preview, at least as well as we can (actually site title and tagline are currently previewed whenever a refresh is triggered, but many themes postMessage those, so we may want to find a way to do it directly with JS).

      Also, we should work out a way to implement the RSS feed links that can be specified for Windows 8.1 tiles alongside the various site icons that are used in that context so that all WordPress sites get automatic live tiles out of the box. See https://wordpress.org/plugins/custom-windows-pinned-tiles/. A filter to change the post type that it pulls would be nice too.

  • Daniel Bachhuber 11:41 pm on May 11, 2015 Permalink |
    Tags: , ,   

    Shortcake (Shortcode UI) chat summary – May 11th, 2015 

    Present: @danielbachhuber, @matth_eu, @goldenapples

    • Fusion pushed Image Shortcake to production today. It’s a plugin that uses Shortcake to replace with [img]. The biggest outstanding implementation issue is aligning an image left or write with text wrap. @goldenapples will continue to explore in Shortcake.
    • We’d like users to be able to edit shortcode attributes with a rich-text editor. However, core doesn’t easily support this use-case. For now, it looks like we’ll transparently encode and decode attributes with HTML values. @matth_eu will create a core ticket see how we can make this less of a hack.
    • We’re still looking to ship v0.4.0 on or around June 9th. Enhancements will be landing in the next couple of weeks so we can have a week or two of soaking before publishing to WordPress.org.

    Logs: https://wordpress.slack.com/archives/feature-shortcode/p1431371317000011

    Next chat: same time and place

    • Pat Hawks 11:57 pm on May 11, 2015 Permalink | Log in to Reply

      Replace *what* with `[img]`?

    • goldenapples 12:34 am on May 12, 2015 Permalink | Log in to Reply

      Replace `` tags or `` shortcodes inserted through the WP Editor using the *Add Media* function.

    • Jon Brown 1:49 am on May 12, 2015 Permalink | Log in to Reply

      As much as I’ve _long_ advocated for some sort of intelligent image object/element that themes & plugins could affect the markup on, shortcodes for this just feels wrong…. I’ll certainly be testing it, and am excited at the possibility, just skeptical that anything shortcode based is a reliable future theme change proof option.

  • Mark Jaquith 10:07 pm on May 11, 2015 Permalink |
    Tags: , passwords   

    The Plan for Passwords 

    For the 4.3 release, I’m leading the group working on passwords. We had a chat today, and here is our plan:

    Re-work password choosing/changing UI

    This has four main points:

    1. Default to generating a password for the user — if they want to choose their own password, they can, but the default should be that we generate a secure one for them.
    2. Default to showing the password input as plain text — to reduce typos, eliminate the second “confirmation”, and show them the password we’ve generated.
    3. In case of manual password entry, help them choose a better password — instead of just showing them how strong/weak it is, help them make it strong (“keep going… make your password longer!”).
    4. Make them jump through an “are you sure?” hoop to set a weak password.

    We like the WordPress.com UI, and think we can derive some inspiration from that. Also, some work has already been done on #24633, which we could use as a starting point.

    No manual or e-mailed passwords for creating other users

    When creating an account for someone in WordPress, this is a bad time to let the user-creator pick a password. First, we’re risking that it’s weak, but even if it isn’t weak, it isn’t going to memorable for the actual user who will own the account. In this case, we should just generate a password, and send the user a password view/reset link.

    Upon password reset, generate new password, and fill it in

    When a password reset link is visited, we should set a new random password, log them in, and offer to show them the new password. Again, the idea is to discourage weak human-created passwords. They could still go in and choose a new one, but by default they’ll be getting a secure, random one.

    Password reset links should expire

    Besides being one-use, password reset links should expire after a short period of time.

    Users should be notified of password/e-mail changes

    If your password changes, or if you update the e-mail address on your account, that should generate an informational e-mail. (e.g. “if you made this change, then all is good”). In the case of the e-mail changing, the e-mail should go to the old address. This will prevent attackers from silently using XSS/CSRF to take ownership of accounts. There will be a record, now.

    • daveshine (David Decker) 10:15 pm on May 11, 2015 Permalink | Log in to Reply

      Sounds all good – go for it! :-)

    • Mike Hansen 10:15 pm on May 11, 2015 Permalink | Log in to Reply

      I really like #3.

      • Eric Andrew Lewis 1:36 am on May 12, 2015 Permalink | Log in to Reply

        Offering users tips on how to make a password stronger can help.

        The explicit method mentioned (“make your password longer!”) isn’t a sure-shot. Adding one word onto another word won’t add much more security. Adding more randomized bits will.

        e.g. Comparing zxcvbn crack times: “word” = instant. “word99″ = 3 minutes. “wordpress” = instant.

        • Flex Perception 12:47 pm on May 12, 2015 Permalink | Log in to Reply

          UI Proposal/Idea

          It would be cool if there was an explanation provided, for example, the user starts typing the password “pas” …

          > It’s important not to use phrases that are easily guessed, such as “password” … can we start over?

          User starts over… “jack” …

          > Getting better! We do require punctuation such as a special character. These characters are “!@#$%^&*()-_=+~`.?/:;{[}]” on your keyboard. Your password will be stronger by inserting these characters.

          Ok, so user types “jack50″ …

          > Great! You’re almost there, make sure to use lower & upper case letters, and we do require that your password be at least 8 characters long. Keep going, we have faith in you!

          User keeps going… “jack50NUI” …

          > Awesome! All you need now is a special character and your password will be Medium-Strong. For a strong password, try following the instructions above to create a longer password.

          User types more characters … “jack50NUI>?”

          > Your password is now strong and your user account can be created. Please take note of your password in a secure location.

        • Bernhard Kau 1:25 pm on May 12, 2015 Permalink | Log in to Reply

          No one replied with the comic, yet? :)

          Here it comes: https://xkcd.com/936/

          Longer is usually better than using more characters. Escpecially using common substitutions or symbol won’t improve security.

          So a password like “w0rdpr3$$” is less secure (entropy of 35.8 bits) than something like “thisismyshinyblog” (entropy of 65.6 bits).

        • Mark Jaquith 8:09 pm on May 13, 2015 Permalink | Log in to Reply

          But I think we can tell, from zxcvbn why the crack time is low. Like, when it IS due to length.

    • Doug Wollison 10:21 pm on May 11, 2015 Permalink | Log in to Reply

      Might be jumping the gun here, but I have to point out some potential issues with #2.

      I’ve done this on projects in the past and it’s backfired (even after the client has heard and approved the concept). First off, layman users aren’t at all accustomed to it, and will probably think something broken (some may even think the site is insecure because the password isn’t masked; it’s happened). Second, there’s the rare but embarrassing use case of someone demonstrating the signup process to others and the viewers seeing the password being used by the demonstrator, which could be bad if they use one of their usual passwords (again, it’s happened).

      Obviously showing the generated password is fine, but I think you’d have to stick to just an opt-in for unmasking the password, and of course add a filter to force enable that feature for developers.

      • Brandon Kraft 10:36 pm on May 11, 2015 Permalink | Log in to Reply

        WP.com hides it, but provides an option to reveal. Newer versions of IE apparently does this too.

        WP.com example: https://signup.wordpress.com/signup/?user=1

        • Doug Wollison 11:20 pm on May 11, 2015 Permalink | Log in to Reply

          I’m wondering if it’s worth still showing the confirm field when they don’t bother to unmask the password to check; the whole point is to avoid people using a mistyped password during signup after all.

        • Eric Binnion 11:34 pm on May 11, 2015 Permalink | Log in to Reply

          On https://wordpress.com/me/security, WP.com does show the generated password by default.

          There were some opinions on either side, but we opted to go with showing the password for a large increase in usability.

      • Bernhard Kau 1:35 pm on May 12, 2015 Permalink | Log in to Reply

        I also dislike the idea of showing the new password by default. Having a way to show the hidden password (preferable only while hovering, pressing a button and not as a toggle), might be useful.

      • Greg Ichneumon Brown 10:07 pm on May 12, 2015 Permalink | Log in to Reply

        Etsy also got some interesting results due to interactions with autocorrect in browsers (esp on mobile) when they A/B tested showing passwords. That was for login, but there may be similar cases to think about.

        Video describing that here: https://youtu.be/0dVIjWTI_A0?t=1303

      • xjamesb 10:36 am on May 22, 2015 Permalink | Log in to Reply

        I have done government security work in the past and I find the idea of showing plain text passwords by default surprising.

        The process of issuing credentials is called “registration”. It is best practice for registration to be performed on a secure device in secure location and for strong credentials to be created.

        In the typical WordPress scenario we cannot trust the device or location. For example, the user may be in an internet cafe using a computer that has a screen-grabber installed, with someone shoulder surfing them under a CCTV camera.

        It is for this reason that “secure by default” systems do not show plain text passwords. My preference is that WordPress remains secure by default in this context.

        I think that WordPress has a great opportunity to move into the Enterprise Application space but this will be killed off pretty quickly if security types like me say “they show plain text passwords – doh!”. For this reason I strongly urge that a masked password option is retained even if it is not the default.

    • David Angel 11:33 pm on May 11, 2015 Permalink | Log in to Reply

      These all sound like good changes. I work in an open office environment, so I think an option to hide the password might be nice for some people.

    • schmoo2x 11:33 pm on May 11, 2015 Permalink | Log in to Reply

      My $0.02 – it would be VERY helpful if there was a “force user to change password on login” flow, a la Google Apps. Especially when creating new users, it’s a way to make sure that the email has been changed from a “temp” password. Far too often to I see my users searching their email for their setup email and copy / pasting that PW into WordPress to log in.

      • Michael Aronoff 1:22 pm on May 12, 2015 Permalink | Log in to Reply

        I want to add my 2 cents (whoo up to 4!) on this point.

        I add accounts for VERY inexperienced users. I develop a website for a client and then create an account for them when I hand it over. Making them jump through extra hoops will be a non-started for many of them which means this will just require many more aggravation steps for me as the developer.

        As an example if you require new users to login to create their password the actual steps will be more like this:
        1. Create new account with my own secondary email account.
        2. Get login link and then create password for the new user account.
        3. Change the email address for the new account to that of the “actual” new user.
        4. Now I can email the client the full login details

        I believe that developers should still be able to create accounts for new users without making too many extra hoops to jump through.

        I like the idea of extra security but I think that would be better served with longer password length or a visual clue.

        Oh I just had a good idea. Why not use the site logo as a sitekey type visual clue? It should appear on the login screen so there are no extra steps. But it could be randomly swapped with other images and simply be a question such as “is the image below your site logo”? or something like that.

        • schmoo2x 6:29 pm on May 14, 2015 Permalink | Log in to Reply

          I should be clear and say that I don’t think it should be *required*, but an easy-to-use option built into core.

          Either way, I’m not sure how being asked to pick a new password right away when you log in for the first time is that large a burden – and for many users, it’s less of a burden than enforcing truly strong passwords.

          Let’s not forget that anything sent via email should be considered compromised, since email is transmitted in plaintext. If we’re not enforcing a password reset upon logging in, the option to have the password emailed to the user should come with a warning for those who are less aware of that reality.

          The flow could go like this:

          1. Admin creates user with generated password, checks “change password on next login” box.
          2. User receives email with user / pass
          3. User logs in with user / pass
          4. WP displays PW reset screen (just two fields, PW and Retype PW)
          5. User is redirected to page, authenticated.

          This is the same flow that Google Apps uses, as well as many other apps I’m aware of. We could also just skip step 2 altogether, and have that initial email be a one-time-use link to create the password (similar to PW Reset emails).

      • michaelkturk 3:17 pm on May 12, 2015 Permalink | Log in to Reply

        There are a number of plugins for forcing a change or expiring passwords. We like this one. https://wordpress.org/plugins/force-password-change/

      • schmoo2x 6:39 pm on May 14, 2015 Permalink | Log in to Reply

        Re-reading the original post, instead of my “force PW change” idea, +1 for sending a password reset link upon user account creation. This is a great way to handle the issue of emailing a user their new password, and risking their account to compromise.

    • MRWweb 11:58 pm on May 11, 2015 Permalink | Log in to Reply

      Worth logging the very recent Nielsen Norman Group article on this: http://www.nngroup.com/articles/password-creation/

      They recommend a show/hide button for #2 as some other people are advocating.

      I also imagine that possibly using the “password” input type and trying to polyfill missing features may be a nice progressive-enhancey / future proof (right…). If going that route, also relevant are:

    • Arnan de Gans 12:25 am on May 12, 2015 Permalink | Log in to Reply

      What about existing accounts?

    • pembo13 1:07 am on May 12, 2015 Permalink | Log in to Reply

      This all seems to rely heavily on each WordPress install being able to reliably send email. What happen’s when that’s not the case?

    • Ozh 6:01 am on May 12, 2015 Permalink | Log in to Reply

      An idea could be to pimp use of password managers a la 1password keepass etc… Generating a strong un-memorable password like WP.com does only makes sense if you’re using one, and Average Joe or my mom have no clue about such an option

    • Anton Timmermans 6:09 am on May 12, 2015 Permalink | Log in to Reply

      Have you thought about internationalizing the password meter, currently it is completely oblivious to different languages. For example “wachtwoord” is seen as semi secure but it’s a direct translation of “password” in dutch.

      To internationalize the meter it would probably require changes to zxcvbn, but WordPress has done things like these in the past.

      • Aaron Jorbin 8:38 pm on May 13, 2015 Permalink | Log in to Reply

        We wouldn’t need to make any changes to zxcvbn, we can use the user_inputs variable to add to the dictionary. I think the biggest challange is translating a dictionary and ensuring that performance isn’t negativly impacted by adding in 100,000 additional words. The current dictionary is:

        “the 10k password list is from Burnett, released in 2011.

        Frequency-ranked names and surnames come from the freely available 2000 US Census. To help zxcvbn not crash ie7, I cut off the surname dictionary, which has a long tail, at the 80th percentile (meaning 80% of Americans have one of the surnames in the list). Common first names include the 90th percentile.

        The 40k frequency list of English words comes from a project on Wiktionary, which counted about 29M words across US television and movies. My hunch is that of all the lists I could find online, television and movie scripts will capture popular usage (and hence likely words used in passwords) better than other sources of English, but this is an untested hypothesis. The list is a bit dated; for example, Frasier is the 824th most common word.” – https://blogs.dropbox.com/tech/2012/04/zxcvbn-realistic-password-strength-estimation/

        Every language would need to come up with there own dictionary as I don’t think the translation of smith (a common American surname) is nearly as important as the common surnames in other nations.

        Technically, I think the only piece we would need to worry about is older browsers dealing with really really large objects.

    • Benjamin Pick 6:24 am on May 12, 2015 Permalink | Log in to Reply

      Love these changes.

      Except “Password reset links should expire”. This makes sense for the current use case (I forgot my password to I send to myself a reset link email) but not for the new one (An admin has created a user for me and I didn’t do anything about it, now it only shows “link has expired”):

      In my experience when I create user accounts for my clients, often they won’t do anything about it for days. So they would call back and say “the link you sent me doesn’t work anymore, can you send me a new one”.

      To avoid this maybe it would be enough to not only say “link has expired”, but also: “send new password reset link to the same email adress now?”

      • Mark Jaquith 8:15 pm on May 13, 2015 Permalink | Log in to Reply

        Good idea! Could just do it automatically, even. “That link has expired. We sent you a new one just now. Go click it!”

    • MichaelApproved 11:18 am on May 12, 2015 Permalink | Log in to Reply

      > No manual or e-mailed passwords for creating other users
      > In this case, we should just generate a password, and send the user a password view/reset link.

      The best part about this is that email accounts will no longer be a treasure trove of account creation emails. If a user’s email is compromised, the hacker can look through old emails to find out account information for WordPress created user accounts.

      Of course, users should delete these emails to prevent this kind of attack but this doesn’t always happen. By sending an expiring link, it eliminates this weakness in the account creation process.

    • Bernhard Kau 1:50 pm on May 12, 2015 Permalink | Log in to Reply

      My opinions on these topics:

      Great ideas:

      • User notification (to old email address)
      • Password reset links should expire

      I really don’t like the idea of showing them the randomly created password. I would stick with giving them the change to set a personal password with to password fields. The strengh should be displayed as a meter.

      For generated password: Never send them per email, never show them to the user, as they might just copy them into their password safe apps and so the valid plain text password is still laying around in their inbox.

      Why not send them an email with the ability to set a new password. This reset link would expire after the first visit after a very short amount of time.

      For existing user, the admin could also just click a link which will send them such an email. New users would receive such an email automatically.

      Using these mechanism, there will never be a plain text password in an email or shown on the screen, unless they press a button to reveal the password, but this is not really necessary, if you have to retype the password anyways, which should be done, as even showing a password does not help against typos.

    • brucedwilliams 3:20 pm on May 12, 2015 Permalink | Log in to Reply

      I would advocate for a way to impose a “minimum quality” for passwords. Perhaps that could use the current password quality indicator code, but as Anton points out there are issues with that. However, I think it is generally better for users to enter their own password, subject to some minimum standards, than to auto-generate one for them.

    • michaelkturk 3:20 pm on May 12, 2015 Permalink | Log in to Reply

      We synch users with a CRM by pulling in new records, auto-generating a password, and emailing the user the account credentials. I assume the only considerations would be either a) using the core function to generate the new password, or b) ensuring our generated passwords are compliant with the minimum structure this new password process requires.

      Would that be right? Or would this require some sort of additional verification?

    • perezbox 3:37 pm on May 12, 2015 Permalink | Log in to Reply

      Curious, probably beyond password choosing, but while you’re looking at reworking passwords:

      1 – Any discussions on TFA / MFA? The argument used to be that it didn’t belong in core, yet so many applications are making it standard these days. Should WordPress?

      2 – Any discussions on introducing password review periods? 1 month / 3 months / 6 months reset policies? Especially effective post-hack and as part of a good overarching security policy.

      Some observations / thoughts:

      1 – Think it’s a great idea, but I wonder what the impact on the enduser will be. End users are stubborn creatures. Anything that disturbs their experience is cause enough to revolt. I mention this not because of the password generation, but the password storage. Where do they put it? Could this be a good time to introduce the idea of a password manager for them? If they don’t have an easy way to remember, or store the password, they’ll just forget it, use the reset link next time they try to log in and we’re back to square one. We’ve just kicked the preverbal can down the street.

      2 – If you generate the password, then there isn’t the need for verification so that’s simple enough. If the user selects their own password though, I’d be curious to see what happens if you remove the verification. Even showing it plain text by default, I can still feel a lot of need for a verification feature. Maybe that’s just an old-school mindset, not sure. There is the shoulder surfing concern, but then again if you’re doing a random generated one, unless someone is taking pictures over your shoulder, you’re probably fine.

      3 / 4 – Both talking to the creation process, makes a lot of sense. “You sure you want to use this weak password? ….” maybe add some statistics that come from weak passwords and make going to the next step difficult. Think of how Google blacklists, you have to click on advanced and proceed. They make it hard to the person proceed. Not sure if that’d be too aggressive.

      Anyway, nice thoughts..

      • Ipstenu (Mika Epstein) 6:03 pm on May 12, 2015 Permalink | Log in to Reply

        As much as I want to enforce TFA, I think it’s still too ‘complex’ for the average user, in the case where they lose or upgrade their device. It’s hard enough to reset tfa for WordPress.com, imagine how to walk the average skilled user through it for self hosted.

        We should suggest password managers in general, but I think we’re still a couple years out for TFA Maybe suggest a plugin for it? I think this would need to rock the lobster as a ‘feature plugin’ first before we bake it into core.

    • tomdxw 4:33 pm on May 12, 2015 Permalink | Log in to Reply

      IIRC generated passwords are currently a random mixture of letters and numbers, right? Are there any plans on switching to a method like diceware which generates something that could be remembered by a human?

    • Dave Navarro, Jr. 4:52 pm on May 12, 2015 Permalink | Log in to Reply

      My biggest problem with passwords right now is that the “weak/strong” formula is flawed. I have passwords that I’ve used which show “very strong” on other sites that show as weak in WordPress. So the method of calculating a weak/strong password needs to be re-examined.

      • Samuel Wood (Otto) 5:46 pm on May 12, 2015 Permalink | Log in to Reply

        Dave: WordPress switched from a “simple” method of determining weak/strong to using a much more complex and detailed method. The zxcvbn library was created by Dropbox and uses a more realistic attack method to determine strength.

        In other words, your passwords are probably weak, regardless of what some other services say. The library WordPress is using is generally better. Not perfect, but nothing is perfect.

        More on zxcvbn: https://blogs.dropbox.com/tech/2012/04/zxcvbn-realistic-password-strength-estimation/

        • Dave Navarro, Jr. 8:28 pm on May 12, 2015 Permalink | Log in to Reply

          I just tried two passwords that WordPress says are weak in cPanel and they both are strong there. Also, both passwords are ISO compliant. So I think Dropbox and WordPress are overly protective.

          • Samuel Wood (Otto) 1:09 am on May 13, 2015 Permalink | Log in to Reply

            • Dave Navarro, Jr. 2:28 pm on May 13, 2015 Permalink

              Still doesn’t disprove my original point… The method in WordPress is overly aggressive in its formula. Which isn’t horrible, better passwords are better. But it freaks people out when you are ALWAYS telling them that the sky is falling, when in fact, it’s not.

              In any case, it’s pointless to argue about it… Obviously the code is here to stay and I can just disable the “meter” to satisfy my needs.

            • Samuel Wood (Otto) 3:24 pm on May 13, 2015 Permalink

              Dave: We’re just going to have to disagree on “overly aggressive”. I would say that the other strength-indicators you’re comparing zxcvbn to are “overly permissive”. Dictionary attacks are a real thing, and simplistic bit-strength indicators are essentially useless.

        • Dave Navarro, Jr. 8:31 pm on May 12, 2015 Permalink | Log in to Reply

          Also, as others have mentioned, as long as there are hooks to modify/disable the new features, I’m all good. I have NEVER had a WordPress site compromised by someone guessing a user’s password. But I’ve had numerous issues with sites being compromised by piss poor overly complicated code in core or in a plugin.

    • Samuel Wood (Otto) 5:42 pm on May 12, 2015 Permalink | Log in to Reply

      On the topic of supporting Two Factor Authentication:

      This should be supported by core and made easily pluggable. We don’t need to build in the actual security methodology behind it, but the login-flow process should be something that can be added by a plugin.

      And while we don’t need to build in the actual security mechanisms themselves, we could, as an example, go ahead and create the standard TOTP mechanism (RFC 6238) as used by Google Authenticator and several other existing systems. Either as a plugin, or in core. I’d be happy to contribute to this part.

      But the important part is that the login flow for this should exist without the plugin having to resort to weird hacks to add in those extra screens and user-profile settings. That part should be reasonably standardized and generalized to support any form of extra authentication, whether it be two-factor-by-email, two-factor-by-TXT-message, or two-factor-by-device-code.

    • DeBAAT 10:42 am on May 13, 2015 Permalink | Log in to Reply

      Could we use the nonce mechanism for expiration of the reset link?

    • stk_jj 4:42 pm on May 13, 2015 Permalink | Log in to Reply

      I like the idea on showing a »crack-time« for a self-chosen password. More than displaying random generated in plain text. Concerning TFA I would recommend a real simple solution (without engaging any third-party supplier) like Sergej Müller hacked last WordCamp Hamburg: https://github.com/sergejmueller/2-Step-Verification

    • Peter Cralen 5:44 pm on May 13, 2015 Permalink | Log in to Reply

      It would be great, if whole function is as simple as possible for users. The best it would be just email and user chosen password. Who will need something more secure, something extra can always extend it with plugins.
      Keep in mind millions of users, normal people who register/login to websites and they never hear something about two factor, strong password …

    • Chuck Reynolds 7:49 pm on May 13, 2015 Permalink | Log in to Reply

      these are all great. long overdue but I understand.

    • eatingrules 1:48 pm on May 14, 2015 Permalink | Log in to Reply

      VERY glad to see you’re going to stop offering the option to send new users their passwords via email!

  • Helen Hou-Sandi 6:37 pm on May 11, 2015 Permalink |
    Tags: , , ,   

    Weekly core UI meetings for 4.3 

    Remember weekly UI chats? It’s been a couple years since they wound down, but I’d like to get them started again for at least the 4.3 cycle, as we have some efforts that are not specific to a given feature or component team. UI chats are also a great way for newer contributors to get involved, as there are often a number of smaller patches that can be made and committed quickly. We’ll hold meetings each Thursday, starting this Thursday, May 14, 2015 13:00 UTC-4 in the #design channel in Slack. Updates will be posted here on Make/Core.

    For this week, let’s touch on these points:

    • Better responsive list tables.
    • Getting rid of media-new.php.
    • Screen-by-screen sweep for low-hanging fruit on small screens and touch devices (e.g. inconsistent spacing or font sizes at a given media query point).
    • The state of the CSS roadmap.
    • Coverage for other working groups (passwords, network admin, editor, customizer, anything else?).
    • Bug gardening team (see the UI focus on Trac).
    • Open floor (sound off below ahead of time if you wish – remember that this is about admin UI).
  • Konstantin Obenland 5:06 pm on May 11, 2015 Permalink |
    Tags: ,   

    This week in 4.3: May 11 – 17 

    This is the jump-start post for the third week of the WordPress 4.3 release cycle.

    Core Meetings this week:

    4.3 Feature Chats this week:

    Notable updates from last week:

  • Konstantin Obenland 10:09 pm on May 7, 2015 Permalink |
    Tags: ,   

    Dev Chat Summary, May 6th 

    Agenda, Slack log.

    Editor (#)
    Spent last week to go over the things they want to work on. @iseulde will work on the mobile editor toolbar first. They’ll milestone tickets as they get patches. For posterity and everyone who wants to follow up, the Editor game plan for 4.3 can be found here: https://make.wordpress.org/core/2015/05/01/editor-wish-list-for-4-3/

    Admin UI (#)
    Not much to talk about yet as @helen was out last week and will be out for the next few days. She will schedule a meeting for next week, likely Thursday, May 14 1700 UTC. location to be determined.

    Network Admin UI (#)
    There was a good chat about NA UI on Tuesday. First steps are documenting pain points now and move forward with tickets, etc. Multisite chat summary: https://make.wordpress.org/core/2015/05/06/multisite-office-hours-recap-may-5-2015/

    Customizer (#)
    Noteworthy from Monday’s chat is that Menu Customizer was added to the 4.3 roadmap for the Customizer, while Transactions were taken off it. No other news besides that: https://make.wordpress.org/core/2015/05/04/customizer-chat-summary/

    Better Passwords (#)
    Weekly meetings are on Mondays at 1700 UTC in #core-passwords. Right now they’re throwing ideas around, by Monday @mark wants to have gone through that and have a make/core post that outlines the major goals for this release, so they can get to work.

    Accessibility component update (#)
    The accessibility team has spent a lot of time generating tickets for tabular data, based on user feedback gathered during the 4.2 cycle. It’s about 8 tickets right now, all prefixed with “List Table:”. They have also been focusing on establishing a new heading hierarchy for the admin. Resolving the H1 issue is fairly simple, but has broad impact across the admin; should probably get this in ASAP. It shouldn’t have much impact in normal usage, but e team is unsure what kinds of edge cases might be out there. There are two separate issues: implementing H1 across pages and addressing the hierarchy within pages; @joedolson suggested to handle just the primary H1 to start, then start looking at the internal issues.

    Build tools component update (#)
    Started upgrading dev dependencies and our version of QUnit. @jorbin will finish those updates this week. People will likely need to do some npm installs to ensure they have the up to date versions.

    Next chat will be on May 13, 2000 UTC

  • Konstantin Obenland 6:18 pm on May 6, 2015 Permalink |
    Tags: ,   

    Devchat Agenda for May 6 

    Here’s the agenda for today’s Dev Chat in the #core channel on Slack.

    A lot of people will be on traveling to LoopConf or the VIP Developer Workshop so I anticipate a rather short meeting.

    Time/Date: May 6 2015 20:00 UTC:

    1. Feature Updates
      1. Editor – @azaozz / @iseulde
      2. Admin UI – @helen (if available)
      3. Multisite Admin UI – @jeremyfelt (if available)
      4. Customizer – @westonruter
      5. Passwords – @mark (if available)
    2. Component Updates
      1. Accessibility – @joedolson
    3. Open Floor – Looking for dev feedback on a ticket? Use this part of the meeting to let us know!

    Recommend reading:

    • Ryan Boren 6:58 am on May 7, 2015 Permalink | Log in to Reply

      We have five feature teams. How about a feature team list along the lines of the one on the Feature Plugins Tracking page? I want a place to point contributors looking to help with a feature, beta testers in particular.

      • Samuel Sidler 1:56 pm on May 8, 2015 Permalink | Log in to Reply

        How is that different from the components page? A good example is the customize subcomponent, which includes the latest posts for the component as well.

        • Ryan Boren 10:57 pm on May 8, 2015 Permalink | Log in to Reply

          I forget the components pages exist until I’m reminded of them. They don’t have chat times or channels. There is nothing that associates the components pages to features and feature teams in 4.3. The top-level components page is not tailored to 4.3. Finding any information I care about requires drilling down through each component, once I figure out which components map to which feature. This assumes a lot of knowledge.

          One page that gives me background on 4.3 and shows me how to follow and help. A start: https://make.wordpress.org/core/4-3/

  • Jeremy Felt 3:27 pm on May 6, 2015 Permalink |

    Multisite Office Hours Recap (May 5, 2015) 

    Multisite office hours are held every Tuesday at 20:00UTC in #core-multisite.

    We had a lively conversation today around some of our objectives for the 4.3 cycle. The conversation was mostly focused around creating a visual record for the current network admin UI and then establishing our goals for moving that forward. @hugobaeta, @sofiarose, @ubenaut, and @kraftbj all volunteered to start capturing workflows for devices. There are a lot of good notes in #core-flow and examples of other visual records on make.wordpress.org/flow we can use as a launch point.

    Here’s an initial prioritized list of some common workflows. Please add and/or discuss in the comments. I’m likely missing many things. :)

    • Add a new user to a site when the user does not currently exist as a network user.
    • Add a new user to a site when the user does exist as a network user.
    • Install, enable, and then activate a theme for a single site on the network.
    • Install a theme and enable it for use on a network.
    • Install and then activate a plugin for use on a single site on the network.
    • Install and then network activate a plugin.
    • Setup multisite from scratch in a subdirectory configuration.
    • Setup multisite from scratch in a subdomain configuration.
    • Create a new site on the network.
    • Upgrade WordPress, including the network upgrade.
    • Update a plugin.
    • Update a theme.
    • Edit the domain/path for an existing site on the network.

    We briefly discussed the possible need for validating domains and paths that will arise from #22383 efforts. We need to gather a list of tickets that could benefit.

    And we just touched on how we might start working toward a future site switcher for core. This is something that would be excellent as a feature plugin for a future cycle, so if you’re interested—please speak up. Ideas are fun to pass around at this point.

    Finally, I’m on the hook for ticket gathering before next week’s office hours so that we can start to prioritize a list of UI (and other) improvements. At the same time, we’ll start finding more and more to fix from the viz-rec process and from general admin UI improvements.

    I’ll start that list of tickets in the comments here and then repackage it in a post for next week. Please add any tickets to the comments that you see as useful for network admin UI improvements.

    Thanks to everyone for participating!

    Chat log

compose new post
next post/next comment
previous post/previous comment
show/hide comments
go to top
go to login
show/hide help
shift + esc
Skip to toolbar