WordPress.org

Make WordPress Core

Tagged: updates Toggle Comment Threads | Keyboard Shortcuts

  • George Stephanis 3:52 pm on December 11, 2015 Permalink
    Tags: , , updates   

    2FA! 2FA! 2FA! 

    Howdy, all! I’m back, and we’re getting the Two-Factor Train rolling again!

    We had our first meeting yesterday at the usual time (22:00 UTC / 5pm Eastern) in #core-passwords.

    https://wordpress.slack.com/archives/core-passwords/p1449784908000119

    Following some critical feedback and discussions both at the Community Summit and at WordCamp US, we’re adjusting our focus. Technical feasibility is turning out to be far less of a concern than ensuring we don’t create an undue support burden by users getting locked out and providing a way back in.

    Previously, we had been anticipating the primary way to override a loss of their second factor would be either adding a constant or modifying the database records (either directly or via a shell tool such as WP-CLI). However, we have had a number of concerns from assorted interested parties, and the fact of the matter is that it is feeling like too high of a barrier for many WordPress users. As @macmanx (new Forums Team Rep) summarized in our chat yesterday,

    I’ll say it this way: We want users to be able to secure their sites with 2FA, not sit back and watch outdated abandoned sites pile up because they locked themselves out and simply give up when when we mention FTP, Database, or SSH.

    So, there are several things that have been brought up:

    Require a constant in `wp-config.php` to enable 2FA

    The idea being that, by adding a constant to wp-config, the user has demonstrated that they know how to use FTP and edit files on their server manually, so if all goes to heck, they have the ability and knowledge to take the constant back out, so they can get back into their site admin.

    I feel that this is a bad idea, because it violates many of the WordPress Core Philosophies. It wouldn’t work out of the box, and we’re no longer designing for the majority. It results in us adding not only an option, but an option that’s hard to set.

    If we have to hide it behind a constant, I feel that it shouldn’t even be in Core, and would be better left as a plugin.

    (yes, I know Multisite runs this way, but there are other reasons that was merged into core)

    Require multiple providers being enabled

    The idea here being that if the user has two, there is less likelihood of getting locked out as they’d have a backup. However, for myself, I can’t tell you how many times I’ve downloaded backup codes and promptly lost them. Or how many times my phone has been destroyed (washing machines and phones shouldn’t be friends). There’s still a lot of opportunity for things to go wrong, especially on the scale of powering a quarter of the web. Edge cases become commonplace. 🙁

    Send Text Messages

    No can do, this would require a third-party server to send them through, and that’s plugin territory.

    Leave Emailed Codes as an always-available fallback

    This, I feel is our best option.

    There are some concerns regarding the large percentage of WordPress sites that are on servers that can’t send email (as high as 25% by some guesstimates I’ve heard floated), so we’d need to send a code and make sure it gets received before turning on the actual two-factor login prompt.

    While it doesn’t provide the best security (if someone breaks into your email address, they could both reset your password and get the incoming authentication code), it is 1) no worse than the status quo, 2) not our responsibility to keep secure, and 3) if they’ve broken into your email, you probably have bigger concerns.

    We can certainly include a filter for methods to disable / add from plugins, and so if someone wants to disable email manually, they totes can. By explicitly disabling the Core security feature, they’re then demonstrating that they know enough to fix it if it goes wrong.

    In the end, my feelings were largely best summed up by @michael-arestad, describing the two ways of balancing ease of use versus airtight security:

    Ease-of-use: core potential
    Airtight security: plugin town

    And we can always ship the plugin ourselves to let folks disable Email, but that feels like if it were in wp-admin that we’d be giving them just enough rope to hang themselves. 🙁

    ===

    Now, none of this is finalized, so if you disagree, please voice your concerns in the comment section below. I’m hoping that we’ll get enough discussion that we’ll be able to confidently make a final decision on what path we’re taking at next week’s meeting — which will be on Thursday at 5pm Eastern / 22:00 UTC in #core-passwords

     
    • Samuel Wood (Otto) 4:00 pm on December 11, 2015 Permalink | Log in to Reply

      +1 for “email as an always-on fallback” and “must verify a code via email to even turn 2FA on in the first place”. Best solution.

    • chriscct7 4:01 pm on December 11, 2015 Permalink | Log in to Reply

      For emails, what about using .org as an email provider where the site would ping .org and .org would send out the email?

      Also with text messages you don’t need to use a third party service. You can just use a library that maps carriers to their standard email to SMS address and then send an email (or .org sends an email) to that email. An example is https://github.com/JeffMatson/WP-SMS-Notifications/blob/master/carrier-list.php

      • George Stephanis 4:04 pm on December 11, 2015 Permalink | Log in to Reply

        Doesn’t work for all carriers. For example, Project Fi (which I’m on) doesn’t have an email to txt message gateway.

        • chatmandesign 4:05 pm on December 11, 2015 Permalink | Log in to Reply

          Would be a nice option to provide for those on carriers that support it, but definitely not something that can be relied upon for all users.

          • George Stephanis 4:07 pm on December 11, 2015 Permalink | Log in to Reply

            It also is something that would be easy to forget to update if you change cell phone carriers. Then the old carrier’s gateway would fail silently.

      • Mark-k 4:35 pm on December 11, 2015 Permalink | Log in to Reply

        I think that free SMS is mainly a US thing. I don’t know of any email to SMS gateway for any of the companies operating in israel.

        Making wordpress.org an email relay will just increase the option it will be marked as spammer, and there is the privacy aspect as well.

        • George Stephanis 4:44 pm on December 11, 2015 Permalink | Log in to Reply

          I agree, plus I hesitate to route something as critical as login through one central server for the default fallback core implementation. Feels like putting too many eggs in one basket.

          • Jon Brown 5:28 pm on December 11, 2015 Permalink | Log in to Reply

            and for those that travel internationally… SMS isn’t always available (changed SIM Cards, outside mobile coverage but on WiFi, etc..)

    • chatmandesign 4:02 pm on December 11, 2015 Permalink | Log in to Reply

      Is 2FA really something that should be built into core? It seems like you provide some good arguments why 2FA should be managed by technical administrators and security experts, not managed by end users at all.

      To be honest, I’d rather see federated login support built into core… Then the people who want 2FA can simply choose a login provider that has the technical chops to provide 2FA in a way that’s actually secure (e.g., Google).

      • Mikel King 4:29 pm on December 11, 2015 Permalink | Log in to Reply

        I have to agree leaving 2fa to the realm of 3rd party systems makes better sense.

        I think user base would be better served with having password expiration, character diversity, character length and history retention as well as session duration limit settings built into the core.

      • thetechnuttyuk 1:46 pm on January 25, 2016 Permalink | Log in to Reply

        I agree with this, 2FA should stay with the people who know what they are doing. I think it is okay to maybe add the option of WordPress 2FA within something like Jetpack, or to provide a tip message within Core to download the plugin, as WordPress built 2FA might be eaiser to those who don’t know how to set-up this as well.

        But I don’t think it should be built in.

        Third parties can do a much better job, a great example being Duo Security, who currently offer an awesome all-around solution that integrates directly with WordPress, we use it on all our sites and it works perfectly.

    • Varun Sridharan 4:02 pm on December 11, 2015 Permalink | Log in to Reply

      +1 For Emails .

      Nice feature 🙂

    • Omaar Osmaan 4:03 pm on December 11, 2015 Permalink | Log in to Reply

      +1 for email as an always-on fallback, and to verify a code for the first place.

      May be “require a constant in `wp-config.php` to *disable* 2FA”- should be a doable, too.

    • Mikel King 4:21 pm on December 11, 2015 Permalink | Log in to Reply

      I understand you feeling about the wp constant; however, why not reverse that process. Where normally we would have to define a constant to turn something on why not make it on by default and if you get into trouble you have to define DISABLE_2FA?

      That being said I just completed lighting up DUO Security’s 2fa system on our production sites and overall the users have embraced it. So I believe that it’s ready for primetime if you can make it work.

      On a side note does anyone else find the discussion of enhanced security and FTP in the same breath ironic?

      • George Stephanis 4:28 pm on December 11, 2015 Permalink | Log in to Reply

        I understand you feeling about the wp constant; however, why not reverse that process. Where normally we would have to define a constant to turn something on why not make it on by default and if you get into trouble you have to define DISABLE_2FA?

        We will be including at least one constant / filter or something to that effect to disable 2fa.

        I personally think filters is better than constants, as you can have multiple plugins messing with a filter no problem, but if two try to define the same constant, it’s sad christmas.

        • Omaar Osmaan 4:30 pm on December 11, 2015 Permalink | Log in to Reply

          From a end-user perspective, constants are easy to assign- as a Dev, I would prefer the filter, yes.

        • Mikel King 4:33 pm on December 11, 2015 Permalink | Log in to Reply

          If a user did something stupid locking themselves out would they need an mu-plugin to trigger the filter so that they could attain access again?

          • George Stephanis 4:39 pm on December 11, 2015 Permalink | Log in to Reply

            You mean with the proposed always available Email fallback that just emails them a code?

            • Mikel King 6:48 pm on December 11, 2015 Permalink

              I was thinking more of a mu-plugin that unlocks that user’s account. Similar to how you described the constant definition below. The advantage is that you could apply the filter to multiple account in said plugin. However the disadvantage is that most users & general site admins are not very savvy when it comes to mu-plugins so it’s a technical barrier…

          • Ipstenu (Mika Epstein) 10:40 pm on December 11, 2015 Permalink | Log in to Reply

            The issue there is that a required MU plugin means they have to have file access to the system AND know how to install that.

            And when they don’t, they’ll be putting undue burden on hosts who have to walk people through things.

            My issue (and this isn’t news to George) is that users do NOT know how to dig themselves out of holes, and if we’re throwing them into one (TFA) we damn well have to make sure they have a ladder accessible to the majority of users.

            Sadly that means email and confirm code before locking in. It’s the lowest common denominator.

        • idealien 6:13 pm on December 11, 2015 Permalink | Log in to Reply

          “We will be including at least one constant / filter or something to that effect to disable 2fa.”

          +1 for wp-config constant required to enable the 2FA feature.

          Please keep the use-case of sites that use LDAP for external validation in mind. All UI / strings / messages that trigger related to WP passwords should respect that constant / filter as any reference to a WP password just adds user confusion.

          If / when this does come to core – please set a higher standard than 4.3 release notes did at communicating the new messages and hooks to disable email notifications. Paint a clear picture between new / updated functionality and new / updated constants, hooks, filters, etc related to it.

    • AITpro 4:32 pm on December 11, 2015 Permalink | Log in to Reply

      There are some concerns regarding the large percentage of WordPress sites that are on servers that can’t send email (as high as 25% by some guesstimates I’ve heard floated), so we’d need to send a code and make sure it gets received before turning on the actual two-factor login prompt.

      In my experience over the past 5 years, I am seeing an increasing trend in automatic emails (PHP mail() vs direct emails sent from a computer email application like Outlook) being rejected due to anti-spam measures on sending and receiving Mail servers and 3rd party email services that automatically blacklist Mail Server IP addresses. At this point in time I would say 25% automated email failure/rejection is an accurate number. I imagine that that number will continue to increase steadily. So logically a fallback system like generating a non-email time sensitive encrypted/hashed string may be a smart move in the long run. Example: example.com/unlockme.php?action=foo&key=EwtNARIrmZEWBRTvYzdn&unlock=blah

      • AITpro 4:37 pm on December 11, 2015 Permalink | Log in to Reply

        Oops forgot to mention this very important point: When generating/sending emails from yourself to yourself from your own server there is not typically going to be a problem with automated emails being rejected. The problem occurs when dealing with different sending and receiving Mail Servers. ie someone is using a different Mail Server other than the origin Mail Server for that website.

      • George Stephanis 4:41 pm on December 11, 2015 Permalink | Log in to Reply

        We’re only keeping Email on as an emergency fallback. There are other providers that will be also included, such as TOTP (Google Authenticator), Backup Codes kept in a safe place, FIDO U2F usb security keys, and others.

        So it’s not a ‘purely email’ 2fa system. Just that email will always be available if you lose the other methods.

    • CotswoldPhoto 4:36 pm on December 11, 2015 Permalink | Log in to Reply

      My feeling is that you have 2 levels of user; those who are happy to edit wp-config.php and those that are not. So, why not add a switch in wp-config.php that by default is commented out? If a user is capable and willing to uncomment it to enable 2FA, they have no need of an emailed backdoor password. If they are locked out, they can edit the wp-config.php file to switch it back off. Then, a second level of enabling that requires the user to enable it in admin, where it will send out a ‘rescue’ email, or maybe just show the backdoor one time passkeys for them to copy? Once off the page, the keys are hashed. I seem to recall this is what Joomla used to (may still does?) do.
      Why should 2FA be in core? Security like this SHOULD be. Only with it in core will all the variety of user and alternative login plugins adopt and support the core code.

      • George Stephanis 4:43 pm on December 11, 2015 Permalink | Log in to Reply

        So, why not add a switch in wp-config.php that by default is commented out?

        For new installs, perhaps, but on updates wp-config.php is never touched, so this wouldn’t help most sites.

        • CotswoldPhoto 5:12 pm on December 11, 2015 Permalink | Log in to Reply

          But you could allow the more competent user to add the line? I have edited the wp-config.php file of every site I have ever made in WordPress.

          • George Stephanis 5:15 pm on December 11, 2015 Permalink | Log in to Reply

            Sure, and you’re certainly not a typical user, let alone those who don’t even know what FTP is. We need to do our best to make 2FA accessible to everyone, not just the privilege of the technically minded.

    • Brandon Kraft 4:48 pm on December 11, 2015 Permalink | Log in to Reply

      Another alternate idea: Infrastructure in Core, methods in plugins. At least initially.

      Instead of asking users to install possibly multiple, random plugins to provide multi-method 2fa, we put the infrastructure in Core, release the major methods via plugins (either a “special” status, a la the importers, assuming the #core-passwords group is willing to maintain it long-term).

      The current code allows for extending it through other plugins, so if new third-party solutions or new standards come out, Core provides an easy way to allow for that extendability while insuring some level of compatibility.

      /////////

      My fear with an e-mail backup, even if it is verified as working, could always stop working (moved hosts, shared hosts get blacklisted and the e-mail provider silently drops blacklisted e-mails). I’m not sure a way to ensure an always available 2fa method that isn’t open to some type of failure.

      • George Stephanis 4:50 pm on December 11, 2015 Permalink | Log in to Reply

        I really dislike shipping a whole infrastructure in core that does nothing, when we can easily provide solid implementations of some providers. It feels like we’re violating “Good Software should run Out of the Box”

    • Dave McHale 4:54 pm on December 11, 2015 Permalink | Log in to Reply

      Can you clarify the final point in the post? Would a filter/constant be available that disables the email functionality, or the 2FA itself?

      Similar to Brandon above, I’d be concerned with host failures, host moves, all sorts of variables that may change after-the-fact. While no solution will be perfect, I think, it seems sensible to me that at least a constant be provided for “if all hell breaks loose, set this constant in your wp-config to turn off 2FA entirely”. At least then a technical admin can disable the feature, log back in, and hopefully troubleshoot from there. As long as this is the case, I think the option provided definitely sounds like the most sensible of the alternatives listed.

      • George Stephanis 5:09 pm on December 11, 2015 Permalink | Log in to Reply

        Yes, regardless of everything else, there will be a constant to turn off 2FA. I’m thinking something like…

        `define( ‘DISABLE_2FA’, true );` — disables it entirely while the constant is in effect
        `define( ‘DISABLE_2FA’, 12 );` — disables it only for user ID 12
        `define( ‘DISABLE_2FA’, ‘bob’ );` — disables it only for username `bob`
        `define( ‘DISABLE_2FA’, ‘bob, jane’ );` — disables it for users `bob` and `jane`

        Some of these may be overthinking it, so I’m not sure what the final disable implementation will be, but all of these are feasible.

        • Brandon Kraft 5:13 pm on December 11, 2015 Permalink | Log in to Reply

          Should we have an UI for admins to tempoarily disable/reset/issue-backup-code for a particular user?

          (Or do we already? Haven’t ran the plugin on a multi-user site yet).

          • George Stephanis 5:14 pm on December 11, 2015 Permalink | Log in to Reply

            Yeah, we do already. Admins can disable other users methods just as they can change passwords and whatever.

            • Mikel King 6:43 pm on December 11, 2015 Permalink

              The real concern here is if it’s the admin that’s borked their 2fa access. I mean it is most important to ensure that every account with admin capabilities is using 2fa.

        • Dave McHale 5:20 pm on December 11, 2015 Permalink | Log in to Reply

          Nice. And I like those ideas. I would personally prefer to use them as one-off definitions, rather than allowing your fourth example with both users. If someone wants to turn it off for multiple users, I don’t see harm in making them just use two lines such as

          `define( ‘DISABLE_2FA’, ‘bob’ );`
          `define( ‘DISABLE_2FA’, ‘jane’ );`

          Still clean, and less potential for disaster while parsing out human-typed delimited input, too. Plus if you DO allow for multiple users by username, you would probably want to support multiple users by id, too, and that starts getting even messier, I think.

          Will per-user filters to disable 2FA be implemented by default as well? Will core support “2FA is turned on for this site, but you can check a box to have a single user opt OUT of using it”?

          • George Stephanis 5:21 pm on December 11, 2015 Permalink | Log in to Reply

            I see plenty of harm in that, insofar as a single constant can’t be defined twice. It’s a PHP thing.

            • Mikel King 6:40 pm on December 11, 2015 Permalink

              That’s exactly what I was thinking. I think the filter method may be the only way to hit multiple users at once.

          • George Stephanis 5:24 pm on December 11, 2015 Permalink | Log in to Reply

            Will per-user filters to disable 2FA be implemented by default as well? Will core support “2FA is turned on for this site, but you can check a box to have a single user opt OUT of using it”?

            Getting a bit out of scope for this discussion, but the filters will look something like

            `apply_filters( ‘user_can_2fa’, $configured, $user );` — or something akin to that, so you can use the filter to turn it on or off for either everyone or just specific users, based on their WP_User as passed to the filter.

            If you’d like to talk about this more in depth, please ping me in Slack? #core-passwords

        • Omaar Osmaan 1:59 pm on December 12, 2015 Permalink | Log in to Reply

          Multiple options for the constant looks good.

          But may be constant could be just to hard-disable the 2FA entirely- overriding the filters, and keep it simple. While the filter could provide all those flexibility to empower 2FA options.

    • rawrly 5:11 pm on December 11, 2015 Permalink | Log in to Reply

      Emailing a reset token for 2FA, is an ideal solution. Not only is it no-less secure than the current “forgot password” system, it leaves what is effectively evidence of tampering with someone’s wordpress site, on a third party server (the email server, assuming it’s hosted elsewhere.)

      Setting up an option in wp-config, i agree sounds odd. Wouldn’t the standard put this option setting in wp_options in the database? In cases where email reset tokens are not wanted, I’m sure that advanced user could use phpmyadmin or myql on the CLI just as easily as they could use vim/nano/pico/emacs. (What I mean here, it sounds like a lot of extra work for something to be non-standard and help a very small number of users)

      You however did not give a lot of credit for one-time use emergency tokens. Basically a “reset 2fa token” that never expires until deleted or used. These are somewhat of a standard for cases where touching the database is not an option (possible on some hosting platforms I am sure, if not for users being unfamiliar) and email might not be trusted enough verification (again, a fringe case, but maybe email service is broken on the WP site’s server). They wouldn’t have to be required to be generated if not wanted, and should not be the only option for resetting 2fa, but can be one more option that would cover almost all (including the most fringe) cases for 2fa users wanting access in case of emergency lost second factors (and as secure as their personal laptop/desk are.)

      • George Stephanis 5:39 pm on December 11, 2015 Permalink | Log in to Reply

        You however did not give a lot of credit for one-time use emergency tokens. Basically a “reset 2fa token” that never expires until deleted or used.

        We already have these fully implemented. But we can’t rely on them, because humans lose things.

        • TobiasBg 5:41 pm on December 11, 2015 Permalink | Log in to Reply

          One idea here could also be to show regular reminders every two-three months or so, when a user logs in, about whether a backup email address is still correct, how many backup codes have been used, etc., similar to how Google does it.

        • Mikel King 6:51 pm on December 11, 2015 Permalink | Log in to Reply

          Or worse forget to even save those tokens somewhere offline for future use. Or even worse yet store those OTP’s in a email folder that then get’s hacked and well Bob’s your uncle…

        • rawrly 7:51 pm on December 14, 2015 Permalink | Log in to Reply

          As long as it’s an option, that’s great. It certainly is a bit much to ask as the only solution for resetting 2FA.

    • Jon Brown 5:40 pm on December 11, 2015 Permalink | Log in to Reply

      Yes in core. Yes email fallback, but… have the ability to _disable_ email fall back via define in wp-config.

      Further, I definitely would like the ability to restrict 2FA to certain user roles. because:
      1) I don’t want to run into having to support membership users that enabled 2FA because it was there…
      2) I equally like the idea of mandating the administrators and editors use 2FA.

      Currently we handle (2) by using 2FA on /wp-login.php, but not requiring it on our custom /login pages. If an admin tries to login on /login they get denied and redirected to /wp-login.php. Pippin wrote a quick plugin for this on Restrict Content Pro: https://github.com/pippinsplugins/rcp-fatwpl/blob/master/rcp-force-admins-to-wp-login.php

      • George Stephanis 8:11 pm on December 11, 2015 Permalink | Log in to Reply

        but… have the ability to _disable_ email fall back via define in wp-config.

        Why a defined constant? I’d been expecting that we’d using a filter for that, but very eager to hear arguments in favor of a constant instead.

        Further, I definitely would like the ability to restrict 2FA to certain user roles. because:

        Both of these restrictions, forcing it on or off, will be totes doable, I expect, either globally, or on a user-by-user basis (and therefore on a user role basis)

    • Philip Ingram 6:03 pm on December 11, 2015 Permalink | Log in to Reply

      Yes in core, yes to email feedback, yes to disable via constant, yes to the idea of a unique randomized url for a traditional login fallback.

      Personally while I use a 2F plugin that works very well I can’t help but feel the dread of knowing this doesn’t really solve any of my REAL problems security-wise with my sites. While my sites don’t get hacked I still feel the pain of the hack attempts.

      Hackers bots are killing the web for WordPress sites. Every site I work on eventually becomes discovered and expects repeated hack attempts (sometimes upwards of thousands of hits per minutes) because there is no seamless and easy way to obscure that the site is running on WordPress. Changing the url and disabling xmlrpc is not a solution either but helps in some cases.

      I think the problem is much worse than protecting the login credentials. We need to be looking at how we can approach the problem of dealing with the constant knocking at the door costing against server resources and bandwidth resulting in poor performance and excessive hosting costs.

      Normally in a one-off scenario I would think this the responsibility of the IT/Server arena not the website application software however when one product powers 25% of the web, I think the responsibility crosses the barrier as only my WordPress site’s experience this problem on such a massive scale.

      There is such a wide number of hijacked IP addresses, blocking at the web server has very little effect and doesn’t address the amount of hits. Especially for those running on inexpensive shared servers hosting upwards of 6000 sites where the large majority are receiving constant bot activity specifically targeting WordPress sites.

      For some, the only approach for relief is to use a security DNS service that is already aware of the large majority of compromised IP addresses and block the attack before it even hits the web server. This comes at a price. Additionally, the different server builds adds complexity whether apache, nginx etc. so my thoughts are strongly leaning towards a way to finally be able to obscure a site is running WordPress. Is a free 3rd party filtering (firewalled DNS) service out of the question for an open source project like this? Could the means justify the cost of WordPress fixing the “WordPress” inherited security problem?

      On a similar scale, we see this problem spiraling out of control much like email spam where even the age old tradition of blacklisting isn’t very efficient anymore and more often a nuisance for legitimate users.

      • George Stephanis 8:17 pm on December 11, 2015 Permalink | Log in to Reply

        yes to the idea of a unique randomized url for a traditional login fallback.

        This feels just like the Backup Codes provider we already have, except instead of being per user, it’s global — and therefore a touch more dangerous. It would let anyone that knows the randomized url thingy bypass 2fa on any other user account, if it’s global. If it’s per user, then it’s just a more complicated version of backup codes.

        While my sites don’t get hacked I still feel the pain of the hack attempts.

        Have you considered the Protect module in Jetpack? It’s good at saving server load by exiting early on attempts from bad ip addresses. Unfortunately, it’s not something that can be done in Core WordPress, as it’s dependent on a third party server identifying the botnets trying to break into sites.

        Anyway, as fascinating as the topic is, I’m afraid it’s out of scope for this project, apart from 2FA making WordPress more difficult for botnets to crack into, and therefore less appealing.

    • Philip Ingram 8:55 pm on December 11, 2015 Permalink | Log in to Reply

      In regards to the randomized url, yes global is much simpler and if somehow a hacker figured out /wp-login.php?7c850yqbaude4cxr=ts43ng0t564dopl0 they’d still have to have a real username to brute force against but likely get locked in the first few attempts anyway. Another fail safe might be to email notify an admin of the attempt of a failed login via that obscure url so it could be changed immediately.

      I’d prefer wp-login.php was no longer a constant. I know obscurity is not considered a good practice for website security but the lack of obscurity it what puts my sites on the radar in the first place. No one seems to care about hacking my non-wp sites.

      While not off topic by any means I do understand this is out of scope but thanks for allowing me to post my thoughts regardless.

    • dmccan 11:01 pm on December 11, 2015 Permalink | Log in to Reply

      If I read the old session notes correctly, this discussion is really the lowest common denominator fallback for sites that cannot or don’t implement additional 2FA options or for times when alternatives aren’t available (such as cell phone loss). For example, it looks like there is to be support for using the Google Authenticator service. It has clients for Android and iOS. So, I think you are on a good track with the plan as outlined.

      FWIW, WordPress.com has 2FA with SMS recovery. I know JetPack is separate, but perhaps the JetPack team would allow JetPack users to register their cell phone number for account recovery as another option.

    • Ryan Hellyer 4:34 am on December 12, 2015 Permalink | Log in to Reply

      It sounds like you guys have done an excellent job on this. The email backup solution sounds perfect.

    • Jon (Kenshino) 10:27 am on December 12, 2015 Permalink | Log in to Reply

      Loving the discussion

      But just to make things clear…. When the Support Team suggested having email by default as a fall-back, it isn’t the same as having it as the only fall back.

      Our suggestion really focuses on – is there any easy, non-code way for the normal users to get back to logging in if they really have no idea what they’re enabling.

      Once they’re comfortable and/or they are advanced users, they can swap out the email fall back to some other fall back. But they must always have 2 levels of providers to allow them to login. (Or possibly use a filter to deactivate that requirement, once they are able to put in code, that shows a level of tech competency whereby we can take off the training wheels)

      I have the experience of getting to WCUS, trying to login Facebook only to find it disabled because me being in another country. My backup phone number was unfortunately not one that had roaming enabled. Facebook wanted my photo ID and other really intimate details that I had no intention to give so I gave up and logged in when I returned.

      Users should always have the choice to select the providers that they are comfortable with.

      And do remember though, admins must also have to be comfortable to support 2FA. Normal subscriber roles on websites shouldn’t be able to enable 2FA if the admins don’t even know what it is or at least how it works on WordPress. Administrators should definitely be given the master button like how it is implemented by Google Apps.

    • Doug Smith 3:33 pm on December 12, 2015 Permalink | Log in to Reply

      The regular username / password login can be reset by e-mail as a fallback. A major use case for a second factor is to protect against something like a compromised e-mail account being used to reset logins. Doesn’t using the same fallback for factors then effectively remove the second factor?

    • Michael Arestad 8:53 pm on December 12, 2015 Permalink | Log in to Reply

      I’m still very much on the fence with this being in core from a user experience standpoint. I’m really worried about people locking themselves out one way or another. I’m worried about the ease of use. I’m worried about users avoiding it altogether.

      If it feels really nice to use and isn’t presenting people with tons of settings (kinda like Slack’s email login, but that’s probably more like 1fa), then I’d be more comfortable with it.

      If it’s something that only a very few will use, I would prefer it not be in core. My gut feeling is that adoption of it would be low for a few reasons:
      1. 2fa can be pretty confusing.
      2. It requires some aspect of app switching (to check email/text/etc) to do it. If it’s pretty dang tedious to do and makes you think, why do it?
      3. They have never used it before, so why use it now?

      I want to see where this ends up before I weigh in either way, though. I think it’s definitely needed, but maybe not wanted by the majority of users. I like @kraftbj‘s suggestion of at the very least maybe providing the infrastructure in core (if needed) for 2fa plugins.

    • thetechnuttyuk 1:37 pm on January 25, 2016 Permalink | Log in to Reply

      I noticed this today, so sorry I’m a bit late to the party, I just need to mention my thoughts on WordPress integrating 2FA directly into WordPress, as I have a problem with it.

      That problem is that generally WordPress likes to add features without a turn-off switch, srcset was a recent example of that. 2FA would need to have a turn off switch, that completely turns it off, not just kinda turns it off, completely turns it off, not only because not everyone wants to use it, but because some people want to use software that is better than what WordPress is likely going to integrate, Duo Security being the perfect example of that.

      For that reason, I believe it’s better to simply keep this feature as a plugin addition, maybe ask the user if they want to add it via something like Jetpack, or just showing a message in Core, but honestly, this should not be a built-in feature that has no option for turning off, without adding code in files you’ll forget about and replace a year later.

  • Daniel Bachhuber 9:30 pm on November 2, 2015 Permalink
    Tags: , , , , , updates   

    Shortcake (Shortcode UI) chat summary – November 2nd, 2015 

    Present: @danielbachhuber, @goldenapples, @matth_eu

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

    • We released Shortcake v0.6.0. Read through the full release notes.
    • Weekly meetings are on hold until January. Between now and then, we’ll be thinking about what we need to do to put forth a core proposal. @matth_eu might put together sketches.
    • We missed the boat on getting a Shortcake representative to the community summit, and are researching ways to helicopter @goldenapples to said community summit boat.

    Next chat: sometime in January 2016

     
  • Daniel Bachhuber 7:42 pm on October 5, 2015 Permalink
    Tags: , , , , , updates   

    Shortcake (Shortcode UI) chat summary – October 5th, 2015 

    Present: @danielbachhuber, @goldenapples, @matth_eu

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

    • Matt’s making process on support for encoding HTML in attributes. Gallery functionality is also almost done, but there’s one small bug.
    • Than started work on trying to add some filters that can be used to handle floated/non-block previews. It still some work to go, as it’ll involve overriding some methods deep in mce.view.
    • Daniel will hit up the backlog when he has a moment, as there are a number of unanswered open issues.
    • We discussed inline editing and agreed upon an ideal abstraction .

    Next chat: same time and place

    Next release: v0.6.0 – Tuesday, November 3rd

     
  • Joe McGill 10:21 pm on September 5, 2015 Permalink
    Tags: , , , updates   

    Responsive Images Feature Plugin Update 

    Following up on our first official project update, here’s a brief status update to keep everyone informed about the progress we’ve made.

    Updates

    • Released v2.4.0 early last week, fixing several bugs and adding a few filters (changelog). Please test on your sites and leave us feedback!
    • Created placeholder tickets for adding srcset and sizes support ( #33641 ) and improving the compression settings of Imagick ( #33642 ).
    • @jaspermdegroot is digging into the content filter approach to support responsive images for old posts. Performance tests and details on GitHub. Feedback appreciated!

    Next Steps

    We’re ready to create an initial patch candidate for core. We’ll be working on that over the next week, with a more detailed update at that time.

    Check out the logs from our last meeting and join us for the next one on Friday at 19:00 UTC in #feature-respimg.

    Questions? Please leave feedback below, or ask anytime in #feature-respimg.

     
  • Pascal Birchler 6:31 am on September 2, 2015 Permalink
    Tags: , , , updates   

    oEmbed Feature Plugin Update 

    After kicking off the oEmbed feature plugin a couple of weeks ago, it’s high time for another status update.

    In case you have missed it, the oEmbed API plugin makes WordPress an oEmbed provider, allowing you to embed blog posts just like YouTube videos or tweets. Of course everything happens with security and ease-of-use in mind.

    oEmbed Feature Plugin

    Embedding a post is super simple!

    We made some great progress over the last few weeks. The highlights are:

    • Improved test coverage, which led to many fixed bugs
    • Auto-resizing of the embedded iframe so it looks great on every screen
    • It seamlessly integrates with the REST API, but also works perfectly without it

    The plugin is very stable so far. We’re looking into bringing it to WordPress.com for testing, but of course we also need your help to bring this further! Download the plugin from the repository — play with it, break it, and help us fixing all bugs that may appear. We’re always looking for areas to improve.

    We’re now mainly working on getting it into shape for an eventual core merge proposal and implementing the different oEmbed response types. This means supporting embedding attachment posts and posts with different post formats.

    Please, test and report both errors and suggestions either on GitHub or our #feature-oembed Slack channel. Anyone is welcome to join us!

    Next chat: September 7 2015 9pm UTC

     
  • Daniel Bachhuber 8:16 pm on August 31, 2015 Permalink
    Tags: , , , , , updates   

    Shortcake (Shortcode UI) chat summary – August 31st, 2015 

    Present: @danielbachhuber, @matth_eu

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

    Next chat: same time and place

    Next release: v0.6.0 – Tuesday, November 3rd

     
  • George Stephanis 2:31 pm on August 31, 2015 Permalink
    Tags: , , updates   

    Two-Factor Auth Update 

    It’s been a couple weeks since our last update, but we’ve had some solid headway in the last couple days!

    Current status of default providers:

    • Email: In and works.
    • FIDO U2F: In and works, but only for PHP 5.3+ (library dependency, non-trivial to revise for 5.2)
    • Backup Codes: In and works.
    • TOTP (Google Authenticator): Pull request open (several, actually), I expect to see it merged in the next couple days.

    For the providers that are in and works, there may be minor issues either via code architecture or enhancements like better ui / ajax or whatnot — it’s just easier to solve those via small pull requests to master, versus endlessly debating in a pull request without actually merging it in. 🙂

    Application Passwords are also included in the plugin currently, however I’m not sure whether they should be a part of it or not in the end — they are included to allow users who use two-factor authentication to still use xml-rpc functionality, which can’t support two-factor authentication.

    For TOTP, we will need to be able to generate QR codes, and the de facto standard library I’ve found for generating them locally seems to be https://github.com/kazuhikoarase/qrcode-generator — which has both PHP and JS implementations and is MIT licensed. I’m currently leaning towards the JS implementation, but I’d be fine with PHP instead. Either way works just as easily.

    Please, test and report both errors and suggestions either on GitHub or on our Slack channel — #core-passwords.

    As always, our next chat will be on Thursday at 5pm Eastern, in #core-passwords.

     
    • JeanPaulH 2:58 pm on August 31, 2015 Permalink | Log in to Reply

      We’d love to have application password support, so please keep supporting this.

    • Aaron D. Campbell 3:18 pm on August 31, 2015 Permalink | Log in to Reply

      I think app passwords are important. I’m honestly wondering though if they shouldn’t basically be another provider (thus making them something that can be turned off rather than just not used).

      As for QR codes, I can definitely see the merits of both the JS and PHP methods. I still have a hard time breaking myself out of the old school rut of “don’t rely on JS”. It seems like using a PHP library would allow you to still function without JS while still using JS to augment and enhance the functionality (like regenerating the QR code via an httprequest.

      Having said that, the JS library I’ve used for this before was https://github.com/jeromeetienne/jquery-qrcode/ (also MIT). It still works well, but it looks like it hasn’t seen any love in the last year.

      • George Stephanis 3:15 pm on September 2, 2015 Permalink | Log in to Reply

        The jQuery QRCode library you linked actually just uses the one that I linked — https://github.com/jeromeetienne/jquery-qrcode/blob/master/src/qrcode.js — to generate the image itself. (like I said, it seems to be the de facto standard)

        I don’t think application passwords can be just another provider — as they aren’t used in the same way. They’re not used as the second step, and only work on non-interactive logins. That is, if someone has an Application Password, they should only be able to use it for xmlrpc or the like — not actually logging in to the admin panel as you.

  • Joe McGill 11:35 pm on August 25, 2015 Permalink
    Tags: , , , updates   

    Update: Responsive Image Support for Core 

    The responsive image team has been meeting regularly for a while. After our meeting earlier this week, we realized that make/core needs an update on what’s been going on with the RICG (Responsive Images Community Group) feature plugin, as well as to request feedback on a few questions.

    Our meetings are in #feature-respimg each Friday at 1900 UTC, so please come and chat to give feedback or if you’re interested in helping out!

    Background

    Several years ago, a ragtag group of web professionals identified a need for new HTML markup which would allow developers to declare multiple sources for an image—allowing devices to select the image source that was most appropriate for its own capabilities. Fast forward to today and all major browsers have either implemented these new tools or currently have them under consideration for development.

    With that as background, the RICG has been working on an Official WordPress Feature Plugin™ to test the viability of adding responsive image support natively into WordPress. Specifically, our aim is to automatically add srcset (using w descriptors) and sizes attributes to the image markup generated by WordPress. According to the WordPress.org plugin directory, there are over 10k active installs, so we’ve definitely seen an interest in this functionality.

    There are two main pieces of functionality included in the plugin, which can be considered separately for inclusion in core:

    1. Logic for producing responsive image markup
    2. Advanced image compression (via ImageMagick)

    Responsive Image Markup

    There is a lot to consider when proposing a change to the way WordPress outputs image markup, so I want to be clear about some of our assumptions going in:

    • Responsive image support should be added ‘invisibly’ without introducing new settings for users to worry about.
    • WordPress, out of the box, should only deal with resolution switching, and not the art direction use case for now. In other words, we would not be adding any API or admin UI for outputting different cropped images at specific breakpoints. (For more information about use cases and all things related to responsive images, I’d recommend reading the terrific Responsive Image 101 series by Jason Grigsby).
    • Provide this functionality using default and available user-defined sizes (via add_image_size()) for source sets rather than creating an additional set of crops. This choice is based on early feedback from Nacin regarding file-count concerns on some shared hosts.
    • Provide filter hooks so theme/plugin authors can extend/override defaults.
    • All sizes of an image (i.e., _wp_attachment_metadata['sizes']) with the same aspect ratio are resized versions of the same image, not custom art directed crops. This assumption has been okay so far, but there may be be plugins that replace the default image sizes with art directed crops that maintain the same aspect ratio. We’ll need to determine how to handle these cases.

    Questions to Consider

    1. How should we handle markup embedded in post content?
      • Currently, we embed the srcset attribute directly into posts with sizes added as a data attribute to make it easier for theme authors to filter the sizes attribute later. It’s tricky to decide when it’s appropriate to add layout relative markup to the database, but WordPress is currently doing this to a certain extent by adding width/height attributes to images, so this may be the best solution for now.
      • Instead, a more elegant solution would be to filter the content on output. This would avoid saving layout markup in the database, and extend support to posts with images that were published before the feature became available. We have a proof of concept but are unsure if adding another filter to the_content is appropriate. Confirmation either way on this question would help us move forward.
    2. Should we support srcset and sizes in older browsers?
      • The plugin includes the picturefill.js polyfill, which provides support for older browsers, but would be a new dependency for core.
      • We could view srcset and sizes as a progressive enhancement and only provide support in WordPress for newer browsers. In that case, we could drop the polyfill and save WordPress an extra JS dependency. Note that this polyfill is written by the same people writing and implementing the spec. We consider it to be very reliable.
    3. Should we turn responsive image support on by default?
      • “Decisions not options.” We propose that responsive images are enabled by default in core, with filters provided for disabling or modifying the feature.
      • If core does not want responsive images enabled by default, they could be enabled through a current_theme_supports() flag. Themes would have to “opt-in” to the feature.

    Advanced Image Compression

    The second potential enhancement introduced through our plugin is an improvement to the default ImageMagick compression settings currently being used in core. RICG contributor Dave Newton has done great research on the best compression settings for ImageMagick, and included them as an opt-in option within the plugin.

    The updated settings are absolutely killer when there are sufficient CPU and memory resources on the host server. In our trials, file sizes have decreased by >50% compared to the default core settings.

    However, on limited servers, these new settings could cause problems. We are iterating on them to find the right balance between the file-size savings and the CPU resources required to process large files.

    Final Notes

    We need your help!

    New features need lots of feedback and testing. Help us test these enhancements by installing the latest version of the plugin from WordPress.org.

    Be sure to enable advanced image compression and tell us how it does with your setup so we can gather more feedback.

    If you know of plugins that heavily modify or interact with custom image sizes or art-directed crops, please leave a comment below so we can test it with this feature.

    Have thoughts on the questions above? Let us know in the comments!

    Want to get involved? We meet each week in #feature-respimg on Friday at 1900 UTC.

     
    • Ahmad Awais 1:08 am on August 26, 2015 Permalink | Log in to Reply

      Will join the next meeting. Let’s do it.

    • bravokeyl 1:58 am on August 26, 2015 Permalink | Log in to Reply

      It’s a good one , but is “ element getting traction from specifications ?

      • wilto 2:49 pm on August 26, 2015 Permalink | Log in to Reply

        Yes indeed! All of the markup patterns used by the plugin are part of the HTML Living Standard:
        https://html.spec.whatwg.org/multipage/embedded-content.html#embedded-content

        While the plugin is using Picturefill for the sake of older browsers, all modern browser support this markup natively to some extent—current versions of Firefox and Chrome support it fully, while Safari and Microsoft Edge have partial support. Picturefill polyfills these features in a granular way, so anything that can work natively will, while anything without native support will be shimmed.

    • Robert Chapin 2:10 am on August 26, 2015 Permalink | Log in to Reply

      For the HiDPI Gravatars plugin, I’ve been referencing caniuse.com with the “Usage Relative” option selected. We really are at the point now where Internet Explorer 11 is the only significant browser without support for srcset. Decide accordingly. Is it really worth adding core bloat to support IE 11? Would it benefit anyone other than Surface users? Are the accessibility benefits for desktop just as easily acheived in Chrome?

      • Joe McGill 2:00 pm on August 26, 2015 Permalink | Log in to Reply

        This is almost true. As of today, Safari only supports `srcset` with x descriptors so the polyfill is still needed to support w descriptors and `sizes`. There are signs that the next version will include full support, but that is currently not the case.

    • Michael Arestad 2:21 am on August 26, 2015 Permalink | Log in to Reply

      > 2. Should we support srcset and sizes in older browsers?

      No. No need. this can gracefully degrade.

      > 3. Should we turn responsive image support on by default?

      This is definitely the hardest question and might answer itself during larger-scale testing. Going forward, it would make sense to unless it breaks a bunch of themes that do crop the attachment images (or do something else funky).

      • Joe McGill 2:07 pm on August 26, 2015 Permalink | Log in to Reply

        Thanks Michael,

        As a counter argument for supporting srcset and sizes in older browsers: with many older devices being in use around the world, I wonder if the addition of the polyfill—at just over 11kb minified—is worth the potential bandwidth savings that would be gained by potentially loading smaller image sources.

    • padams 6:25 am on August 26, 2015 Permalink | Log in to Reply

      Responsive images are probably not going to be very useful unless the theme itself has a responsive design. Did you guys think about making themes declare support for responsive images instead of making it a global on/off setting?

      • tevko 1:13 am on August 27, 2015 Permalink | Log in to Reply

        Hey padams, since we’re using the srcset attribute with sizes, responsive images will help regardless of fixed width or fluid designs. This is because the srcset / sizes combination works to deliver the best image size based on the users screen resolution and viewport width. This means that two different devices at the same width could get a different image, simply because their screen resolutions are different. This is great for the user because it means that their device will get the best looking image regardless of viewport size.

    • Monika 6:42 am on August 26, 2015 Permalink | Log in to Reply

      >> 3. Should we turn responsive image support on by default?

      >>>If core does not want responsive images enabled by default, they could be enabled through a current_theme_supports() flag. Themes would have to “opt-in” to the feature.

      yes please!

      Why:
      1. RICG This plugin works by including all available image sizes for each image upload.

      Most of the time we don’t need “all” image sizes , thats why I preferr
      https://wordpress.org/plugins/responsify-wp/

      it is easier to use as RICG if I don’t want all image sizes

      Feedback: If I’m using: ‘advanced-image-compression

      my upload failes
      256php memory

    • kuzvac 7:11 am on August 26, 2015 Permalink | Log in to Reply

      Please use “picture” element instead of srcset! Picture element already have backward compatibility to older browsers. https://dev.opera.com/articles/native-responsive-images/
      And use cases https://dev.opera.com/articles/responsive-images/
      And progressive jpg, god, yes.

      • wilto 2:54 pm on August 26, 2015 Permalink | Log in to Reply

        For a “fully automated” situation like this one, we’re apt to get a much better result using `srcset`/`sizes`. `picture` is intended for “art direction” use cases, where there’s a need to set explicit and very specific breakpoints based on the viewport, with the image sources themselves varying slightly. All the `srcset` syntaxes, however, allow the browser to choose the best fit from a list of sources that are identical (apart from their dimensions). `srcset` factor’s in the user’s display density, the size of the image _in the layout_ (rather than based on the viewport), and soon additional factors like a user preference or a bandwidth cap. Since WP will be generating all the different cuts of an image, we end up with something completely seamless: smaller images for the user and no wall of breakpoint decisions for the image uploader.

        And no worries about backwards compatibility—that’s covered with `srcset` as well, either via Picturefill or via the old-fashioned `src` attribute on `img`.

    • Brad Touesnard 11:48 am on August 26, 2015 Permalink | Log in to Reply

      > 2. Should we support srcset and sizes in older browsers?

      I think by default they should not be supported in older browsers, but it should be easy to just install & activate an official plugin to enable them for older browsers.

      > 3. Should we turn responsive image support on by default?

      I suggested the `current_theme_supports()` flag on Slack. I think it should be up to the theme to turn on responsive image support. If the theme is designed for WordPress’ current image resizing it’s not very likely to work well with responsive images.

      I’d like to see the image compression stuff spun off into it’s own independent plugin. Is there a reason it is lumped in with the responsive image stuff?

      • tevko 1:31 am on August 27, 2015 Permalink | Log in to Reply

        Hey Brad, thanks for the feedback.

        Regarding your first point, seeing that RICG Responsive Images is the official plugin, and that plugin provides fallback support, it would seem natural to assume that if integrated into WP Core, fallback support would also be provided.

        Additionally, being an interfaceless plugin that runs behind the scenes, it wouldn’t be readily apparent to users that something else would need to be installed in order to provide fallback support. I think bundling a small polyfill in with the feature would make it easiest on all users. The ability to dequeue the polyfill also exists and has been documented here – https://github.com/ResponsiveImagesCG/wp-tevko-responsive-images#tevkori_get_srcset_string-id-size-

    • John Huebner 12:36 pm on August 26, 2015 Permalink | Log in to Reply

      > In other words, we would not be adding any API or admin UI for outputting different cropped images at specific breakpoints.

      Just my thoughts on this one aspect. While it would be great to have something built into WP automatically handle responsive images, without the ability to specify different images this will not be of much value in the work that I’m required to do. Using the automatically generated images will only be of use to the most generic users. I don’t think I have a single client that would be happy with this model, which is why I don’t use the plugin mentioned.

      • wilto 3:01 pm on August 26, 2015 Permalink | Log in to Reply

        We’re totally agreed that the “art direction” use case covered by the `picture` element—and the accompanying UI changes that would have to go into uploading images—is a valuable one. It’s in the planning stages now.

        However, just like you said, this _is_ a feature of use to the most generic users: anyone putting together a responsive theme that contains large images. If you’ve got visitors to your site using small viewports or low-density displays and you’ve got a theme that contains large or high-resolution images, adding this feature to core ensures that you’re not serving massive images to small viewports or high-density images to low-density displays—situations where the user will see no benefit, but be forced to incur an additional cost.

        It’s better to think of this as a behind-the-scenes enhancement to images, rather than a situation where your client will need to pick and choose breakpoints. Rolling out these features on FT.com resulted in a 66% reduction in image weight*. On my current project we’re looking at an ~80% reduction on 320px, low-density displays, without any changes to the uploader workflow.

    • Nicolas Juen 3:32 pm on August 26, 2015 Permalink | Log in to Reply

      Hi,
      I’m glad this feature is coming to the core, in my agency we are already using a custom solution for this consisting of this plugin (https://github.com/asadowski10/advanced-responsive-images) + WP_Thumb.
      The difference here is that the frontend developper is defining locations on json file, and associate image sizes + breakpoints wich are defined in one other file.
      Then on post_thumbnail function we call with one arg (data-location) with the location defined on json file. This allow us to handle multiple display cases, like in the slider, content, widget area etc.

      Is this conception have been tough ? Is this core functionnality will be hackable so we can do like this ?
      We are using picture fill too but it’s not compatible with lazyload, some libraries do and use the picture element, wich is pretty different from srcset.

    • Ricard Torres 8:18 pm on August 26, 2015 Permalink | Log in to Reply

      One of the top plugins out there that deals with images: https://wordpress.org/plugins/regenerate-thumbnails/

    • Phil Smart 11:57 pm on August 26, 2015 Permalink | Log in to Reply

      I’m just going to weight in quickly and say that I actually like the idea of what the Fusion guys are exploring with their plugin, Image Shortcake (http://fusion.net/story/144755/introducing-image-shortcake-v0-1-0/).

      Their basic approach is to add images to TinyMCE as shortcodes – instead of direct markup – giving them the flexibility to dynamically implement whatever specific markup they need.

      I know it’s a stepping a little deeper than straight up responsive image support, but storing images as shortcodes does seem to be a great starting point for then folding in (and easily updating) necessary markup.

    • Morten Rand-Hendriksen 5:14 pm on August 27, 2015 Permalink | Log in to Reply

      Quick answers:

      1. As you probably know from my blog posts, I am a proponent of the filter-on-output solution. For responsive images to work as effectively as the spec allows, theme and plugin devs have to be able to define the actual display sizes of images through variables. For that to work, the HTML output must be filtered based on current theme and plugins. This will cause some issues with caching services and CDNs, but I think that’s a minor concern. The one thing I hope can be avoided is the blanket approach of sizes=”100w, [original_image_size]”

      2. Backwards compatibility within reason is impoetatn because those that will benefit the most from this development (people on slow / low bandwidth / expensive connections and older devices) often use older browsers.

      3. Yes, turn it on by default. This should be invisible and transparent. We have a major opportunity here to use WordPress to push web standards forward, and that cannonly happen if we make some serious commitments like this.

      Great work to everyone who has been working on this. I am very excited about this plugin and its potential.

  • Daniel Bachhuber 8:11 pm on August 24, 2015 Permalink
    Tags: , , , , updates   

    Shortcake (Shortcode UI) chat summary – August 24th, 2015 

    Present: @danielbachhuber, @goldenapples, @miqrogroove, @azaozz

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

    • We triaged the remaining issues for v0.5.0. Daniel will be picking them up over the next day.
    • A big project for v0.6.0 will be to go through core’s feature plugin guidelines and identify what we need to change to be valid.
    • Spent time discussing @miqrogroove summary of shortcode problems, and proposed solutions

    Next chat: same time and place

    Next release: v0.5.0 – this week (a bit overdue)

     
  • Ryan McCue 7:29 am on August 14, 2015 Permalink
    Tags: , , , , updates   

    WP REST API: Versions 1.2.3 (Security Release) and 2.0 Beta 4 

    First and foremost: version 1.2.3 of the REST API is now available. Download it from the plugin repository or from GitHub. This is a security release affecting sites running version 1.2 or a 2.0 beta releases.

    Security Release

    Recently, we were alerted to a potential XSS vulnerability introduced in version 1.2 of the API related to the JSONP support. This vulnerability also existed in version 2.0. Thanks to Alex Concha (@xknown) for reporting this issue to the team responsibly.

    This release was coordinated by the REST API team and the WordPress core security team. The security team is pushing automatic updates for version 1.2.3, but do not wait or rely on the automatic update process. We recommend sites or plugins that are using either v1.2.x or 2.0 beta releases update the plugin immediately.

    If you’d prefer not to upgrade, you can instead disable JSONP support through a filter. For version 1:

    add_filter( 'json_jsonp_enabled', '__return_false' );

    To disable JSONP on version 2:

    add_filter( 'rest_jsonp_enabled', '__return_false' );

    If you have a question about the security release, you can find the team in #core-restapi on WordPress.org Slack, or you can privately message @rachelbaker, @rmccue, @danielbachhuber, or @joehoyle.

    Version 2.0 Beta 4

    Alongside the security release for version 1.2, we’re also releasing the latest beta for version 2.0: 2.0 Beta 4 “See My Vest”. You can download this from the plugin repository or from GitHub.

    This beta release includes the security fix from version 1.2.3, so we recommend everyone running a version 2 beta update immediately to fix the issue.

    As well as the security release, this beta also includes a bunch of other changes. Here’s some highlights:

    • Show public user information through the user controller.

      In WordPress as of r32683 (scheduled for 4.3), WP_User_Query now has support for getting users with published posts. To match current behaviour in WordPress themes and feeds, we now expose this public user information. This includes the avatar, description, user ID, custom URL, display name, and URL, for users who have published at least one post on the site. This information is available to all clients; other fields and data for all users are still only available when authenticated.

    • Send schema in OPTIONS requests and index.

      Rather than using separate /schema endpoints, the schema for items is now available through an OPTIONS request to the route. This means that full documentation is now available for endpoints through an OPTIONS request; this includes available methods, what data you can pass to the endpoint, and the data you’ll get back.

      ⚠️ This breaks backwards compatibility for clients relying on schemas being at their own routes. These clients should instead send OPTIONS requests.

    • Update JavaScript API for version 2.

      Our fantastic JavaScript API from version 1 is now available for version 2, refreshed with the latest and greatest changes. Thanks to Taylor Lovett (@tlovett1), K. Adam White (@kadamwhite) and Nathan Rice (@nathanrice).

    • Embed links inside items in a collection.

      Previously when fetching a collection of items, you only received the items themselves. No longer! You can now request a collection with embeds enabled (try /wp/v2/posts?_embed).

    • Move /posts WP_Query vars back to filter param.

      In version 1, we had internal WP_Query vars available via filter (e.g. filter[s]=search+term). For our first betas of version 2, we tried something different and exposed these directly on the endpoint. The experiment has now concluded; we didn’t like this that much, so filter is back.

      ⚠️ This breaks backwards compatibility for users using WP Query vars. Simply change your x=y parameter to filter[x]=y.

    • Respect rest_base for taxonomies.

      ⚠️ This breaks backwards compatibility by changing the /wp/v2/posts/{id}/terms/post_tag endpoint to /wp/v2/posts/{id}/tag.

    As always, we have a detailed changelog as well as the full set of changes if you’re interested.

    (Note that while this version 2 beta breaks backwards compatibility, the 1.2.3 security release does not break compatibility with the 1.2 branch.)

    This release had 11 contributors, and we’d like to thank each and every one of them:

    $ git shortlog 2.0-beta3...2.0-beta4 --summary
         1   Daniel Bachhuber
        11   Daniel Jalkut
         1   Fredrik Forsmo
         1   Jared Cobb
         3   Jay Dolan
        26   Joe Hoyle
        10   Josh Pollock
        25   Rachel Baker
        50   Ryan McCue
        24   Stephen Edgar
         8   Taylor Lovett
    

    Thank you again to all of our beta testers, and thanks to everyone who let us know how you’re using the API. We’re taking note of all of your feedback, and you might see some further changes related to that in coming releases.

     
    • Ahmad Awais 8:18 am on August 14, 2015 Permalink | Log in to Reply

      Hey, Ryan!
      Did you change the folder name or main file name in WP REST API 1.2.3 since I am using 1.2.2 and I didn’t get any update notification, which is weird.

      • Ryan McCue 10:10 pm on August 14, 2015 Permalink | Log in to Reply

        The patch in 1.2.3 is minimal and didn’t change the filename. If you’re using the API from GitHub, your folder might accidentally be called WP-API, whereas it should be json-rest-api to match the repo.

    • CotswoldPhoto 9:40 am on August 14, 2015 Permalink | Log in to Reply

      Great work team REST API. I really hope that this makes it into core for 4.4.

    • Rachel Baker 12:56 pm on August 14, 2015 Permalink | Log in to Reply

      Oh, please won’t you see my vest! 🎶

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