WordPress.org

Make WordPress Core

Updates from Mark Jaquith Toggle Comment Threads | Keyboard Shortcuts

  • Mark Jaquith 11:54 pm on July 28, 2015 Permalink |
    Tags: , ,   

    Passwords in 4.3: Strong by Default 

    One of the development efforts in the WordPress 4.3 cycle was improving the way that passwords are chosen and changed. Before, people had to start from scratch when choosing a password. They were presented with an empty box, and had to use a really terrible tool for generating secure passwords: the human brain.

    Here’s how things look now, as we approach 4.3’s release candidate…

    Screen Shot

    And when you click that button…

    Screen Shot

    You start out with a strong password. And if you like, you can just accept that. Most modern browsers will offer to remember it for you (as well as password managers like 1Password and LastPass). Or, you could go old school and write it on a sticky note. Hey: anything is better than choosing “letmein”!

    You can, of course, click into the field and edit it. But now the password strength meter is better integrated with the field. Things start to look dire as you go your own way.

    Screen Shot

    That red seems to signal danger. And hey, look, below. This password is SO BAD that WordPress wants to make extra sure you know you’re doing something monstrously foolhardy.

    If you’re in a public location, you can hide your password, to prevent people from peeking over your shoulder.

    Screen Shot

    This new interface is also integrated into the Add New User screen. By default, we won’t even reveal the password. We’ll just send the user a reset link.

    Screen Shot

    But if you’re in a non-email environment or would like to pass this password to the user in a secure method such as iMessage, Signal, or TextSecure, you can reveal it…

    Screen Shot

    The new interface can also be found on the password reset screen and the WordPress install screen. They all start you out with a long, random, unguessable password. Although WordPress isn’t stopping you from choosing terrible passwords, the default in 4.3 is that you get secure passwords, and making them less secure takes a bit of work.

    In addition to this new UI, we have also stopped e-mailing passwords, so valid passwords aren’t going to sit in your e-mail inbox, waiting for some future e-mail hacker to gain access. Password reset links now expire in 24 hours by default. And when your password or e-mail changes, we send you an e-mail (in the case of e-mail, to your old address), so if someone hijacks your browser session and changes those critical items, at least you’ll be aware that it happened, and you can take action. You can disable these e-mails via the send_pass_change_email and send_email_change_email filters (just have them return false).

    Huge thanks to everyone who contributed code, testing, UI, and thoughtful feedback on this feature!

     
    • Pippin Williamson 11:59 pm on July 28, 2015 Permalink | Log in to Reply

      Hurray!

    • Dylan Ryan 3:19 am on July 29, 2015 Permalink | Log in to Reply

      +1

    • Gary Jones 7:34 am on July 29, 2015 Permalink | Log in to Reply

      Excellent stuff. All of this is a real step forward. Thank you to all those who contributed.

      Is the code modular enough that it can be applied to the front-end (e.g. via a function call in a template), as part of a visitor sign-up / checkout with a registration process?

      • spivurno 10:55 am on July 29, 2015 Permalink | Log in to Reply

        Also interested in this answer.

      • Inggo 1:14 pm on July 29, 2015 Permalink | Log in to Reply

        Similarly interested in this as well.

      • John James Jacoby 2:05 pm on July 29, 2015 Permalink | Log in to Reply

        In my opinion, no; the code is not currently written to make it easy to pull into a template part.

        That said, the HTML and accompanying CSS & JS is very simple, and could be encapsulated relatively easily in a future release.

        Look for BuddyPress and bbPress to go this route soon, and contribute upstream where possible.

    • Gustavo Bordoni 7:52 am on July 29, 2015 Permalink | Log in to Reply

      What an Awesome update! Real good to see this to become a reality.

    • TobiasBg 7:57 am on July 29, 2015 Permalink | Log in to Reply

      Can I suggest to rename the filter `send_pass_change_email` to `send_password_change_email`?

    • Mario Peshev 8:40 am on July 29, 2015 Permalink | Log in to Reply

      That’s a great update, can’t wait to see it in the next major core update.

    • Minion 8:51 am on July 29, 2015 Permalink | Log in to Reply

      “stopped e-mailing passwords…”. I like that! So say if new user created, will the option “Send this password to the new user by email.” also contain link that expires in 24hours?

    • Collizo4sky 1:08 pm on July 29, 2015 Permalink | Log in to Reply

      Can’t wait to see this live. Great update.

    • John James Jacoby 2:11 pm on July 29, 2015 Permalink | Log in to Reply

      This is one of those small changes that will make a huge impact on the security of the web. Some users will be confused. Some admins will need to explain to their users why this is now a requirement. Someone will make a plugin to revert this back to the pre-4.3 experience. What matters is everyone will be safer and more secure from the start and going forward.

      Nice work, team!

    • Paradigm5h1f7 6:38 pm on July 29, 2015 Permalink | Log in to Reply

      I’m hoping that people will actually use this. From this – ” WordPress isn’t stopping you from choosing terrible passwords” – I assume that the worst offenders will continue using their one-password-for-everything… why not make it so the user cannot accept anything less than a strong password? Can the user still choose “letmein” ??

      Also wondering if there can be a way to recommend users get a trusted password manager. Unfortunately, although “Most modern browsers will offer to remember it for you…” – they also store the passwords in plain text so any malware can grab them. This is a long standing issue that Chrome refuses to fix…

      Just some thoughts. All in all, it’s a good step in the right direction, but maybe preaching to the choir too much. It does look good though, and reinforces that the onus is on users to be secure in their password management.

  • 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!

  • Mark Jaquith 5:57 am on November 11, 2014 Permalink
    Tags: ,   

    Focus v2 demo video 

    Here is the current state of the Focus v2 project, a re-think of Distraction Free Writing:

    I would like to propose that we immediately merge this into core for 4.1.

    Some of the bullet points:

    • Current Distraction Free Writing (DFW) interface is too much of a transition.
    • Current DFW doesn’t give you quick access to everything (you feel trapped in it).
    • Current DFW isn’t very discoverable.
    • New DFW (Focus v2) triggers on keyup (discoverable).
    • New DFW transition is seamless. Things you don’t need while typing just go away. Your scroll position is maintained. It’s the same editor, whereas before it was a separate one.
    • New DFW gives you instant access to all your meta boxes and everything else, with a wag of the mouse, a TAB press, or a tap.
    • Best of both worlds!

    Not mentioned in the video is that the old DFW button now is a disabling toggle for this mode. So it’s Auto/Off, instead of On/Off.

     
    • Ansel Taft 6:19 am on November 11, 2014 Permalink | Log in to Reply

      It looks grrrrrreat!

    • Andrew Ozz 6:29 am on November 11, 2014 Permalink | Log in to Reply

      Works great, lets merge!

    • Mickey Kay 6:32 am on November 11, 2014 Permalink | Log in to Reply

      Looks awesome. One suggestion would be to expand editor to full width. I realize this might cause more distractions with text wrapping changing on the transition, but it might be nice to try going full width and really taking advantage of ALL the real estate.

      • Michael Arestad 10:25 am on November 11, 2014 Permalink | Log in to Reply

        It’s super distracting if the field you start typing in moves at all. I would love it if there was later work done to ensure that the editor is always centered on the user’s screen.

      • Avryl 11:26 am on November 11, 2014 Permalink | Log in to Reply

        If the content is smaller than the editor (most cases), it doesn’t make any difference, you juts have more white on your page. If the content is larger than the editor it’s most likely more difficult to read and write something.

      • Timothy Bowers 2:49 pm on November 11, 2014 Permalink | Log in to Reply

        Ya it does look awesome.

        I too would personally love to either see the editor expand or at minimum centre, but I get how that might be distracting for some.

      • fredhead 3:07 pm on November 11, 2014 Permalink | Log in to Reply

        This definitely is an improvement. Maybe the option to make the editor full width while typing could be a future option and enhancement. It’s also true the left and right columns of the editing page are fixed width. Widening the browser window before you start writing expands the default editor width before the rest of the editing elements disappear, something not obvious in the video. The empty right column in the video looks wider than it is in most cases for me.

        I happen to like the current DFW scheme but would want to add the top buttons and the word count to that all white background. I didn’t mind clicking in/out. But this solution works for me.

    • Peter Luit 6:54 am on November 11, 2014 Permalink | Log in to Reply

      @Mickey: no full width (does not represent the actual display), but more focus on WYSIWYG, playing with typefaces etc.

      Still the editor does not represent the actual display of what is to be expected. The ‘preview’ button is an ‘in-between’ solution, but I would like to see a real WYSIWYG editor. So removing distractions with this feature is fine, but for me it is just a beginning of a complete new focus on the editor.

      • Avryl 11:21 am on November 11, 2014 Permalink | Log in to Reply

        There’s no way to do “real” WYSIWYG on the back-end, at least not with this UI. If you want a WYSIWYG editor, install a front-end editor plugin. The back-end editor is *not* a WYSIWYG editor, it’s a visual editor for HTML.

        • Ihor Vorotnov 9:18 pm on December 17, 2014 Permalink | Log in to Reply

          Just to make everything clear. Like you say, it’s a visual editor for HTML, but the look and feel can be changed to fit the front-end. There’s editor-style.css and add_editor_style() function which allows us to make our back-end editor look pretty close or even the same to what we see on the front-end. So, in fact it’s possible to achieve. But the way to do it is not really obvious and easy to do for non-devs.

    • Luke Carbis 6:56 am on November 11, 2014 Permalink | Log in to Reply

      +1

    • Hassan 7:33 am on November 11, 2014 Permalink | Log in to Reply

      I like it!
      Will there be an option to disable this though for those who might find it annoying? User-specific maybe?

      • Avryl 11:22 am on November 11, 2014 Permalink | Log in to Reply

        Yes, there already is. Just click the fullscreen button on the right and it will disable it for the current user.

    • Philip Arthur Moore 7:46 am on November 11, 2014 Permalink | Log in to Reply

      Goodness gracious this is nice.

    • SiamKreative 8:30 am on November 11, 2014 Permalink | Log in to Reply

      I never actually used the DFW mode so it’s a great news!

    • chzumbrunnen 8:32 am on November 11, 2014 Permalink | Log in to Reply

      Nice! Would kind of an opposite “forgiveness” be cool or do you think this would add distraction back?
      What I mean is: if you don’t write for a certain amount of time, bringing the metaboxes back.
      Probably, if someone needs it, he will move the mouse there but I thought maybe someone could miss it and not know where to search.

    • Ryan Hellyer 8:50 am on November 11, 2014 Permalink | Log in to Reply

      Am I the only one who doesn’t see the point in this? I assumed anything dedicated to distraction free writing would need to be opt-in and full-screen. The benefit I saw in the distraction free editor was that it was full-screen. Just hiding some admin Chrome doesn’t seem very useful to me.

      I’m sure I’ll get used to it once it’s baked into core though :)

      • Andrey "Rarst" Savchenko 8:59 am on November 11, 2014 Permalink | Log in to Reply

        The typical DFW formula includes opinionated enforcement of minimal environment, not just providing it. In that way current DFW is genuinely such.

        This feels more like solution to bulky admin interface than genuine DFW editor. It’s good in it’s own way, but more like Distraction Light, not Distraction free.

        PS I suppose can use browser’s functionality to get full screen part.

      • Dave Clements 3:43 pm on November 11, 2014 Permalink | Log in to Reply

        Nope, you sure aren’t. I’m really not seeing what all the fuss is about yet. Once it lands, I may come to love it, but I certainly don’t (yet) see it as a feature that I would want, need or use.

      • Mark Jaquith 6:24 pm on November 11, 2014 Permalink | Log in to Reply

        DFW was never full screen. It was full-ish window. Same as this. We’re height limited by the window, which we’re using to good effect in both. We’re width limited by $content_width anyway, so making the editor wider isn’t going to change anything (unless we get rid of the concept of $content_width limiting, which would be a big decision).

    • dimitris33 11:13 am on November 11, 2014 Permalink | Log in to Reply

      is this for 4.1?

    • mindctrl 1:48 pm on November 11, 2014 Permalink | Log in to Reply

      This is great work. Question: why does the menu bar on the left do a slide transition while everything else fades nicely? The slide is distracting and doesn’t feel right, and it doesn’t match what happens to the rest of the interface. Why can’t it fade like everything else?

      • davdebcom 2:15 pm on November 11, 2014 Permalink | Log in to Reply

        Agreed, fade out/in of menu bar seems less distracting than the current slide.

      • Mark Jaquith 6:26 pm on November 11, 2014 Permalink | Log in to Reply

        Because the fade was way more distracting. We all had the same instinct you did, and tried it two separate times. But because it starts almost-black and fades to almost-white, the “color distance” of the fade proved to be very distracting.

        Also, “sliding” is sort of a known paradigm with the menu, as it has the expand/contract feature that implies horizontal motion.

        • mindctrl 12:13 am on November 12, 2014 Permalink | Log in to Reply

          Interesting. Thanks for shedding some light on that.

        • Gary Jones 1:02 am on November 13, 2014 Permalink | Log in to Reply

          Was there any discussion about sliding the admin bar up, rather than just darkening the text (which is a third animation type happening at the same time as the slide left and fade)?

    • davdebcom 2:28 pm on November 11, 2014 Permalink | Log in to Reply

      1. In current DFW saving the article does not refresh the page, so you have almost infinite “CTRL Z” history which is pretty nice! I would really miss that in this new version. The video does not show how saving works now, but I assume it refreshes the page like the current post edit page?

      2. I actually liked that it was a transition to get into and out of DFW, because you make a conscious step to go into that writing mode. Maybe keep the current “real” DFW, and add these improvements as part of the non-DFW normal writing mode. Instead of replacing the current DFW, improve the current normal writing mode?

      • Mark Jaquith 6:29 pm on November 11, 2014 Permalink | Log in to Reply

        1. We had that in until recently, but (a) it wasn’t working correctly and (b) was slipped in without much discussion, and is kind of a big change on the main post screen, so should have real discussion. Maybe a separately investigated change?

        2. A lot of people just didn’t know about it, and a lot of people wanted to try it (and did), but then stopped using it because the transitions were so onerous.

      • Helen Hou-Sandi 9:27 pm on November 12, 2014 Permalink | Log in to Reply

        FWIW, cmd-S actually triggers an autosave. It’s not really exposed anywhere, and isn’t the same as the button, but could be of interest to you.

    • leemon 4:14 pm on November 11, 2014 Permalink | Log in to Reply

      Will we be able to toggle this feature off?

    • Michael Beil 5:26 pm on November 11, 2014 Permalink | Log in to Reply

      Interested to see where this pushes the editor in the future.

    • Matt Mullenweg 5:35 pm on November 11, 2014 Permalink | Log in to Reply

      How does this work and look on mobile?

      • Ryan Boren 6:05 pm on November 11, 2014 Permalink | Log in to Reply

        I wanted visual records showing post creation and edit from front page to published, with and without adding media and with and without focus turned on, for all devices. I’m doing a little touch device testing with the plugin version of Focus, and it seems to be properly disabled. The Focus button brings up the old DFW interface. Regardless, I personally wouldn’t let any feature plugin merge without visual records, especially a feature sitting at the heart of our most important flows.

        Using the editor is a bad experience on an iPad. That doesn’t appear to be the fault of Focus, but vizrecs are still needed. We should baseline this bad experience without Focus and then vizrec with Focus to make sure Focus isn’t making anything worse.

      • Mark Jaquith 6:31 pm on November 11, 2014 Permalink | Log in to Reply

        On mobile, you already have a full width editing experience, so this doesn’t affect mobile. But as Ryan says below, our mobile editing experience needs its own round of TLC.

        • Ryan Boren 6:32 pm on November 11, 2014 Permalink | Log in to Reply

          Saying it doesn’t count. Showing it with a visual record does. You know how little thought is given to mobile. Let’s change that.

          • Mark Jaquith 7:16 pm on November 11, 2014 Permalink | Log in to Reply

          • conualfy 9:26 pm on December 16, 2014 Permalink | Log in to Reply

            I speak for WP 4.0.2: Mobile needs a lot of work, I was trying to write one post on Firefox for Android and id was not nice at all. My main problem was selecting large texts (multiple “screens”), it lost my selection because of some strange autofocus (I guess). It worked a little better on Chrome for Android, but still not very easy to do this.

            Another thing to work on for mobile is that some top Admin Bar menus dissapear on mobile. I cannot clear cache (I use WP Super Cache) for the active loaded page/post on mobile because that menu item is gone on mobile, the only thing I can to is to flush all cached pages (and this in not very good for site performance).

    • Davide 'Folletto' Casali 5:43 pm on November 11, 2014 Permalink | Log in to Reply

      My visceral reaction seeing that is “omg please turn it off” — even if my technical reaction to that is “that’s amazingly well executed”. :)

      So… I’m very skeptical about this. Our mind already naturally spaces out if the context stay fixed. If you animate it out… you’re actually creating movement that will attract the attention focus.

      If I want distraction free, I want that explicitly. I use that when I want to focus, but when I do, it’s explicit. That’s why the previous distraction free for me was excellent (even if I agree that could be improved). So I’m also sad to see that mode actually go away, even if I’m glad and I find clever that I can disable it so simply (we probably need a better icon if it lands, tho, I guess). I guess that it’s important to make that toggle now to stick between sessions, since it’s not a mode anymore but a configuration feature on the same page.

      That said, I’m ok in trying it. Maybe in the end what it does it’s not enough to trigger the perception and won’t create too much discomfort when using WordPress as a CMS. :)

      • designsimply 3:36 pm on November 12, 2014 Permalink | Log in to Reply

        I guess that it’s important to make that toggle now to stick between sessions, since it’s not a mode anymore but a configuration feature on the same page.

        I think this part is already done. I tested the toggle setting to off and that setting seems to already be sticky between sessions for me. I tried logging out and logging back in and clearing cookies and logging back in and the setting was still disabled after the first toggle.

    • hearvox 7:30 pm on November 11, 2014 Permalink | Log in to Reply

      I work w/ journalists who often have lots of metaboxes that need values (CFs, taxonomies, etc.). The current DFW never caught on b/c there’s too-much back and forth — it feels like an entirely separate editor/screen. Focus makes it feel like just a little different view of the editor you’re already working in. Pretty sure that’s the feel the folk I work with want.

    • NodleRedoy 8:45 pm on November 11, 2014 Permalink | Log in to Reply

      I wonder if a menu type approach to the “post settings widgets” (publish, tags, categories, etc.) could make the editor area a bit cleaner.

      What I mean is this… if you would take these “post settings widgets” and put them into a menu on the right side of the page, so that they would fly out when activated (clicked/hovered over) could you remove some of the standard editing page “clutter” and possibly compliment the DFW changes shown in the video.

      I do like the looks of where this is going!

    • johannesfosseus 9:50 pm on November 11, 2014 Permalink | Log in to Reply

      Please, don’t. We (and many others) use WordPress as a “plattform” and we have more then half of the content in meta boxes. In that perspective it’s becomes very odd if content disappear when you type in the default post area. Not great if the distraction free writing becomes a distraction for non bloggers!

      • Andrew Ozz 10:53 pm on November 11, 2014 Permalink | Log in to Reply

        This is a JavaScript based feature. Once it is merged you will be able to completely disable it by deregistering the script, and/or possibly by using a PHP filter (by completely I mean the users won’t even know it exists).

        • Yogi T 9:03 am on November 15, 2014 Permalink | Log in to Reply

          Please, make this feature as an option and not a default. Make a checkbox on the Profile Page, so every User can decide on its own to use it. Please do not realize the deactivation based on a filter or hook. Not every user knows the functions.php!

      • Kolya Korobochkin 12:59 pm on November 16, 2014 Permalink | Log in to Reply

        Totally agree with johannesfosseus. This is terrible when you start typing and stupid animation is coming. I hate animations when they occur and I did not expect this. Mark should go to Microsoft (they love animations).

      • John Eckman 1:06 pm on November 20, 2014 Permalink | Log in to Reply

        The more one uses structured content (less blobs, more chunks) the less useful DFW becomes, and the more potentially distracting this will be.

        Would it be possible at some later point to register certain meta-boxes or UI parts as not fading when focus v2 “happens”?

    • Patrick Steil 1:57 pm on November 12, 2014 Permalink | Log in to Reply

      Seems like a great default. As long as a user can easily turn this off if they don’t like it, then I think it will make sense for most users. And there should be a way to turn it off site-wide as well…

      Would love this in core… great work!

    • LittleBigThings 4:06 pm on November 12, 2014 Permalink | Log in to Reply

      I think this would make a nice addition to user experience in the backend editor, thanks.

      I was wondering about whether the idea has come up to add a delay of “a couple of seconds” before the interface fades away. Even if the fade starts only on typing.

      I think people often want to correct a word or set something in bold, … or do just a small change for which the fade does not have an added value. Distraction free writing is required for a state which you enter after some time you have started to write. It would save some fade out and in.

      Just a thought, great work though!

    • siteshack 8:11 pm on November 12, 2014 Permalink | Log in to Reply

      Looks really great. 1 issue that I noticed that I though could be potentially annoying. Around 4:36 in the forgiveness section you had the cursor ready for typing moused over to categories and the text scrolled down. You therefore lost the position of typing and would have to scroll back up and find it.. Now I haven’t played with v4 yet so this maybe my lack of experience with this. It’s great though

    • Ionel Roiban 2:40 pm on November 13, 2014 Permalink | Log in to Reply

      Wonderful! I realize now why our editors don’t ever use DFW. This is a real improvement. How soon are we going to see this in the core?

    • Tracey 9:52 am on November 15, 2014 Permalink | Log in to Reply

      When I first started typing I loved it, then I felt that having the very simple and low key editing bar on show all of the time might be quite nice. I forgot it was there until I wanted to exit full screen. All said it is a massive improvement and I will certainly be using it regularly.

    • philsimon 1:36 pm on November 18, 2014 Permalink | Log in to Reply

      It does seem like an improvement. I don’t like how many of the features (h2’s, padding, etc.) aren’t available in the current version.

    • Jakours2 11:04 pm on November 19, 2014 Permalink | Log in to Reply

      Nice 😀

    • ahortin 7:36 am on November 20, 2014 Permalink | Log in to Reply

      I can see this annoying quite a few people, myself included. I find it more distracting that the screen changes, with the menu sliding in an out, every time the mouse moves out of the visual editor. Would much prefer this was turned off by default and only enabled if you wanted it. I’ve never once used the Distraction Free editing screen.

    • Nick Young 6:58 pm on November 21, 2014 Permalink | Log in to Reply

      Please add the option to disable this. As I am developing plugins sometimes I only need to make one change to test a shortcode and am having to wait for the screen to come back in order to update the post. Could see how others may like it, but for me it is super annoying.

    • Shmoo 2:41 pm on November 22, 2014 Permalink | Log in to Reply

      If I see this correctly this option isn’t turned on by default, you have to press the formerly ‘full-screen’ button first right? it’s not like my grandmother will update WordPress one morning, she starts typing a new blog post and all her side content disappears on her and she calls me at 7 in the morning?

      Personally I like this feature, it’s well designed and pretty but I also think this is too sexy for 85% of the WordPress users. People who care about stuff like this don’t write their blog posts inside the WordPress back-end from scratch but have standalone writing tools on their computers/tablets. 100% sure those people will not give up their native clean 3rd party writing app for a fancy WordPress Javascript feature.

    • Breno Alves 8:02 pm on November 22, 2014 Permalink | Log in to Reply

      Awesome UX!
      Maybe this can be enabled by default, just for some user roles.

    • AxisThemes 8:16 pm on December 28, 2014 Permalink | Log in to Reply

      Awesome but we have utilized the metabox to create a Drag and Drop Page Builder. How to force them to make visible 😛

  • Mark Jaquith 5:20 pm on September 10, 2014 Permalink
    Tags: ,   

    9/10 Agenda 

    WordPress 4.0 “Benny” is out the door, warming hearts, flying off shelves, and many other euphemisms besides. After a brief respite to enjoy our success and a job well done, we turn our eyes to the future: 4.0.1, 4.1, and more.

     
    • Ionel Roiban 5:31 pm on September 10, 2014 Permalink | Log in to Reply

      Congratulations, everyone!

    • Stephane Daury (stephdau) 5:43 pm on September 10, 2014 Permalink | Log in to Reply

      4.1 release lead nominations: I’m going to go right in crazy mode and suggest @rmccue.
      Note: I have not discussed that with him, so it’ll catch him by surprise.
      My logic is as so:

      • in May, we had a big IRC convo during our weekly chat about committing to WP API.
      • From what I can tell, said API is quite ripe for 4.1, or could be with the proper effort.
      • Making Ryan a lead (if he can afford to) could be a good way to make WP API the big ticket item for 4.1
      • Stephane Daury (stephdau) 5:46 pm on September 10, 2014 Permalink | Log in to Reply

        That’s also obviously my vote for the focus in 4.1. :)

      • Justin Sainton 6:41 pm on September 10, 2014 Permalink | Log in to Reply

        Really great suggestion! I think @rmccue would make an awesome lead, but I just don’t know about it for the release where he’s the lead on such a major component as the WP-API.

        Just spitballing here, but I wonder if it wouldn’t be a better situation to have someone as a release lead who can shepherd the whole release, not just that specific component? In my imagination, getting the API in the 4.1 release would require someone like Ryan to be more fully devoted to that specific component than to the whole release.

        Just my two cents.

      • Andrew Nacin 6:41 pm on September 10, 2014 Permalink | Log in to Reply

        When the API is merged in, we’d probably be best served with Ryan’s focus to be 100% on the API, and not need to worry about anything else also going on. The release lead is as much a project manager as it is a final arbiter, shepherd, and what not. Also, the API is going to be a big ticket item in the release it’s in, no matter what. :)

      • Michael Beil 4:44 am on September 12, 2014 Permalink | Log in to Reply

        I concur with having @rmccue at the helm.

    • Stephane Daury (stephdau) 5:51 pm on September 10, 2014 Permalink | Log in to Reply

      Call to action on feature plugins for 4.1 and beyond: in the same line as my WP API suggestion, and if it does make it in 4.1, I (we?) would like to resume work on the Press This rewrite, with the twist of building it as a WP API client. It could act as a great bundled example.

    • Andrew Nacin 6:57 pm on September 10, 2014 Permalink | Log in to Reply

      Some questions to ask:

      • What have we done in the last few releases that could benefit from a v2, even small things?
      • What have we added in the last few releases that needs to be propagated to other areas?
      • What have we not touched in a very long time and is long overdue for a revisit?
      • What brand new features should we consider working on?
      • What existing features need a complete rethink?
      • What are some bite-sized things that we could do to make a big impact? (3.9 and 4.0 were full of these.)
      • What are big things that are broken and that we feel like we could fix / make better?
      • What might Twenty Fifteen benefit from having in core?

      Also, if you want to help lead a release or want to suggest someone, be sure to read this post from 4.0.

      • Stephane Daury (stephdau) 7:08 pm on September 10, 2014 Permalink | Log in to Reply

        For #1 and #2: we delayed a move to Backbone.js (propagate) for the plugins browser/modal (updated in last release) in 4.0, under my advice, to focus on functionality rather than getting bogged down in a library switch. Should that be tackled that in 4.1, building on the experiences of the Media Grid et al?

      • Nick Halsey 7:30 pm on September 10, 2014 Permalink | Log in to Reply

        To address several of those points, I’d like to continue iterating on the Customizer. Starting to build out better JS APIs in particular, building up to several features that’ve been delayed due to the lack of structure here.

        I’d really like to get media in the Customizer rebuilt (initial patch on #21483), and to officially deprecate and redirect/deep-link the old header and background admin screens. Given Twenty Fifteen’s emphasis on those features, this seems like a good time to finally pull the trigger here.

      • John Blackbourn 7:31 pm on September 10, 2014 Permalink | Log in to Reply

        What have we not touched in a very long time and is long overdue for a revisit?

        I think we need to have a think about all the JavaScript which is landing in WordPress these days, and make sure we are documenting it well enough, whether we need to prioritise an action/filters API for this, whether we are doing enough to educate contributors and other developers on the JavaScript APIs, whether we need a better structure for the .js files, etc etc. See also Eric’s post on wp-hackers.

        What are some bite-sized things that we could do to make a big impact?

        Fix the currently rubbish comment notification settings. See #6286, #14676, #761, Email Alerts plugin.

      • Ihor Vorotnov 2:01 am on September 11, 2014 Permalink | Log in to Reply

        Jumping in here. The feature which is highly anticipated by literally any WP developer outside US and several other english-speaking countries is… some multilingual features in core.

        Here’s my idea in details: https://wordpress.org/ideas/topic/native-multilingual-cms-features-one-more-time#post-27185

        Basically, even making terms slugs non-unique and adding some super-taxonomy `language` will allow major plugin developers (WPML, Polylang) do the rest. WPML currently allows to have posts and pages with same slugs, but not categories, tags and custom taxonomies.

        Right now I’m building a pretty large international website, which will function a s a website and a mobile app platform (backend) – thanks to JSON API. Having urls like `example.com/ru/profile-2/edit` or `example.com/ru/profile-ru/edit/` (just plain simple hierarchical pages) is kind of freaky. Or `example.com/ru/events/country/canada-2/city/toronto-2` and `example.com/ru/events/country/canada-ru/city/toronto-ru`…

        Sooner or later, we need to add solid multilingual features to core to become CMS / Framework, not a blog platform.

    • Zach "The Z Man" Abernathy 7:18 pm on September 10, 2014 Permalink | Log in to Reply

      I personally would love to see a little more work in the area of media with respect to actually managing the media items. For instance, being able to group things in folders would be a huge improvement.

    • John Blackbourn 7:21 pm on September 10, 2014 Permalink | Log in to Reply

      I would like to get the ball rolling on open and closed Multisite networks which didn’t get any traction in 4.0 due to time constraints.

    • Boone Gorges 7:23 pm on September 10, 2014 Permalink | Log in to Reply

      I won’t be able to make this meeting, but I’d like to spend some time during the 4.1 cycle improving WP_*_Query classes. Improved test coverage (see eg #29560), followed by fixing some of the more egregious bugs (such as #19623), and adding what I see as some missing features (#29181, #29181, and a few others I am cooking up). May also look into abstracting some of the common logic into some sort of base class that the others will extend.

    • Robert Dall 8:01 pm on September 10, 2014 Permalink | Log in to Reply

      I’d like to fix the poor UI In the widgets since they were last updated. Specifically #27180 I know we can do better.

    • Aaron Jorbin 8:12 pm on September 10, 2014 Permalink | Log in to Reply

      I’d like to work on getting our JS unit tests running automatically on multiple browsers. I’d also like to look into some automated tests around front end performance of the admin and finding areas that we can speed things up (and also maintain a benchmark of how things are).

    • Xavier Borderie 8:16 pm on September 10, 2014 Permalink | Log in to Reply

      I’d vote for changing the in-editor image update, making like the one in Confluence. I use this wiki tool at my job, and love that, while WP uploads the file and shows the library, letting me inserting the media, when I really want to directly insert it in place. Makes a huge difference.

      • Xavier Borderie 8:17 pm on September 10, 2014 Permalink | Log in to Reply

        “in-editor image upload*”

      • Xavier Borderie 8:35 pm on September 10, 2014 Permalink | Log in to Reply

        Top notch foreign typography. It’s very hard, for instance, using French quotes or non-breaking spaces in the editor without resorting to copy-paste. The editor tries to hot-swap curly quotes but fails in many cases.

      • Xavier Borderie 8:39 pm on September 10, 2014 Permalink | Log in to Reply

        For translators: mark clearly strings that are used in JS, HTML labels/title tags or e-mail, because some translations use HTML entities to get some local things done, and that obviously does only work in HTML situations, not the others. I’m willing to work on that.

      • Xavier Borderie 8:29 am on September 11, 2014 Permalink | Log in to Reply

        Finally tackling that multilinguism issue — or at least build the foundations in 4.1, because it’d make for a great 4.2 announcement (‘cos, y’know, 42, Hitchhiker’s Guide, the Babel fish, all that :) ). Allegedly, the SPIP CMS does it very well (see here for their introductory post).

        • Vincent Mimoun-Prat 8:01 am on September 18, 2014 Permalink | Log in to Reply

          +1 For that too. Multilingual support is as of today more or less buggy depending on the plugin you are using. There are very few options out there and they all are flawed to some extend.

          It would be great to see at least a first step towards a multilingual base framework that plugins could eventually use to build a UI on top of that.

          Current approaches:

          • WPML has CPT and lots of meta data to translate taxonomies -> extra useless queries, bloated UI and code, …
          • Multilingual Press requires one subsites per language -> lots of duplicate site setup required + does not work for e-commerce where you would need two separate shops, would have two separate stocks, …
          • Some other plugins use markup within posts/taxonomies -> Makes editing a nightmare.

          Basically because no foundation for multilingual support is there, we don’t have a mean to get a decent solution to the problem.

      • Xavier Borderie 12:44 pm on September 15, 2014 Permalink | Log in to Reply

        Oh, and since I just got another two requests for that non-ending issue: please do something about the “WordPress address (URL)” and “Site address (URL)” setting fields! People keep using it with no other thought, this bringing their site down, hoping for others to help them out! There must be a better way: hide it, add a warning, anything else than giving the impression that the use can enter URL in these fields and that WordPress will magically set everything in place :)

    • Stephen Edgar 9:50 pm on September 10, 2014 Permalink | Log in to Reply

      The Export API was proposed for 4.0 and didn’t make it, would be great for 4.1:
      Export API improvements/overhaul #22435

    • Dan Milward 11:34 pm on September 10, 2014 Permalink | Log in to Reply

      I agree with Nick Halsey. For me it’d be something small and scene setting for more socket.io integration in the future – its hard to argue against the technology on the basis that Automattic acquired it right?

    • Brandon Wamboldt 2:15 am on September 11, 2014 Permalink | Log in to Reply

      The last few releases have made great strides in user experience in the admin, but now I think the team should focus on developers a bit for 4.1. As somebody who works frequently in WordPress, a big pain point is still list tables.

      I frequently create custom tables for data that really don’t fit the mold of post types, and I often have to duplicate large amounts of code to create a list view that mimics the other list views (posts/pages/etc). If you guys could ease that, it would be awesome!

    • Shail 5:00 am on September 11, 2014 Permalink | Log in to Reply

      For me most awaited feature is taxonomy meta. Is this feature in race? I know this is a very big change but I like to see it in core.

    • Ryan Boren 12:50 pm on September 11, 2014 Permalink | Log in to Reply

      I’ll dump my rough notes.

      Mobile and media. Media and mobile.

      Context, Trust, Awareness, Flow

      Press This. With the mobile improvements to the media modal that landed in 4.0, Press This can use the modal without being crippled on phones. The wordpress.com/post/ editor on wordpress.com has worked through some of the same problems that Press This needed to work through, hopefully smoothing the way. The /post/ editor also showed what you can and cannot get away with. Media, preview, and links are important. wpviews and wplinks are must haves. Media must be visual, not raw html, short codes, or even placeholders. Creating galleries should be possible and easy. Press This has a freedom that the /post/ editor does not. PT doesn’t have to worry with existing content edit flows. It can be tailored to a fairly one way creation flow (akin to Tumblr). It also has an advantage in that it can and does allow escaping to the full editor in the admin when the user needs more than PT provides.

      Press This is not just UI. It is bookmarklets, extensions, side-loading, re-blogging, and sharing. It is the sharing mechanism in Android and iOS8. Someday it will be accommodated by the apps. Keep the entire Press This and sharing ecosystem in mind. When dev resumes, prioritize bookmarklets and fleshing out the sharing mechanisms, especially on mobile. Press This the UI is, in part, a trojan horse for getting a decent mobile posting interface on phones, but the sharing big picture should not be lost to new UI fascination.

      Press This the UI should be a marquee user of WP API.

      Large (full screen-ish) images should be a tap/click away in the media modal. Creating and captioning galleries is difficult when provided only thumbnails. Maybe borrow the attachment details modal from grid view.

      Re-think media modal for touch devices. Get rid of tabs, especially in the absence of multi-select. Full images on tap with details below (like the attachment modal) rather than opening the sidebar and presenting another thumbnail sized image. That sidebar is awful on phones.

      Re-think the media modal in general. We know more about how it is used than we did back when. We know what plugins are actually rather than speculatively doing with it. Is having a separate gallery flow still a necessary compromise? Is a sidebar the best way for plugins to integrate? Is there anything blocking VideoPress and Dropbox plugins from integrating? Which plugins integrate well with the media modal?

      Create gallery and image posts from the media library grid view. Give bulk selection a purpose. This will accommodate mobile flows where images are uploaded to the media lib from a mobile device (via Android’s multi-select capable sharing mechanism, for example) and then gallery posts are later created from a desktop. This is a means of working around our lack of mobile multi-select and gallery creation interfaces.

      Phone UX improvements, particularly menus. Is it possible to swipe to open/close side menus on the mobile web? Side menus must have swipe to be usable. Tapping a menu icon in b’ar should dismiss the menu instead of visiting a link. There is often no safe “tap outside” room on a phone, so all menus should dismiss when their icons are tapped. Very aggravating.

      When adding links on mobile, don’t require highlighting text to activate link icons. Buggy on phones.

      Tweak wplinks for phones. It’s already pretty good and keyboard up/down responsive, but mostly by accident.

      Multi-select upload everywhere.

      B’ar consistency. The front page b’ar on touch devices is my favorite. Tablets in landscape show the narrower b’ar in the admin, which always disappoints me.

      Images uploaded to the media library and then added to a post don’t show up in the “Uploaded to this post” filter. Not being able to filter down to images already on the post makes setting featured images tedious. Uploading from mobile to media lib and then posting later is a common mobile flow.

      Fix the image editor on phones.

      Lose media-new.php?

      Oh wouldn’t it be nice…

      Settings that don’t suck.

      An index.php featuring Press This and a reader.

      Reader views for all list table screens.

      Theme switching from the customizer.

      Notifications, Stream.

    • Paal Joachim Romdahl 11:01 pm on September 11, 2014 Permalink | Log in to Reply

      Improving/renewing Settings was briefly touched upon but stopped up. Having a real useful Settings section would of course be really helpful. I bet a lot of people would have input about this and I bet there are also a few developers that really would like to come together and make this happen.

    • Stephen Edgar 5:54 am on September 12, 2014 Permalink | Log in to Reply

      Another suggestion, and with 99 stars at the time of writing:
      https://core.trac.wordpress.org/ticket/12706 – Custom post status bugs in the admin

      • pampfelimetten 8:37 am on September 18, 2014 Permalink | Log in to Reply

        Oh, yes please! I’m waiting for ages to have this fixed. It’s pretty weird that so much of the post status functionality is hardcoded, when you can tailor pretty much everything else to your needs in wordpress.

    • leemon 6:11 pm on September 12, 2014 Permalink | Log in to Reply

      Please, tackle the following taxonomy bugs once and for all:
      https://core.trac.wordpress.org/ticket/5809 – Updating a term in one taxonomy affects the term in every taxonomy
      https://core.trac.wordpress.org/ticket/5034 – Impossible to have duplicate category slugs with different parents

      Fixing this would be cool too:
      https://core.trac.wordpress.org/ticket/22938 – Presentation of hierarchical taxonomy in Media modal should be checkboxes rather than comma-separated tag list

      Thanks

    • Paal Joachim Romdahl 9:12 pm on September 12, 2014 Permalink | Log in to Reply

      Certain features are directed toward a developer and would not really help a “regular” user as much. I am thinking that features also could be placed into categories of who would this be helpful for. Placing a feature into: Developer, Designer, Advanced Users, Basic Users. Most people who are associated with being here on this forum are very likely Developers. A few probably Designers and a very very would then place themself into the remaining two categories.

      As I work with education I identify myself have very strong empathy for a person who has just began with WordPress. And oftentimes see WordPress through their eyes. Core needs eyes on features from people with different backgrounds that can share thoughts and their perspectives into seeing a much larger view.

    • Rodrigo Primo 8:59 pm on September 16, 2014 Permalink | Log in to Reply

      Fixing the performance issue with the algorithm used to display a list of hierarchical posts (pages or another custom post type) would be a great improvement for 4.1. This ticket has a patch already and is waiting for dev feedback.

      https://core.trac.wordpress.org/ticket/15459

    • Vincent Mimoun-Prat 7:53 am on September 18, 2014 Permalink | Log in to Reply

      Hi,

      I have just updated the patch I had submitted for 3.8 and 3.9 on an important performance improvement for meta queries. It would be great if that could be reviewed and included in 4.0.1 or 4.1

      https://core.trac.wordpress.org/ticket/24093

    • Paal Joachim Romdahl 12:22 am on September 22, 2014 Permalink | Log in to Reply

      Improving the WordPress importer/exporter plugin would be nice. To have a separate section for media or improving on the media aspect of the import/export.

    • Dave Clements 6:39 pm on September 22, 2014 Permalink | Log in to Reply

      It’d be great to see the work already carried out on #21506 (Standard Theme Hooks) carried forward through testing and implementation.

    • JakePT 7:39 am on September 24, 2014 Permalink | Log in to Reply

      I’m desperate for #20943 to be fixed.

  • Mark Jaquith 6:25 am on July 23, 2013 Permalink
    Tags:   

    About page for 3.6 

    As we approach 3.6 final, we need to start thinking about the About page for the release. What should go on it? Shout out your ideas.

     
    • johnbierly 8:23 pm on July 23, 2013 Permalink | Log in to Reply

      At this point, as long as there’s a link to download 3.6, I don’t care if the entire page is collages of cartoon giraffes!

      Maybe style the page with the Twenty Thirteen fonts to give it some character. That could be a cool thing to do for every year’s major release — style that version’s page like the default theme for that year.

    • Chuck Reynolds 3:16 am on July 24, 2013 Permalink | Log in to Reply

      typography and html demonstration… li’s, ol’s, blockquote, h1-6, code blocks, etc etc

    • daveshine (David Decker) 11:36 am on July 24, 2013 Permalink | Log in to Reply

      The obvious things: Updated Revisions, updated Menus, etc. :-)

    • Siobhan 3:07 pm on July 24, 2013 Permalink | Log in to Reply

      Emphasis on how the writing experience in WordPress has been improved, particularly with Autosave which is an awesome new feature but may not be entirely obvious.

      Also worth talking about post locking which is great for multi-author blogs, & improvements to revisions.

    • Xavier Borderie 4:13 pm on July 24, 2013 Permalink | Log in to Reply

      Is there any way translations can use their own set of (translated) screen captures?

    • Eric Andrew Lewis 4:38 pm on July 24, 2013 Permalink | Log in to Reply

      How about including the “Introducing 3.6” video?

    • adamsilverstein 6:11 pm on July 24, 2013 Permalink | Log in to Reply

      closed the wrong browser tab the other day while editing a post, came back to the post edit page and restored from the browser backup. BOOM! no lost work. wow! that’s amazing!

    • EricMesa 6:28 pm on July 24, 2013 Permalink | Log in to Reply

      What I’m most excited about for 3.6 and I would like to see in the about page would be some instructions on how to use the new, awesome built-in audio and video players.

      If it wouldn’t cause too much confusion, I’d also like a section on the page telling me where to get the Post UI Plugin.

    • Shea Bunge 9:03 pm on July 24, 2013 Permalink | Log in to Reply

      Updated menus, revisions, new theme.

    • delevega 5:24 am on July 31, 2013 Permalink | Log in to Reply

      Links to useful codex pages that have to do with the use of new or different functions / features. Maybe some information on twenty thirteen.

  • Mark Jaquith 6:29 am on July 10, 2013 Permalink
    Tags:   

    Hey! Remember that WordPress 3.6 release we were working on? Yeah… we’re still at it. But there’s hope! Post Formats UI has been extracted, and Revisions has gotten an intense refactoring that makes it scale up to hundreds of revisions without killing your server or your browser. A backlog of many hundreds of tickets has been whittled down. As of this writing, we’re below 40 tickets for 3.6, and they’re actively being committed and punted as appropriate.

    The plan is to keep on those tickets and get to RC by Friday. Help is appreciated! A bunch of people have been “pinged” regarding tickets on report/6, so please scan through those and log on to IRC to check for messages.

     
  • Mark Jaquith 8:25 pm on June 5, 2013 Permalink  

    We’re going to have some working IRC hours tomorrow, June 6th, between 1400 UTC and 1800 UTC. Show up if you can and we’ll hammer away at the remaining items from this post!

     
  • Mark Jaquith 8:16 pm on May 29, 2013 Permalink  

    Post Formats UI is exiting core, will live as a plugin 

    This is a hard decision. I’ve been talking to a lot of WordPress core developers and contributors, and the overwhelming consensus is that Post Formats UI is not ready for WordPress core, and that it would be a mistake to ship it as it currently exists. We’re going to pull it out, and let it continue development as a plugin, much like MP6.

    I fought hard for it, and a lot of people put a lot of effort into it. But the result just isn’t compelling, or obvious, or any of the things that it should be. It’s not just a matter of polish, it seems to be a fundamental issue with the concept. The release can’t be held up any longer for this. It needs to come out. I should have made this decision earlier. That’s on me. But letting it ride would be the worse mistake.

    Here is the proposed plan for extracting it, and for dealing with other tangentially related or other release-related items:

    Post Format Things to Move to the Plugin

    • The posts screen UI, including icons in H2 #24452 #24502
    • Enabling all formats by default #24452
    • The custom screen options (go back to what we had before) #24452
    • The content/excerpt/title necessity modifications in wp_insert_post() #24503
    • Content area size changes #24452
    • structured-post-formats support and post_formats_compat() #24453 #24454
    • Revisioning of the post format and post format metadata keys #24455

    Post Format Things to Keep in Core

    • Icons on edit.php (perhaps adding them to the radio format chooser to sync that context) #24519
    • post-new.php?format= shortcut
    • aside/status auto title generation (when blank)
    • URL extraction function (renamed from get_content_url() to get_url_from_post_content())
    • Post Format previewing #24483

    Upgrade Path for Beta Dogfooders

    • Consider rolling upgrade that pieces together post_content based on existing meta keys
    • Alternatively, include this as a tool in the post formats plugin
    • Perhaps a WP-CLI component to the post formats plugin, so those upgrades can be done on the command line, once

    Strategy for Media

    • Leave most of wp-includes/media.php — keep audio/video support
    • Call functions directly rather than calling do_shortcode() #24505
    • Have wp_get_(audio|video)_extensions() wrap wp_get_mime_types( $type = null ) if feasible #24504 (NOPE)
    • Remove or make sane attachment_url_to_postid() #24458
    • For A/V shortcodes, include the attachment ID, instead of just the URL (makes attachment_url_to_postid() unnecessary) #24458
    • Transition those IDs on import #24458
    • Consistency: embed shortcode takes URL as its content, but a/v ones take an attribute — make both for both? #24456

    Shortcodes

    • Keep shortcode_exists() and has_shortcode()

    What Else?

    Did I miss anything? Is there something that doesn’t seem like the right path forward to you? Let’s hash this out so we can move on it.

     
    • nphaskins 8:21 pm on May 29, 2013 Permalink | Log in to Reply

      It seemed mostly O.K to me kinda sad to hear it was pulled out. So with it going to a plugin does this mean core will never have UI for post formats?

    • Frankie Jarrett 8:28 pm on May 29, 2013 Permalink | Log in to Reply

      Agreed. It’s the right decision at this point to safely move forward. Thanks, Mark.

    • Mel Choyce 8:29 pm on May 29, 2013 Permalink | Log in to Reply

      If we want to keep the new icons, here are two rough ideas for placing them in the post formats metabox:


    • Travis Northcutt 8:30 pm on May 29, 2013 Permalink | Log in to Reply

      Mark, thanks for making the tough call to keep things moving forward.

    • Grant Palin 8:36 pm on May 29, 2013 Permalink | Log in to Reply

      That’s unfortunate, as the built-in UI is something I’ve been watching for a while. Good to know that it may eventually be reintegrated into core after it stabilizes and matures some more. Would the plugin solution be set up to minimize difficulties in transitioning it back to core? That is, forward compatibility?

      • Grant Palin 8:39 pm on May 29, 2013 Permalink | Log in to Reply

        Though I do see the rationale in separating the two, similar to that of the admin UI plugin. Don’t hold up the core release unnecessarily, but keep the door open for future integration.

    • mor10 8:47 pm on May 29, 2013 Permalink | Log in to Reply

      A hard decision to be sure, but the right one nonetheless. I believe Post Formats have a place in WordPress, but not in the core. I see great things ahead for Post Formats as a plugin. And mad props to the developers. Good code is good code whether it is in the core or in a plugin.

    • Hassan 8:52 pm on May 29, 2013 Permalink | Log in to Reply

      Oh, didn’t see this coming.

      Don’t know, mixed feelings.

    • Amy Hendrix (sabreuse) 8:52 pm on May 29, 2013 Permalink | Log in to Reply

      Thanks for making the tough call. I still think it’s a terrific feature, but I’d much rather give it time to evolve as it should rather than being shoehorned in to the (way cluttered, but that’s a different discussion) edit screen to make a deadline.

      And I’m super-happy we get to keep the stuff that came with.

    • Chuck Reynolds 8:52 pm on May 29, 2013 Permalink | Log in to Reply

      wow this is huge… mid dev w/ post formats… with the way they’re going it does seem like the best decision to pull them and make a killer plugin for it.

    • taupecat 8:55 pm on May 29, 2013 Permalink | Log in to Reply

      I’m sad to see the post formats UI go. I was really looking forward to it, but happy that we’ll be able to use it via the plugin.

    • extravaganzasd 8:55 pm on May 29, 2013 Permalink | Log in to Reply

      Thanks for this Mark – hopefully Post Formats will have a rejuvenating “vacation” from core and come back better than ever.

    • Eric Andrew Lewis 9:02 pm on May 29, 2013 Permalink | Log in to Reply

      If something is pushed into a plugin, it’s no less awesome for it. Cheers to all the awesome work that’s been done on it, looking forward to the plugin version. 😀

      • Chuck Reynolds 9:10 pm on May 29, 2013 Permalink | Log in to Reply

        biggest concern right now is timing.. when. mid dev with something and i’m fully engulfed in post formats and cpts…. sigh.

    • Siobhan 9:08 pm on May 29, 2013 Permalink | Log in to Reply

      Really sorry to see this go – I’ve been having lots of fun using Post Formats recently. I don’t think I’d have ever used them if it hadn’t been a core thing with me running trunk.

      However, it sounds like the right decision, and a tough one to make. I’ll be installing the plugin and, as a recent post format convert, am happy to help with any feedback and improvements to it.

    • mt_Suzette 9:13 pm on May 29, 2013 Permalink | Log in to Reply

      I agree with Siobhan, sad to see this feature go as I was really digging the Post Formats, but I can understand the need to keep core as lean and mean as possible, and add it as a plugin if desired. Very hard decision to make, and I fully support it and look forward to using the plugin for those clients it will benefit.

    • Syed Balkhi 9:13 pm on May 29, 2013 Permalink | Log in to Reply

      Good call there :) I think it was getting a bit crowded in the Post UI for a whole lot of us who won’t be using the post formats.

    • Devin Reams 9:14 pm on May 29, 2013 Permalink | Log in to Reply

      Mark, I can’t remember if Alex brought the “Post Formats Fallback” to your attention early on. This is probably easy to incorporate or at least give a head start if desired:

      http://alexking.org/blog/2011/11/02/wordpress-post-format-fallbacks
      https://github.com/crowdfavorite/wp-post-formats-fallback

      • Andrew Nacin 8:22 pm on June 3, 2013 Permalink | Log in to Reply

        Devin, yeah, the feature was heavily influenced by Alex’s work.

        • Devin Reams 11:28 pm on June 4, 2013 Permalink | Log in to Reply

          Right. I was referring to reminding of the “Fallback” tool in reference to the need for:

          • Consider rolling upgrade that pieces together post_content based on existing meta keys
          • Alternatively, include this as a tool in the post formats plugin
    • John James Jacoby 9:14 pm on May 29, 2013 Permalink | Log in to Reply

      This really is a shame. Any opinions worth sharing on what could have been done to avoid the retraction? We had all hands on deck with this at the beginning, then it got broken up into minutia, followed by a few weeks of tuning.

      What did we learn from this experience, and how do we avoid it for future releases? Maybe a post-mortem-post after 3.6 is out?

      • toscho 10:17 pm on May 29, 2013 Permalink | Log in to Reply

        Maybe each new feature (remember favicons?) should live in a separate branch until it is ready to be merged without blocking the release. Or it should start as a plugin until the interface and the code work good enough.

      • Mark Jaquith 11:07 pm on May 29, 2013 Permalink | Log in to Reply

        I will do a postmortem on the release.

    • BobDunn-Trainer 9:18 pm on May 29, 2013 Permalink | Log in to Reply

      I agree, I think it was a good decision. For many who love and use WordPress all the time, I can relate to the loss. But for the average user, I’m still on the fence there. Even with their introduction, it could have only added more confusion or a matter of just ignoring them. I like seeing the direction of a plugin… great job and I know it wasn’t a decision that was made lightly.

    • Devin Walker 9:19 pm on May 29, 2013 Permalink | Log in to Reply

      I believe post formats was the big new feature in 3.6 that everyone was looking for but if it isn’t ready then I don’t think it should be rushed. It makes sense to put it in a plugin. In my opinion, good decision.

    • mor10 9:19 pm on May 29, 2013 Permalink | Log in to Reply

      How will this impact Twenty Thirteen? It seems to me the core feature of the new theme was the heavy integration of post formats.

      • Amy Hendrix (sabreuse) 9:55 pm on May 29, 2013 Permalink | Log in to Reply

        Very little, actually — the great majority of what Twenty Thirteen does is based on styling the Post Formats that have always existed (well, existed for several years, anyway!), and the team is already working on the remaining changes that need to be made.

        • mor10 10:22 pm on May 29, 2013 Permalink | Log in to Reply

          I’m curious to see how videos will be pulled out of the content for index pages and above-the-title display. That said I think the proposed method of putting image and video links in a separate field was questionable because of the fallback for themes that don’t support Post Formats and how the content risked getting excluded from feeds. Looking forward to seeing solutions to these issues and best practice examples on how to dislodge embedded videos for display elsewhere.

      • Nick Halsey 1:43 am on May 30, 2013 Permalink | Log in to Reply

        Well it’s straightforward from a technical standpoint but I think it’s awful from a user perspective, especially for new users. The primary feature of the theme is to do cool things with post formats, but the majority of users will not know that about Twenty Thirteen, and likely won’t know about post formats at all.

        You can’t really do much in an obvious way with the existing “UI” (if you can call it that), so that leaves Twenty Thirteen in an awkward position for non-power-users. We need to include a tooltip or some sort of obvious help text at a minimum, to ensure that users discover the concept of post formats, point out the metabox, etc. Without post formats, for new users, Twenty Thirteen is just a bold, but mostly white theme with orange accents that discourages a sidebar… and we all know how much more amazing it is than that.

    • zekeweeks 9:22 pm on May 29, 2013 Permalink | Log in to Reply

      Bummed – this was the thing I was looking forward to most in 3.6, and really enjoying in the nightly builds. That said, the decision to hold off until the fundamental issues can be resolved is the right one.

      What I’m more curious about – for future additions that are similarly wide ranging in scope, and critical in terms of getting the UX just right, how do we minimize risk for release cycles? Beta 1 was released with the claim that “we shouldn’t release a beta if we were still working on completing the main features” – I don’t bring this up due to any naïve belief that everything is worked out before a beta release; rather, I wonder if such conceptual and UX-critical issues should be solidified earlier in the process. (Or can they even be? Definitely interested in what everyone else thinks.)

      • Erlend Sogge Heggen 10:20 am on May 30, 2013 Permalink | Log in to Reply

        This is easy. All major features should always start their incubation period as a plugin. The MP6 project has proven this approach to be very effective.

        (Matt Mullenweg and others seemed to be in favor of this approach, but the notifications bar isn’t responding so I can’t find the comment)

    • bryananthonylewis 9:22 pm on May 29, 2013 Permalink | Log in to Reply

      Great question!

    • Andrés Villarreal 9:24 pm on May 29, 2013 Permalink | Log in to Reply

      Like many people commented before, I have mixed feelings too. Personally, I would have love to see this feature in the core, but on the other hand, I think WordPress has evolved a lot from the simple blogging platform that it used to be years ago, and the post formats UI could have meant an unjustified rollback towards that way, even being a burden for non-bloggers that won’t use it.

    • wptotaltraining 9:37 pm on May 29, 2013 Permalink | Log in to Reply

      I think that is a really good call. I was worried about training my clients on that, because most of them struggle with just the basics. Also I am looking forward to the new dashboard in the new release so glad to get it moving. Making it a plugin is great way for those who understand it to use it.

    • amdirect 9:53 pm on May 29, 2013 Permalink | Log in to Reply

      Big decision……also a tough one I bet. Don’t know if it is bad or not, just digesting it now. Knee jerk reaction is not good, but will think about it more.

      Thank y ou,.

    • blondishnet 10:23 pm on May 29, 2013 Permalink | Log in to Reply

      Nice mockups.

      The decision for making this a plugin is logical. I don’t use a lot of the post formats currently.

    • Shapeshifter 3 10:42 pm on May 29, 2013 Permalink | Log in to Reply

      I know I’m not a Core Developer, but I find this irritating. Trying to get developers to continually agree on a focused destination must but be like trying to herd cats. As an end user, I thought everybody here was creating a great new feature for WordPress. This is similar to moving the Link Manager to a Plugin (which I immediately installed). The Link Manager was removed from Core because supposedly not enough people used it. A similar sentiment here is that the additional options of post formatting will confuse new users. Too bad…let them read and learn a little. This dumb dog thought you were doing a great endeavor. To placate someone such as myself, can you Please immediately make available the new plugin so I can install what your are now removing from Core…..Sorry if I sound rude.

    • StyledThemes 11:48 pm on May 29, 2013 Permalink | Log in to Reply

      Yikes! I was just working on my next WordPress theme that has a lot of custom styling for each of the post formats. Hopefully this won’t be affected. I’m really not a fan of 80% of the post format options but a couple there are worthy. However, I can understand not wanting to put something in that isn’t ready for prime-time yet and to take on some rethinking of how to implement them is important.

    • Brent Logan 12:34 am on May 30, 2013 Permalink | Log in to Reply

      Core or official plugin, makes no difference to me.

      The main benefit of an “officially blessed” post formats structured data format is preventing “lock in” to a specific theme. Now, themes can support this data format and we can choose any theme that supports it.

      For that matter, the ability to extract the structured data from older posts that don’t use it is a huge step forward.

      Kudos to everyone who had a hand in making this happen. I look forward to continued improvements with post formats.

    • Mike Zielonka 12:53 am on May 30, 2013 Permalink | Log in to Reply

      I am a little bummed because folks that don’t follow the details of WordPress dev may miss out on these new features unless they hear about the plugin.

      Could you include the Post Formats plugin in the WP 3.6 updates so folks could at least see what it looks like and give them an admin notice to remove it if they don’t like it?

      • Andrew Nacin 8:24 pm on June 3, 2013 Permalink | Log in to Reply

        By removing it, we’re recognizing that this is not ready for “prime time”. So no, it will not be shipping with 3.6.

    • Nick Halsey 1:50 am on May 30, 2013 Permalink | Log in to Reply

      Is this plugin going to be usable for production environments and non-power-users, or is the idea to do something strictly development-oriented?

      I think that releasing a plugin for users that contains the current core behavior and a separate plugin to rethink the UI and iterate, a la MP6, would be in everyone’s best interests. That way all of the theme, etc. developers who have been preparing for a greater core emphasis on post formats can make their plans work for end users with a constant UI until the re-thought UI is potentially re-introduced into core and released. After all, 3 betas were released with the PFUI in some form. Such a plugin would probably use exactly what we have now, and allow people to actually use it without worrying about stability. That sort of a plugin and an MP6-style plugin have entirely different objectives and should be treated accordingly.

    • Jon Brown 8:57 am on May 30, 2013 Permalink | Log in to Reply

      I want to make sure I’m not filling in the gaps with too many assumptions.

      Post Formats have been in core for a long time now and will continue to be in core, correct.

      What is getting moved out of beta core and into a plugin is just the recently proposed enhancements to post formats to surface them more even in themes that don’t explicitly support them.

      The reason is because that work ended up with what some of us think is a pretty bad UI and it’s better to continue to iterate it in a plugin than it is to release it with core. The new plugin is really intended just a temporary bridge for those that have already started working with the structured post formats and those who wish to continue work on the structured post formats. That plugin is not intended to be core plugin or a long term solution for the masses to consume, right? I’m inferring that from likening it to MP6, whereas some of the comments here seem to think of it as a “core plugin” that people should feel confident adopting as “blessed”.

      • Aaron D. Campbell 2:30 pm on May 30, 2013 Permalink | Log in to Reply

        Post Formats have been in core for a long time now and will continue to be in core, correct.

        Correct

        What is getting moved out of beta core and into a plugin is just the recently proposed enhancements to post formats to surface them more even in themes that don’t explicitly support them.

        Correct

        And the plugin will be very much like MP6 in that it will be a staging ground.

        • Jon Brown 7:36 pm on May 30, 2013 Permalink | Log in to Reply

          Thanks for confirming Aaron. Some of the comments here seemed to conflict with what I understood.

          Personally I’d like to see MORE major features get developed and iterated as plugins over the course of a couple point releases. Instead of trying to go start to finish on major features in a single point release.

          I’d think that approach would reduce the occurrence of things like custom menus, structured post formats, etc. causing major delays to releases like this. Instead of building the functionality from scratch in core, the plugin code iterated over a few releases would get move into core at the begin of a point release dev cycle and then it’d just be a matter of validating the migrated code and minor cleanup.

          Maybe it’d even garner more participation because it’d give people a place to really focus their development efforts. I can see non-core contributors getting involved with a core feature development plugin more easily than wading into core trac…

    • Sami Keijonen 11:43 am on May 30, 2013 Permalink | Log in to Reply

      I’ll have to disagree on the decision. But in the same time now I have huge respect to Mark. These kind of decisions are always hard when it impacts so many people one way or another. And there are not so many people out there who can build WP as a better platform and in the same time make big decisions and stand behind them.

      I guess most of us might have selfish reasons do we agree or disagree on this one: Now I have to re-think my upcoming theme, update my old theme, now I have to teach my clients new stuff, I don’t like how it looks/works, I like how it looks/works, these should always be in the core / plugin, I don’t eve use post formats, I use them all the time.

      WP Core theme, thanks for hard work.

    • Brad Touesnard 12:51 pm on May 30, 2013 Permalink | Log in to Reply

      Tough decision Mark, but I think it’s the right one. I’ve heard from a few developers (client services and product) very concerned about the confusion over these new UI elements and the boom of support it was sure to cause.

      I love the idea of MP6 and this new plugin. Cautiously rolling things like this into a plugin, getting it stable, and then letting developers get their toes wet, test it on a few clients and see what happens. Making sweeping changes and having to deal with the consequences all at once is a lot tougher on developers.

    • memuller 1:18 pm on May 30, 2013 Permalink | Log in to Reply

      A sad decision, but the right one nonetheless (but yeah, we could have made it a lot earlier).
      I think MP6 has show us that developing new features as a plugin is very, very awesome and effective for a lot of reasons; so I’m thrilled to see this approach being used with more new features.

    • johnbierly 1:32 pm on May 30, 2013 Permalink | Log in to Reply

      Back when the F-117 stealth fighter was still top secret, its pilots weren’t even allowed to tell their families they were flying at night, much less WHAT they were flying. They had to maintain normal schedules with their families (up all day, sleep at night), but for missions they had to flip that around to sleep all day, fly all night. The need for secrecy even in their daily schedules was very hard on their bodies and brains, and two pilots/planes were lost in accidents due to disorientation and fatigue.

      So when other pilots stepped up and said, “We’re too tired to fly safely,” it was not seen as a sign of weakness.

      It was seen as a sign of STRENGTH.

      So double bravo to you and your team, Mark. Bravo for thinking outside the box and trying to add something radical and fresh to WordPress, and bravo again for knowing when to admit it’s not quite ready in its current form. This is why WordPress is king.

    • contempoinc 3:05 pm on May 30, 2013 Permalink | Log in to Reply

      So when can we expect the plugin?

    • Chris Blackwell 3:52 pm on May 30, 2013 Permalink | Log in to Reply

      This is not the right decision! Everyone has been talking about Post Formats UI in WordPress 3.6 and is touted as “the feature” for the next version of WordPress. To pull this out now after 3 betas is ridiculous. If you need more time, then take it, delay the release.

      I can just see the boring headlines now, “WordPress 3.6 released with new Theme and some audio/video support”

    • Sallie Goetsch 5:09 pm on May 30, 2013 Permalink | Log in to Reply

      I begin to understand why we were talking about free will and determinism yesterday. :-\ Seriously, though, I’d been using the post formats UI for weeks, because my current WordPress class for MediaBistro started May 8th, and in an attempt to provide my students with instruction they’d need for an imminent upgrade, I recorded 2 sets of video lectures about post formats: one with 3.5 and Twenty Twelve, one with 3.6 beta and Twenty Thirteen.

      Everything about the new post formats UI appeared to be working, AND it seemed a lot clearer how you were supposed to go about using them than when they were first introduced. The link post format always puzzled me before; I’d have to look it up, then test it, before I could record an example for the students. (And clearly I never made a habit of using it myself.) My likelihood of using Aside or Chat outside the classroom is approximately nil, but at least the new UI made it clear enough what to do. (I have a client who is using Aside, in a Twenty Twelve child theme, for her workshop announcements, because it’s blue and stands out. Semantically all wrong, stylistically appealing to her.)

      What I’d like to be able to take back to my students and to my meetup (which also got a demo of the new post formats UI, on the 19th), is an explanation of what wasn’t working, since they’ve all seen it apparently perfectly functional. You folks are building it, and I trust that you can see far more than I can why it’s not ready for prime time, or at least not ready for core. (I haven’t had time to look at the code, or to test it in any environment but a clean new install with Twenty Thirteen.) But I’d like to be able to take something back to people who thought “This looks easier and more fun than the way it was before.” (It was WAY more fun. Made the page edit screen look sad and neglected by comparison.)

      Once the plugin actually exists, I can tell them to install the plugin–which I presume will require 3.6. Are you going to call the plugin something obvious like Post Formats UI, so I can tell them what to look for, even if it’s not available until the class is over? I’m about to record a set of videos on the topic of plugins everyone needs (e.g. backups, security, spam prevention) and then one on plugins for writers (most of these people come from a journalism background), so now would be a good time to be able to include something.

      Thanks,
      Sallie

    • Nashwan Doaqan 5:14 pm on May 30, 2013 Permalink | Log in to Reply

      +1, It’s the right decision :)
      “Do One Thing & Do It Better Than Anyone Else”

      We love WordPress to be clean,smart,easy … I think that the current features are enough for 3.6, we should focus on bugs and making the API better.

    • Johannes Fosseus 5:41 pm on May 30, 2013 Permalink | Log in to Reply

      This is great news, backend ui need to be cleand up. I realy would like to se more stuff hidden or moved to plugins. So, from me, good news.

    • Veuse 7:58 pm on May 30, 2013 Permalink | Log in to Reply

      Will 3.6 still be shipped with the audio/video player? I suppose I will need to create custom meta-panels for video? Would love to see a “featured video” panel included, much like “featured image”

    • Anointed 9:49 pm on May 30, 2013 Permalink | Log in to Reply

      -1
      I was so excited about ths one feature that I literally spent weeks sending email notifications out to theme and plugin developers to notify them about the new post-formats ui in order to get them to finally fully support post-formats as it was such a prevalent part of the core. In the past, getting theme and plugin authors to add proper support for post-formats was virtually impossible. This time I was having great luck in getting acceptance and now you’ve pulled the rug out from underneath us.

      I read the entire post and replies but at no point did I see WHY ARE THEY BEING REMOVED?

      Like most others, I’ve played around with them for weeks now, built my own theme extensions for them and a few cool plugin concepts and really I have never had a problem. They seemed to work great, so why remove them now?

      What is even left to look forward to in 3.6 now?

      • Frankie Jarrett 10:09 pm on May 30, 2013 Permalink | Log in to Reply

        “…a fundamental issue with the concept.” Go look at the open tickets in Trac and they speak for themselves.

        WordPress is awesome because things that aren’t ready don’t ship. I think we’re all a little frustrated but we should be mostly thankful and move forward.

        Jane Wells gave warning this could happen over a month ago, so it’s not like it’s a huge surprise.

        https://make.wordpress.org/core/2013/04/23/post-formats-schedules-and-philosophy/

      • Aaron D. Campbell 10:28 pm on May 30, 2013 Permalink | Log in to Reply

        It’s not that they didn’t work or that they were unusable. However, in the end they’re no as great as we really want our post format support to be. Usually that’s fine because we can simply iterate and improve with each release, but in this case we’re worried that the direction we took will prevent us from achieving our ultimate goal. We don’t want to paint ourselves into a corner. We’re worried that if we continue as we are now, when we ultimately do something else, we’ll just have a lot of legacy code to support and a lot of extra code to write and maintain for all the backwards compatibility that will be required to make the new stuff work with what we were putting in 3.6.

        Without them, there’s still plenty to look forward to in 3.6. Post revisions have gotten a serious facelift and are going to be much easier to use, which is awesome. The new menus changes have tested far better than our old menus. There’s been a lot of work around autosaves, so that data is never lost even if your connection to your server is. The new Twenty Thirteen theme is still being released with this version too! Additionally, not all the work surrounding post formats is being pulled. For example, we’re going to be keeping the new audio and video embeds, which give native support for audio/video embeds directly in WordPress.

    • Jonas Lundman 1:05 am on May 31, 2013 Permalink | Log in to Reply

      Bad idea to remove formats from the core. At least make it as add theme support and dont make a fancy layout cluttered button in the top of edit pages. Leave the metabox as it is.

      I just started building themes based on the formats. It filles the gap between categories and theme templates. The latter is to present the structure of the page view and the format to grain the content part in the tamplate, without adding new themes.

      For example, in setups as CMS, internal projects with cistom post types and diffrent layers of front end access, a small status format can be adjusted for the contents purpose in layout and script funstions. List formats in categories and make all image format posts open in modal etc etc.

      The format UI make it possible to adjust the responsive desgin and views for diffrent roles.

      This is a huge step back to remove the UI and the future of using WP as a cloud service and much more.

      I agree formats is an overkill for users with default Twenty themes, but the few of us who extend the wordpress world, please respect the small voices in this matter

      / Jonas Lundman, coordinator and project manager.

    • manuelmasia 1:07 pm on May 31, 2013 Permalink | Log in to Reply

      As Anointed I spent a lot of hours to make my themes compatible with the new feature. I think it would be very kind if WP 3.6 had the ability to activate the new UI with a function like add_theme_support(), so the work of many developers won’t be lost.

      I think many developers won’t trust anymore the announcements of the beta versions, and this would be a shame.

    • Jeff Mackey 7:21 pm on May 31, 2013 Permalink | Log in to Reply

      I understand the decision. While unfortunate, it does makes sense.

      Question —

      If I was running the nightly build (recent, that supported the Post Format UI) in a test environment, and had several posts saved using the various formats, and then upgraded to the latest nightly build (that no longer has the Post Format UI), how do I modify those posts now?

      For instance, I no longer see the special image, video, or link fields in the Edit Post screen.

    • Daniel_Iceman 8:29 pm on May 31, 2013 Permalink | Log in to Reply

      I’ve been playing with 3.6-beta3 and it looks great, post formats ui don’t seems to be confusing in any way to me. The issue discussed by Jane Wells https://make.wordpress.org/core/2013/04/23/post-formats-schedules-and-philosophy/ don’t occur anymore.

      All important modification brings new tools and challenges, recently we saw this with Windows 8 and the Start Menu issue. It was partially solved giving user the oportunity to bring button back by themselves, so if something similar can be used here, would be good if the post formats ui could be activated in a simple way, no plugin, like any other configuration. Let’s say, in Settings > Writing page.

      I’m not a pro developer. Sure would not be so hard for beginners to do it as well. Thanks.

    • porter1985 2:03 pm on June 1, 2013 Permalink | Log in to Reply

      i think giving user the option to have this as a plugin is a great step.

    • Emory 3:31 pm on June 2, 2013 Permalink | Log in to Reply

      Post formats were great, and I was really happy with the way they were being implemented. I’m pretty disappoint.

    • Chandra M 12:30 pm on June 3, 2013 Permalink | Log in to Reply

      I am glad this is going out from the next version. I felt it was too confusing as there are just loads of fields and options. It never made sense to me to use 2 image fields for Image post formats and no fields in Gallery post format. It was just turning into a cumbersome CMS. Hope it matures enough at a later time.

    • Matt Van Andel 5:55 pm on June 4, 2013 Permalink | Log in to Reply

      Although the styling coincidentally falls in line with the MP6 direction (which is why I posted this there first), I threw together an alternate design that goes a little further with the end-user education, without the major underlying changes that Post Format UI introduced. It’s available as a plugin as of yesterday… https://wordpress.org/plugins/better-formats/

      And here’s what it looks like in use:
      http://www.mattvanandel.com/wp-content/uploads/2013/05/betterformats-screencap.jpg

      Two things…
      1. I think education and UX are important here… much more important than the underlying technology. In my openly-biased opinion, Post Formats are, and should remain, an aesthetics feature… not a functional one. I think that was the biggest mistake in Post Formats UI. This approach adds descriptions inline, which should help spur usage and adoption by end-users.

      2. We can improve usability and user experience substantially with a little bit of a UI refresh… but there are power users who don’t need the training wheels, and we can gradually take them off. In this early prototype, I’ve included an option for hiding the descriptions, which makes the Formats box a lot more compact. A “mini mode” with smaller icons (like Mel proposed) is also an idea worth seriously considering, since the less-verbose box still takes up a lot of space.

      My personal bias is to hide the radio buttons as much as possible. They’re an artifact from another time, and they look out of place. They also don’t help explain to users what they are used for. The “Better Formats” prototype may not be the best option for WordPress in the end, but I think it’s a step in the right direction… that is, emphasizing education over interface (in a manner of speaking).

    • VegasKev 6:46 pm on June 4, 2013 Permalink | Log in to Reply

      ugh…what a tough call that must’ve been. But I agree with you Mark. If it isn’t 100% ready, push it to future release. And with Murphy’s Law….everything will fall into place right after 3.6 or 3.6.1 drops and you’ll be adding them “early” into 3.6.2 or ..3 instead of 3.7 …cuz that’s how the universe works…lol

    • Abhishek Ghosh 10:08 pm on June 4, 2013 Permalink | Log in to Reply

      It is a very very good decision. #2 with colored icon on hover looks great.

    • perryb 1:46 pm on June 5, 2013 Permalink | Log in to Reply

      I wonder if there is another way of approaching Post Formats.

      The issue is that by implementing the UI you are instantly overloading users with all sorts of options, many of which they will not need and may not understand.

      How about making it so the post editor can intelligently detect what type of post is being created?

      Sub 200+ characters = aside PF
      Single image = image PF
      Gallery = gallery PF
      Link = link PF
      etc

      The publish button would change according to context ( perhaps with a choice ) “Publish as image etc” or “Publish as regular post”

      This way the feature could be easily switched on in the background by developers who can choose to support as many post formats as they like (perhaps even control the rules that determine format detection).

      The user only gets presented with the option at the point they hit publish ( reduced set of options ) and this would greatly reduce the demands on the interface.

      I also wonder if Post Formats would be better used if integrated more with the iOS and Android apps. If you take a photo on your phone and post it then it might instantly become an image format post and so on.

      I really like the concept and the purpose of Post Formats and I get the impression that they were introduced to facilitate more casual blogging styles (perhaps even reinvigorate blogging itself).

      Perhaps you need to think more about how people might realistically use them in practice which might give a clue as to how the UI might work.

      Look from the other end of the telescope :)

    • Mike 9:55 am on June 8, 2013 Permalink | Log in to Reply

      Just saw the latest build. I have to say it is a mighty shame that talented programmers are engaged in a monthly project to remove goodness from WP.

      I’m not buying the GUI confusion mumbo jumbo. Microsoft has made fortunes for many by aggressively promoting GUI confusion and they and we have survived.

      I think the confusing GUI aspects would have been quicker improved from release feedback. When evolution of technologies and GUIs is considered, it puts this controversy into perspective – Much a Do About Nothing.

      Perhaps there are times when consolidation and retrenchment are good, but there is no evidence that this was one of those times. IMHO there is every indication it was time to move boldly forward.

      I urge WordPress folks to keep the spirit and focus on making dreams happen rather than cutting them down to size.

    • ecabral 6:19 pm on June 8, 2013 Permalink | Log in to Reply

      @ Mark – RE: Did I miss anything?

      Yes :) When ca we expect the plugin to come out?

    • allancole 10:26 pm on June 11, 2013 Permalink | Log in to Reply

      I’m chiming in late, but I’m really disappointed about this. I’ve been developing themes for WordPress since 2006 and decided to subscribe to the nightly builds for the first time ever based on the new implementation of this Post Formats GUI alone.

      Post Formats have needed their own content fields and their own GUI since 3.1 and I never understood how they were useful without them.

      The problem with current Post Format GUI is that it doesn’t explicitly ask users to do anything specific with their content so while compatibility between themes may be better without Format fields, there’s no way for theme devs to deal with Post Format content in any consistent manner. In my opinion, ALL Post Formats should have their own separate content fields. That way all themes can take advantage of the additional content in the same way (or not). Without their content fields, Post Formats are really just standardized categories, which aren’t very intuitive for users to implement and it’s limiting to theme developers who may want to push the envelope.

      The design and of the GUI is a separate thing and if its buggy or confusing for users, it may not be worth squeezing it into 3.6 — I get that — then push it to 3.7. While the new GUI may not have been perfect, it was very close to what it needed to be and I found it to be very intuitive. The most confusing part was why each Format didn’t come with it’s own fields (ie: Galleries, Asides, etc). Seems like such an obvious next step for the GUI for the reasons I mentioned earlier. Most of my other smaller gripes have already been mentioned in other comments but Post Formats should also be theme dependent, just like Custom Headers/Backgrounds via add_support().

      All-in-all It’s just sad to finally get a taste of a much needed feature only to find out it’ll ultimately be removed from core and converted into a plugin making it more difficult for theme developers to do awesome stuff. I do however, like the idea of implementing it this way for testing purposes a la MP6.

      Just my 2¢.

  • Mark Jaquith 10:01 pm on April 17, 2013 Permalink
    Tags:   

    The weekly IRC meeting has been moved back one hour to 20:00 UTC. Still on Wednesdays. As always, check the sidebar for that info.

     
  • Mark Jaquith 8:07 pm on March 27, 2013 Permalink  

    We’re really close 

    We’re so close to beta, I can taste it. For today’s meeting, think of anything outstanding that is still a beta blocker and then let’s talk about how we can get it sorted today. We’re going to keep at it until it’s ready. When? When it’s ready. But I’m hoping in the next 24 hours.

     
c
compose new post
j
next post/next comment
k
previous post/previous comment
r
reply
e
edit
o
show/hide comments
t
go to top
l
go to login
h
show/hide help
shift + esc
cancel
Skip to toolbar