Dev Chat Summary: February 15th (4.7.3 week 3)

This post summarizes the dev chat meeting from February 15th (agendaSlack archive).

4.7.3 Schedule

  • Completed first pass on all tickets in the 4.7.3 milestone, @jnylen0 is reviewing those that “need” to land in 4.7.3, and identifying a release date for 4.7.3 in the coming week

Customizer team update

  • #23601 (Use ACE Code Editor for Theme and Plugin editors) and #12423 (Include Ace (or similar) as default code editor)
    • Topic of discussion is a code editor library to be used in Custom CSS, WP content editor HTML view, file editor, and any other place that code is modified
    • Had planned to go ahead with CodeMirror since it is what Jetpack uses in its Custom CSS module, but @afercia pointed out accessibility problems
    • So we’re looking for insights into best of breed accessible code editor libraries
    • @afercia: looking to to understand if (1.) there’s consensus about introducing some sort of syntax highlighter library (plus other functionalities) and (2.) if it is going to completely replace the current WP content editor HTML view
    • @jorbin: Once one is decided upon, would like to encourage reaching out to the project maintainers and opening a dialogue about things like security and backwards compatibility
    • @helen: each area (Custom CSS, WP content editor HTML view, file editor) needs individual consideration and rationale
    • Goal is to provide a better user experience for when users edit code in WP
    • Custom CSS:
      • #38707: Customizer: Additional CSS highlight, revisions, selection, per-page, pop-out
      • @westonruter this is what #core-customize is most interested in, but picking a code editor library should be done ensuring that it doesn’t cause headaches if code editors are implemented for HTML view and file editor. i.e. the same library should be used throughout core.
    • WP content editor HTML view:
      • @joemcgill: the text editor now is not technically an HTML view, but is a plain text editor that is parsed into HTML. For instance, breaks are turned into `<p>` tags, shortcodes can be typed, etc., so a “code editor” is something slightly different.
      • @helen: per @iseulde and lots of discussions over time, is a little more complicated in that it’s not an actual HTML editor, so is getting rid of wpautop() is a requirement
      • @mike: I’d love to see code highlighting in the HTML view.
      • @afercia: If both the visual editor and the text editor are going to be replaced by Gutenberg and some sort of CodeMirror-like, well the level of accessibility for both is still uncertain and there’s the danger to introduce an accessibility barrier for the main scope of WordPress: entering content.
    • File editor:
      • @jorbin: I seem to remember that having been replaced with something fancier than what is in place now, but that having been ripped out
      • @helen: File editors really raise the question of whether users should be made more comfortable in them vs. being encouraged to use something else.
      • @brechtryckaert: security-wise I’m not a fan of the ability to edit files from the backend, people who are comfortable enough to edit code usually have a prefered editor
    • @jorbin: We already have our agreed upon accessibility coding standards that state:
      • All new or updated code released in WordPress must conform with the WCAG 2.0 guidelines at level AA

    •  @westonruter: if CodeMirror fails this test, as it seems to, then we need input on GPL-compatible code editors that are accessible.
    • @afercia: I propose to discuss this at the next accessibility meeting on Monday, invite people to do research, and possibly involve the testers group.
  • #38900 (Customize: Add REST API endpoints for changesets) and #39634 (Customize: Add REST API endpoints for panels, sections, controls, settings, and partials)
    • Thanks to @kadamwhite we have an initial (empty) feature plugin repo for the REST API endpoints for customization
    • Feel free to watch that repo and be apprised of developments
    • Next steps are to design the endpoints, write the failing tests for them, and then  go about writing the endpoint controllers
    • @kadamwhite: this is the first major effort within other areas of core that are turning up inconsistencies like #39805 (Expose featured_media property on post resources in “embed” context) so I’m excited to see what other improvements we can make as this work continues

