WordPress.org

Ready to get started?Download WordPress

Make WordPress Core

Updates from John Blackbourn Toggle Comment Threads | Keyboard Shortcuts

  • John Blackbourn 5:52 pm on June 11, 2014 Permalink | Log in to leave a Comment  

    SSL taskforce 

    We’re hoping to make many improvements relating to SSL/HTTPS support in 4.0. Several fixes have already gone in over the last couple of weeks, and several are in progress.

    Below is an ad-hoc list of SSL related bugs and potential enhancements that I’ve experienced in one way or another. Please leave a comment with details of other SSL related issues you are aware of (whether they’re already in Trac or not). I’m going to be tackling as many issues as possible for this release. We may or may not find some time to discuss some of this during tonight’s dev meeting.

    Issues with HTTP front end and an HTTPS backend

    • Customiser previews break, site is requested over http
    • ‘url’ and ‘return’ links in customiser have incorrect scheme
    • Media inserted into posts gets the incorrect scheme
    • GUIDs use the admin scheme
    • Network admin, some mixed http/https issues – #14867, #27499
    • Idea: filter to enable plugins to specify URLs / post IDs / paths which should be forced to https?
    • Idea: filter to enforce front end over http? (excluding urls from above filter)
    • Arguments in favour of a front-end ajax handler: x-domain and x-protocol issues with domain mapping

    General issues with HTTPS on front end

    • Should we force https scheme on local content in post content, post excerpt, comment text, etc?…
    • Should we force https scheme using canonical? – fixed – #27954
    • Should we force https scheme for enqueued local scripts/styles?

    General issues with HTTPS backend

    • Mixed content in the editor – can we force https scheme for local content? What about CDNs etc?
    • XML-RPC does not enforce https – looks like a wontfix – #28424
    • Theme thumbnails aren’t loaded over https – fixed

    General HTTPS issues

    • No support for secure oEmbeds
    • wp_get_attachment_url() doesn’t respect scheme – #15928
    • HSTS – not something core should do – could be enabled with a filter but not enabled by default
    • “Update siteurl and home as well” on network admin loses https scheme

    Issues specifically with HTTPS everywhere

    • Not all cookies have secure flag set – #28427
     
    • Andrew Nacin 6:14 pm on June 11, 2014 Permalink | Log in to Reply

      I think HSTS could be enabled by a constant; this would handle XML-RPC forcing in the process (#28424).

    • Andrew Nacin 6:16 pm on June 11, 2014 Permalink | Log in to Reply

      I don’t think canonical is enough for forcing SSL. We probably need a new FORCE_SSL constant that handles everything over SSL and prevents any requests over HTTP (basically, weak application-side HSTS). The next logical extension to that would be having FORCE_SSL_HSTS that does both SSL + HSTS. Or, as said, a filter.

    • Zack Tollman 6:21 pm on June 11, 2014 Permalink | Log in to Reply

      I think keeping FORCE_SSL separate from the HSTS control is important as undoing HSTS is more complicated than toggling a constant. You need to set a new header.

      I never thought of setting HSTS via PHP, but I think this is a fantastic idea. We just need to consider undoing it by setting a header to cancel HSTS if necessary. I could see this being a confusing and frustrating problem for devs.

    • Dean Taylor 7:52 pm on June 11, 2014 Permalink | Log in to Reply

      Consider “blacklisting” and notification to admins of non-HTTPS embedded content. For example http://prezi.com/ embeds do not support HTTPS. Even if you change the embed URL to HTTPS ultimately it loads some content over HTTP causing mixed content warnings to users.

      The idea is to help existing WordPress sites with their transition to HTTPS.

      • Zack Tollman 6:12 pm on June 13, 2014 Permalink | Log in to Reply

        This is a good idea, but perhaps not ideal for core. I think that while this SSL efforts are underway, a plugin that provides this feature should be developed.

    • webaware 11:04 pm on June 11, 2014 Permalink | Log in to Reply

      I think you need to make any moves to force SSL an option. In the case of HTTPS backend, forcing SSL on content in the editor can break the frontend if the site certificate is self-signed, for example; visitors would see patches of missing content because the certificate is untrusted. If the frontend is set to HTTPS, however, then it is appropriate to force content to HTTPS too.

      I reckon the idea to handle HTTPS for enqueued scripts and stylesheets in core is terrific. If you’re doing that, you also want to handle media added to content dynamically, which you can do via the wp_get_attachment_url and upload_dir filters.

      You might as well enforce HTTPS for scripts and stylesheets whether local or non-local, since they are malware vectors and should either work or not — no “works if visitor allows it” nonsense. A failed non-local script load means some script doesn’t run, but an insecure content warning means the site looks unsafe to a visitor and can scare people away (and the script load fails anyway on any decent browser).

      Forcing HTTPS for non-local content must be an option, if done at all. Non-local content, including CDNs, may not have SSL hosting or may have self-signed certificates. Visitors can be warned (by their browser) that the site includes mixed content and then accept to view the “unsafe” content. It’s a bad smell, but it happens on some sites. Forcing HTTPS would effectively remove that content from the site.

      Before setting enforcement, it might be a good idea to check that WordPress can actually detect SSL:

      • reverse proxies often don’t pass through the HTTPS environment variable for SSL connections
      • some reverse proxies pass HTTP_X_FORWARDED_PROTO or another environment variable instead (but that can be spoofed)
      • some reverse proxies don’t pass ANYTHING identifying the connection as originating on SSL

      I have a dodgy fix for that last scenario, but it’s a stab in the dark thing and must be installed with intention by someone who has identified their problem: https://gist.github.com/webaware/4688802

    • Terence 4:57 pm on June 12, 2014 Permalink | Log in to Reply

      The problem is that for plain text Apache2 figures out which vhost you meant via the request. Plain text is easy.

      But for SSL based requests, Apache2 doesn’t even get the request to process until after the SSL encryption is established and by then you got the wrong VHOST and wrong cert.

      The old method just says send it to the first VHOST with SSL. That’s why *.qloudpress.com will work: the wildcard cert is fine for subdomains. When you want to use someotherdomain.com, Apache2 will still send you to the wrong VHOST and SSL cert. Previously, you bound SSL VHOSTS to separate IPs to get around that.

      That’s where SNI (Server Name Indication) Independent of IP comes in. It figures out the requested web site and VHOST before Apache2 starts processing the request. You ask for someotherdomain.com, you get sent to the correct VHOST and SSL certs. Apache2 serves the request using the correct certs and all is right in the world.

      SNI is definitely the way to go.

    • Jan Thiel 4:58 pm on June 16, 2014 Permalink | Log in to Reply

      If not covered by the other changes already, please finally approach https://core.trac.wordpress.org/ticket/20534 ;-)

      Nice to hear WP Core finally learns HTTPS!

      One more thing: I belive forcing HTTPS might not be the right way. The default way should be WP delivers its content with the protocol it was requestet. Quite simple for starters and enough to solve many problems right now.
      An option (just a simple one) to make the whole Blog or only WP-Admin HTTPS-Only would be a very nice addon. But after all, it might be much more itelligent to consider “Force HTTPS for Logged In users” instead of “Force HTTPS for WP-Admin”. Because WP-Admin at all is not that important to secure. It is the User and their credentials that has to be secured via transport! Combining that switch with the Secure- and HTTP-Only Cookie Flags should make kind of a dream team.

      Good hunting, brgds

      Jan

    • John Blackbourn 5:01 pm on June 16, 2014 Permalink | Log in to Reply

      Thanks Jan, I’ll add #20534 to the list!

      Of course WP won’t be forcing any particular protocol on anybody. What we’re aiming to do is ensure that if someone does use SSL on their site, then everything that should be is served over SSL (and vice versa).

    • Just a guy 5:24 pm on July 10, 2014 Permalink | Log in to Reply

      Sorry, I’m late to the party, just saw this Also, I apologize if this has already been mentioned, but I haven’t seen it explicitly, so I’ll mention it just in case.

      On multisite networks where a wildcard certificate is used and SSL is forced in login/admin areas network-wide I’ve seen issues getting cookies to carry over from the https backend to the http frontend which results in the admin bar being unavailable on the front-end

      For hosting I use WP Engine, which is fairly widely used, so I assume it’s not just an issue with the host. As a work around I’m using WPMU DEV’s domain mapping plugin (based on Donncha’s original domain mapping plugin) and it’s a reasonable temp fix, but not ideal.

  • John Blackbourn 8:22 pm on May 13, 2014 Permalink
    Tags: , ,   

    Agenda for tomorrow’s Multisite chat 

    We’re having a dev chat about Multisite in #wordpress-dev tomorrow (May 14, 2014 18:00 UTC). I’d like to split the chat into two main areas:

    1. Open vs. closed networks
    2. Everything else

    The concept of an open network where users can create their own sites was the popular impetus for WordPress MU, but is decidedly not the primary use case for multisite anymore. Most operate closed, trusted networks, where site signups are disabled (and often user signups are disabled as well).

    Back in October, Andrew Nacin published a collection of thoughts on potential changes to Multisite, one of which was the idea of open vs. closed networks. I’d like to discuss this concept and whether now is the right time to tackle it. Here are some relevant paragraphs from that post:

    When a network is not designed for “open registration”, there are a number of undue burdens that should be lifted for administrators. Uploadable file types are severely restricted, and the amount they can upload is capped. They cannot activate installed plugins, though there is an option for this. They cannot add users to their sites without knowing their email address (ostensibly to prevent spam), and the user must still go through a “confirmation” process. New sites must go through an “activation” process. They cannot create new users.

    I don’t think WordPress needs to decide that the multisite feature is only geared for closed networks. Rather, a single option — set on install, and controllable via network settings — can control this entire paradigm very effectively.

    Essentially, I am proposing we trust single-site administrators in a closed network to not be spammy, and to be given wide-ranging control of their own sites; but that we do not extend that trust to important areas of security.

    So, let’s discuss whether now is the time to introduce the concept of open vs. closed networks, what form it takes, and to which functionality it extends.

    • What differences should we see between an open network and a closed network?
      • Open user registration
      • Open site registration
      • Capabilities for regular Administrators (plugins, themes, users)
      • Email notifications (amount of, and wording in)
      • User listing and user editing UI differences
      • Site listing and site editing UI differences
      • Network admin dashboard UI differences
    • What form should the open vs. closed network option take? A UI option when installing multisite? Changeable after the fact or set in stone like subdir/subdomain option?
    • What changes need to be considered for existing multisite installs?

    Secondly, let’s discuss all other multisite improvements that we would like to see. Several may well be related to the idea of open vs. closed networks, and that’s ok. Here’s a list to get us started:

    • Reign Rein in notification emails when adding sites, users
    • Improve user searching – #27304
    • Improve user management
    • Better explanations for what archive/spam/delete does to a site
    • Merge in the Hyper Admins plugin
    • Merge in the User Management Tools plugin

    If anyone has particular issues they’d like addressed (bonus points for existing tickets on Trac), leave a comment and we’ll see what we can cover.

    Two other items worth mentioning are:

    • Domain mapping
    • SSL improvements

    I don’t think we’re yet at the stage where we could consider implementing domain mapping in core. It has a prerequisite of removing the subdirectory vs. subdomain paradigm, and we’re not near approaching that (unless someone wants to step up).

    Regarding SSL improvements, I’m planning on arranging a separate working group to tackle a whole raft of SSL improvements in core that aren’t just related to multisite. I’ll be publishing a separate post in the next couple of days to get us started.

     
    • Robert Dall 8:47 pm on May 13, 2014 Permalink | Log in to Reply

      I couldn’t agree more on adding the Hyper Admins and the User Management Tools into core. That makes a lot of sense.

      I could also see real benefit to the Domain Mapping and SSL Improvements.

      Here is why:

      I am actually in the middle of a project where I am using a multi-site for company that has 5 different websites that offer 5 different areas of the products and or services offered.

      So while we could use 5 different installs of WordPress were using the power of multisite to keep the admin to a minimum.

      Domain Mapping will be of great use to this and many other types of multisite usage.

      SSL and wildcard SSL is someone confusing to the uninitiated any improvement to WordPress multisite and SSL would be of great benefit.

    • Sallie Goetsch 8:49 pm on May 13, 2014 Permalink | Log in to Reply

      That’s “rein in.”

      However, I’m really glad to see Multisite getting some attention. I’m not qualified to help develop it, but I’ve noticed the lack of developments in the last several WordPress versions. What IS the status of domain mapping? Do you still need a plugin for it or not?

      Are there any plans to institute network-wide widget areas? Right now network-wide menus are possible with a plugin, but there’s no way to add network-wide widget areas at all.

      How about default theme settings that the network admin can control? I’ve got a project coming up where we’re actually leaning toward NOT using Multisite in part because the network admins would have to go in and configure theme options for each sub-site separately (even though they will be the SAME for each site, with the only difference being a different logo image). We could hack the theme up so it doesn’t have any other options, but that’s not really a good alternative, either.

      I realize these things are too much to ask for 4.0, but wanted to at least add them to the wishlist.

      Thanks!
      Sallie

      • John Blackbourn 3:07 pm on May 14, 2014 Permalink | Log in to Reply

        What IS the status of domain mapping? Do you still need a plugin for it or not?

        Yep, there’s no support in core for domain mapping currently.

        Are there any plans to institute network-wide widget areas? How about default theme settings that the network admin can control?

        Network-wide widgets, menus, and settings are an interesting idea and certainly something I’ve seen requested before. The complication comes when those widgets, menus, and settings need to be present on the main site, which may not be desirable. I’ll add it to the agenda!

    • Rouven Hurling 9:27 pm on May 13, 2014 Permalink | Log in to Reply

      i would love to see #15800 fixed, so that network wide plugins can add a tab the site edit where there can display their options (or in my case, data and options for that client and so on)

    • Knut Sparhell 1:29 pm on May 14, 2014 Permalink | Log in to Reply

      As long as the mulitisite setup can only be done from wp-config.php this should also be where to set a WP_IS_TRUSTED_NETWORK constant. You don’t specifically install a multisite, you install WordPress and transform it to mulitsite by editing wp-config.php.

      The spam site option may be removed unless some sites actually have it set already. The way links was deprecated is the way to go.

      Users should be registered through a signup process to avoid sending passwords over email. Single sites could also gain from a better signup process. For trusted networks this should be unified.

      There is a plugin for dealing with user activation keys, removing unused and unnecessary signups. This could be part of core.

      Shared media could also be something for the future, and have in mind.

      The important thing now is where to start, how to simplify things and not doing things that may block further evolution and flixibility.

      • John Blackbourn 3:10 pm on May 14, 2014 Permalink | Log in to Reply

        As long as the mulitisite setup can only be done from wp-config.php this should also be where to set a WP_IS_TRUSTED_NETWORK constant. You don’t specifically install a multisite, you install WordPress and transform it to mulitsite by editing wp-config.php.

        That’s not quite correct. You add the `WP_ALLOW_MULTISITE` constant but then you still need to go through the setup process in the admin area. This is where I imagine the open/closed network option will go.

        I agree with all your other points!

      • Boone Gorges 4:58 pm on May 14, 2014 Permalink | Log in to Reply

        > There is a plugin for dealing with user activation keys, removing unused and unnecessary signups. This could be part of core.

        Agreed that this is a problem. See also the new “Pending Users” feature in BuddyPress (http://wptavern.com/buddypress-2-0-to-add-signups-administration-screen – BP now creates the wp_signups table for non-multisite as well, to centralize signup management) and this plugin: http://wordpress.org/plugins/unconfirmed

    • Paal Joachim Romdahl 4:50 pm on May 19, 2014 Permalink | Log in to Reply

      An idea… brainstorming….
      What about having a Network page similar to a All Pages/All posts screen. Only here we can create connections. Create a new sub site or link with existing site.

      Create a new sub site options:

      • title, description and perhaps URL.
      • Optional check box for Domain.
      • Check boxes for Shared media, share posts, etc.
      • And probably other options.

      Link with existing site.

      • URL of site
      • Username and password.
      • Check boxes for shared media, share post etc.

      and more.

      This would really make it into a Network page that one can connect existing or new site.

  • John Blackbourn 9:58 am on February 25, 2014 Permalink
    Tags:   

    Contributors Wanted for WP Contributor Day, Manchester, UK 

    WP Contributor Day is a free, one day event focused on enabling and demystifying how everyone can contribute to core. The first event is this coming Saturday – 1st March.

    The organiser, Jenny Wong, is looking for existing contributors to come along and help guide the new contributors.

    From the poll of people who have already signed up, it would be great to have a couple of people from core, themes, plugins, documentation, support and accessibility come to Manchester for the day. Those are the current most popular areas.

    More information can be found at wpcontributorday.com.

    If anyone wants to contact Jenny, she can be found on Twitter at miss_jwo or via email at wpcd@jwong.co.uk.

     
  • John Blackbourn 1:06 am on November 27, 2013 Permalink
    Tags: ,   

    Features as Plugins: Register Your Interest 

    Three of the features in the upcoming WordPress 3.8 release were developed first as feature plugins:

    • MP6, the new visual style for the admin area
    • THX38, the new theme management experience
    • DASH, the refreshed dashboard screen

    Feature plugins are regular plugins whose ultimate aim is to be put forward as new features for future versions of WordPress. This model allows for efficient, collaborative development over longer periods of time, and a certain amount of visibility among people who help develop for core. The status of existing feature plugins can be seen here.

    This post is a call for people who are planning on working on feature plugins in the near future to make themselves known in the comments. People who would like to pro-actively help out should then comment on individual comment threads.

    If you are a developer, designer, or curator who’d like to act as a project lead for (or at least take a primary role in) the development of a feature plugin, please leave a top-level comment on this thread with the following information:

    • A brief (one paragraph) overview of your feature plugin proposal.
    • Current plugin status (idea stage, planning stage, under development, existing feature plugin, prior work, etc).
    • Your role in the plugin (developer, designer, lead, etc).
    • What you’d like help with (scoping, planning, wireframing, development, design, etc).
    • A top secret magic code name for your plugin (optional).

    Please note that this thread is not for putting forward ideas for things unless you are planning on taking an active and primary role in its development. This is an organisation thread, not an ideas thread.

    Anyone who’d like to collaborate on any of the plugins listed in the comments should leave a reply to the corresponding comment indicating your interest and what you can help out with.

    Bear in mind this is not a list of potential features for WordPress 3.9, or indeed any other particular future release. Feature plugins are not tied to any specific release and will only be considered for potential inclusion in core once they reach a certain level of completeness.

    We’ll see how this list pans out over the next few days and go from there! It’s expected that we’ll organise some IRC meetings in due course.

     
    • George Stephanis 1:24 am on November 27, 2013 Permalink | Log in to Reply

      The Search Initiative needs brave souls willing to spearhead some of the varied bits in it. If anyone wants to work on something, but isn’t quite sure what, please snag one of these bits and run with it!

      I’ll be continuing my previous work in addressing points 1, 4, and 7 from that list. If anyone would like to take points 2, 3, 5, or 6, please do!

      • Weston Ruter 3:35 am on November 27, 2013 Permalink | Log in to Reply

        For 5, I’ve been working with @johnregan3 on a plugin called Admin Screen Search (WIP). The idea is to index the full text (not just links) of all admin pages (accessible to the user via the admin menu), to parse out areas of each page and assign weights to text matches appearing in headings, labels, help texts, and input values. When doing a search, admin page results would be sorted by weighted matches. Our plan is to let it be one of Omnisearch providers, and happily to be merged into the core plugin and into core itself.

        Our role: leading development of search results for admin pages

      • Sam Sidler 10:08 pm on December 2, 2013 Permalink | Log in to Reply

        Are you planning on holding weekly chats again?

        • George Stephanis 10:54 pm on December 2, 2013 Permalink | Log in to Reply

          I was intending on finding the people that would want to attend and working the weekly meeting around them, do you think it would be more useful the other way about?

          • Sam Sidler 11:19 pm on December 2, 2013 Permalink | Log in to Reply

            Either way works, but if you haven’t found others yet, it might be worth announcing a weekly chat and having weekly status updates so others can passively get involved. If no one shows up, still holding office hours is good, so if someone decides to show up one day, they know when and where.

    • John Blackbourn 1:32 am on November 27, 2013 Permalink | Log in to Reply

      Here’s mine: Keyboard shortcuts for WordPress. Adding Gmail-like shortcuts for the admin area for navigation, saving posts, adding content, etc. Lots of possibilities.

      Status: Under development. Functional proof of concept here.

      My role: developer

      I’d like help with: General collaboration on development.

      • Tareq Hasan 3:08 pm on December 2, 2013 Permalink | Log in to Reply

        I did something like this about a year ago :)

      • Sam Sidler 11:24 pm on December 2, 2013 Permalink | Log in to Reply

        How are you deciding what the shortcuts will be? Are there other web apps we can look at that have keyboard shortcuts we can compare to? Obviously Gmail, but Google Docs? Blogger? Probably quite a few do, though I’m struggling to think of any right now.

        Once you’ve decided on a set of shortcuts, can most of this be done directly in core? Doesn’t seem like it needs to be a feature plugin unless there are some major-ish UI/UX or backend changes to consider. Making it extensible for plugins might be part of that consideration, I suppose.

        Would love to see it as a plugin in the repository too. :)

        • John Blackbourn 6:43 pm on December 3, 2013 Permalink | Log in to Reply

          I’ve looked at a few web apps/sites (see https://github.com/johnbillion/wordpress-keyboard-shortcuts/issues/3). “G” followed by another key appears to be a defacto standard for navigation, as do others such as “/” for search and “?” to display the list of shortcuts.

          Extensibility is important. I started it as a plugin for the same reasons that feature plugins exist anyway – easy iteration and collaboration, and if they never end up going into core then we still end up with a plugin.

          • kkalvaa 1:54 pm on December 4, 2013 Permalink | Log in to Reply

            Have you considered international versions of those hotkeys? Several “standard” hotkey setups are completely unsuable on non-english keyboard setups due to several characters being mapped to a modifier key (shift/alt). Both “/” and “?” are characters with modifier keys for several keyboard layouts.

      • Tareq Hasan 7:46 am on December 3, 2013 Permalink | Log in to Reply

    • @ubernaut 2:06 am on November 27, 2013 Permalink | Log in to Reply

      i have gotten mixed opinions as to whether this fits within the features as plugin paradigm but i think it would be huge improvement to ux especially for particularly active sites from a content production standpoint. The feature is having categories pre filled and un-selectable in bulk edit mode. Doing this operation (removing categories) for a large number of posts one at a time is really tedious.

      Status – idea stage (http://core.trac.wordpress.org/ticket/11302)
      Role – Maybe design or lead if applicable but i’m not proficient in php
      Help needed – development primarily i think there isn’t much to this besides the coding and ux/ui determinations
      Code Name – Geronimo

      • Sam Sidler 10:11 pm on December 2, 2013 Permalink | Log in to Reply

        This doesn’t need to be in a feature plugin.

        As a ticket in core that seems to be wanted, it just needs a patch for inclusion. I recommending finding a developer who’s interested in doing that work.

    • Ryan McCue 2:07 am on November 27, 2013 Permalink | Log in to Reply

      The WP API team is ramping up development over the coming weeks, and we’re looking for anyone interested to help out!

      I’m leading the team as we work to build an awesome JSON API with hope to launch as a core feature in WordPress 3.9.

      Anyone who’s interested is welcome to get involved, no matter who you are. Javascript and theme developers are our weakness at the moment, so they’re especially welcome.

      • Julien 11:10 am on November 28, 2013 Permalink | Log in to Reply

        Hello Ryan,

        how can I join your team ?

      • Sam Sidler 10:14 pm on December 2, 2013 Permalink | Log in to Reply

        Is your goal to ship the entire feature plugin (as in, all parts of it) as a feature in WordPress 3.9? With authentication still under development, that’s a tight timeline. Have you considered breaking out the pieces that are most ready/complete and polishing them for inclusion? (On the flip side, you could break out the in-development parts. Both ways focus on polishing what’s closest instead of working on new features.)

        • Ryan McCue 9:05 am on December 5, 2013 Permalink | Log in to Reply

          Sorry for being so slow to get back to you.

          The core (that is, all the routing and base parts) should be done by Christmas, and that will be ready for merge. For everything built on top of that, probably best to handle it case-by-case, which is an advantage of keeping it modular.

          I suspect we’ll be able to merge all of it, but it depends on the timeframe for 3.9. Word on the grapevine is that we won’t be seeing it for a few months yet, and if so we can hold off merge until mid-cycle. Of course, my sources could be wrong there. :)

          • Sam Sidler 7:49 pm on December 9, 2013 Permalink | Log in to Reply

            I imagine, given the holidays, that the merge window won’t happen until January. But who really knows? ;)

    • Chris Reynolds 3:06 am on November 27, 2013 Permalink | Log in to Reply

      The Admin Help improvements team is still working on our feature plugin. The goal is to rethink how help is presented in the WordPress admin.

      • Status: Under development
      • My Role: Lead, developer
      • I’d like help with: We can always use more devs. When we’ve got something to test, we will also be reaching out to accessibility and internationalization folks.
      • Sadly, I don’t have a top secret magic code name.
    • Mike Schinkel 6:47 pm on November 27, 2013 Permalink | Log in to Reply

      Post/Object Relationships

      Status: Implemented and in use on client products as 1st generation, about to redo as 2nd generation for current client project.
      Role: Project lead/developer/architect
      Codename: Relatable

    • Manny Fleurmond 8:13 pm on November 27, 2013 Permalink | Log in to Reply

      I’m stretched thin as it is but I would love to extend the media modal even further to allow full previews of media, as well as abstract out the image editor to a Backbone app

    • Scott Taylor 10:30 pm on November 27, 2013 Permalink | Log in to Reply

      Audio/Video 2.0

      I have a few ideas:

      • Audio playlists with a Spotify/Rdio/Soundcloud like UI
      • Shareable/embeddable widget that loads an iframe to your site’s player/music
      • Make you site an oEmbed endpoint provider – turn your Audio / Video / Playlists into embeddable widget iframe code
      • Subtitles for video

      The gist: let your site do what Soundcloud et al do.
      How? Don’t know! Let’s find out.

      • Fab1en 8:39 am on December 2, 2013 Permalink | Log in to Reply

        I can help with that : I’m using WordPress as a audio/video publisher for artists and web-documentaries since version 3.2. You can see artists web sites here with an audio player and the artist’s discography that shows as playlists. And various web documentaries where each video is a WordPress Media.

        I published partially the code I’m using for those sites in 1player plugin. Sadly, I did not find the time to update it recently. I was delighted to see that WP 3.6 adds video and audio support directly into the core, but I see that some of the features I need are missing.

        Video and audio support is well integrated into the Media Library, but, in my opinion, those media specificity should be addressed more precisely, as this has been done for images management.

        • You can avoid to specify src parameter in the shortcode : WP will get the media attached to the post instead. That’s great, but there is the same issue as there were for the gallery shortcode : video/audio must be attached to the post, so to publish one video in several posts you have to duplicate it. Why not introduce an “id” (or ids) param in the shortcode to allow easy video/audio embed ?
        • Each video/audio can only have one format (resolution and encoding). It would be great to provide several versions for the same video/audio : mp4/webm or mp3/ogg and low/hight resolution for example, with the same mechanism as the one used for image thumbnails. This would allow to output several tags inside the tag.
        • It’s generally a good idea to host video/audio files on a CDN. WP Media Library should provide a way to save an attachment in the Library with an _wp_attached_file pointing outsite WP server install. This remark is also valid for other media like images.
        • Specifying the poster image source in the shortcode is not very convenient. One would expect to use an image from the WP Library. That would also allow to use built-in image resize service to fit the video size. One solution is to attach poster metadata to the Media object that represents the video. Another solution for posts with “video” post-format would be to use the featured image.
        • I’m a little bit disappointed by the way video/audio embeds are displayed in the tinymce editor. That would have been great to display a nice picture as for the gallery shortcode.
        • There should be a graphical UI to set some player parameters : default video size, controls display… MediaElementJs allows you to tune your player this way. Why not put this in Settings > Medias screen ? There would be room there for advanced settings as well, like a list of available skins and controls (play, pause, next, volume, fullscreen…), control bar position, and flash fallback policy.
        • On top of that, some advanced features could be implemented : playlist support (via video/audio gallery), subtitles and chapters, Dailymotion and YouTube integration within the mediaelement player, and as Scott said oEmbed endpoint, iframe embed widget …
      • Sam Sidler 10:16 pm on December 2, 2013 Permalink | Log in to Reply

        Sounds like a large and exciting project! I recommend writing up an overview of your vision, perhaps for make/ui to start, and starting a weekly chat to gauge interest.

    • Janneke Van Dorpe 12:37 am on November 28, 2013 Permalink | Log in to Reply

      The Front-end editor is currently in an idea/planning/design stage. The goal is to make a perfect, easy to use WYSIWYG editor.

      A plugin is being worked on, we have weekly IRC meetings on Mondays, 16:00 UTC, #wordpress-ui, and publish regularly on make/ui. We also set up a Skype group, so let us know if you’re interested and I’ll add you to the conversation. My Skype username is jannekevandorpe.

      Anyone who’s interested is welcome, at the moment we’d like to experiment more with different interfaces, and develop something to preview oEmbeds and shortcodes/galleries. TinyMCE experts are especially welcome!

    • mttktz 1:37 am on December 14, 2013 Permalink | Log in to Reply

      I’ve often thought that the big difference between WordPress and a tumblr, facebook, twitter, etc is that WordPress is write only. You don’t read and re-share like you do on those platforms. I think it’s more natural and conversational to read where you write. I’ve started a plugin that integrates a feed reader into WordPress’s admin area in the style of google reader.

      I’ve got a working prototype – you can subscribe to feeds, mark items as read, unsubscribe, etc. http://wordpress.org/plugins/orbital-feed-reader/screenshots/

      I really want this feature to exist in wordpress, so I started it – but I don’t want to be the only person working on it and I’d like if it became part of the default.

      I’d like help with design/wireframing, development and any suggestions on how to improve this and make it an actual feature. I think it would be a good additions to core.

      • mttktz 1:38 am on December 14, 2013 Permalink | Log in to Reply

        Erm – please do check out the screenshots. I forgot to mention that I’d like for you to be able to easily reblog – and that is working at the moment as well.

      • Sam Sidler 7:24 pm on December 14, 2013 Permalink | Log in to Reply

        An interesting idea! This is a good place to find other people, but this post is getting older and I bet not a lot of people are following these comments anymore. We’ll try to get another post up for feedback and you should introduce your project and hopefully find others to help.

        • mttktz 12:22 pm on December 23, 2013 Permalink | Log in to Reply

          Thanks! I’m still chugging away at it and I’m still hopeful that it would be interesting to WP core folks.

    • Eric Mann 2:28 am on December 14, 2013 Permalink | Log in to Reply

      A little later to the post, because with 3.8 on the horizon I didn’t realize this was for post-3.8. At the same time, I still want to flag this project:

      Overview:
      Refactor WordPress’ `get_template_part()` to behave like an actual, object-oriented templating framework. Developers will be able to pass objects/data in to the function and have it immediately available from the template without needing to declare globals or mess with output buffering to juggle scope. Likewise, commonly-used objects (like `$wp_query` and `$_REQUEST` should be available without needing to reference the (super)global directly.

      Current plugin status:
      Was custom code deployed for a client. Has since been rolled into a feature plugin and is hosted on GitHub: https://github.com/ericmann/MVPress

      My role:
      Developer/Lead

      What I need help with:
      Feedback on approach – does this do what we want it to do?

      Top secret magic code name:
      Going with “MVPress” for the time being.

    • GregRoss 3:07 pm on December 24, 2013 Permalink | Log in to Reply

      **Overview:**
      Replace the current admin theme system with a more robust model that mirrors the site admin theme code.

      **Current plugin status:**
      I’ve created a proof of concept plugin, The Admin Theme Experience (wordpress.org/plugins/the-admin-theme-experience/) which is functional but not complete (see the readme for additional details).

      **Your role in the plugin:**
      Developer/Lead

      **What you’d like help with:**
      Anyone with knowledge of the current site theme code would be helpful.

      **A top secret magic code name for your plugin:**
      The Admin Theme Experience

  • John Blackbourn 12:00 am on October 25, 2013 Permalink
    Tags: , ,   

    JSON Encoding and SSL for api.wordpress.org Communication in WordPress 3.7 

    There are two changes to the way WordPress communicates with api.wordpress.org in 3.7: JSON encoding and SSL.

    JSON Encoding

    In versions prior to WordPress 3.7, data that WordPress sends to (and receives from) api.wordpress.org is serialized using PHP’s native serialization functions. PHP-serialization has two main problems:

    • Security: It has the potential to lead to security exploits via PHP object injection.
    • Portability: It’s hard to unserialize these strings in other languages besides PHP.

    In WordPress 3.7, most API calls have now changed so they send and receive JSON encoded data instead. The three major ones are:

    • Core update checks
    • Plugin update checks
    • Theme update checks

    The following calls have also changed, but you’re probably not so interested in these:

    • Importers list
    • Credits list
    • Browse Happy (the browser version check)

    How might this affect plugin or theme developers?

    In general this won’t affect developers at all. If your plugin or theme just consumes the API then you don’t have to make any changes. The API calls that send and received JSON encoded data have all had their version numbers bumped from 1.0 to 1.1 (for example, api.wordpress.org/plugins/update-check/1.1/. If you are consuming the version 1.0 endpoints you’ll continue to get PHP-serialized data. If you want JSON encoded data, you can switch to using the version 1.1 endpoints.

    There is one situation that developers may need to account for. If your plugin or theme hooks into the update API requests in order to remove certain plugins or themes from the update checks, your code may need updating.

    A common method for removing a plugin or theme from the update checks is to hook into http_request_args, unserialize the data being sent to the API, remove the given theme or plugin from the data, and serialize it again. This will no longer work in WordPress 3.7 and your code will need to be updated so it decodes and encodes the data as JSON instead.

    An example of a plugin which has been updated to handle JSON encoding along with fallback support for PHP-serialization (depending on the version number in the API call) can be seen here: https://github.com/cftp/external-update-api/compare/f4d58e2…281a0ef

    Note that there are two API calls which have not yet changed to using JSON encoding:

    • Plugin info
    • Theme info

    These two calls will most likely be updated to use JSON encoding in WordPress 3.8.

    SSL Communication

    As part of the hardening process of this release, WordPress 3.7 will only communicate with api.wordpress.org using SSL (HTTPS) when the server supports it. This is an especially important security enhancement, given that automatic background updates are now a part of WordPress. Indeed, automatic background updates are disabled if the server cannot communicate securely with the api.wordpress.org.

    How might this affect plugin or theme developers?

    Again, this won’t affect developers in general. If your plugin or theme hooks into API calls you may need to update your code to it handles calls to https://api.wordpress.org/ in addition to http://api.wordpress.org/.

    JSON encoding and support for SSL means the WordPress.org APIs are in a much better position going forward.

     
    • Lester Chan 1:00 am on October 25, 2013 Permalink | Log in to Reply

    • djmceltic 8:17 pm on November 5, 2013 Permalink | Log in to Reply

      I have installed 3.7.1 cleanly on a server with SSL. The server is behind a firewall and many of the admin features are broken out of the box. Not sure what the fix is for this but it seems like there might need to be more configuration during install for SSL if you are going to force it.

      • John Blackbourn (johnbillion) 8:25 pm on November 5, 2013 Permalink | Log in to Reply

        Could you get some details of your server together (name and version of the OS, web server, TLS (OpenSSL/GnuTLS/etc), details of the firewall) and post a ticket to Trac? Thanks!

        • djmceltic 12:42 am on November 6, 2013 Permalink | Log in to Reply

          Hi John

          Windows 2008 R2 PHP 5.4.16 MySQL 5.5. With 3.6 and earlier we have had issues behind the firewall searching for plugins and themes and simply didn’t use this functionality – just did uploads. We have about 40 different WP installs (many different versions – couple haven’t been touched in years) and these are all working fine on same server.

          It looks like WP sees that I have ssl running on sever (which I do) and then whenever in the code we see if ( $ssl && is_wp_error( $request … it returns the warning message – PHP Warning: An unexpected error occurred. Something may be wrong with WordPress.org or this server’s configuration. If you continue to have problems, please try the support forums. (WordPress could not establish a secure connection to WordPress.org. Please contact your server administrator.) in C:\inetpub\wwwroot\ticket\wp-admin\includes\theme.php on line 298 – or whatever line the error comes from.

          It doesn’t happen on the update link which I find odd but happens on themes.php and install-plugin.php and a couple other areas.

          It is frustrating to think that we have to have an internet connection to change a theme or install a plugin. I work offline on my laptop all the time. But to fix the server issue is there a way to tell WP that we don’t want to use ssl? Or is there any other suggestions (I have tried adding my proxy server and all of that stuff in the config and no help)? Also our proxy does pass ssl urls – so not really sure if this is an ssl issue or proxy issue or both.

          • Dion Hulse 12:54 am on November 6, 2013 Permalink | Log in to Reply

            This sounds like you’re having connectivity troubles or latency issues, the WordPress.org API’s have a timeout of 3 seconds, if you exceed that it doesn’t work.

            Plugin/Theme update checks however have a 30 second timeout when run via Cron, so they’re probably succeeding which explains why updates work but installs don’t.

            So this is probably completely irrelevant to SSL by the sound of it, You might want to increase the timeouts for connections:

            add_filter( 'http_request_timeout', function( $timeout ) {
               return max( $timeout, 10 ); // minium of 10 seconds as a default timeout for HTTP
            } );
            

            Yes, it’s frustrating that you have to be online or with an internet connection for Update Checks and Install-from-web to work, Core Developers suffer the same problems sometimes, but, WordPress is a web-app and expects to operate in an online world, there are constants available to block outgoing HTTP requests when running in a locked-down environment though (See WP_HTTP_BLOCK_EXTERNAL and friends)

            • djmceltic 1:22 am on November 6, 2013 Permalink

              Dion

              I am fine with those updates requiring you to be online – but not just switching between already installed themes and plugins.

              Also the issue I detailed is not a proxy server timeout issue. I just installed 3.7.1 on server on same LAN as my web server that does not have SSL and it works fine. Not sure why but SSL is killing the apps. And the warnings I am getting are directing me to lines looking for $ssl = true.

      • Dion Hulse 11:29 pm on November 5, 2013 Permalink | Log in to Reply

        Not quite sure what the issue is, is it, a) SSL is broken in your install, b) Firewall blocks HTTPS but not HTTP? c) Firewall blocks all outgoing HTTP/HTTPS, d) Something else?

        Either way, create a trac ticket as John said if it’s something we can fix.

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