WordPress.org

Make WordPress Core

Updates from George Stephanis Toggle Comment Threads | Keyboard Shortcuts

  • George Stephanis 3:16 pm on January 27, 2016 Permalink |
    Tags: ,   

    The Two-Factor Plugin is currently on a brief hiatus, while we work on splitting off it’s Application Passwords feature into a smaller, solo feature plugin.

    https://github.com/georgestephanis/application-passwords/

    Application Passwords was initially a sub-feature of Two-Factor Authentication, but due to the fact that we had very little confidence in Two-Factor being ready for the 4.5 cycle, we spun off a nearly-complete sub-feature that may mesh very well with the existing REST API.

    Application Passwords lets each user choose to generate “Application Passwords” — randomly generated 16-character alphanumeric codes, that are only displayed to the user once, upon creation. These passwords can be revoked either individually or all at once, and track usage, so in the admin UI you can view the most recent IP and Date that the password in question was used.

    The passwords are only valid for non-interactive prompts. That is, for use with our XML-RPC and REST APIs. They can not be used on `wp-login.php` or to access the admin panel. The idea is that each application you connect to your WordPress account — a mobile app, if this then that, Microsoft Word, or some sort of local blogging software, they all have their own password that can be revoked if the device is lost or no longer in usage, all without dispensing full access to your account.

    For folks building a quick one-off script that needs to tie into WordPress, this is far simpler than using the obscure oAuth version that Core has to use because we can’t guarantee HTTPS, and far more secure than the existing “use your account password for api calls” standalone plugin, that many folks would likely choose to default to otherwise.

    Screen Shot

    Code reviews, issues, and pull requests are very welcome.

     
    • Mikel King 3:53 pm on January 27, 2016 Permalink | Log in to Reply

      Awesome thanks for this!

    • Laurens Offereins 4:29 pm on January 27, 2016 Permalink | Log in to Reply

      Interesting. Am I wrong to say this is like GitHub’s access tokens? Would this be useful for, let’s say, making user-specific RSS feeds, allowing private posts in the feed? I’ve for long wanted a unified interface for creating user-specific access keys.

      • George Stephanis 8:33 pm on January 27, 2016 Permalink | Log in to Reply

        Hrm, well, RSS feeds don’t ordinarily require authentication, but I guess you could use it as authentication on a JSON API endpoint that gives similar data and tailor it to a user.

    • Scott Kingsley Clark 5:56 pm on January 27, 2016 Permalink | Log in to Reply

      I love this feature, looking forward to it!

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

    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.

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

    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.

  • George Stephanis 12:10 pm on August 3, 2015 Permalink
    Tags: , ,   

    Two-Factor Authentication Weekly Update! 

    We met on Thursday and discussed the providers in progress — TOTP, FIDO U2F, and Backup Codes.

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

    In Attendance:

    Last week we merged in the functionality to support fallback methods and have a great pull from @valendesigns to better automate the workflows and systems, as well as adding in some unit tests — https://github.com/georgestephanis/two-factor/pull/8

    We also need some Design help with some flows and options screens, so if any designers are interested in pitching in, let me know! 🙂

    Next meeting will be Thursday, August 6th at 21:00 UTC

     
  • George Stephanis 12:09 pm on July 24, 2015 Permalink
    Tags: , ,   

    Two Factor Meeting Recap 

    Next week’s meeting will be on July 30th, 2015 at 17:00 ET — two hours later than this week’s meeting, to try and not drop it at 4am for some of our people.

    Log: https://wordpress.slack.com/archives/core-passwords/p1437678027000327

    Folks in attendance:

    @georgestephanis
    @bjornjohansen
    @swissspidy
    @stevenkword
    @aaroncampbell
    @jeffmatson
    @extendwings
    @cconover
    @julien731
    @deltafactory
    @tomdxw
    @valendesigns

    Reviewed rough plans with authentication provider classes and who is working on each. @julien731 has a wealth of experience with TOTP and @extendwings with U2F, and will likely be helping with each respectively.

    I’m expecting to have the fallback methods branch finished and merged in by EOD today or tomorrow. At that point, it will likely need some design love, as it will need to account for three different things — what the user’s primary provider is, what providers the user has enabled, and configuring providers. For the moment we’re going for functionality over design, so it’ll just be checkboxes for available, radio button for primary, and letting each provider handle configuration.

    Added @valendesigns and @stevenkword as committers on the repo.

     
    • CotswoldPhoto 6:39 pm on July 24, 2015 Permalink | Log in to Reply

      I am hoping to use the Google one (I currently use the one written by Henrick Schack together with the Per User Prompt written by Ian Dunn), so I hope it has a lazy code option (allow codes +/- time error) as the time window on the standard version is too tight for many servers to be accurate to. Also, for security reasons, I hope the system uses a per user prompt; the standard WP login box at first, if user and pw are correct, a new box appears to prompt for the 2FA code. Errors returned (to hacking bots) do not reveal that 2FA is active for that user.

  • George Stephanis 3:55 pm on July 21, 2015 Permalink
    Tags: , , ,   

    Two-Factor Authentication — First Weekly Meeting! 

    Our very first first weekly meeting will be July 23rd, 2015 at 15:00 EDT in the #core-passwords channel on Slack.

    We’ll be addressing some varied issues such as:

    • meeting times (is this a good time for everyone? Is earlier/later better?)
    • Two-Factor Providers, who is working on each.
    • Open Issues.
    • Code Reviews.
    • etc.

    As I’m going on Paternity leave in mid-September for a bit, I’m also hoping that over the next few weeks we can collectively find someone else willing to take up the mantle and push Two-Factor forward in my absence.

    For anyone else just new to this, who is wondering what the deuce I’m talking about, Two-Factor is a feature proposal for core to introduce two-factor support in the interest of greater security and paving the cowpaths with a standard api for plugins to extend to provide their own two-factor providers. Active development is currently on GitHub here ==> https://github.com/georgestephanis/two-factor — and I’m happy to add any regular core contributors as contributors on the repo — just ask during our meeting or in the comments below!

     
  • George Stephanis 9:26 pm on January 15, 2014 Permalink
    Tags: ,   

    Due to a lot of stuff in my lap for the next few months, I don’t have the time to keep chasing down things for Search.  If anyone would like to take point, I’d be glad to help in any way possible, I just don’t have the time to wrangle it personally for the foreseeable future.

     
    • utkarshd_42 5:40 pm on March 7, 2014 Permalink | Log in to Reply

      Hi sir,
      I would like to work on the search initiative for the coming GSoC 2014. Can you suggest me as to how to proceed further with the code that has already been completed?
      And what will be my objectives that I have to complete.

      • George Stephanis 5:44 pm on March 7, 2014 Permalink | Log in to Reply

        Have you read the history of posts on this p2 already?

        • Utkarsh Dixit 6:57 pm on March 7, 2014 Permalink | Log in to Reply

          Yes, i’ve already read the entire history of posts. In the ideas page the objectives weren’t specified clearly and i don’t know whether or not you were active on the mailing list, so had to comment here

        • Utkarsh Dixit 7:42 pm on March 7, 2014 Permalink | Log in to Reply

          I’m also going through the codebase of the current plugin available for omnisearch. Hoping to work for the search initiative 🙂

      • Utkarsh Dixit 4:51 am on March 9, 2014 Permalink | Log in to Reply

        Hi sir,
        Can you suggest me some other improvements that you would like to see in the search initiative. Even the ideas that haven’t yet been planned or thought of completely. Hope that I will be able to complete most of them 🙂

      • Utkarsh Dixit 5:50 pm on March 9, 2014 Permalink | Log in to Reply

        Hi sir,
        This includes all the patches I have worked on till now, including the patch for asynchronous search. Please look into it. Its my first time contributing to WordPress so my code might not be upto the par or possible full of bugs. Please suggest changes, approaches, ideas anything that you think might help me.

        https://github.com/utkarshd420/omnisearch-patch/

    • Utkarsh Dixit 5:06 am on March 8, 2014 Permalink | Log in to Reply

      “the biggest task at present seems to be unifying all the search forms in the administrative interface to feed into a global search ”

      We could already use the code given for omni search plugin and could probably change the action parameter of each search form in the admin panel with a hidden input of

      <form id="posts-filter" action="” method=”get”>

      Plugin should be activated for this… Therefore we can use the plugin already build to unify all the search fields in the admin panel..
      is this approach feasible? It works well (I’ve tried for the search posts form)..

    • Utkarsh Dixit 2:18 pm on March 8, 2014 Permalink | Log in to Reply

      I’ve also tweaked the codebase ,of the plugin, a little now it shows the the no. of posts (if found).. Not much a change, but now I have the basic understanding of the way this plugin works.. Waiting for some further updates 🙂

    • Utkarsh Dixit 11:16 am on March 9, 2014 Permalink | Log in to Reply

      Trying to include the suggestions of posts to search in the plugin too, using AJAX to do it… I’ll share the patches one it’s completed. Hoping to complete it soon.

      • George Stephanis 9:56 pm on March 9, 2014 Permalink | Log in to Reply

        Howdy.

        Sorry for the delay getting back to you, just a bit overwhelmed with other stuff this weekend.

        I’ve actually just added you as a committer to the plugin itself — it’s terrific to see someone eager to start working on it.

        I’ll respond in more detail to the above tomorrow! 🙂

      • George Stephanis 9:57 pm on March 9, 2014 Permalink | Log in to Reply

        I would suggest in the interim, though, to read up on Core’s Coding Standards and Styles — things like including spaces, and always using braces for conditionals as an example.

        https://make.wordpress.org/core/handbook/coding-standards/php/

        • Utkarsh Dixit 7:15 pm on March 10, 2014 Permalink | Log in to Reply

          Thanks for the link. Have gone through all the coding standard. Will use them from the next time. 🙂

          Sir, will you be attending this?
          https://make.wordpress.org/core/2014/03/10/gsoc-irc-chats/

          • George Stephanis 9:18 pm on March 10, 2014 Permalink | Log in to Reply

            Yup, I’ll be there. 🙂

            • Utkarsh Dixit 4:49 pm on March 11, 2014 Permalink

              Hi sir,
              Was going across the IRC chat logs when came upon this

              ” often our search acts more like a filter — if I search for “Jaquith” on the posts screen I see a listtable of posts, it doesn’t say what context (or even necessarily what matched if not the title) in the results ”

              I tried making a patch for it… If the search term is in the post or the content of the page it is displayed as

              $title
              …..something something something $search_term something something something….

              In each row.
              I had to tweak the wordpress codebase a little ( WPINC\class-wp-posts-list-table and WPINC\class-wp-list-table)

              Will upload the patch soon and provide the link on this forum 🙂

            • Utkarsh Dixit 6:15 pm on March 11, 2014 Permalink

              There is a slight mistake in the earlier comment I had made changes in wp-admin/includes/ and not in WPINC. Sorry for the above mistake.

    • Utkarsh Dixit 7:09 pm on March 11, 2014 Permalink | Log in to Reply

      https://github.com/utkarshd420/omnisearch-patch

      Also updated the patch I have explained here:
      https://make.wordpress.org/core/2014/01/15/search-initiative-on-hold/#comment-13044

      Hope you will look into it 🙂
      Please provide me feedback, bugs and further approaches you would like the search initiative to have. 🙂

      PS: tried my best to adhere to the coding standards might have some deviations though, as its my first time contributing to WordPress. Hope you don’t mind. 🙂

    • Utkarsh Dixit 7:54 pm on March 12, 2014 Permalink | Log in to Reply

      Hi sir,
      This is in regards with the gsoc chat session.. will you be available between 11:30 am to 8:00 pm UTC, tomorrow i.e. 13/3/2014?
      I would really like to discuss the current patches that I have provided as well as the new approaches that we can take on improving omnisearch.
      Please mention the timings that you will be available at (If you won’t be able to attend during the above time).
      Thanks 🙂

      • George Stephanis 8:07 pm on March 12, 2014 Permalink | Log in to Reply

        Just joined the channel now, I should be online around that span. I may be idling, so feel free to poke me there, or on #wordpress if ever needed — `georgestephanis`

    • Utkarsh Dixit 6:08 pm on March 15, 2014 Permalink | Log in to Reply

      Hi, couldn’t find you on the IRC Channels so am posting here, following (utkarshdixit11.wordpress.com) is the link to my proposal. please go through it once and suggest me any necessary changes that might be needed. Thanks 🙂

  • George Stephanis 4:49 pm on December 9, 2013 Permalink
    Tags: , ,   

    Search Initiative Chat Recap 

    Link: https://irclogs.wordpress.org/chanlog.php?channel=wordpress-core-plugins&day=2013-12-06&sort=asc#m36279

    In Attendance:

    Topics Discussed:

    • The ‘big’ portion of the Search Initiative may have to be delayed unless we get sufficient interest and participation.  A small group with little feedback will have significantly more difficulty building something that will necessarily be attractive to the community at large, and have far less chance of adoption.
    • x-team (Weston and John) have been working on “admin screen search” here, which is very much in line with the Navigation is often tricky to find a menu item (seen time after time in user testing videos). Possibly suggest admin pages as the user is typing their query? auto-suggest item from the original summation post. However, it would need a search field to hook onto to offer the results.  Some questions about how best to cache it were brought up, as that would be expensive to run, but it seemed best to address that after figuring out precisely what it’s going to search and how it’s going to happen.
    • Scott and the Metamorphosis team have been working on how to better structure Post Meta for assorted post types and the like. This would mesh quite well with the Not all relevant information is searched. I may have relevant data stored in a postmeta field, but it’s not indexed for searching item from the original summation post.  If a `include_in_search` flag could be set on specific meta keys, it could provide far more accurate results, as opposed to the status quo, where postmeta is not used in search (leading to rather difficult situations in CPTs where `content` is not supported or is not representative of the item in question)

    We’ll be continuing on December 13 22:00 UTC unless a time that works for more people is suggested in the comments below.

     
    • Scott Kingsley Clark 5:00 pm on December 9, 2013 Permalink | Log in to Reply

      I wonder if exclude_in_search vs include_in_search should be used for interoperability with post type args and the new meta field API we’re working on. What should the default be is the main question here, assume all fields added will get included in searches, or make the default to exclude unless that default is overridden.

      • George Stephanis 5:06 pm on December 9, 2013 Permalink | Log in to Reply

        Possibly instead of having it be a straight boolean, let folks set it explicitly as ‘include’ or ‘exclude’ — and let whatever’s calling them default whichever way it prefers (or to a configurable/filterable value) if not specified?

    • Eric Andrew Lewis 5:34 pm on December 9, 2013 Permalink | Log in to Reply

      Querying post meta data has been a contentious topic. With the current schema and API, querying many meta keys with a search term will not perform well at scale.

      I’ve heard lead developers say that creating complex queries on post meta is doing it wrong (although I can’t find something to cite in that regard), and post meta should exclusively be used for outputting in templates. Although I haven’t heard a top-down recommended alternative to this prickly architectural question. For custom post(/content) types, some projects have invented their own method for dealing with this. BuddyPress uses tables for all of its data objects. Pods creates tables dynamically for custom content types.

      Perhaps a topic to have an IRC summit on, or even its own working group.

    • George Stephanis 1:21 am on December 14, 2013 Permalink | Log in to Reply

      Major apologies, all. I was laid out with a migraine this afternoon and completely lost track of the meeting this afternoon.

  • George Stephanis 9:37 pm on December 4, 2013 Permalink
    Tags: , ,   

    The Search Initiative needs YOU! 

    the-search-initiative

    The Search Initiative needs people!  We’ve (okay, I’ve) had some terrific feedback from folks already, and would love for the actual work to have a plurality of voices coming together to build it!

    What is the Search Initiative?

    Glad you asked! The Search Initiative is a collection of smaller tasks aimed at making searching within the admin panel a more unified, streamlined, simpler experience.  We are not presently looking to change the search experience on the front-end of sites.  Many themes do a variety of display methods for that, and we shouldn’t step on their toes.  Instead, the biggest task at present seems to be unifying all the search forms in the administrative interface to feed into a global search.  Probably offering tabs for each searchable content type, with a count of the number of entries in each.

    There’s also other aspects that can work in parallel, such as client-side suggestions when someone is typing in a search query. So if they begin typing in ‘New P’ — it would autocomplete the links to ‘New Post,’ ‘New Page,’ and ‘New Pachyderm’ (if they’ve got an elephant post type) — and how can we offer more relevant search results on post types by efficiently searching Post Meta as well?  I’d love to get some collaboration with Team Metamorphosis on this aspect.

    If you’re interested, we’ll be having a chat on Friday evening (after the 3.8 code freeze — this is intentional) at December 6 22:00 UTC in #wordpress-core-plugins on Freenode.

    If you’d like to be involved, but either don’t know what IRC or Freenode is, or can’t make it at that time, just drop a comment below and I (we, hopefully) will make sure to loop you in and take your schedule into consideration for future chats.

    The Search Initiative has need of all sorts, from Designers and UX prototypers, to folks able to write and perform user testing, as well as back-end and front-end coders willing to help ensure a tight integration with core.  Most of all, we need you!

     
    • Rouven Hurling 9:58 pm on December 4, 2013 Permalink | Log in to Reply

      Friday or Wednesday evening? think you didn’t write the Shortcode correctly.
      Either way I would love to help with this, but I’m not going to make it on Friday and there seems to be no one in IRC right now, so I guess that means that it’s on Friday.

      • George Stephanis 4:00 pm on December 5, 2013 Permalink | Log in to Reply

        Sorry — I wrote out the [time] shortcode with just the time, and didn’t specify a date, so it seems to keep assuming the current date. Will fix. Yes, I’d meant on Friday.

    • David Radovanovic 10:55 pm on December 4, 2013 Permalink | Log in to Reply

      Please count me in. I would be happy to offer any support.

    • Christian Foellmann 3:38 pm on December 5, 2013 Permalink | Log in to Reply

      I see you are planning on using tabs.

      We already have the assets for horizontal (e.g. network/site-info.php and associated css) and vertical (current help with add_help_tab) tabs but no integration with the Settings API/SomeName API to use it in wp-admin for custom sites.

      How about integrating tabs generation into core to use it in “all these” places?

      • George Stephanis 4:01 pm on December 5, 2013 Permalink | Log in to Reply

        Well, maybe. There’s a lot of ways to do it, and I don’t want to bite off more than we can reasonably chew. I’d love to have you chip in on the implementation if you’d like to tackle the tabs, though.

    • Scott Kingsley Clark 5:46 pm on December 5, 2013 Permalink | Log in to Reply

      I should be around for the meeting, will be representing Metamorphosis since Eric Lewis won’t be able to make it.

  • George Stephanis 10:17 pm on November 11, 2013 Permalink
    Tags: ,   

    The Search Initiative 

    The Search Initiative

    IRC Chat Log

    In Attendance:

    • George Stephanis
    • Ryan Boren
    • Samuel Sidler
    • Mark Jaquith
    • Helen Sandi
    • Sarah Goodling
    • Matt Mullenweg
    • Andrew Nacin

    We opted to begin by reevaluating what pain points we believed there currently were in the WordPress admin around search.

    These are just what we came up with in the chat, please comment afterwards with any additional issues you’d like to see considered. Some of these are pretty big issues, and could easily be spun off into seperate projects. This looks like it is shaping up to be a significantly larger endeavor than was initially run as Omnisearch.

    Current Problems to Solve (The Status Quo) (Because the status is NOT quo)

    1. We have a lot of search forms in the admin, and it’s troublesome to have to find / navigate to the type of thing you want to search before actually searching it. (#)
    2. When searching, often it’s difficult to know / overly vague why a specific result has been included in the result set. (#)
    3. Not all relevant information is searched. I may have relevant data stored in a postmeta field, but it’s not indexed for searching. (#)
    4. When searching, and no results are found, the user hits a ‘dead end’ — no suggestions or path forward is offered. (#)
    5. Navigation is often tricky to find a menu item (seen time after time in user testing videos). Possibly suggest admin pages as the user is typing their query? (#) — Related plugins: Jarvis and WP-Butler
    6. We don’t currently support syntactically-aware search queries. “Comments by [user]”, “Posts in [category]” etc. (#)
    7. There is currently an inconsistency in the adminbar search field. It displays on the front-end of the site, but not on the admin side — due to WordPress not having a unified search results page to send people to on the back-end. (#)

    I feel that 1, 4, and 7 are the most similar and the solution for both would be more a single unit, whereas 2, 3, 5, and 6 are more distinct and could be done in parallel or in subsequent iterations.

    Possible road forward:

    Have a Global Search Page, with some sort of tabbed interface. There would likely need to be an ‘Overview’ tab, and then for each different data type being searched, its own tab. Generic search forms (like the adminbar search) would land on the overview, but if the initial search form designated which bit of content they’d like to search (for example, using the search form on the admin posts page), send them directly to its respective tab, the content of which would be akin to the current search results pages currently dispersed throughout the admin.

    We would be able to add in the adminbar search form to the admin (yay consistency) and even auto-suggest based on links off of the current page (akin to Jarvis or WP-Butler) — or leave that to plugin territory.

    Parallel projects on the rest would be terrific, as I don’t personally see them as interdependent. They could be iterations or new groups could spring up to tackle them.

    That’s what I’ve got, now I’d love to hear your use cases, feedback, and where you’d like to see this headed. Let’s get the feedback in early this time, folks! 🙂

     
    • Scott Kingsley Clark 1:22 am on November 12, 2013 Permalink | Log in to Reply

      I built the Filters plugin to expand on providing a better UX for searching and filtering on multiple fields and taxonomies at once. It uses Thickbox inline but I plan on integrating the Media Modal possibly instead, for a nicer UI with a less buggy popup.

      https://wordpress.org/plugins/filters/

      I would hope that any solution that is built, can support filtering my fields and taxonomies in a better way than it is now.

      • George Stephanis 3:38 pm on November 12, 2013 Permalink | Log in to Reply

        We’d certainly welcome your input as this develops. As someone with prior experience building an addition to the search experience, it’d be invaluable input.

    • Dwain Maralack 6:09 am on November 12, 2013 Permalink | Log in to Reply

      I love the global Admin search bar and think Ajax search should be built in as the has become the standard.

    • RicaNeaga 2:49 pm on November 12, 2013 Permalink | Log in to Reply

      Please consider if a third-party search api is a viable solution (to be included / implemented alongside wordpress installation).

      For example vbulletin now bundles sphinxsearch.com , and they say for large websites (with large databases) this addition is a ”performance enhancement that will allow you to offload search from your MySQL database”.

      • George Stephanis 3:35 pm on November 12, 2013 Permalink | Log in to Reply

        I don’t believe it’s something that we would bundle with core, but — as I remarked above — the hooks will certainly be in place that a third-party provider could provide a plugin to replace or supplement existing results if desired.

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