Editor team update

  • Working full steam on prototypes, notably the Gutenberg UI prototype
  • The related GitHub repo has quickly become wonderfully active
  • Looking to discuss browser support for the new editor
    • @georgestephanis: So long as it can fall back to something that doesn’t utterly die, it should probably be fine.
    • WP Admin currently supports IE 8
    • Current browser market share
    • @jorbin: I would love to see us not drop support for anyone if possible
    • @joemcgill: Alternately, if we’re going to bump the browser requirements at any point, now is probably the time.
    • @joen: flexbox was mentioned as being nice to use in context of editor UI
    • flexbox support
  • The agenda for the Editor chat today was to discuss how using the UI prototype felt in the past week, and deciding where to take it next
  • We are looking for people to use and provide feedback the prototype, so please take a look if you can!

REST API team update

  • The REST API team has no significant updates since last week.

#4-7, #4-7-3, #core-editor, #core-restapi, #dev-chat, #summary

Customization Meeting Notes: January 23, 2017

From today’s #core-customize meeting:

Thanks @iandstewart for help with notes. Drop by #core-customize next week on Monday at 1:00pm EST for the next full meeting, or join us at the same time tomorrow for ticket triaging.

Editor Technical Overview

As we start looking at the editor from a technical perspective it’s important we identify the main obstacles and requirements we face before we start conjecturing solutions. As @matt wrote before, the editor focus aims to make writing rich posts effortless. This has taken the path of treating a post as being composed of distinct pieces of content called blocks. These pieces should be easy to insert and manipulate, providing rich and contextual interfaces to interact with as you craft a post.

So how do we go about turning this into a reality? Content in WordPress is, fundamentally, HTML-augmented text; that is to say, it has no inherent data structure. This has been a very important aspect of WordPress and a force for the open web—it speaks to the sense of ownership and freedom WordPress gives you, since it’s always easy to get the full content of your publications—yet the lack of structure gets in the way of the goal to treat content as composed from individual pieces. (This reality also became an issue for the development of post formats a few years ago, but I digress.)

It’s relatively easy to add structure, but it’s not trivial to do so in a way that doesn’t harm data integrity, portability, and the cohesiveness of the post_content. So let’s lay out a first requirement:

① Shape of the Data: Portable Text

To ensure we keep a key component of WordPress’ strength intact, the source of truth for the content should remain in post_content, where the bulk of the post data needs to be present in a way that is accessible and portable, while still providing additional structure on top of HTML semantics for our editing tools. Data needs to be praised and respected. This additional structure would hopefully be invisible to the document’s display context, as it ensures the rendered content is viewable in situations that may not be aware of blocks at all. (Think of email clients, RSS, older editor versions, mobile editors, database dumps, etc.)

Storing things separately means post_content becomes either a pointer or duplicated data, which fragments the source of truth since they can get out of sync easily. (A few content block plugins do this by storing structured data in postmeta and pure data in post_content.) On the other hand, storing things together means structure can become gibberish if it’s not formatted properly before display.

How can we then offer users a great experience when creating or manipulating content without sacrificing the spirit of integrity and data reliability that is expected from WordPress? Good representations of the data would also make it easier to develop robust collaboration tools in the future by allowing us to lock things in a more fine grained way. I believe this is important to figure out soon to allow us to prototype quickly, so I’ll follow up with an initial proposal by the end.

Honouring HTML leads to a second requirement:

② Simplicity and Semantics of Representation

Unless we are improving the semantics of the document we should minimize what markup we add to identify a block; for example, avoid adding extra DOM elements or attributes, both for simplicity and standards sake. WordPress has been a champion of web standards, and we should not venture away from this quality. How can we add structure in a way that remains invisible to the output (as meaningful content as possible) but gives the necessary hooks to infer a structured view for editing purposes?

While we discuss how to structure the content to include invisible demarcation of blocks, the aspect of their nature leads to a third requirement:

③ Static & Dynamic Blocks

Blocks can be either static or dynamic. That is to say, some blocks can be stored with all the necessary aspects needed for their display, while others need to be processed before generating their final output (shortcodes, embeds, widgets, etc). This distinction is important because the most common two blocks people will naturally use are text and images. We should not break their clarity as we treat them as blocks.


 # Static
Here’s some text.

# Dynamic
[text id=123] // Pulls "Here's some text" from somewhere.

This conceptual separation of blocks is useful for designing our project, yet they generate abstract complexity which users should not be exposed to, leading to a fourth requirement:

④ Consistent Experience

