Make WordPress Core

Updates from John Blackbourn Toggle Comment Threads | Keyboard Shortcuts

  • John Blackbourn 11:00 am on October 12, 2015 Permalink |
    Tags: ,   

    Tweaks to user searching and management 

    A few improvements have been made to user searching and user management in WordPress 4.3 and the upcoming 4.4. Here’s an overview:

    • 4.3: Performing a search on the Users screen now searches the user’s username, email address, display name, nicename, and URL, instead of just their username and nicename. See #27304
    • 4.4: Performing a search on the Network Admin -> Users screen previously required the use of a * wildcard character at the beginning and/or end of the search term, otherwise the search required an exact match. This is no longer the case, so finding users on Multisite is no longer frustrating and inexplicably dysfunctional. This, combined with the changes in 4.3, means searching for a phrase such as “@gmail.com” now works as you would expect. See #32913
    • 4.4: It’s now possible to filter the Users screen by users who have no role (in addition to being able to filter the screen by individual roles), if there are such users. See #22993
    • 4.4: Users with multiple roles (it’s possible to programatically give a user multiple roles, although this isn’t possible via the UI) are now shown as having multiple roles on the Users screen. This helps avoid obfuscation of a user’s roles. If your plugin facilitates the assignment of multiple roles to an individual user, you should test it against trunk and look at using the new get_role_list filter introduced in [34963] if necessary. See #22959

    Any other improvements you think could be made? Leave a comment.

    • JakePT 11:36 am on October 12, 2015 Permalink | Log in to Reply

      Does this new search also search first and last name fields individually? Be nice if it did.

      I also really want the option to not send users their passwords back. When building a site for a client, we’ll set up their account well before handing it over, to make sure permissions, white-labelling etc. are all working fine. Even then we have our own handover method and don’t need to send the WP Mail. I’m kind of shocked that this change was made, honestly. I’m sure a lot of people do the same thing.

    • sirjonathan 12:39 pm on October 12, 2015 Permalink | Log in to Reply

      How about the ability to search by meta values stored in usermeta? I’ve got a case where I’ve added a column to display a custom value but don’t currently have a way to search by that value.

    • deltafactory 1:52 pm on October 12, 2015 Permalink | Log in to Reply

      On the User list table, would it be possible to (optionally?) store per-role user counts in a transient or other cache? For large user-bases with a wide variety of roles, the slow LIKE query that drives this isn’t necessary on every page load while paging through or searching users.

    • Laurens Offereins 3:26 pm on October 12, 2015 Permalink | Log in to Reply

      Great! Any chance #32956 would make it next?

    • Justin Tadlock 9:45 pm on October 12, 2015 Permalink | Log in to Reply

      I’m just stopping by to formally say thank you for the improvements in 4.3 to user searching. You don’t know how many headaches you’ve saved me in just a short time. So, thanks.

      And, keep up the great work!

  • John Blackbourn 6:52 pm on October 7, 2015 Permalink |

    add_rewrite_rule() accepts an array of query vars in WordPress 4.4 

    A small change to add_rewrite_rule() in [34708] means that in the upcoming WordPress 4.4 an array can be passed as the second parameter instead of a query string.


    add_rewrite_rule( 'foo/([^/]+)/bar/([^/]+)/?$', 'index.php?post_type=foo&name=$matches[1]&taxonomy=bar&term=$matches[2]' );


    add_rewrite_rule( 'foo/([^/]+)/bar/([^/]+)/?$', array(
    	'post_type' => 'foo',
    	'name'      => '$matches[1]',
    	'taxonomy'  => 'bar',
    	'term'      => '$matches[2]',
    ) );

    While this isn’t the biggest change in the world, it makes this parameter much easier on the eyes.

    (Note that your $matches variables need to remain in single quotes!)

  • John Blackbourn 3:15 pm on October 7, 2015 Permalink |
    Tags: , ,   

    single-{post_type}-{post_name}.php: New theme template in WordPress 4.4 

    A new theme template has been added to the theme hierarchy as of r34800: single-{post_type}-{post_name}.php.  This template follows the rules of is_single() and is used for a single post or custom post type. It’s most useful for targeting a specific post in a custom post type, and brings consistency to the templates available for pages and taxonomies. It comes in the hierarchy before single.php and single-{post_type}.php.

    Don’t forget, too, that in WordPress 4.3 singular.php was introduced and the hierarchy of attachment templates was fixed.

    • petermolnar 3:22 pm on October 7, 2015 Permalink | Log in to Reply

      wp-config should have an option that sets the max allowed depth for template searches. As in:
      1 -> single depth, eg. single.php, {taxonomy}.php
      2 -> 2 level depth, eg. single-{post_type}.php
      3 -> unlimited depth, eg. single-{post_type}-{post_name}.php

      I wouldn’t be surprised it’d result in a measurable speed gain.

      • John Blackbourn 3:36 pm on October 7, 2015 Permalink | Log in to Reply

        That would save a maximum of about five file_exists() calls, depending on whether you’re using a child theme or not. I doubt it would have any measurable impact at all. file_exists() checks are very fast when absolute file paths are used.

        Additionally, it would introduce inconsistency to the template hierarchy, and consistency is a huge benefit of the theming system in WordPress.

    • kjbenk 4:07 pm on October 7, 2015 Permalink | Log in to Reply

      This is really cool and I can see an immediate use case for this.

    • Ravinder Kumar 5:05 pm on October 7, 2015 Permalink | Log in to Reply

      Nice addition to WordPress.

    • Dinesh Kesarwani 5:28 am on October 8, 2015 Permalink | Log in to Reply

      Yes! nice addition. I also suggested similar template before some time ago. But, it was rejected.

    • BenRacicot 12:10 am on October 10, 2015 Permalink | Log in to Reply

      Golf clap

  • John Blackbourn 12:06 pm on October 1, 2015 Permalink |  

    Request for feedback: Your HTTPS configurations 

    An ongoing goal of WordPress is to improve the way it works for sites that use HTTPS, and more specifically sites that run a mixture of schemes (for example, HTTPS in the admin area but HTTP on the front end).

    One of the most visible bugs currently is that media in an HTTPS admin area is served over HTTP unless the ‘WordPress Address’ setting (siteurl) also uses HTTPS, which means that the FORCE_SSL_ADMIN constant isn’t a complete drop-in solution to securing your admin area.

    Addressing all the possible configurations of HTTPS is difficult, so I’d like to put out a request for anyone who’s using a particularly interesting HTTPS configuration on your site to let us know what your setup is.

    Of particular interest would be a site that’s using different domain names for HTTPS and HTTP, different domain names for the admin area and front end, different ports anywhere, self-signed certs for the admin area, HTTPS admin areas with additional access restrictions, multisites with and without domain mapping that use a mixture of HTTPS and HTTP, etc.

    If your site has an interesting HTTPS configuration, and of course if it suffers from scheme related bugs as a result, please let us know in the comments below.

    • petermolnar 12:18 pm on October 1, 2015 Permalink | Log in to Reply

      I have no idea what reasoning could justify https only for the backend.

      Anyway: use // for urls, for _every_ in-site url, including css, js, any link instead of http:// or https:// prefixes. That will help avoiding mixed content issues because it get interpretered by the browser according to the url.

      Apart from that… use https w/ http2 everywhere, not just for the backend.

      • Bjørn Johansen 12:53 pm on October 1, 2015 Permalink | Log in to Reply

        The protocol relative URL is now an anti-pattern. Ref.: http://www.paulirish.com/2010/the-protocol-relative-url/

      • Ipstenu (Mika Epstein) 1:51 pm on October 1, 2015 Permalink | Log in to Reply


        1) IE 6 doesn’t support SNI, so you don’t want to lock out people yet

        2) Caching (caching https is not easy for the common man… yet)

        • Jon Brown 2:22 pm on October 1, 2015 Permalink | Log in to Reply

          IE6 rightly gets most of the bad press, but I have seen SNi fail on oild OSX / Safari as well.

        • petermolnar 2:47 pm on October 1, 2015 Permalink | Log in to Reply

          IE6 – meh
          caching – fair point, but mixed content is a lot worse.

          • Ipstenu (Mika Epstein) 3:27 pm on October 1, 2015 Permalink | Log in to Reply

            Read https://en.wikipedia.org/wiki/Server_Name_Indication#Implementation – There’s a lot more than just IE 6. Old Safari too. Not everyone can upgrade to El Capitan.

            • pepe 7:27 am on October 6, 2015 Permalink

              According to Wikipedia, Safari has had SNI since 3.0, released with OS X 10.5.6. That’s an OS that was current 8 years ago (10.5 was released in October 2007). The only people who really could not upgrade to that line are those still using very ancient PowerPC based systems.

            • jeffmcneill 9:49 am on October 6, 2015 Permalink

              The big problems we saw last Jan. is that ~5% of customers were coming with too old of an Android browser that doesn’t support SNI. Also older Blackberry. It would affect 7-8% of customers, so decided to hold off for a year. IE6 had zero customers, though some amount of traffic.

            • Ipstenu (Mika Epstein) 4:56 am on October 7, 2015 Permalink

              @pputzer – I know that’s 8 years ago. The reality though is that by forcing HTTPS we force SNI for many users. That means the users who will be most adversely impacted by the change are the ones with the least ability to fix it.

              THAT is shitty UX.

              People don’t have the money to buy new computers every 5 years. People use the web on shitty mobile nokia phones. It’s one thing to say “You can’t shop here because we cant’ make a secure connection.” It’s another thing entirely to kick them out of 25% of the internet.

              So yeah. I’m gonna fight this one for everyone’s grandparents.

    • John Huebner 12:22 pm on October 1, 2015 Permalink | Log in to Reply

      On the hosting provider I use if I set up SSL then on a site then the entire site is severed on HTTPS, no choice. Once done you cannot access the site by HTTP.

      I have had serious problems setting up WP with SSL. If I set up SSL first then the site breaks because it attempts to redirect to HTTP while the server is redirecting to HTTPS and I can’t login to change it. If I change WP first then the site breaks attempting to redirect to HTTPS that does not exist while I’m setting up the SSL.

      I think that the above comment by @petermolnar might help solve this situation.

      • petermolnar 12:33 pm on October 1, 2015 Permalink | Log in to Reply

        You could; at least it _can_ be set up like that, that’s a choice of the provider if it redirects to https.

      • Ipstenu (Mika Epstein) 3:28 pm on October 1, 2015 Permalink | Log in to Reply

        I want to say this is a hosting issue, but it highlights a major concern. Not all hosting platforms are created equal :/ And telling the end user “its your host” is a terrible idea.

        • John Huebner 1:38 am on October 2, 2015 Permalink | Log in to Reply

          Thank you for that. The company I work for uses a particular host for all the sites we build. I can’t simply decide to use another one and I doubt I’m going to convince the hosting provider that they need to change the way they do things.

    • AdamConway 12:29 pm on October 1, 2015 Permalink | Log in to Reply

      Couldn’t agree more with @petermolnar. Apart from the fact that I don’t see good arguments for not simply hosting the whole site on SSL (if you have part of it there), there is a solution to this built in to URI syntax standards, so why not just use it? I can’t see a downside with that! It might not solve issues where you have mutliple domains with SSL only on some, but relative links (relative to site root at least) are the only real solution to that.

      I use a very simple solution of allowing HTTP to the server but then redirecting to HTTPS in apache (mod rewrite) before it gets anywhere near wordpress, and haven’t had any issues with that. The early sites which were set up with http we had to do database rewrites to fix.

    • thomaswm 12:30 pm on October 1, 2015 Permalink | Log in to Reply

      We operate a multisite network with subdirectory configuration. Every site gets a domain mapped to them using the Domain Mapping plugin. We have a wildcard SSL certificate for the main site’s domain, but we do not have any certificate for the other sites’ domains.

      We have a custom plugin in place to make certain sites available under a subdomain of our main site’s domain via HTTPS so they can use our wildcard SSL cert. This would lead to scheme-related problems, but we use the “WordPress HTTPS” plugin to rewrite the URLs of embedded media.

      Also, one of our most used themes has its own way of dealing with mixed content: It uses the “the_content” filter, look for URLs which point to the current website and runs them through the function “wp_make_link_relative”.

      You see that this is all quite hacky and I’m not really happy about that, but it works after all. 😉

    • Mark Wilkinson 12:39 pm on October 1, 2015 Permalink | Log in to Reply

      I run a similar setup to @thomaswm. I have a multisite installation install on my domain and this domain has a wildcard SSL certificate. Most of the actual sites in the multisite are mapped to a domain name which does not have a certificate and therefore I want the backend to happen over the sites sub domain URL. This can then use the wildcard SSL of the main domain.

      I have had issues in that the domain mapping plugin re-writes all the admin links to mapped-domain.com/wp-admin rather than using subdomain.domain.com/wp-admin, but have over come this with a plugin.

      I am sure there are going to be more issues crop-up with this setup though. Hope this is the sort of thing you where after.

    • CotswoldPhoto 12:40 pm on October 1, 2015 Permalink | Log in to Reply

      I have to wonder how many sites will NOT be https soon. With Let’s Encrypt nearly ready to launch its free service, due week of 16 November 2015 https://letsencrypt.org/2015/08/07/updated-lets-encrypt-launch-schedule.html https is going to blossom.

      • Ipstenu (Mika Epstein) 2:11 pm on October 1, 2015 Permalink | Log in to Reply

        Please note: LetsEncrypt has pushed back the date at least 3 times already, and they’re not going to be world-wide usable right away. At best we can say that this might be usable for the general public by next summer (2016).

        Also remember getting the cert is problem #1. Problem #2 is the common human ADDING the cert to their servers. Shared hosts may have problems.

    • Gregory Karpinsky (@tivnet) 12:49 pm on October 1, 2015 Permalink | Log in to Reply

      After several unsuccessful attempts to have regular pages HTTP, admin and WooCommerce checkout HTTPS – we gave up and made https the whole site.
      If was really impossible to track all redirects, and also to fight WC bugs with their “force SSL on checkout”.
      From now on, any serious e-commerce site we’ll do on https from the very beginning.

    • Patrick Steil 12:56 pm on October 1, 2015 Permalink | Log in to Reply

      Two points to add here:

      1. Google wants “SSL everywhere” so I think you all shouldn’t worry too much about supporting http on front or back and https on the other. Should be all or nothing.

      2. Every site out there can get a FREE SSL certificate for any domain they want by using CloudFlare as their web site firewall / front end. We are using this on our WPMS and it is working very well!

    • Dave McHale 1:03 pm on October 1, 2015 Permalink | Log in to Reply

      Considering that Symantec recommended Always-On SSL as far back as 2011, I wonder how much longer it will take for most administrators to finally realize that there isn’t a good reason to NOT supply https for all connections. http://www.symantec.com/page.jsp?id=always-on-ssl

      Google and many other vendors have also repeatedly stated that secure connections do not have a measurable performance hit (MaxCDN source: https://www.maxcdn.com/blog/ssl-performance-myth/ ) I just don’t see any valid arguments against it nowadays.

      While WordPress obviously needs to support numerous configurations, it would be nice to see a push towards encouraging “best practices” moving into the future. I think this means “make my whole site use https” is the primary DECISION users should be making in the admin area. Is it turned on, or turned off? Less granular OPTIONS.

    • Bjørn Johansen 1:11 pm on October 1, 2015 Permalink | Log in to Reply

      If you’re behind a reverse proxy that handles, and terminates, HTTPS for you – with the connection between the reverse proxythe result of the protocol between the reverse proxy and WordPress

      If you’re behind a reverse proxy or load balancer that handles and terminates HTTPS for you – like CloudFlare, Sucuri, Big-IP and many more – and the connection between the reverse proxy and WordPress is plain HTTP, WordPress gets confused.

      The reverse proxy should, and usually does, set a HTTP header explaining the situation. I believe the de-facto standard for this is to set the header “X-Forwarded-Proto” to “https” (even though I’ve seen many others variant as well: E.g. the header “WL-Proxy-SSL” to “true” on Big-IP).

      This is an issue that can easily be solved in the web server config, or by adding the following code to wp-config.php:
      if ( isset( $_SERVER[‘HTTP_X_FORWARDED_PROTO’] ) && ‘https’ == $_SERVER[‘HTTP_X_FORWARDED_PROTO’] ) {
      $_SERVER[‘HTTPS’] = ‘on’;

      Maybe this should be considered as an addition to the is_ssl() function?

      • J.D. Grimes 1:37 pm on October 1, 2015 Permalink | Log in to Reply

        Yes, I use CloudFlare on my sites, and having to add this code to wp-config.php is a pain. It would be a nice enhancement if that was handled automatically. The only reason that might not be feasible is that the HTTP_X_FORWARDED_PROTO header, being client-supplied, isn’t trustworthy.

      • Jon Brown 2:29 pm on October 1, 2015 Permalink | Log in to Reply

        This is the unusual case I was going to share. I setup cloudflare + self signed ssl on several of my personal sites, it can work, but can be flaky. I’ve used that same snippet.

        Beyond that it gets weird as well when I want to ssl a few front end form pages (I use the WordPress https plugin).

        Fwiw, I’m more worried at the moment about supporting http2, but this is still important.

      • webaware 11:35 pm on October 1, 2015 Permalink | Log in to Reply

        This can’t be handled “automatically” because that header (and its friends) cannot be trusted; you need to know that a) your website uses such a configuration, and b) which one. See this comment on #31288 for more details.

        At the very least, you need to select this as an option. Pasting that code into wp-config.php is the simplest and fastest fix, or you can use a plugin (there’s a couple, including my SSL Insecure Content Fixer).

    • Ipstenu (Mika Epstein) 1:48 pm on October 1, 2015 Permalink | Log in to Reply

      Multisite – https backend, one site on the network is https front end.

      And Multisite is a good warning spot for HTTPS everywhere since if you have subdomains, you have to either have a multi-subdomain cert or you have to make one per subdomain. And no, HTTPS Everywhere is NOT going to make multi-subdomains right away. They’ve outright said that, so please keep in mind the biggest hurdle with HTTPS will be getting certs installed :/ The common man does not find this easy. Hell, I’m a professional and I hate it.

      As soon as HTTPS everywhere is out, my stand-alone sites will be going to https all around, but Multisite I have to test and figure out.

      • webaware 11:22 pm on October 1, 2015 Permalink | Log in to Reply

        +1 same scenario, plus multi-network multisite. I have CloudFlare providing SSL to the networks with wildcard so it’s not a problem at present, but it’s not ideal and looks unprofessional (have you looked at the certs? nasty!) However, it’s a simple free solution to that problem if CloudFlare is suitable for the network. Individual sites can then be configured with their own certs.

        Talking with clients about SSL certs, single site certs are confusing enough for many. Multisite with subdomains, or even single site with a mobile subdomain, gets messy and/or expensive fast. Throw in some mixed content errors and clients start pulling hair — theirs, yours, passers by.

    • Otto Keklinen 2:27 pm on October 1, 2015 Permalink | Log in to Reply

      We force admin https for our users always. If the site does not have its own SSL certificate, it will fall back to our generic wildcard certificate, so the whole admin will be at a different domain. This is possible with our custom plugin: https://wordpress.org/plugins/https-domain-alias/ This plugin would solve at least all the current unencrypted password transmissions in all official hosting environments (not self hosted).

    • Brandon Kraft 3:14 pm on October 1, 2015 Permalink | Log in to Reply

      I have a multinetwork multisite site. 99% of domain mapping takes place via separate networks on the install. The rest of the domain mapping is secondary domains that redirect to the primary.

      The main network is a subdomain multisite site with HTTPS on a wildcard cert. None of the other networks have SSL.

      With regard to SSL, the most noticeable pain point is the WP Multi Network plugin has a link to each network’s dashboard that uses `network_admin_url`, which is uses `network_site_url()` with the `admin` flag for scheme, which returns of the HTTP/HTTPS scheme of the *current network* not anything specific to that network.

      I just traced back the code; haven’t opened a ticket yet or explored the best way to check if a particular network should have a particular scheme.

    • Aaron D. Campbell 3:26 pm on October 1, 2015 Permalink | Log in to Reply

      I have a multisite install for some of my personal sites (read that as “I haven’t had time to invest in solving all the idiosyncrasies with the setup”). The plan was to use aarondcampbell.com as the main site with a wildcard SSL. I then wanted to use subdomains over SSL for admin for the sites (geekreprieve.aarondcampbell.com/wp/wp-admin), and mapped domains for the front end (geekreprieve.com).

      I tried to use Mercator, but it ended up still requiring some code to filter ‘upload_dir’ to use the proper front-end URL rather than the current URL when you add media to a post. Ultimately, it was far more difficult to set up than I had expected, and it still has it’s quirks that I just haven’t had time to fix up (like the main site front end being accessible via both http and https).

      @johnbillion I’m happy to give you access to poke around (or give you the code or whatever) if you think it would be helpful.

    • DuzAwe 3:58 pm on October 1, 2015 Permalink | Log in to Reply

      Using LetsEncrypt and cloudflare to provide SSL for live and test sites currently. Nothing fancy

    • xwolf 4:38 pm on October 1, 2015 Permalink | Log in to Reply

      I am hosting a multisite network at our university in which all plain HTTP requests are redirect towards HTTPS. We dont make a mix of HTTP and HTTPS, cause there is no need for HTTP and we made the experience, that on mixed installation several themes and plugins use absolute pathes based on HTTP for generating media files or other things.
      Therfor all multisite instances are SSL only.
      We did this by changing the siteurl and all other settings to SSL.
      For redirection from HTTP to HTTPS we are using Server directions and RewriteRules in .htaccess for the main hostname of the site an its potential cname aliases.

      We set the main university site http://www.fau.de to SSL-only in October 2014. We got no problem report or issue about it. Our website-statistics show that only 0.23 % of 65.827.341 pageviews last month were made bei IE6-Browsers. IE8 got 1.21 %. Thats not enought to take care about this old trash.

      • war59312 11:27 pm on October 1, 2015 Permalink | Log in to Reply

        Should use:

        Content-Security-Policy “upgrade-insecure-requests”

        Force SSL without an insecure redirect needed. And will NOT break http paths. :)

    • jancbeck 4:40 pm on October 1, 2015 Permalink | Log in to Reply

      I have a multisite installation where I host sites of my friends. I’m using WPMU domain mapping to give each of them their own non-https domain. It’s a multisite subdirectory setup but the domain mapping works with subdomains too, so it’s kinda mixed (shop.mydomain.com and mydomain.com/shop are both possible).
      My host comes with one free HTTPS domain that I already use for other projects so I installed the whole multisite into a ‘/wp/’ subdirectory. It doesn’t really matter for the frontend URLs, because they are mapped anyways. It’s just so the admin area is available at https://mydomain.com/wp/wp-admin/
      I also use Jetpacks CDN (Photon).

      This runs pretty stable for a about a year now. The most common problem is related to the subdirectory install. However one current problem related to HTTPS is that the “link modal” in the editor will add the https protocol to the content and clicking these links on the non-https frontend will result in a browser error message.

    • dmori 6:05 pm on October 1, 2015 Permalink | Log in to Reply

      I have a situation with http in admin but https on front page login form. I noticed that you cannot load customizer and page if they are different (i.e. http/https mix).

      It would be good if you could make the wp-login page use https only – rather than force all admin. This way logging into site would be secure.

      If there was a way to make have all wp-login pages use https (without users needing an SSL for their site) would be great. I don’t know if this could ever be possible, but this would have an immediately positive effect for all wordpress websites.

      I know this is for top level devlopers – but please remember not all wordpress users have the knowledge and experience you do. We want to make it as accessible to as many people as possible.

    • Mike Nelson 6:11 pm on October 1, 2015 Permalink | Log in to Reply

      We have an event registration plugin, where many users want to only make certain frontend pages (relating to event registration) SSL.
      Specifically, an issue many users encounter is the following: when someone goes to register for an event, one payment option is to go to Paypal and then return to the site’s “Thank You” page. However, on certain browsers when a user is redirected from an SSL Paypal page to a non-SSL “Thank You” page, they will get a scary warning “You are visiting an unencrypted page etc etc… are you sure you want to do this?”.
      Us technical people think “yeah that warning makes sense, they entered their credit card data onto a secure Paypal page, and now they’re returning to a non-secure page on WordPress which doesn’t need to be secure anyways because no sensitive data will be exchanged on this page, so that’s a-ok” but many of our site admins using the plugin don’t understand that, and many of their clients signing up for events don’t understand that either. So the solution most of our plugin users want is to ONLY have the frontend “Thank You” page to be SSL, so that users won’t get the browser warning I just mentioned, but otherwise they want to keep everything else non-SSL.
      We used to recommend the WP HTTPS plugin https://wordpress.org/plugins/wordpress-https/ but it’s recently not getting much support

      • Ipstenu (Mika Epstein) 9:02 pm on October 1, 2015 Permalink | Log in to Reply

        FWIW, WordPress-Https still works. And it’s good for when you have to enforce things like “Damn it, why did you enqueue with http!?!”

        I’ll make a post on make/plugins to remind people though…

    • war59312 11:19 pm on October 1, 2015 Permalink | Log in to Reply

      We force SSL using Strict-Transport-Security and Content-Security-Policy. 100% SSL. A+ Rating on ssllabs.com.

      We follow security guide @ bettercrypto.org as well.

      Along with a few other security methods, such as Content Security Policy (CSP), X-Frame-Options (Frame-Options), X-XSS-Protection, X-Content-Type-Options, X-WebKit-CSP, and X-Permitted-Cross-Domain-Policies.

      Even though we don’t store any Personally identifiable information (PII).

      I want my users, clients, staff, partners, etc. to know they are protected to the very best of my ability.

      Personally, I believe all of these should be the default and required (by LAW). Even more so if you do make use of PII.

      Think it would be wise for WordPress to enable as many as these security settings as possible by default.

      • war59312 11:24 pm on October 1, 2015 Permalink | Log in to Reply

        wordpress.org should make use of all of these features.

        Please enable Strict-Transport-Security and Content-Security-Policy. Takes a few seconds really. 😉

        Your already “forcing” SSL, so how about do it correctly!! Please!!

        • war59312 11:26 pm on October 1, 2015 Permalink | Log in to Reply

          That is:

          Content-Security-Policy “upgrade-insecure-requests”

        • vhmark 1:48 am on October 2, 2015 Permalink | Log in to Reply

          In our case we’re https to the load balancer, http between the LB and the web servers, and the LB does NOT pass through any $_SERVER variables to indicate this.


          • Requests come from the client to the load balancer as https, but are translated to http from the the LB to the web server.
          • Unfortunately the LB does not tell the server it is working over https, so the is_ssl() function returns the wrong result.
          • The practical result is that you can see the site, see the login page, but cannot login.
          • Forcing SSL gets around the problem.

          $_SERVER[‘HTTPS’] = ‘on’;
          $_SERVER[‘SERVER_PORT’] = 443;

      • vhmark 1:42 am on October 2, 2015 Permalink | Log in to Reply

        Our is all https back + front-end mutisite subfolders. The twist is that to cut down on mixed content errors we built a search-replace-on-submit of post+comment content for a whitelist of sites.

    • Henry Wright 8:43 am on October 2, 2015 Permalink | Log in to Reply

      I try to use HTTPS everywhere, always.

    • mydiskdriveonline 4:21 pm on October 2, 2015 Permalink | Log in to Reply

      I have a multisite/subdomian install with a couple mapped domains at Dreamhost.

      I rewrite the root site and mapped domains to https in apache virtual hosts:

      RewriteCond %{HTTP_HOST} =myrootsite.com [NC]
      RewriteRule ^(.*) https://myrootsite.com$1 [R=301,NE]
      RewriteCond %{HTTP_HOST} =mappeddomain.com [NC]
      RewriteRule ^(.*) https://mappeddomain.com$1 [R=301,NE]

      I pull out the ServerAlias’s(mapped domains) that Dreamhost groups in with the “mirrored” rootdomain from and give them each their own so they can each get a cert.

      So my root site uses a regular cert, not a wildcard(cant afford it). mapped domains each have there own cert, the rest of the subdomains do not use https.

      Issues I have are:

      Network admin get_site_url(); for sites defaults to https. Is there a way to force it to use http:// all the time?

      To fix the Networked sites upgrader i use:
      add_filter(‘https_ssl_verify’, ‘__return_false’);
      add_filter(‘https_local_ssl_verify’, ‘__return_false’);

      I also do a search and replace in post_content and make my urls relative instead of absolute (ie. remove https://mysite.com/files/ and replace with /files/) every week or so.

      I know I’m beating a dead horse but I really wish WordPress used relative urls.

    • jwz 5:49 pm on October 2, 2015 Permalink | Log in to Reply

      I recently switched my site to be SSL-only. But before that, I had it configured so that admin URLs were HTTPS and non-admin URLs were forced to be HTTP. I did this because my SSL cert was self-signed, since I was the only one using it. I didn’t want normal blog readers to ever be hit with the “unsigned cert” warning.

      Here’s how I accomplished that:

      RewriteEngine On
      RewriteBase /blog/

      1. These URLs require SSL. All others require non-SSL.

      RewriteRule ^wp-(admin|login|register|signup) – [E=NEEDSSL:1]

      1. This URL can be either SSL or non-SSL. Leave it alone.

      RewriteRule ^wp-admin/admin-ajax\.php$ – [QSA,L]

      1. This Facebook query-string can be either SSL or non-SSL. Leave it alone.

      RewriteCond %{QUERY_STRING} (^xd_receiver) [NC]
      RewriteRule .? – [QSA,L]

      1. NEEDSSL && !SSL: turn it on.

      RewriteCond %{HTTPS} !=on [NC]
      RewriteCond %{ENV:NEEDSSL} =1
      RewriteRule .? https://%{HTTP_HOST}%{REQUEST_URI} [R=301,QSA,L]

      1. SSL && !NEEDSSL: turn it off. Except on staging server.

      RewriteCond %{HTTP_HOST} !=staging.jwz.org [NC]
      RewriteCond %{HTTPS} =on [NC]
      RewriteCond %{ENV:NEEDSSL} !=1
      RewriteRule .? http://%{HTTP_HOST}%{REQUEST_URI} [R=301,QSA,L]

    • Jeremy Felt 7:39 pm on October 2, 2015 Permalink | Log in to Reply

      I wrote up some of the workings around our config here: https://jeremyfelt.com/2015/04/24/a-method-for-managing-mixed-httphttps-sites-in-multisite/

      In a nutshell:

      • We get individual certs from InCommon.org as domains are created. We’ll request multi-domain certs when we want to support www as well. Each unique, non-www domain gets some kind of cert.
      • Sites are sometimes briefly accessible via HTTP on the admin and front-end while we wait for a cert request to be fulfilled.
      • Once a cert is available, all admin requests for that domain are forced HTTPS.
      • Recently, we’ve started forcing all front-end requests for new domains to HTTPS, though there are some domains that still support HTTP requests.

      We’re usually on the latest Nginx mainline release and the following config is included for each site: https://github.com/washingtonstateuniversity/WSU-Web-Provisioner/blob/master/provision/salt/config/nginx/wsuwp-ssl-common.conf

      We’ll be switching to HTTP/2 next week. :)

    • David Smith 8:57 pm on October 2, 2015 Permalink | Log in to Reply

      Substantially all of our sites are behind an F5 LTM appliance (actually, a cluster of them…) for SSL offloading.

      There’s an iRule (F5’s scripting language) that redirects all port-80/non-SSL requests to port 443, and the sites have https:// in the WordPress database site_url. Couple different wildcard certs for various third-level and fourth-level domain names, nothing too fancy there. The F5 proxies requests to the backend Apache server (or, in my case, to a Varnish cache server, which in turn talks to WordPress), and everything behind the F5 is non-SSL. (Authentication isn’t an issue, it’s handled external to WordPress via Shibboleth, and that IS encrypted even on our internal network.)

      One thing I’ve done, that looks kinda strange but works just fine: Apache is perfectly happy to respond to “SSL” requests over port 80, if you tell it to. You just specify a second ServerName parameter in the configuration, like so:


      ServerName yoursite.name.org
      ServerName https://yoursite.name.org:443
      (whatever other stuff you normally do here)


      If you forget that, or have a sticky keyboard that keeps typing ’43’ instead of ‘443’, you’ll notice immediately because most of your JavaScript and CSS won’t load. :)

    • Peter Wilson 9:41 pm on October 4, 2015 Permalink | Log in to Reply

      I’m not sure it’s unusual, my set up is:

      • wildcard certificate
      • admin over https with FORCE_SSL_ADMIN set to true
      • front end is http only, any https requests redirect with a 301 as canonical URLs are (or were) inconsistent

      I started with SSL everywhere but experimented to see if Google preferred performance or SSL, removing the SSL handshake improved my rankings.

    • kirrus 9:28 am on October 5, 2015 Permalink | Log in to Reply

      Typically, HTTP on backend, apache running either mod_php or php-fpm. Varnish performing reverse proxy duties, then HTTPS from an nginx or pound terminator. Slowly becoming more nginx, thanks to requests for HTTP2 / SPDY support.

      So far, it’s proved difficult to get running smoothly with no issues.

    • Primoz Cigler 4:34 pm on October 5, 2015 Permalink | Log in to Reply

      Our production: we have use a cloudflare’s HTTPS in front of our VM with nginx + php-fpm. So while cloudflare actually talks to our server over regular HTTP, the site looks like HTTPS externally.

      In order to make that work properly, we had to set the $_SERVER[‘HTTPS’] = ‘on’; which is probably an ugly hack.

    • pepe 7:40 am on October 6, 2015 Permalink | Log in to Reply

      As for curious SSL configurations and bugs, I’ve got a story to tell:

      A friend and I are running a closed multisite network consisting of unrelated sites (while multisite makes some things easier, for this scenario, I’d opt for independent installations if I had to set it up again today). It’s a subdirectory install mapped completely via the Domain Mapping plugin (i.e. even the admin access is on the mapped domain).

      For a long time, we had served both SSL and non-SSL on the frontend, but forced the backend to always be SSL. That made for some problems, because the post URLs used by the backend were always `https://` (e.g. inserted images, internal links). To overcome this, I added custom code to the theme of my personal blog that filtered the various links to change them to relative URLs (for images) or `http://` (for post URLs). At a first glance, this worked fine.

      However, at first apparently unrelated, I noticed that I couldn’t preview posts anymore, starting around WP 3.9 or 4.0. I assumed some change in core was the reason. Draft preview worked for pages and custom post types, just not for posts. I tracked the error down to an empty user object in core, but couldn’t find a reason for it.

      A few weeks ago, we decided to move to SSL all the time. With this, I removed my filters for the backend URLs and – voilà – post previews do work again. I’m still not sure what the connection is, but I am sure that there is one.

    • Alex Phelps 6:53 am on October 8, 2015 Permalink | Log in to Reply

      We run a closed multisite with ~1000 sites (~1500 domains) where we force all admin to be on the network domain on HTTPS and the mapped domain for the site frontend can be on either HTTP or HTTPS. By default, all of our sites load the frontend on HTTP. For SSL, we normally recommend using Cloudflare’s Free SSL service since it doesnt require a certificate on our servers, we support both Flexibile and Full SSL.

      Technical Setup:

      • Hosted on AWS
      • Varnish + Nginx servers out in front caching all requests with Varnish (port 80) and Nginx to terminate SSL and cache SSL requests.
      • Internal requests between caching servers and WordPress app servers on port 443 (but not strict on the ssl certificate)
      • WordPress App servers running Nginx + HHVM and failover to PHP-FPM.
      • Small internal app to distribute SSL certificates to all caching servers to manage SSL configurations on them.

      We ran into a few issues with the WP Admin bar on the frontend not referencing the correct domain protocol for the backend and also some interesting redirect scenarios when switching from the frontend to the backend with mapped domains.

  • John Blackbourn 4:49 pm on September 15, 2015 Permalink |
    Tags: , ,   

    Enforcing the show_ui argument for post types 

    Since [34177], the show_ui argument for post types is now enforced to correct unexpected behaviour whereby the post type listing screen and post editing screen for post types with show_ui set to false were still accessible via a manually entered URL.

    There’s a small chance this may have an effect on your plugin or website if it’s relying on the fact that these screens were accessible. If this is the case, you should correct the arguments for your post type by setting show_ui to true, and then setting show_in_menu, show_in_nav_menus, and show_in_admin_bar to false, as appropriate.

    • simonrcodrington 10:49 pm on September 15, 2015 Permalink | Log in to Reply

      Agreed. It makes sence if you specify show_ui that you would not want access to your custom post type admin areas at all (I naturally assumed that setting this would make those areas inaccessible) .

  • John Blackbourn 2:29 pm on June 10, 2015 Permalink  

    Site icon and image cropping controls 

    A couple of weeks later than intended, a brief update on the site icon functionality which has been touted as a potential feature for 4.3. The site icon functionality aims to provide an admin UI (via the Customizer, at least initially) for users to upload an icon which is then output as a favicon and associated touch icons, while also allowing themes or plugins to re-use the icon in other places as they see fit.

    The existing header image control in the Customizer (and its corresponding functionality on the old custom-header screen) provides a means for uploading a header image and then cropping it to the desired size. Unfortunately this control is fairly tightly coupled with the header image functionality, and therefore extending it for use with the site icon control has meant duplicating a lot of code.

    It’s looking more and more like #29211 should be tackled before the site icon functionality, in order to avoid this duplication and in order to allow other controls to provide a croppable image upload (such as for background images in #32403).

    Due to my limited availability to work on the site icon feature in the coming weeks, I think it would be worthwhile instead focusing on #29211 and the introduction of an abstracted control that supports image cropping, which can then be used for the site icon and custom background controls.

    The current non-working site icon feature plugin can be found in this repo on GitHub. It uses considerable code from the custom header image control. If someone wants to take that and run with it that would be great, or if someone wants to tackle #29211 instead, that would be great too.

    • Marko Heijnen 2:44 pm on June 10, 2015 Permalink | Log in to Reply

      I’m more then happy to help out. Image cropping etc is what I did before.

    • Greg Ross 2:48 pm on June 10, 2015 Permalink | Log in to Reply

      I spent quite a bit of time working on this problem when I built my OS Integration plugin (https://wordpress.org/plugins/os-integration/), but I didn’t integrate it in to the customize.

    • Ciprian 3:11 pm on June 10, 2015 Permalink | Log in to Reply

      Would this replace the Jetpack favicon feature? Would they be developed/maintained in parallel?

    • Mel Choyce 5:14 pm on June 10, 2015 Permalink | Log in to Reply

      Are there any plans to support .ico?

      • Samuel Wood (Otto) 5:45 pm on June 10, 2015 Permalink | Log in to Reply

        ICO files are somewhat difficult to do. Supporting them should be an optional thing, I think, not necessarily a blocker for implementing the underlying support for favicons as png-only to start with.

        A few ICO producing libraries were mentioned in #16434, and if something like this is created as PNG first, then adding on code to also save ICO files would not be difficult if the right library to do so can be found or created.

    • Nick Halsey 1:40 am on June 11, 2015 Permalink | Log in to Reply

      A note regarding #29211 – that was originally written before 4.1, when we redid the other core media controls. So the best approach would probably to make a cropped-image control that extends WP_Customize_Media_Control, using header images as inspiration, then update the header image control to leverage it. Header images no longer use the latest and greatest in the Customizer, so it’s worth a bit more of a rethink than generalizing their functionality I think.

    • imath 5:29 pm on June 23, 2015 Permalink | Log in to Reply

      Hi @johnbillion thanks a lot for your great work about this feature, i’ve been exploring the plugin on the github repo and just posted some suggestions into a pull request :)

  • John Blackbourn 3:53 am on April 2, 2015 Permalink
    Tags: ,   

    Reminder: Term splitting in 4.2 

    Here’s a quick reminder to plugin authors. Beginning in WordPress 4.2, shared taxonomy terms will get split into separate terms when one of the terms gets updated.

    What does this mean for you? If your plugin is independently storing term IDs in post meta, user meta, or options, then it’s likely you’ll need to update your plugin to prevent problems when a shared term gets split.

    Boone Gorges has posted a complete guide to preparing for term taxonomy splitting. Take a read if you’re a plugin author and you think a plugin of yours may be affected.

  • John Blackbourn 8:07 pm on January 26, 2015 Permalink  

    Here’s a reminder for those who haven’t seen it. Please take a few minutes to fill in the Community Hub Poll as the poll closes in the next few days. Get at it!

    • Michael Arestad 11:22 pm on January 26, 2015 Permalink | Log in to Reply

      I’m not particularly clear on the purpose of the community site. Judging from the survey, it sounds like it could pretty much end up being a clone of meetup.com. I’m not too fond of that idea, but I’ll wait until more info is available before judging.

  • John Blackbourn 11:47 pm on January 14, 2015 Permalink

    There will be a meeting in #core Slack next Tuesday at 2100 GMT (January 20 2015 21:00 UTC) to discuss feature plugins for WordPress 4.2. Several have been proposed. (If you want to propose one, please do it on that thread.)

    In order for a feature plugin to be considered for merge into 4.2, the plugin should already be fairly stable in order to avoid the sort of late development work that we’ve seen with merged feature plugins in recent releases.

    A separate meeting to discuss the feature plugin workflow and development process in general will be scheduled at a later date.

    • NateWr 10:05 am on January 15, 2015 Permalink | Log in to Reply

      I may have missed it already, but was there a meeting where people could suggest tickets they wanted to see addressed in 4.2?

    • Paal Joachim Romdahl 11:32 am on January 21, 2015 Permalink | Log in to Reply

      Will all feature plugin suggestions receive feedback as to why or why not each seem suitable as a feature plugin? What is the criteria to become a feature plugin and who decides on this? As it seems like this would be a good community discussion as to what to include in WordPress core and not.

  • John Blackbourn 9:30 am on January 13, 2015 Permalink

    Feature plugins in 4.2 and beyond 

    Feature plugins for WordPress 4.2 and beyond need to be planned. Let’s get some suggestions together along with their status and who’s working on them.

    For each feature plugin that you would like to see considered, either for 4.2 or for a future version, please leave a comment with the following details:

    • Current status (eg. idea, planning, early/late development, testing, stable)
    • Who’s responsible
    • Link to GitHub repo or w.org page, if appropriate
    • Whether you’d like the plugin to be considered for 4.2

    It’s become apparent that feature plugins need to be at a much more mature stage before they are considered for merge into core. After all, the point of a feature plugin is to build a feature as a plugin and if the plugin never gets merged into core then we’re still left with a fully workable standalone plugin. Any feature plugins which are to be considered for 4.2 need to be at a very mature stage already.

    • Hugh Lashbrooke 9:41 am on January 13, 2015 Permalink | Log in to Reply

      Not sure what kind of things you’re looking for here exactly, but I built this plugin to improve the export tool: https://wordpress.org/plugins/export-plus/ because the patch I submitted doesn’t look like it’s going to be merged anytime soon: https://core.trac.wordpress.org/ticket/27048.

      The plugin is fully functional and there aren’t any bugs that I’m aware of. The only thing it really needs before merge is unit testing, which is a problem because the core unit test library for the export tool was rewritten for a separate patch that also hasn’t been merged (https://core.trac.wordpress.org/ticket/22435), so we would need to revert the core unit test repo for this side of things. Anyway – just thought I’d throw this out there because I think it’s a very useful filler until the export API is properly rewritten like that other patch is doing.

    • Rami Yushuvaev 11:56 am on January 13, 2015 Permalink | Log in to Reply

      Currently, the wp.mce.views API is still experimental (https://core.trac.wordpress.org/browser/tags/4.1/src/wp-includes/js/mce-view.js). It would be nice if WordPress 4.2. will Introduce the full API.

    • Eric Mann 2:59 pm on January 13, 2015 Permalink | Log in to Reply

      I’d been working on Secure XML-RPC for consideration as a feature plugin, and would like to see it revisited.
      Current Status: Late development (on hold as the JSON API was supposed to be in core already, but since it’s not, let’s take some time to revisit this for security sake)
      Who’s Responsible: Me, at the moment. More than happy to have other collaborators.
      Github: https://github.com/ericmann/secure-xmlrpc
      Consider for 4.2: Yes please

      The plugin currently sub-classes the XML-RPC server to provide the secure authentication method as an alternative to sending username/password in plain text. If/When rolled into core, this subclass would be replaced by actually updating the core server implementation. Everything is still backwards compatible (original auth still works, it just sends an X-Deprecated header), so concerns about this breaking existing libraries are minimal.

      • Dave Navarro, Jr. 6:41 pm on January 14, 2015 Permalink | Log in to Reply

        Does anyone know the status of the JSON API? Are they ever gonna finish it?

        • Adam Silverstein 9:43 pm on January 14, 2015 Permalink | Log in to Reply

          Development is ongoing, version 1.1 was recently released and is avaialable for your use: https://wordpress.org/plugins/json-rest-api/

        • Eric Mann 12:09 am on January 15, 2015 Permalink | Log in to Reply

          v1.1 is live. When it’s eventually rolled into core, we’ll increment the version to v2.x. Unfortunately, the “when” for rolling into core is a moving target. Every time we get close, something else comes up to delay it. I was expecting it in 4.0. Then 4.1. Now we’re hoping it might make it into 4.2, but still no promises.

          I’m still really looking forward to the JSON API making it into core. It’s going to be a huge step forward to what WordPress can do. That said, XML-RPC isn’t going to disappear, even when the new API ships. So we should do what we can to make sure that the existing remote interaction API works and is secure.

          • Dave Navarro, Jr. 10:22 pm on January 15, 2015 Permalink | Log in to Reply

            Okay, great! So 1.1 is ready for production sites?

          • dshanske 12:05 am on January 17, 2015 Permalink | Log in to Reply

            I was hoping for a gradual sunsetting of XML-RPC after JSON came into core, although I know that is less likely to happen.

            Of course, it may merely be my annoyance of it being probed by so many outside sources.

    • Mike Hansen 4:02 pm on January 13, 2015 Permalink | Log in to Reply

      I have been exploring starting a project for the registration flow for new users. This would include the signup, login, email, etc.
      Current Status : Idea/Planning
      I would like to lead this project. I would like to have it ready for consideration in 4.3.

      Looking for others interested as well.

      • Travis Northcutt 4:53 pm on January 13, 2015 Permalink | Log in to Reply

        Mike, would this potentially include an option for something like “send this user a link to set their password” when creating a new user in wp-admin? Basically, a way to avoid setting passwords for users, and to avoid transmitting passwords via email.

        Feel free to ping me on twitter (tnorthcutt), I may be interested in helping out.

        • Mike Hansen 5:03 pm on January 13, 2015 Permalink | Log in to Reply

          Yea, plain text passwords in email is one thing on the list.

          • Ihor Vorotnov 10:03 pm on January 21, 2015 Permalink | Log in to Reply

            If this includes possible improvements to the whole registration process, I may be interested as well. Working on a several large projects based on WP, created 2 different versions of custom registration / activation / login process. Have some interesting experience, fails and mistakes, wins and tweaks.

    • Scott Kingsley Clark 4:17 pm on January 13, 2015 Permalink | Log in to Reply

      We’re still working on getting a proposal together for a new Metadata API for registering contextual custom field data (type of data, label text for forms) along with UI (show custom fields in a post edit screen with their corresponding field type inputs).

      It’s not ready, and we’re currently in the process of rebooting our efforts geared towards everything as a result of a discussion with core dev @helen

      We’ll be starting up discussion and status posts in the coming month.

      Though, not exactly a normal feature plugin, we’re hoping to develop it in such a way that it could be used and tested via a plugin for proof of concept.

      • Ihor Vorotnov 10:05 pm on January 21, 2015 Permalink | Log in to Reply

        That might be yet another bottleneck for multilingual sites until WP core becomes multilingual. Just saying :)

      • Nick Halsey 4:33 pm on January 13, 2015 Permalink | Log in to Reply

        I’d love to see this, especially if it takes inspiration from (or actually uses, which could be a possibility) the Customizer API. The ease with which devs can spin up, for example, a media control with previewing with that API, as well as being able to easily create custom controls (and custom sections and panels) by subclassing in PHP and JS would be great for post meta.

    • Siobhan 5:02 pm on January 13, 2015 Permalink | Log in to Reply

      Feature Plugin – Image Flow
      Better image uploading, management, and editing, on every device.

    • Nick Halsey 5:17 pm on January 13, 2015 Permalink | Log in to Reply

      Menu Customizer

      Current status: late development/iterations
      Who’s responsible: me (Nick Halsey, @celloexpressions), with help from @westonruter, @voldemortensen, and others so far
      Links: https://wordpress.org/plugins/menu-customizer/, https://github.com/voldemortensen/menu-customizer, continuous discussion in #core-customize on Slack
      Whether you’d like the plugin to be considered for 4.2: depends on 4.2 timeline and how the next couple weeks go. It’s fairly stable and usable, but there are a few things that need refactoring, and we’re also working on improving core APIs to make things less hacky. The UI is essentially the same as the Widget Customizer UI, so while there’s potential room for improvement there, I don’t foresee needing significant design work before the initial version goes into core (and no one has done much work there yet).

      • Paal Joachim Romdahl 4:05 pm on January 14, 2015 Permalink | Log in to Reply

        What about adding features from kirki?:

        • Nick Halsey 9:03 pm on January 14, 2015 Permalink | Log in to Reply

          That could probably be done in the form of core tickets/patches if anyone’s interested. The only potential thing that could add would be more custom controls.

      • Samuel Sidler 7:34 pm on January 14, 2015 Permalink | Log in to Reply

        I’d like to see some user testing before it goes into core. Has the accessibilty team reviewed it?

        • Nick Halsey 8:59 pm on January 14, 2015 Permalink | Log in to Reply

          I’ve done some informal in-person user testing and not run into issues. But if someone has the ability to do better user testing that we can iterate from, that would obviously be better (maybe @designsimply?).

          It would be good if the accessibility team started reviewing it. I’ve done basic keyboard-only tests and retained things from the menus admin and the widget Customizer API, but I have only limited knowledge there.

    • Daniel Bachhuber 5:33 pm on January 13, 2015 Permalink | Log in to Reply

      Shortcake (Shortcode UI)

      • Current status: Early to mid development
      • Who’s responsible: Matt H-Y from Human Made and a few of us from Fusion.
      • Link: https://github.com/fusioneng/Shortcake
      • Whether you’d like the plugin to be considered for 4.2: Could, if there’s interest. We have it in production, and it’s available on WordPress.com VIP. Currently it’s more of a developer API than user-facing feature because it requires code-level configuration. At the least, it would be good to get some core opinions on it.
      • Scott Kingsley Clark 9:47 pm on January 13, 2015 Permalink | Log in to Reply

        Would be a good idea to be sure we’re aligned in approach and what we’re doing between the Metadata project and Shortcake, could share some lessons learned and come up with a solution that has even greater reach.

      • Hugh Lashbrooke 7:09 pm on January 13, 2015 Permalink | Log in to Reply

        This sounds interesting – I’d be keen to get involved here. Will check out the repo.

    • petermolnar 9:00 am on January 14, 2015 Permalink | Log in to Reply

      Filter Post Formats
      If the site supports post formats, we should be able to filter by them on the posts admin.

      ImageMagick Sharpen Resized Images
      Simple Image Sizes
      WP Resized Image Quality
      For those who use WordPress as a portfolio, the default image quality is disappointing. Please let us have the option to change those.

      Thin Out Revisions
      Revisions are nice – unless you have hundreds of them.

      Unattach and Re-attach Media Attachments
      Instead of re-uploading everything, this would be useful.

      The default pagination is way too simple.

      Pingbacks are dead, long live webmentions.

      • John Blackbourn 10:01 pm on January 14, 2015 Permalink | Log in to Reply

        Can you provide some more info like I asked for? Would you like these plugins considered for 4.2 or later releases? What’s the current status of each?

        • dshanske 1:47 am on January 15, 2015 Permalink | Log in to Reply

          Who’s Responsible: The plugin was developed by Matthias Pfefferle, but I’m not sure if he’s prepared to lead a project on it.
          Current Status: Webmention is fairly mature
          Links – https://wordpress.org/plugins/webmention/ and the Github version https://github.com/pfefferle/wordpress-webmention

          It is basic plumbing for a better alternative to Pingbacks and Trackbacks. Both of those have become so much of a problem that people often disable them. It is time to start building better solutions than disabling them. That comes with a better foundation on which to base enhancements.

          Semantic Linkbacks
          Who’s Responsible: The plugin was developed by Matthias Pfefferle, but I’m not sure if he’s prepared to lead a project on it.
          Current Status: Also mature
          Links – https://wordpress.org/plugins/semantic-linkbacks/ and the Github is https://github.com/pfefferle/wordpress-semantic-linkbacks

          Semantic Linkbacks endeavors to generate richer trackbacks, pingbacks, and ‘webmentions'(see above) by parsing the source URL for microformats, but could also add other types of markup.

          Back to the issue of linkbacks of all types becoming useless…this, combined with webmention, is the start of making linking to other sites a more meaningful thing once more.

        • petermolnar 3:45 pm on January 15, 2015 Permalink | Log in to Reply

          I’m sorry for not being more detailed; I should have been in the first place.
          Thanks for dshanske for stepping in for the webmentions/semantic linkbacks plugin.

          For the rest:

          Thin Out Revisions
          Current status
          Mature and actively maintained.

          Who’s responsible
          blogger323 user.

          Plugin to be considered for 4.2?
          The provided functionality helps cleaning up and maintaining revisions in a nice and user-friendly way; yes, it should be considered might even for 4.2

          Current status
          Mature and old project, under active development.

          Who’s responsible
          Eric Martin and StudioFuel users.

          Plugin to be considered for 4.2?
          Not neccessarily for 4.2, but since it provides sophisticated and detailed settings for pagination, including labels, range, etc., therefore it could be considered.

          ImageMagick Sharpen Resized Images
          Current status
          Relatively new plugin but actively maintained.

          Who’s responsible

          and niwreg users.

          Plugin to be considered for 4.2?
          For one of the following versions where the Media Library receives significant updates.

          WP Resized Image Quality
          Current status
          It have not received an update in a long time and seems to be unmaintained.
          The functionality it provides is very useful though, especially for image-heavy portfolio sites.

          Plugin to be considered for 4.2?
          For one of the following versions where the Media Library receives significant updates.

          Unattach and Re-attach Media Attachments
          Current status
          Seem to be abandoned, but the idea it represents should be considered as a feature.

          Plugin to be considered for 4.2?
          For one of the following versions where the Media Library receives significant updates.

    • Dan Nisbet 2:37 pm on January 14, 2015 Permalink | Log in to Reply

      It’s not anything gigantic or groundbreaking, but I created a plugin called Home & Blog Label: https://wordpress.org/plugins/home-blog-label/

      It simply adds a label next to the pages that are set to display blog posts or on the front page when a user sets them under Settings > Reading.

      I’ve been using it on some client websites and people love being able to quickly scan through the list of pages to find the blog or home page when it needs editing. I’d love to see it as part of core.

    • FolioVision 4:05 pm on January 14, 2015 Permalink | Log in to Reply

      Hi John,

      This is a great idea. We’ve always found the comment moderation/management a bit weak (no wonder so many people are using the Disqus crutch). Our plugin Thoughtful Comments supercharges comment moderation by moving it into the front end (i.e. in context). It also allows banning by IP, email address or domain.

      Unlike many comment plugins, Thoughtful Comments works hand in hand with Akismet, feeding all the information into Akismet as well as the existing WordPress whitelist and blacklist features.

      What’s cool about Thoughtful Comments is that you can add it to a WordPress site with no changes to existing comment moderation tables and you can remove it from a WordPress site with no loss of core functionality. I.e. I think Thoughtful Comments could be integrated into core with a minimum amount of pain. Thoughtful Comments works with all current Subscribe to Comment plugins as well. As we use all core functions and tables, Thoughtful Comments works with all current Subscribe to Comment plugins as well.

      Thoughtful Comments is the most powerful and useful code we’ve ever written (we have four very popular plugins). It’s integration into core would save many, many site owners the pain of Disqus.

      1. Thoughtful Comments is entirely stable and active on some of the most heavily commented political and lifestyle sites in the world.
      2. Foliovision is responsible.
      3. https://wordpress.org/plugins/thoughtful-comments/developers/
      4. We’d love to be considered for 4.2.

      I know Automattic has a horse in the ring (Intense Debate) but improving the core comment moderation would be such a great fix. Upcoming: we have additional invisible caching coming for heavily commented posts (so that if there are hundreds of older comments, they get saved as flat html, lightening PHP load and speeding up busy sites significantly.

      Cordial regards,

      Alec Kinnear
      Creative Director, Foliovision

    • aneeskA 5:21 pm on January 14, 2015 Permalink | Log in to Reply

      Current status : stable
      Who’s responsible : aneeskA
      Link to GitHub repo or w.org page, if appropriate : https://wordpress.org/plugins/downml/
      Whether you’d like the plugin to be considered for 4.2 : YES

    • Adam Silverstein 6:12 pm on January 14, 2015 Permalink | Log in to Reply

      Post Meta Revisioning

      Status: In development.
      Who’s responsible: Me, inviting contributors.
      Status: I’ve been working on Post Meta Revisioning (its a feature!) and a handful of related tickets in the Revisions component. I would love to see this considered for 4.2.

      I took the last patch from #20564 and, with the inclusion of two hooks added in 4.1, turned ‘Revisioning of Post Meta’ into a plugin:

      On wordpress.org: https://wordpress.org/plugins/wp-post-meta-revisions/

      Development taking place on github: https://github.com/adamsilverstein/wp-post-meta-revisions/

      I would appreciate any help with testing, patches, review, etc.

      Tickets related to and relying on this plugin:

      – Ability to edit and preview any revision, not just autosaves

      – Allow published posts to be revised without being updated immediately

      – Preview changes on a published post makes all post meta “live”

      – ‘Restore This Autosave’ immediately updates a published post

    • jtarrier 3:46 am on January 15, 2015 Permalink | Log in to Reply

      Improved Media Library with user-defined subfolders, taxonomies, categories, “where used” etc.

      The current media library only allows us the choice of uploading into year/month folders or into the “uploads” dumping ground. This is severely limiting and has been in dire need of an overhaul for years.

      The following is a list of plugins which provide much of the desired functionality. The main item of functionality not in the plugins (as far as I have found) is the ability to move media between subfolders and having the database links updated automatically.

      WordPress › Media Library Assistant « WordPress Plugins

      WordPress › Support » FANTASTIC app for arranging media library in folders

      WordPress › Media File Manager « WordPress Plugins

      WordPress › Media Category Library « WordPress Plugins

      WordPress › Enhanced Media Library « WordPress Plugins

    • Weston Ruter 5:09 am on January 15, 2015 Permalink | Log in to Reply

      Customize Partial Refresh

      GitHub: https://github.com/xwp/wp-customize-partial-refresh
      w.org: https://wordpress.org/plugins/customize-partial-refresh/
      Contributors: westonruter
      Status: in development, currently adding partial refresh support for widgets
      Milestone: not concerned to get it into 4.2

      This feature plugin is for implementing what is needed for #27355. As of now it resurrects the partial-refresh functionality from the Widget Customizer plugin and makes it available for Customizer management of Widgets as they exist in Core now. The problem being solved is eliminating the painfully slow Customizer preview update times when a setting transport=refresh. Ideally 100% of changes requiring PHP would be implemented using partial refresh as opposed to a full-page refresh, and this would allow us to do cool things like have Customizer controls appear inline on the frontend without even having to “go into” the Customizer to make changes. Partial refresh is closely related to the work being done on transactions: #30937.

    • Pascal Birchler 9:23 am on January 15, 2015 Permalink | Log in to Reply

      this would allow us to do cool things like have Customizer controls appear inline on the frontend without even having to “go into” the Customizer to make changes

      Ohh this sounds great! Just think of all the use cases for this…

    • Dave Navarro, Jr. 10:25 pm on January 15, 2015 Permalink | Log in to Reply

      I’d really like to see “title” supported with the audio player. It’s supported in jPlayer, but I don’t know how much jPlayer was modified for WordPress as I haven’t been able to find the support code in the WP version.

    • Cătălin Dogaru 10:14 am on January 16, 2015 Permalink | Log in to Reply

      Avatar Manager
      Plugin for storing avatars locally. Started as a core ticket (#16020) some time ago.

      • Current status: Pretty stable, feedback/peer review wanted.
      • Who’s responsible: Me and anyone interested.
      • Links: GitHub, WordPress.
      • Whether you’d like the plugin to be considered for 4.2: Not necessary, depending on your interest. At least, it would be great to set a resolution on it.
      • Cătălin Dogaru 1:43 am on February 1, 2015 Permalink | Log in to Reply

        For anyone interested, I’ve posted an update on the original ticket. It would be great to see more opinions on this, whether you think it’s suitable for core or not.

      • Cătălin Dogaru 8:49 pm on January 20, 2015 Permalink | Log in to Reply

        Thanks @dnavarrojr and @dshanske for getting involved! Just to be clear, this doesn’t remove Gravatar support. Gravatar is nice; if you’re using it you’re all set! I just want to make it easier for anyone to update (like GitHub did).

        • dshanske 4:40 am on January 21, 2015 Permalink | Log in to Reply

          The counterargument is that gravatar support should be secondary. WordPress is self-hosted, yet has a dependency on a third-party service. I’m not advocating removing gravatar support…It’s been there too long, and too many things depend on it. But I think that infrastructure should be local first, remote second.

          I should be able to tell my install to only rely on local. If you can’t find a local image, use a local default. It should be a choice.

      • Dave Navarro, Jr. 8:48 pm on January 16, 2015 Permalink | Log in to Reply

        +1 on this, I really would like to see Gravatar removed from core and left in Jetpack and native avatars used instead.

        • dshanske 11:48 pm on January 16, 2015 Permalink | Log in to Reply

          The agument is that gravatar is an industry standard. Nothing ever seems to leave core though.

          Local storage of information should always be the primary option over polling a third-party site, at least for local accounts.

          Although I’d like to find a good solution for also polling the URL provided by a commenter to get their local avatars also.

    • Merv Barrett 6:33 pm on January 17, 2015 Permalink | Log in to Reply

      Not sure if this is the right place to submit a request for an enhancement to get_template_part() I’ve searched but have not found a request for a core change.

      What would make plugin development much easier for plugins adding custom post types is a filter that would enable filtering of get_template_part() function.

      For example for a post type “property” we would be able to override the get_template_part if the post is being viewed.

      Is this possible to add to the core or are we requiring users to create their own single-property.php and archive-property.php.

      Having a filter would allow plugin developers to replace that with their own function and allow for greater control and compatibility with the thousands of themes. In my case adding to the_content is not sufficient as I would like complete control over the contents of the single and archive pages. Doing this also allows the plugin to inject customised content into the theme design withouth breaking the theme layout. (Every theme is so different in CSS and container elements)

      An example would be

      My plugin creates its own template eg:

      Function epl_single_content() {
      // address
      // bedrooms bathrooms price
      // featured image
      // content
      // features
      // map
      // more stuff
      add_filter( ‘get_template_part’ , ‘$post_type’ , ‘epl_single_content’ );

      This would allow WordPress to be able to deal with custom post types and user skills much easier?


    • Nick Halsey 7:49 am on January 19, 2015 Permalink | Log in to Reply

      Customizer Theme Switcher

      Current status: stable, seeking feedback
      Who’s responsible: me (@celloexpressions)
      Link: https://wordpress.org/plugins/customizer-theme-switcher/
      Whether you’d like the plugin to be considered for 4.2: definitely 4.2 material. Although I only started working on it a few days ago, it’s pretty complete thanks to re-using a lot of code and UI from themes.php. Almost could have been done as a core patch, but this makes testing & iteration easier. Additionally, while a couple minor core patches would help, it’s entirely built on the 4.1 Customizer API. Accessibility should be covered, but it wouldn’t hurt for the team to do an audit. See also #26890.

      I have class during the meeting unfortunately, but if this and Menu Customizer could be discussed in my absence that would be great (I’ll read the archives).

      • Nick Halsey 1:10 am on January 20, 2015 Permalink | Log in to Reply

        Also, a clarification: the plugin simply provides the UI and is functional with the current way that theme previewing in the Customizer works. @westonruter also has some ideas for improving the internals, along with the proposed Customizer transactions API. That’s not a requirement but would be nice to have and will likely end up in 4.2 anyway.

    • Måns Jonasson 10:29 am on January 19, 2015 Permalink | Log in to Reply

      Enable Media Replace

      The plug allows users to replace uploaded media, which is perfect for switching out images or files without having to update URL:s on pages.

      Current status: stable
      Who’s responsible: me (@mungobbq)
      Link to w.org: https://wordpress.org/support/plugin/enable-media-replace
      Link to Github: https://github.com/mansj/enable-media-replace

      I think this functionality should be in core.

      • dshanske 4:36 am on January 21, 2015 Permalink | Log in to Reply

        If it is being looked at to replace uploaded media, is there anything we can do to deduplicate media concurrently? I’ve seen people try to upload the same picture multiple times.

      • enailor 7:56 pm on April 7, 2015 Permalink | Log in to Reply

        Just added this plugin as an idea as well.. did not realize it was already mentioned. I use this awesome plugin for every project I do. Thanks to Måns for this great feature!

    • Helen Hou-Sandi 8:24 pm on January 19, 2015 Permalink | Log in to Reply

      RICG Responsive Images

      Current status: Initial release
      Who’s responsible: Primarily @tevko and @wilto
      Link to .org: https://wordpress.org/plugins/ricg-responsive-images/
      Link to GitHub: https://github.com/ResponsiveImagesCG/wp-tevko-responsive-images

    • Ihor Vorotnov 10:30 pm on January 21, 2015 Permalink | Log in to Reply

      Multilingual core, please. Years are passing and WP is still a single-language platform. I understand, that making core truly multilingual will kick WPML out of business. But hey, it’s a core feature in all platforms. It has to be in core.

      Polylang plugin is the best out there, better than WPML (and compatible with WPML API btw)

      Current status: stable, used by many people on many sites, pretty well maintained
      Who’s responsible: https://profiles.wordpress.org/chouby/
      Link to repo: https://wordpress.org/plugins/polylang/
      Whether you’d like the plugin to be considered for 4.2 – I understand that doing it right will require a lot of work and I suppose it has to be done in small steps. Last year I was talking to plugin author about making some significant and useful changes but we faced lots of limitations of the core. Once these limitations are solved, we will do the rest. So, basically, we just need some core architecture changes that will make it possible to turn Polylang into truly multilingual plugin, flexible and solid. I can describe those changes if there’s interest in at least planning to make it happen.

      • Paal Joachim Romdahl 3:37 pm on February 18, 2015 Permalink | Log in to Reply

        Regarding limitations. What about creating (finding existing) trac tickets to solve the limitations?

        The plugin seems really interesting. I hope you will bring this up again sometime in the future.
        I have added it to my to do list of language plugins to take a closer look at.

    • enailor 7:55 pm on April 7, 2015 Permalink | Log in to Reply

      Sorry I am late to this party, but a plugin that I think is very useful and appropriate is Enable Media Replace. I use this on every project I do and recommend it to anyone.

      WP.org link: https://wordpress.org/plugins/enable-media-replace/

      Måns Jonasson is the author https://profiles.wordpress.org/mungobbq/

      I know its too late for 4.2, but it should be added soon. So many added features around the media uploader and management of media, I am surprised this has not yet been added as a default feature.

      Enable Media Replace allows a user to simply replace an image with a new version, preventing the unnecessary uploading of newer versions of an image in addition to older versions that are no longer needed. Most users, in my experience, do not remove old images from the media library, so the library and hosting account can become bloated with images that are no longer used. being able to simply replace an image with a new one, but keep the original file names, also allows a user to update images without having to find every location of that image on their site. Big advantage if the image has been used on several blog posts.

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