WordPress.org

Make WordPress Core

Updates from John Blackbourn Toggle Comment Threads | Keyboard Shortcuts

  • John Blackbourn 12:38 am on January 26, 2016 Permalink |
    Tags: ,   

    HTTPS discussion meeting this Wednesday 

    In recent releases of WordPress there have been various improvements made to support for sites running on HTTPS. While support is currently very good, it’s still too easy to end up with mixed content on a site (HTTP content embedded within an HTTPS page), and especially so when migrating an existing site from HTTP to HTTPS.

    There will be a discussion meeting in the #core-http Slack channel on Wednesday, January 27, 2016 at 2000 UTC. This is one hour before the regular weekly meeting in #core. I’d like to discuss three topics:

    1. Implementing an (opt-in) method of forcing a site to use HTTPS.
      • What should this cover? (Embedded content, enqueued scripts/styles, links, redirects)
      • How should it be implemented? (eg. filter/constant/automatic)
    2. Defaulting to HTTPS for new installs when it’s available.
      • Only applies when setting up a site over HTTP and it’s available over HTTPS.
      • Need to communicate clearly to the user what this implies, with option to toggle.
    3. Aiding in switching an existing site from HTTP to HTTPS.
      • Migrating existing embedded content.
      • Should this be a feature plugin?

    If you’re interested in helping out with any of the above, or with HTTPS improvements in general, join us on Wednesday.

    Further reading: the https tag on Core Trac.

     
  • John Blackbourn 5:08 pm on December 11, 2015 Permalink |  

    Additional labels for custom post types and custom taxonomies 

    In WordPress 4.3 and 4.4, additional labels have been made available for custom post types and custom taxonomies. These get passed in via the labels argument when using register_post_type() and register_taxonomy().

    New post type labels in 4.3:

    • featured_image – Overrides the “Featured Image” phrase for this post type. See #19257.
    • set_featured_image – Overrides the “Set featured image” phrase for this post type. See #19257.
    • remove_featured_image – Overrides the “Remove featured image” phrase for this post type. See #19257.
    • use_featured_image – Overrides the “Use as featured image” phrase for this post type. See #19257.

    New post type labels in 4.4:

    • archives – The post type archive label used in nav menus. Default “Post Archives”. See #16075.
    • insert_into_item – Overrides the “Insert into post”/”Insert into page” phrase (used when inserting media into a post). See #33616.
    • uploaded_to_this_item – Overrides the “Uploaded to this post”/”Uploaded to this page” phrase (used when viewing media attached to a post). See #33616.
    • filter_items_list – Screen reader text for the filter links heading on the post type listing screen. Default “Filter posts list”/”Filter pages list”. See #32147.
    • items_list_navigation – Screen reader text for the pagination heading on the post type listing screen. Default “Posts list navigation”/”Pages list navigation”. See #32147.
    • items_list – Screen reader text for the items list heading on the post type listing screen. Default “Posts list”/”Pages list”. See #32147.

    New taxonomy labels in 4.3:

    • no_terms – Used when indicating that there are no terms in the given taxonomy associated with an object. Default “No tags”/”No categories”. See #32150.

    New taxonomy labels in 4.4:

    • items_list_navigation – Screen reader text for the pagination heading on the term listing screen. Default “Tags list navigation”/”Categories list navigation”. See #32147.
    • items_list – Screen reader text for the items list heading on the term listing screen. Default “Tags list”/”Categories list”. See #32147.

    See the documentation for get_post_type_labels() and get_taxonomy_labels() for the full list of available labels.

     
  • 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
    Tags:   

    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.

    Previously:

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

    Now:

    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.
      Thanks.

    • 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.
      https://core.trac.wordpress.org/ticket/29700

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

      Golf clap

    • elzix 2:26 pm on November 5, 2015 Permalink | Log in to Reply

      I read in the Theme Developer Handbook and assumed single-{post_type}-{post_name}.php was in WordPress 4.3. Is there a way to add the function to my theme or must I convert my posts to pages and use ‘categories for pages’ plugin?

  • 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

        Reasoning:

        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.

        • DS2014 2:00 am on November 17, 2015 Permalink | Log in to Reply

          Good news: I’m excited to let you know that my domain was whitelisted by LetsEncrypt, and I can now use an ACME client to obtain a certificate for it. Running into Problem #2 as I haven’t yet figured out the instructions to actually get the cert and add it. Best I can figure, first I need to install Git. By chance, any idea where I could find out how to do it step-by-step?

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

      http://www.jewelrythis.com
      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.

    • ottok 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.

      Issues…
      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.

    • fiskius 10:31 am on October 29, 2015 Permalink | Log in to Reply

      I run a number of wordpress sites on different domains, but only the web host provides a certificate for the original server site, which I use using the WordPress HTTPS plugin (https://wordpress.org/plugins/wordpress-https)

      so, my site: http://www.example.com
      my admin: https://server.host.com/~username/wp-admin/

      This works fine EXCEPT the theme page and live previews are blank, non of them load at all. As soon as I switch the plugin off, they load. So I’d like to get around this bug! Looks like someone had a similar issuer, but not sure how to apply this patch (https://wordpress.org/support/topic/add-theme-issue-with-fix)

      I appreciate people’s comments that everyone should go for fully SSL, but its too costly for me currently. Looks like Letsencrpyt is good, but I doubt I’d be able to run the commands on my web hosts server.

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

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