One of the biggest benefits of blocks is that composing a post becomes more intuitive and reliable. Everything is inserted under the same assumptions; discovering what can be inserted is a natural part of inserting content. To the user all blocks behave in a consistent and familiar way, even if they provide tailored UIs for their controls.

The user should also be able to edit a post in a different system (mobile, REST, older version of core, apps like Mars Edit, etc), even if they lose the advantages of block editing. That’s another reason why post_content as source of truth matters, compared to storing a JSON structure in postmeta. Having things in two places means they can get out of sync depending on what tool you used to edit.

These nuances of data, UI, and display lead to a final and more general requirement, which is understanding the system we’ll be crafting:

⑤ The System

The editor experience has three fundamental aspects to its system: the UI used to manipulate a block; the demarcation of the block; the rendered output of the block. These are all separate concerns, from the tools we craft to edit a post, to the document syntax that holds the data structure, to the way the final output is generated to be displayed as HTML. (With static blocks that last aspect may be of no significant concern since the document doesn’t care about the presence of static blocks, it just displays them.)

Picturing these concerns as connected but fundamentally separate would help us figure out the best design and technical solutions for each stage, while avoiding us taking aggressive moves by coupling expectations. For instance, JavaScript is a natural technology to look at when it comes to the ability to manipulate and interact with content blocks, yet it may not be the best at all when it comes to rendering the final post to a viewer. Avoiding painting the whole flow under the same light should allow us to focus efforts, because we don’t have to change everything.

❶ Coda

As a final coda, and following @joen‘s design exploration, let’s keep in mind that our first goal should be to set up a reliable foundation to allow us to iterate quickly and test assumptions. I propose we focus initially on a few static blocks (text, image with and without caption, quote) to limit scope of the project.

In which ways can we fulfil ① and ② from the above requirements?

Shortcodes fall short in that they are not invisible, they are opaque, not standing to the scrutiny of semantics, and are also painful to parse. Alternatives could be data-* attributes in the HTML elements or custom elements (paving the way for web components, perhaps), yet we need to be careful with adding cruft.

One other possibility is to look at HTML comments as a way to provide explicit demarcation to post_content without affecting the node structure of the document for something that is inherently spurious to the HTML semantics. WordPress already uses comments for the more tag (<!--more-->) and splitting content into pages in a way that has proven to be quite robust.

It could look something like this:

<!-- wp:image -->
<figure>
  <img src="/">
  <figcaption>A picture is worth a thousand words</figcaption>
</figure>
<!-- /wp -->

There are drawbacks, benefits, and implications with each that we should discuss separately. Are there any other possible solutions?

Please, join us in #core-editor if you are interested. We’re holding weekly meetings in Slack, Wednesdays at 19:00 CET.

#editor

Editor wish list for 4.5

#4-5, #editor

Editor Chat Tomorrow

Tomorrow we have our weekly editor chat (9 June 2015 21:00 UTC) in the #core-editor Slack channel. Here are some points we want to discuss. If any of these are of particular interest to you, be sure to attend. 🙂

  • Last week we added the text pattern plugin, please test! Are there any other patterns we should add? High on the list are for a block quote, #{1,6}  for headings and --- for a horizontal rule. #31441
  • What should happen to word count? Do we (re)move it? When and how should it be refreshed? Currently it only refreshes on enter and backspace, which is not ideal. In any case we also need to fix the counter itself (ignore more unicode ranges, shortcodes…) and this makes the counter slower. #30966
  • Inline linking. We’ve been talking about this for a while. There are some interesting mock ups from @joen, we should iterate on them and code it. Link text may go away. Should we keep “Open link in a new window/tab” in core? If you want to know more about the way it will work or help out, join us. 🙂 If there is consensus it may still make 4.3.
  • Another thing that should be coded asap is the caption placeholder. #32175

If there’s anything else you’d like to bring up that’s editor related, don’t hesitate to do so.

#editor

Editor wish list for 4.3

