WordPress.org

Make WordPress Core

Recent Updates Page 4 Toggle Comment Threads | Keyboard Shortcuts

  • Mike Schroder 5:54 am on April 10, 2016 Permalink |  

    Release Dry Run and Window, RC2 and String Freeze 

    Hey everyone!

    The WordPress 4.5 release proceedings will start at April 12, 2016 at 0900 PDT, with the expectation of release within 2-3 hours of that meeting time. This time allows a decent margin before 5pm EDT (April 12, 2016 at 1400 PDT), at which point a punt to the next day would be discussed.

    To help hit that window, let’s meet the day before at April 11, 2016 at 0900 PDT for a dry run.

    As a final note, WordPress 4.5 RC2 has been released, and with it, hard string freeze is upon us.

    See you at the dry run, and thanks for your help in getting this far!

     
  • Adam Silverstein 9:22 pm on April 7, 2016 Permalink |
    Tags: ,   

    Dev Chat chat notes for April 6/March 30 

    This post summarizes the last two dev chat meetings.

    March 30 meeting:

    Review the full logs on Slack.

    Schedule notes

    Ticket review

    • Discussion of the new link dialog and the removed ‘list of recent posts/search’ section that previously existing in the advanced modal (a regression). It was replaced with the easier inline search, but some users miss it; plan is to restore and rework for the modal.

    April 6 meeting:

    Review the full logs on Slack.

    Schedule notes

    • Release of WordPress 4.5 is scheduled for April 12.
    • About screen nearly complete.
    • Full string freeze by Saturday.

    Ticket review

    • The core dev team went thru remaining tickets for the 4.5 release to decide what should get committed and what should get pushed to a later release.
    • Extensive discussion over the cropper and how to treat options passed by themes when setting up a theme logo.
    • A data inconsistency bug affecting the WP-API was considered significant enough that it needed fixing.
    • As we approach release and changes have less time to be tested, committers feel reluctant to make any changes.
     
  • Andrew Rockwell 12:10 am on April 7, 2016 Permalink |
    Tags: ,   

    Week in Core, Mar 29 – Apr 5 2016 

    Welcome back the latest issue of Week in Core, covering changes [37092-37160]. Here are the highlights:

    • 69 commits
    • 16 contributors
    • 62 tickets created
    • 7 tickets reopened
    • 32 tickets closed
    • Target release date for 4.5 is April 12th

    Ticket numbers based on trac timeline for the period above.

    Note: If you want to help write the next WordPress Core Weekly summary, check out the schedule over at make/docs and get in touch in the #core-weekly-update Slack channel.

    Accessibility

    • Improvements for the Editor wpLink modal form fields. [37160] #33301

    Build/Test Tools

    Comments

    • Wrap the formatted comment text on the comment moderation screen in comment_text() so paragraphs and texturisation are applied. [37158] #34133

    Customize

    • Fix toggle of title attribute field visibility on nav menus admin page. [37153] #35273, #36353
    • Put focus on change button instead of remove button in media control. [37152] #36337
    • Respect aspect ratio on cropped images. [37113] #36318

    Docs

    • Ignore _wp_upload_dir_baseurl() from parsing for the Code Reference. [37114] #36371

    Editor

    • Remove trailing space from a help text string. [37159] #36407
    • Restore the bottom half of the modal. Make it always expanded and remove the toggle. It is used as advanced link options now, no need to have simple mode. [37154] #36359

    Embeds

    • Improve how iframes are loaded after being initially hidden. [37093] #35894

    General

    • Add deprecated notice and removal warning to _wp_upload_dir_baseurl(). [37112] #36371
    • Snoopy: use escapeshellarg instead of escapeshellcmd [37102-37094]

    HTTP API

    I18N

    Javascript

    • Add nonce to AJAX action for script compression setting. Merges [37143] to the 4.4 branch [37144] [37143]

    Networks and Sites

    Plugins

    Role/Capability

    • Add create_sites and delete_sites to the list of capabilities that are checked as part of the comporehensive roles and capabilities tests. [37157] #32394, #36413

    Taxonomy

    Themes

    • Remove $size reference from get_custom_logo().  [37135] #36327

    Upgrade/Install

    • Add Nonce to updating wporg_favorites user meta field Merges [37145] to the 4.4 branch [37146] [37145]

    Thanks to @adamsilverstein, @afercia, @azaozz, @dimadin, @DrewAPicture, @iseulde, @jeremyfelt, @johnbillion, @jorbin, @nbachiyski, @obenland, @ocean90, @sidati, @swissspidy, @TacoVerdo, and @westonruter for their contributions!

     
  • Ryan McCue 9:23 pm on April 6, 2016 Permalink |
    Tags: , ,   

    REST API: Slashed Data in WordPress 4.4 and 4.5 

    Hi everyone. The REST API team recently discovered a bug with parameter parsing in the API infrastructure, part of WordPress 4.4. For those of you using the API infrastructure, you need to be aware of a bug fix we’re making with the API.

    The Problem

    The REST API has several types of parameters that it mixes together. These come from several sources including the request body as either JSON or URL-encoded form data ($_POST), query parameters ($_GET), the API route, and internally-set defaults. Unfortunately, due to an oversight on our behalf, these parameters can be inconsistently formatted.

    In WordPress, the superglobal request variables ($_POST and $_GET) are “slashed”; effectively, turning magic quotes on for everyone. This was originally built into PHP as a feature to help guard against SQL injection, but was later removed. Due to compatibility concerns, WP cannot change this behaviour for the superglobals. This only applies to the PHP superglobals, not to other sources of input like a JSON body or parameters in the URL. It additionally does not apply to form data on PUT or DELETE requests.

    Internally, some low-level WordPress functions expect slashed data. These functions internally call wp_unslash() on the data you pass in. This means input data from the superglobals can be passed in directly, but other data needs to be wrapped with a call to wp_slash().

    When the REST API gathers the data sources, it accidentally mixes slashed and unslashed sources. This results in inconsistent behaviour of parameters based on their source. For example, data passed as a JSON body is unslashed, whereas data passed via form data in the body is slashed (for POST requests).

    For example, the following two pieces of data are equivalent in the REST API:

    
    // JSON body:
    {"title": "Foo"}
    
    // Form-data ($_POST)
    title=Foo
    
    // Both result in:
    $request->get_param('title') === 'Foo';
    

    However, if the data contains slashes itself, this will be inconsistently passed to the callback:

    
    // JSON body:
    {"title": "Foo\Bar"}
    
    // Results in:
    $request->get_param('title') === 'Foo\Bar';
    
    // Form-data ($_POST) (%3D = "\")
    title=Foo%3DBar
    
    // Results in:
    $request->get_param('title') === 'Foo\\Bar';
    

    This means that callbacks need to understand where parameters come from in order to consistently handle them internally. Specifically:

    • Data passed in the query string ($_GET, $request->get_query_params()) is slashed
    • Data passed in the body as form-encoded ($_POST, $request->get_body_params()) is slashed for POST requests, and unslashed for PUT and DELETE requests.
    • Data passed in the body as JSON-encoded ($request->get_json_params()) is unslashed.
    • Data passed in the URL ($request->get_url_params()) is unslashed.
    • Data passed as a default ($request->get_default_params()) is unslashed.

    In addition, parameters set internally via $request->set_param() are unslashed. Unit and integration tests for API endpoints typically use these directly, so the majority of tested code (such as the WP REST API plugin) assumes parameters are unslashed.

    See the related Trac Ticket #36419 for more information.

    The Solution for WordPress 4.4 and 4.5

    We are regarding inconsistently-slashed data as a major bug, and are changing the API infrastructure to ensure unslashed data. This will ensure that data is consistent regardless of the source. Callbacks will now receive unslashed data only, and can rely on this regardless of the original data source or request method.

    If you are using functions that expect slashed data in your callback, you will need to slash your data before passing into these functions. Commonly used functions that expect slashed data are wp_insert_post, wp_update_post, update_post_meta, wp_insert_term, wp_insert_user, along with others. Before passing data into these functions, you must call wp_slash() on your data.

    The fix for this issue, will be included in the WordPress 4.5 release candidates and final release. Due to the severity of the bug, we are also backporting the fix to the next minor WordPress 4.4 update. This also ensures you can update your plugins can act consistently across all versions of the REST API.

    We understand that this may inadvertently break some plugins that are expecting slashed data. Right now, it’s not possible to consistently ensure that callbacks receive slashed data, so it is likely that these plugins will already break in some conditions.

    tl;dr: if you’re using wp_insert_* or *_post_meta in your REST API callback, you need to ensure you are calling wp_slash() on data you are passing in, regardless of source.

    We apologize for this bug existing in the first place. Slashed data is a problem that has plagued WordPress for a long time, and we’re not immune to getting caught by the issue ourselves.

     
    • Mike Schinkel 7:16 am on April 7, 2016 Permalink | Log in to Reply

      We apologize for this bug existing in the first place. Slashed data is a problem that has plagued WordPress for a long time, and we’re not immune to getting caught by the issue ourselves.

      Given that this issue created such a major bug, wouldn’t it be a good time to take backward compatible action to slowing start eliminating this as an issue?

      • Mike Schinkel 7:35 am on April 7, 2016 Permalink | Log in to Reply

        In case of interest in addressing this moving forward:

      • Ryan McCue 3:40 am on April 8, 2016 Permalink | Log in to Reply

        As it happens, this is part of my Secret Master Plan for Unslashing, and part of why I wanted to ensure we fixed this right now.

        My Secret Master Plan:

        • Take the generic parts of WP_REST_Request and make a new WP_HTTP_Request object
        • Ensure the Request object has unslashed data
        • Pass the Request around liberally to replace the superglobals (discussed somewhat in #36292)
        • Finally introduce internals that take unslashed data, and turn the existing functions into wrapper functions.
    • NateWr 7:54 am on April 7, 2016 Permalink | Log in to Reply

      Is this change in the latest WP 4.5 RC or do we need to get the latest commits to test our apps?

      • Marius (Clorith) 12:56 pm on April 7, 2016 Permalink | Log in to Reply

        It is not available in RC-1, that’s out at this time, as it was pushed in last evening/earlier today (depending on your time zones), the goal is to get RC-2 out some time this week, and it will include this change.

        If you are running trunk you’ll have access to it at this time, alternatively you can manually apply the patch to your own install if you wish to start testing it right away (the patch from #36419)

  • Mike Schroder 11:22 pm on April 4, 2016 Permalink |
    Tags:   

    Road to 4.5: All Hands on Deck 

    We’re almost there! Release day is April 12.

    In order to get there, help is needed to resolve the remaining issues in the report.

    The regular dev meeting will be at April 6, 2016 at 20:00 UTC, where we’ll go over status, but the report should really be clear before then.

    There are currently 6 12 tickets in the milestone, which with few exceptions need to be resolved so that we can ship an RC 2 this week in preparation for release next week.

    We need all hands on deck — especially if you are a component maintainer or committer, but all eyes appreciated. Please watch the milestone for tickets you can suggest remedies for or whose patches you can review.

    In particular, the help of lead developers and permanent committers is requested, because without approval from two of you for each patch, we cannot move forward with committing fixes. Thanks to those of you who have been doing reviews!

    Tickets with a patch and single sign-off in need of a second are:

    • #34133 – Moderate Comments: Pass through comment_text().
    • #36389 – Selective Refresh: Make sure refresh transport is used only when appropriate.
    • #36410 – I18n: Misleading translators comment and bad string

    Needs testing and double sign-off:

    • #36380 – Moderate Comments: Show link URLs to avoid abuse.

    Has patch and double sign-off, but needs second opinion from Polyglots team:

    • #36407 – I18n: Remove an extra space.

    Needs patch:

    • #36412 – Custom Logo: Can’t skip crop for images smaller than specified in theme.
    • #36392 – Script Loader: wp_add_inline_script() breaks script dependency order.
    • #36173 – About Page: Needs commit with final strings by Wednesday. Draft design & strings attached for review.

    Can ride:

    • #36354 – Bump core themes versions prior to release.
    • #36401 – Bump Akismet for 4.5.
    • #36413 – Additional tests for roles/caps
    • #35857 – Additional tests for customizer/selective refresh

    Thanks for your help in getting us through the final stretch.

     
    • nextwave 1:41 pm on April 5, 2016 Permalink | Log in to Reply

      Just a suggestion- on Moderate Comments: Show link URLs to avoid abuse-
      you need to build in an automatic more tag like split on really long comments. There is no reason to display more than the first 100 words in the scrolling display of comments- either it’s spam- or it’s real- or I can click on the more tag to investigate more. When checking to see what got dumped in spam- the scrolling past these really long comments- which come in batches- make me wonder if I miss a false positive in between.
      Thank you!

  • Ella Iseulde Van Dorpe 6:15 pm on April 4, 2016 Permalink |
    Tags: 4.6,   

    Editor chat 4.6 

    This Wednesday, 6 April, 18:00 UTC we’ll have our weekly editor chat in #core-editor. This time we’d like to discuss the roadmap and ideas for 4.6, so please join us if you can and are interested in pushing the editor forward. If you can’t attend feel free to comment here, or on the summary of the chat that we will post on this blog afterwards.

     
  • Ryan McCue 4:39 am on April 4, 2016 Permalink |
    Tags: ,   

    WP REST API: 2.0 Beta 13 & Roadmap 

    Hi folks! I’m here with another exciting update from the API team.

    Beta 13

    First off, we’re excited to announce 2.0 Beta 13 “yoink.adios\losers” is now available. Grab it from the plugins repo or GitHub while it’s hot. Here’s some of the key updates:

    • BREAKING CHANGE: Fix Content-Disposition header parsing. This technically breaks backwards compatibility to correctly match the header specification. (#2239)

    • BREAKING CHANGE: Use compact links for embedded responses if they are available. We now use CURIEs for sites on 4.5+, which look like wp:term (but canonicalise to the full URI relation). (#2412)

    • Updated JS client to the latest version. (#2403)

    There’s lots more changes in this release; check out the release notes or the commits for this release.

    Roadmap

    We’ve been thinking about how to tackle the API in the coming future. We want to do the most we can to ensure you can build sites with confidence.

    Along these lines, we’re going to release a 2.0 final version in the coming months. This will be a completely stable release with guaranteed backwards compatibility for the foreseeable future. This backwards compatibility ensures that your sites can remain up-to-date with minimal maintenance or issues with upgrading.

    We originally held the software in beta for a long period to ensure that breaking changes could be rolled in if deemed necessary to move the project forward. However, the majority of these breaks occurred at the start of the 2.0 lifecycle, and the API is mostly stable at this point. Keeping the ability to break compatibility benefits only us, whereas moving to a stable release benefits everyone.

    Moving forward, version 2.0 of the WP REST API will follow a normal project release cycle. We will have minor releases in the 2.x series as new features are added, and bugfix releases in the 2.0.x series.

    As for the core merge itself, we are not submitting a merge proposal of the core endpoints for WordPress 4.6. We believe endpoints for the main WordPress objects (posts, users, comments, terms, and taxonomies) are not enough to garner the support needed for the proposal to be accepted. Our hope is that with a stable version 2.0 release, we will attract our community members that have been waiting for the endpoints to be available in core, and submit a merge proposal for the WordPress 4.7 release cycle.

    In addition to attracting more developers within our community, we are also looking to get more contributors involved with the project. As noted in previous discussions, the four of us on the API team can’t keep pace with WordPress itself without help. We’re looking to get WordPress core component maintainers involved in their relevant components, as well as new developers from outside the project. Moving forward, the API team sees our role as advisory over the API itself, with the API treated as an integral part of the component rather than maintained by a separate team. We’re also going to continue to work on our feature plugins (metadata, site/multisite, menus/widgets, and authentication) in parallel, and are looking for help on these as well. (There’s also more news regarding authentication coming very soon.)

    If you’d like to get involved with the API, please let us know. You can comment here, ping us on Slack in the #core-restapi room, or via GitHub issues. We’re looking at spending significant time onboarding new users, so if you’d like to get involved, now’s the time! Our weekly meeting is at Monday 23:00 UTC

    Thanks for catching up with us, and have a wonderful day.

    With love,

    Ryan, Rachel, Daniel, and Joe

     
    • adamf321 4:19 pm on April 4, 2016 Permalink | Log in to Reply

      Hey guys,
      Firstly thanks for all the great work you’ve been producing on the API! I’m the CTO of a digital agency and we’re working on a new infrastructure which relies heavily on it. I would like for us to be involved in some part in the ongoing development of the API – so please keep me up to date with the onboarding process and I will ask who in our team is interested. We have dev and design resources. To give you an early heads-up, this month is pretty hectic, but from next month I think we can make some time to get started.

      Cheers,
      Adam

    • Mike Nelson 4:40 pm on April 4, 2016 Permalink | Log in to Reply

      +1 to 2.0 stable. If we really really really want to make breaking changes in the future it can always be on a 3.0 version. For now it’s nice having something stable.

      And I’m at least interested in helping out with the basic auth plugin

    • nathangraham 10:25 pm on April 14, 2016 Permalink | Log in to Reply

      We rely heavily on the REST API as well so thanks for all of your work. I’m happy to contribute as well.

  • Helen Hou-Sandi 12:09 am on March 31, 2016 Permalink |  

    Iterating on Feature Plugins 

    Feature plugins appeared in the wake of the 3.6 release cycle, in which two large efforts were reverted before the final release: a UI for content using post formats and a refreshed aesthetic for the admin, notably with a new set of icons. Both suffered from the same problem: attempting to create and iterate on a significant feature within a single release cycle. The identification of that problem led to the idea of developing features as plugins, decoupling them from the time restrictions of fairly quick release cycles.

    (While post formats had further issues that led to changes not landing in core, the admin design changes became known as MP6, a feature plugin which was merged in WordPress 3.8.)

    Over the last two and a half years, we’ve had successful feature plugins that were merged into core, efforts that began small and grew as discovery happened, ideas that never quite got off the ground, and ideas that were initially explored in “plugin” form but ultimately became patches for various reasons, usually technical. With over two years of active feature plugins behind us, it’s time to take a look at what’s been successful, what hasn’t been, and where we go from here.

    So, what’s next?

    Feature plugins projects

    Thinking of features as plugins has strapped us in a number of ways, in large part because the “plugin” part implies a functional project from the start. From observation, experienced and newer contributors alike set their initial goal to be some sort of functional plugin. As a result, by the time something is being proposed in whatever forum, there’s been a fair amount of effort spent – and personal attachment developed – for something that might be headed in the wrong direction. Changing direction at that point is very demoralizing and has led to burn out and less participation.

    My suggestion is to move both nomenclature and mindset to “feature projects.”

    Feature projects are similar to feature plugins in many ways (including in name), but may not take the form of a plugin; in fact, they likely will not begin as plugins. Most will start as ideas that need exploration to be more fully formed/fleshed out before implementation. Others will become discrete patches on tickets. Others may turn into multiple plugins, breaking out the successful parts of the project into patches for core, while iterating on the less-successful pieces. Still others may remain in plugin format even after reaching a polished point, as they may not make sense as a bundled part of core but serve a valuable purpose for users.

    To start, there is now a feature projects overview (still in progress) that is more of a higher level overview than the current status dashboard, with listings of feature projects that are in progress or merged, with sections for wishful thinking and projects that have been abandoned for one reason or another to be added in the future. Each project should be accompanied by a brief statement that clearly states what problem the project is solving, its goals, and how it supports the various philosophies and objectives of the WordPress project. The overview will also serve as a sort of roadmap for potential project features, albeit one without promises of delivery timeframes.

    The general goal of this shift in framing and process is for feature development to be successful and lead to a stronger product with more contributors. Some individual goals in support of this are:

    • Attracting and retaining a greater range of skill sets in contributors, for example through being able to more thoroughly engage designers in early stages.
    • Implementing methods of collecting usage information and other data (more on that coming soon).
    • Supporting feature projects with resources for user testing and more structured feedback.
    • Advance both contributor and general community knowledge around product design and development.

    Life cycle of a feature project

    Today, feature plugins move forward in varying directions, frequently without a clear goal or target. This can make it hard to determine what their status is or what next steps might be. Learning from the current situation, feature projects will have clearer check points. For one, there will be bi-weekly meetings where anyone can propose a feature project, check in at specific goal points, update the community on the current status of a feature project, and/or ask for help if they’re having issues advancing their idea. We will kick these off in the #core channel in Slack on April 5 17:00 UTC.

    Beyond this, there are several parts in the life of a feature project.

    First, a feature project should have a brief statement of purpose. Explaining why a feature project is important to WordPress – and how it fits in with the values and philosophies of WordPress – is a necessary part for success. Without such a statement, projects can (and do) get “lost” along the way, ultimately heading in a direction that is not right for core, or start off on the wrong foot entirely.

    This statement of purpose should outline the justification/explanation for why the feature project should exist. This statement is not meant to be encapsulate the entire idea, but should give an idea of how the idea fits into core and its concepts. Keep in mind that a simple statement is better than a long one; comprehensive statements may be all-inclusive, but they narrow the focus in a way that might not make sense as ideas morph based on feedback.

    Here are some examples of previous feature ideas – since implemented – in the form of a brief statement:

    • MP6: Simplify and modernize the design of the admin, with a focus on the rapidly growing user base using HiDPI, touch, and small-screened devices.
    • Widgets Customizer: Improve the WYSIWYG experience of widgets through non-destructive live previews. The current approach of making some changes immediately live but not others breaks users’ expectations and trust.

    After creating and proposing a project with statement at a meeting, ideas should move through a discovery and design process (more on that below).

    Once the discovery results have been put together and published, it will be proposed to the core team as an official feature project during a regularly scheduled meeting. The core team then has the opportunity to study the direction before giving it the green light to move into implementation. It’s important to question ideas and assumptions early on to ensure the design and discovery process went well and that the project heads along the best path.

    Next, with the endorsement of the core team, development of the feature project can begin. Development may take the form of a plugin, a patch on a core ticket, or whatever way works best for the specific feature project.

    Finally, once a feature project is fully developed, it can be proposed for inclusion in core. Proposals can take the form of a Make/Core post along the same lines as feature plugin merge proposals, or by raising the specific ticket at a weekly core devchat. As the project gets closer to the finish line, it’s recommended that the team report on its status at one of the scheduled feature project chats.

    Throughout the entire process, the feature project team should hold weekly meetings, allowing others to ask questions, gather feedback, and help develop the feature.

    Discovery and Design First

    WordPress has always taken a user-first approach to features and often even the APIs that power these features. The benefits of this approach show in adoption and the myriad creative ways developers have found to push its limits. In the past, the project has spent time testing features after they were developed, helping determine if the features were ready for core. However, as we find in product companies and digital agencies, design (interaction, visual, etc.) should be based on data gathered from discovery with real users and happen before design and technical implementation begin.

    Feature design and development should come from interviews with users, developed personas, surveys of those personas, documented flows, and other fairly standard methods. Proper discovery will allow for testing long before functional development begins using low-fidelity storyboards and walking through potential concepts with users, both verbally and visually. Projects should check in at a meeting when discovery results are available and continue to check in through the design process.

    It’s important to note here that some discovery and design stages may be successful by most measures but not lead to a viable feature for core. This is okay. Going through these stages will often still lead to improvements that can be brought back to core and will help us refine feature project approaches in the future.

    Conclusion

    Feature plugins as a concept were a great idea; decoupling features from the release process gives us a lot of room to get things right. Adjusting our approach to cover all features – and to focus on discovery and design first – will give us a better WordPress.

     
    • Tammie 12:18 pm on March 31, 2016 Permalink | Log in to Reply

      “Discovery and Design First”… this entire section made me so happy. Totally agree and look forward to this being in more areas.

      I would like to put myself forward to help with any discovery anyone in any feature project needs. I know there are going to be people in some projects that will be up for it too, but happy to help or pass on what I know about discovering to others too. My offer is also there for those that either want more help or don’t have it in the project currently.

    • J.D. Grimes 12:31 pm on March 31, 2016 Permalink | Log in to Reply

      I think this is a good direction to take the concept of feature projects. If only WordPress were more modular/composible, it would be even easier to develop new features and tweak existing ones.

    • Ryan Boren 1:34 pm on March 31, 2016 Permalink | Log in to Reply

      +1, cosigned, thank you

    • Michelle 1:47 pm on March 31, 2016 Permalink | Log in to Reply

      Love this, not only because it a) treats WordPress more like an actual product where decisions on features should be tested and vetted before they’re built, and b) validates the design and discovery process as “important to WordPress” and saves a ton of unnecessary dev time, but also c) will help encourage those with other important talents like design/ux/ui/user testing (but not core-level development skills) to contribute.

    • Ipstenu (Mika Epstein) 2:14 pm on March 31, 2016 Permalink | Log in to Reply

      Development should take place where it is most logical for the project. Yes! Helen, you sing the song of my people. Thank you. This is a good start and direction for feature projects 🙂

    • Morten Rand-Hendriksen 2:45 pm on March 31, 2016 Permalink | Log in to Reply

      This is great, in particular the Discovery + Design component (which for reference was implemented and heavily criticized in ImageFlow). Building features that are user-centric is paramount as we move forward.

    • Josh Pollock 9:16 pm on March 31, 2016 Permalink | Log in to Reply

      The one really great thing about feature plugins is it makes it really easy to test a feature plugin. You just install that plugin. What would be the equivalent for testing a feature project? If the answer is “apply a patch in git or svn” then I think this will drastically reduce participation by users who are not active contributors, and that concerns me.

      • Helen Hou-Sandi 9:33 pm on March 31, 2016 Permalink | Log in to Reply

        Development may take the form of a plugin, a patch on a core ticket, or whatever way works best for the specific feature project.

        I imagine most projects will still result in plugins when it comes to implementation. This is a reframe, not a replacement. That said, it’s very important that testing happens earlier in the process; testing functionality is sort of meaningless if we haven’t determined the direction.

        • Josh Pollock 9:41 pm on April 1, 2016 Permalink | Log in to Reply

          Ok, that makes sense. Thanks for the clarification.

          I wonder if it makes sense, for projects that are maintained as patches, to provide an easy/ automated way to maintain an updated fork of WordPress with that patch applied that people could test with…

    • Mike Selander 7:42 am on April 2, 2016 Permalink | Log in to Reply

      I love the idea of treating these improvements as a scoped project in and of itself – I think that it will lead to better considered and architected solutions. This is a great path for future features!

    • Torsten Landsiedel 3:28 pm on April 3, 2016 Permalink | Log in to Reply

      This is a great idea, but I think we need much better communication at this point. Where do I get feedback to my feature project idea(s)? At the moment we have this “sorry, wrong channel, try it at xy” and after “too many redirects” people lose their motivation to help anymore. Or the wrong type of people give feedback and the idea is dying, because the right people don’t give any feedback even if the comments just show “+1s” …

      • Samuel Sidler 12:51 am on April 4, 2016 Permalink | Log in to Reply

        As the post says, going forward there will be meetings every two weeks to propose and get feedback on feature project ideas. Those meetings are the perfect time to get feedback on your idea(s).

    • Aaron Jorbin 6:55 pm on April 4, 2016 Permalink | Log in to Reply

      Love this direction and really excited to help provide feedback. I’m wondering if it may make sense to rotate the time a bit in the long run( Perhaps every two months?) or potentially add in a second meeting during a different time of the day. There is no time that will be perfect for everyone, but 1700 UTC is 2am in Tokyo, 5am in Aukland and 10:30pm in Mumbai.

      • Ryan McCue 11:49 am on April 6, 2016 Permalink | Log in to Reply

        Absolutely agree. There’s no way I can viably make a meeting at 3am. Maybe multiple to accommodate differing timezones, or alternate the time for each meeting?

      • Helen Hou-Sandi 8:13 pm on April 6, 2016 Permalink | Log in to Reply

        I agree about differing times and think alternating is a great idea. I have a little bit of an odd schedule, so perhaps keeping one at 1500 UTC and the other (including the next one) at 0100 UTC? The latter makes the date kind of weird (would be Wednesday technically) but seems like it’s okay.

  • Aaron Jorbin 8:52 pm on March 30, 2016 Permalink |
    Tags: , ,   

    WordPress 4.5 Field Guide 

    WordPress 4.5 is the next major version of WordPress and with it come some bang bang changes. This guide will describe many of the developer-focused changes to help you test your themes, plugins, and sites. So grab a ☕️ ,🍷,🍵, or 🍺 and get ready for what’s coming soon.

    JavaScript! and CSS!

    Multiple external libraries have been updated with the two that require your attention being Backbone and Underscore. There were some‼️ breaking changes ‼️ with these two libraries, so make sure to test your code if you use either of these.  jQuery and jQuery Migrate have also been updated, please test with the unminified versions in order to ensure future compatibility with WordPress.

    The script loader has been updated with three big changes. The build process no longer creates wp-admin.min.css, wp_add_inline_script() joins the family of functions, and better support for multigenerational dependencies is included.

    Term Edit Page! –‼️ Backward Incompatible change‼️

    The term edit screen has been separated out from the term list screen. This brings greater consistency to how the admin generates screens for terms and posts but at the cost of the need to change how you register scripts and how you detect that you are on a term edit screen.

    Live Preview: Faster, Extensible, More Features!

    Live Preview (also known as “The Customizer”) once again has received attention this release with the addition of new controls, some performance improvements that require your attention to implement, and a two new user-facing features.

    Setting-less Controls, Device Previews, and Selective Refresh are the three biggest changes you’ll find. Setting-less controls make it easier for you to implement complex interfaces. Device Preview is a user facing feature that allows users to adjust the preview to match the screens on various devices.  This feature includes filters to change the devices users can choose. Selective Refresh allows for changes to appear quicker inside the preview, and you can do so with less code than before. Theme authors need to make changes to take advantage of selective refresh. Luckily, the change will generally result in fewer lines of code needed overall ( more 🍎 than 🍏 ).

    One area that selective refresh helps live preview function faster is with widgets.

    ‼️ If you offer sidebars or a widget in your theme or plugin, please update your code to implement selective refreshBoth themes and widgets need to indicate support, so please update your code accordingly.

    The final change to Live Preview involves a control for a new theme feature, and that is Custom Theme Logos.

    Custom Theme Logos!

    Themes can now offer support for custom logos. Custom Logos add an additional way for users to customize their site and theme developers can customize how custom logos are displayed.

    Image Performance!

    Following up on the introduction of responsive images in WordPress 4.4, WordPress 4.5 is making changes to improve image performance including improved compression settings and smarter handling of image metadata.

    Embed Templates! (and other iterations)

    Iterating on embeds has led to the ability to better customize embeds by adding new templates to the template hierarchy for embeds. Embeds have also had some performance improvements for autodiscovery, the ability to embed the front page of a site, and changes to the iframe of embedded content.

    Comments Component!

    The comments component has a few user-facing changes to make comments easier to moderate. For developers, the most notable change is the ability to adjust field lengths for your custom database schema. Additionally, the rel=nofollow attribute and value pair will no longer be added to relative or same domain links within comment_content.

    Multisite!

    Multisite once again has seen changes with the addition of new filters around site and user creation, and a WP_Site object.

    And more!

    Overall, 372 bugs have been marked as fixed in WordPress 4.5 (so far). There are also dozens of new hooks and dozens of hooks that have received additional parameters. It’s entirely possible that one or more has caused a regression, so please make sure to test your code deeply and report any issues you find.

     
  • Mike Schroder 6:06 pm on March 30, 2016 Permalink |
    Tags: ,   

    Reminder – Dev Meeting Time 

    This is just a reminder that the dev meeting today is shifting an hour earlier today, since Europe has moved into DST.

    The meeting will be at March 30, 2016 at 20:00 UTC.

    We’ll chat about what’s left in the report. See you there!

     
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