This is a list with improvement we’ve been planning for 4.3 and beyond. It’s open for suggestions and discussion, and it will continuously be updated.

  • Improve the editor on mobile. – #29923
    • Contextual floating toolbar.
    • Fix touch and focus issues. – #31247
    • Improve the spacing around the editor?
    • Combine “Add Media” with any buttons added by plugins. – #29989
  • Save and update without a page reload. For this we will need to look into nonce refreshing. – #7756
  • cmd/ctrl+S should work in the text editor and when the visual editor is not focussed. – #31655
  • Fix word count. – #30966
  • Bullet list shortcut. – #31441
  • Drag and drop linked images, captioned images and views. – #28272, #28003, #28826
  • Caption placeholder. – #32175
  • Add tests for our TinyMCE plugins. – #31596
  • Remove old Distraction Free Writing? – #30949
  • Improve editor scrolling.
  • Better default editor styles. – #31253, #32176
  • Inline link form. – Mock ups from @joen. One step done.
  • Leaving dialog. – #28566

Some things we started looking at for future releases:

  • Better structure for meta boxes. (needs tickets, mock ups)

Anything you’d like to see in this release or would like to work on? Please leave a comment.

#4-3, #editor

WordPress Core Weekly

Howdy! Sorry, I dropped the ball last week so this week’s Weekly Roundup is a double issue — it covers April 4, 2015 [32003] to April 18, 2015 [32140].

This week marks the release of RC1, which is the first release that many plugin authors and beta testers will test heavily. If you don’t already, now is a good time to check out the Alpha/Beta forums for any issues that crop up during this testing cycle.

We’re only days away from the release of 4.2; let’s finish strong! 🏃👏 Here’s the rundown of recent changes:

TinyMCE

  • Update to 4.1.9+. Changes:
    • Fixed bug where extra empty paragraphs would get deleted in WebKit/Blink due to recent Quriks fix.
    • Fixed bug where the editor wouldn’t work properly on IE 12 due to some required browser sniffing.
    • Fixed bug where formatting shortcut keys where interfering with Mac OS X screenshot keys. [32058] #31895
  • Disable the wp-autoresize plugin in iOS. All iframes there are already expanded to the height of the content document. [32095] #31937
  • Update the “Keyboard Shortcuts” modal. [32060] #29558
  • Fix our shortcuts on Mac, use Ctrl + Opt + letter. [32059] #29558
  • Use window.twemoji directly in the wpemoji plugin. Gives a chance to the browser to lazy load twemoji.js when reloading the page. [32142] #31901
  • Remove the empty paragraph that sometimes is left over after adding an image caption. [32141] #32003

wpView

  • Remove selected views when inserting content but not when loading all content, and remove the ref. to the selected view node on resetting the views. [32140] #31998
  • Resize sandbox iframes on load. [32056] #31480
  • Empty the content in the timeout, so it doesn’t render iframes twice. [32022] #31669

Build/Test Tools

  • During PHPUnit tests, don’t autodetect permalink structure during WP installation. [32139] #31994
  • Move the built media JS files up a directory to their previous location and naming convention. [32125] #31912 (see [31373])
  • Don’t reference underscore.js source map. [32065] #31477

General/Misc.

  • WordPress 4.2-RC1 [32137] [32138]
  • Use HTTPS URLs for codex.wordpress.org. [32116] #27115
  • Explain all placeholders in translator comment, not just the first one. [32111] #31675
  • Ensure post title input is not shortened for non-public post types. [32071] #30968
  • Improve handling of incomplete From and Content-Type headers in wp_mail(). [32070] #30266
  • wpLink: always show the URL field at the top. [32017] #28206
  • Force default avatar for HiDPI avatars on Discussion Settings. [32129] #31972

Translation and Strings

  • Merge strings that describe the same command. [32078] #31776
  • Update placeholder for FTP credentials. [32077] #31922
  • After [31941], use the decoupled strings from wp-admin/network/themes.php in wp-admin/network/site-themes.php as well. [32029] #28502
  • Correct grammar when referring to “a user” vs “an user” in several places. [32025] #31894

Administration

  • Fix flickering of the admin menu on over-scrolling. [32089] #30900
  • Dashboard: Ensure images other than avatars (such as emoji replacements) in recent comments are not incorrectly positioned. [32076] #31919
  • Admin menu: fix colors for focus state and in IE8. [32075] #31345
  • Dismissible notices: more precise positioning across browsers. [32068] #31233
  • Reset padding for buttons in theme details modal. [32128] #31963
  • Revert [32099] per discussion in #core. [32100] #30900
  • Remove z-index from #adminmenuback. [32099] #30900
  • Don’t print the custom-background class in body_class() when a default color is in use. [32081] #28687
  • Toolbar: Search item consistency for focus state and IE8. [32074] #31322
  • Pointers: Make the dismiss icon a consistent size. [32069] #31915
  • Update more instances of default admin blues and grays. [32051] #31234

Emoji and Smilies

  • Tweak which smiley matches which emoji. [32105] [32107] #31709
  • Update our few remaining smilies to better align with Twemoji, and add frownie.png until Twemoji provides a build containing it. [32104] #31709
  • The emoji JS files should be run through the script_loader_src filter, as they would be if they were registered scripts. [32097] #31938
  • Tidy up the wp_encode_emoji() regex, and clarify the function comment on Unicode 8 support. [32096]
  • Remove an errant / in Twemoji URLs. [32024] #31893
  • Remove executable bit from smilies. [32109] #31709

Themes

  • Twenty Fourteen: update editor styles to better account for adaptive images in small screens. [32094] #31934
  • Twenty Fifteen: update editor styles to better account for adaptive images in small screens. [32090] #31934
  • Theme Compat: Make string translatable and add translator comments. Added in [31941]. [32084] #28502, #31921
  • Move initialization of $customizeSidebar to api.ThemesSection.initialize() to prevent cases where the result can be undefined. [32119] #31793
  • Translator comment should just reference placeholder numbers, not the actual placeholders. [32112] #31675
  • Tell developers how to correctly silence register_sidebar() notices. [32110] #31675

Customizer

Theme Switcher

  • Fix some esoteric breakage in iOS Safari. [32103] #31794
  • Don’t deactivate section on empty search results. [32083] #31889
  • Remove “Add New” reference from customize-controls.js. [32004] #31837
  • Use text input for the search field to prevent double tap issues for Preview and Customize buttons on iOS. [32127] #31794
  • Don’t re-render a theme control if it has already been rendered.
  • Lazy load theme screenshots. [32088] #31793
  • Fix tabbing order if section is open. [32087] #31289
  • Fix preview URL for subfolder installs. [32086] #31896

Shiny Updates

  • Disable shiny updates from modal based on parent window [32082] #31739
  • Fix logic for details based shiny updates. [32080] #31739
  • Disable modal initiated shiny updates on wp-admin/update-core.php. [32067] #31739
  • Use dashes instead of dots as separator for jQuery events in shiny updates . is used for namespaces, so better to use dashes. [32063] #31819
  • Trigger events upon the completion of a shiny update. [32061] #31819
  • Remove Shiny Bulk Updates. Bulk updates don’t need to be ajaxified so let’s revert. [32053] #31770, #29820
  • Conditionally add AYS to leaving shiny updates. [32052] #31769
  • Enable users to initiate a shiny update from plugin detail modal. [32062] #31739

Media

  • Don’t allow whitespace-only image captions from the Media modal. [32079] #21848
  • Fix focus and selected state for the selected attachments set. [32072] #31898
  • Rename get_media_embedded_in_content_allowed filter tomedia_embedded_in_content_allowed_types. [32113] #26675
  • Bring back spinners, now without bouncing select elements. [32101] #22839, #30725
  • Fix the media modal Insert into post button on narrow screens by limiting the width of .media-toolbar-primary and .media-toolbar-secondary only inside .attachments-browser (the top toolbar). [32121] #31908
  • Insert from URL: Make sure the link text is actually used. [32055] #29476
  • Make sure the spinner in the media modal is visible on narrow screens (without affecting the media grid). [32120] #30725

Build Tools

  • Don’t override minified libraries included in core. [32066] #31477

Docs

  • Remove unnecessary inline @see tags from a variety of parameter and return descriptions in wp-includes/wp-db.php. [32050] #31888
  • Remove unnecessary inline @see tags from the wpdb::process_field_charsets()DocBlock. [32049] #31888
  • Add a missing return description for has_header_image(). [32048] #31888
  • Fix a variety of inline documentation syntactical issues in wp-includes/taxonomy.php. [32047] #31888
  • Add a missing @access tag to the DocBlock for the WP_Meta_Query->$clauses property. Also adds a missing return description for WP_Meta_Query::get_clauses(). [32044] #31888
  • Add a variety of missing descriptions and fix syntax for wp_scripts(),_wp_scripts_maybe_doing_it_wrong(), and wp_script_add_data(). [32040] #31888
  • Remove an unnecessary inline @see tag and document the $wpdb global in two WP_Comment_Query methods. [32038] #31888
  • Add missing parameter and return descriptions to WP_Customize_Widgets->filter_customize_dynamic_setting_args(). [32036] #31888
  • Add parameter and return descriptions for WP_Customize_Widgets->get_setting_type(). [32035] #31888
  • Add missing @access tags to two DocBlocks in WP_Customize_Setting. [32034] #31888
  • Document the $theme property in WP_Customize_Themes_Section. Also adds a missing@access tag to the DocBlock for WP_Customize_Themes_Section->render(). [32033] #31888
  • Cleanup DocBlock syntax, add a missing parameter description for WP_Customize_Manager->set_post_value(). [32031] #31888
  • Add inline doc syntax fixes for WP_Customize_Manager->doing_ajax(). Also adds a return description. [32030] #31888
  • Add documentation for the $type and $theme properties in WP_Customize_Theme_Control. Also add some missing @access tags to various DocBlocks. [32028] #31888
  • Fix description alignment for the category_css_class filter docs. [32026] #31888
  • Add documentation for the $type, $mime_type, and $button_labels properties in WP_Customize_Media_Control. [32023] #31888
  • Clarify the DocBlock summary and parameter description forwp_edit_attachments_query_vars(). [32019] #31888
  • Add proper descriptions for the @global and @param tags in the wp_media_attach_action() DocBlock. [32018] #31888
  • Clarify the DocBlock description for wp_print_request_filesystem_credentials_modal(). [32016] #31888
  • Clarify 4.2.0 changelog entry, add global description to the DocBlock for WP_Users_List_Table->single_row(). [32015] #31888
  • Add missing @since versions from a variety of methods in WP_Press_This. [32014] #31888
  • Add missing DocBlocks for the _limit_array(), _limit_string(), _limit_url(),_limit_img(), _limit_embed(), and _process_meta_entry() utility methods in WP_Press_This. [32013] #31888
  • Add a return description to the DocBlock for WP_Posts_List_Table->is_base_request(). [32009] #31888
  • Add an @see mention for Plugin_Upgrader, plus spacing to the wp_ajax_update_plugin()delcaration. [32006] #31888
  • Add a more descriptive function summary for options_discussion_add_js(). [32005] #31888
  • Fix Docblock syntax for the taxonomy_parent_dropdown_args filter. [32003] #31888
  • Add a missing return description for wp_styles(). [32041] #31888
  • wp_install_maybe_enable_pretty_permalinks() should have a consistent @return value. [32027] #6481, #31888

Help/About

  • All strings are available for translation. [32132] [32135] [32136] #31929
  • Change the subhead strings on credits.php and freedoms.php to match about.php.
  • Link the Emoji Codex article in the emoji blurb.
  • Add a second sentence to the JavaScript Accessibility blurb.
  • Switch positions for the JavaScript Accessibility and Complex Query Ordering sections for balance. [32131] #31929
  • Update about page for 4.2. [32118] [32123] [32130] #31929

Upgrade/Install

  • Move wp-plugin-update-success event to after lock is released [32133] #31978, #31819
  • Use named function instead of anonymous function, making it testable and replaceable. [32126] #31964
  • When dbDelta() is checking whether an index is defined in a CREATE TABLE statement, don’t worry if MySQL has a subpart defined on an index, but the CREATE TABLE doesn’t. [32108] #31869

Script Loader

Press This

  • Do not show the bookmarklet upgrade notice when accessing directly press-this.php. [32122] #31968
  • Add mb_strlen() compatibility function. Works the same way as the existing mb_substr() compatibility function. [32114] #31951
  • Check the bookmarklet version and add the update notice from PHP. [32106] #31942
  • Add ARIA attributes to the alerts container. [32102] #31942
  • Fix focusing the Standard Editor link after saving draft, if the user has not focused another element. [32098] #31923
  • Change the link text to Standard Editor. [32093] #31923
  • When saving a draft change the text of the Save Draft button to “Saving…” [32092] #31923
  • Update documentation for press_this_save_redirect filter after [31992]. [32143] #31996

Taxonomy

  • wp_update_term() should check if get_term() returned null. [32117] #31954
  • Avoid an unexpected object error when syncing global terms. Pass the expected single value, rather than object, when recursively calling global_terms(). [32064] #31914, #31149

Editor

Thanks to @adamsilverstein, @afercia, @awbauer, @azaozz, @boonebgorges, @DavidAnderson, @dimadin, @dlh, @DrewAPicture, @ericlewis, @hauvong, @helen, @hugobaeta, @iseulde, @jamescollins, @jeremyfelt, @joemcgill, @joen, @johnbillion, @jorbin, @kraftbj, @lancewillett, @markjaquith, @mattheu, @Michael-Arestad, @mindrun, @morganestes, @nacin, @nitkr, @obenland, @ocean90, @pavelevap, @pento, @peterwilsoncc, @samuelsidler, @SergeyBiryukov, @siobhan, @sirbrillig, @slobodanmanic, @swissspidy, @tmatsuur, @Tmeiste, @tyxla, @valendesigns, @westonruter, and @wonderboymusic for their contributions!

#4-2, #week-in-core

WordPress Core Weekly

Hi everyone, and welcome to this week’s installment of WordPress Core Weekly – covering March 5 2015 [31621] through March 13, 2015 [31764].

If you want to 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.

WordPress 4.2 Beta 1

In case you missed it, the first beta of WordPress 4.2 was released yesterday! Read the announcement post for a quick overview of all features (emojis! 🎉🎉) and be sure to test it extensively.

Code Updates

General

TinyMCE

  • Abstract the code for creating floating toolbars. Introduce editor.wp namespace to hold exported methods from our plugins. [31725] #30619
  • Hide TinyMCE help button on mobile. [31718] #31161
  • Update TinyMCE to 4.1.9. [31700] #31551
  • TinyMCE: when pasting an URL over a selection, insert a link with the URL instead of replacing the selection with it. [31691] #31571
  • In the modal state for Embed previews, only show the Title field when the preview fails. [31632] #29476

Upgrade/Install

  • Shiny Updates: Disable body scrolling when filesystem request modal is open. [31753] #31607
  • Shiny Updates: Don’t translate an error code string. [31751] #31606

Posts, Post Types

  • Allow is_page_template() to accept an array, as many other conditional tags do. [31754] #31271
  • Introduce a new algorithm for displaying a hierarchical list of post objects in the WP_Posts_List_Table. This reduces processing time, reduces database queries, and substantially reduces memory use on sites with a high number of Pages. [31730] #15459

Press This

  • Remove obsolete help tab in Settings -> Writing. [31743] #26794
  • update _limit_url(), use esc_url_raw(). [31737] #31373
  • Filter and select the content on the PHP side. Then pass only the needed data to JS. [31693] #31373
  • Add preview functionality. Opens the preview in a new window or a tab next to the source tab. [31654] #31458

Media

  • EXIF/IPTC captions should populate Caption (post_excerpt) on upload, not Description (post_content). [31694] #22768
  • Introduce a function, wp_attachment_is( $type, $post = 0 ), to collapse the logic for determining whether an attachment is an image, audio, or video. [31645] [31670] #25275

Widgets

Feeds

External Libraries

Plugins

  • Plugin details: Ensure banner image doesn’t repeat. [31719] #30773

Embeds

Customizer

  • Return the original value when filtering theme mods/options and the current blog has changed. [31707] #31428
  • Prevent a race condition when attempting to publish too soon after updating widget form fields with multiple edits. [31706] #31501
  • Fix previewing and applying widgets when previewing another theme. [31705] #31484
  • Introduce WP_Customize_Media_Control, a new base class for all Customizer media controls. [31698] #29215
  • Add loading indicators for the Customizer preview. [31697] #31196
  • Add audio/video previews for upload controls. [31661] #30850

Comments

  • Improved customizability for the Submit button in comment_form(). [31699] #15015
  • Comments: Show more identifying information for moderation and editing. [31641] [31695] #23988

Administration

  • Screen Options: Improve items per page option label. Add a default label “Number of items per page:” to WP_Screen->render_per_page_options() and remove all the existing one-word labels. [31696] #31349, #15576
  • Theme Details: Hide admin toolbar on smaller screens. [31702] #31381
  • Star ratings: Use a yellow color across the board. Keying these to color schemes originally turned out to be weird. [31747] #31424
  • Remove single-use URL parameters and create canonical link based on new URL. [31736] #23367
  • Allow swiping of the admin menu on touch devices. [31720] #31187
  • Restore <title> tag on Posts and Pages screens after [31696]. [31709] #31349
  • Replace flagrant instances of .html(”) with .empty(). [31690] #27034
  • Nav menus: Return to calling links “Custom Links”. [31748] #31344

Networks and Sites

  • Introduce delete_site meta capability. [31673] #30470
  • Return HTTP status code 403 in network admin when access is forbidden. [31658] #31422
  • Return HTTP status code 500 by default in ms_not_installed() [31657] #30002

Query

Users

  • Improve experience when deleting users from a multisite network. [31656] #18132

Bundled Theme

  • Twenty Fifteen: add ARIA attributes to menu toggle. [31644] #31527

Thanks to @adamsilverstein, @afercia, @azaozz, @batmoo, @beaulebens, @bendoh, @boonebgorges, @celloexpressions, @codix, @coffee2code, @craig-ralston, @dd32, @doublesharp, @DrewAPicture, @elliottcarlson, @ericlewis, @Fab1en, @HarishChaudhari, @helen, @hugobaeta, @iandunn, @Idealien, @iseulde, @jeremyfelt, @jesin, @jipmoors, @joen, @johnbillion, @jorbin, @kraftbj, @lancewillett, @LeoPeo, @mattheu, @mattheu, @MattyRob, @Michael-Arestad, @MikeHansenMe, @miqrogroove, @morganestes, @morpheu5, @mkaz, @nacin, @netweb, @ninnypants, @nofearinc, @obenland, @ocean90, @OriginalEXE, @pavelevap, @pbearne, @pento, @peterwilsoncc @podpirate, @rachelbaker, @rodrigosprimo, @scott.gonzalez, @seanchayes, @senff, @SergeyBiryukov, @SergeyBiryukov, @stephdau, @stevenkword, @swissspidy, @thaicloud, @thomaswm, @tyxla, @valendesigns, @westonruter, @wonderboymusic, and @yo-l1982 for their contributions!

#4-2, #week-in-core

Feature Plugin Chat on March 4

As mentioned at this week’s and last week’s meeting, we’re going to be holding a feature plugin chat on March 4 2014 21:00 UTC. If you have an idea for a new feature, this will be a great opportunity to bring it up and find others interested in helping out. In fact, just like we’ve done before, post your feature ideas here.

Please leave one comment per feature idea 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).
  • A list of those involved or already interested in your feature plugin (including you!)
  • What you’d like help with (scoping, planning, wireframing, development, design, etc).

This post and the accompanying chat is for posting ideas that you’d be interested in working on. It is not for posting every feature idea you have for WordPress.

Current feature plugin leads: Please post an update for your plugin here, along with the information above.

See you all at the chat!

#core-plugins

Present your 3.8 feature idea at tomorrow’s meeting

Tomorrow’s WordPress 3.8 meeting at Thursday 18:00 UTC is a great time to present your feature idea to the community. Many groups have already started forming around different ideas.

Comment on this post with a group name to add your group to the list of projects presenting tomorrow. Make sure you bring the following things with you:

  • What problem(s) are you trying to solve?
  • What proposal solution(s) are you interested in exploring?
  • When and where is your group communicating?
  • Who has joined your group so far?
  • If you’ve selected someone to lead your group, who is your lead?
  • If you’ve already started work on your plugin, bring a link to your plugin page.

See you tomorrow!

#3-8, #agenda, #core-plugins