WordPress.org

Make WordPress Core

Updates from August, 2015 Toggle Comment Threads | Keyboard Shortcuts

  • Boone Gorges 4:29 pm on August 27, 2015 Permalink
    Tags: , ,   

    Taxonomy roadmap for 4.4 and beyond 

    In WordPress 4.3, we eliminated shared taxonomy terms once and for all. This means that, by the time WordPress 4.4 is released, just about every WordPress installation will have the same number of rows in the wp_terms and wp_term_taxonomy database tables.

    Why does this matter? When terms in different taxonomies could share the same term_id, terms could only be uniquely identified by a ID-taxonomy pair. This is why every nearly function in our taxonomy API has $term_id and $taxonomy as required arguments. (The decision was made long ago to keep the truly-unique term_taxonomy_id internal for most purposes.) The lack of unique IDs for terms made our API interfaces and internals complicated, and it made it cumbersome to add new features like term metadata.

    Now that term IDs are unique, we can begin the projects of unraveling the now-unneeded complications of the taxonomy API and adding new features that take advantage of the simplified data model. In this post, I’ll outline some of these tasks, and point to areas where interested folks can contribute.

    API simplification and other work on taxonomy internals

    Once each row in the wp_terms table corresponds to a single row in wp_term_taxonomy, there’s no point in having two separate tables (and all the JOINs that two tables require). In 2013, @nacin sketched how this might be done, through a combination of $wpdb tricks and a MySQL view. Here, we need someone to write a patch, and we also need to start a discussion about graceful failures for situations where there are still shared terms in the DB, as well as MySQL version compatibility (view functionality was phased in over the 5.0 series). The tracking ticket for simplification of the taxonomy database schema is #30262.

    With a single term table, we can begin to rewrite our internal SQL queries to remove costly table joins. This kind of refactoring is probably at least one version (and a hundred unit tests) away. In the meantime, we can begin the process of simplifying the API interfaces. For example, functions that accept term IDs, like get_term() no longer need to require an explicit taxonomy parameter.

    Having a unique identifiers for terms means this is also a good time to move toward WP_Term; see #14162. This class can start off being a fairly simple model that takes care of things like basic cache management and data integrity – see WP_Post – but over time, I envision moving business logic to the WP_Term, introducing convenience methods for chaining, and so on.

    Term Meta

    There’s been lots of clamoring for taxonomy term metadata #10142. Unique term IDs make it viable, since WP’s *_metadata() functions assume object IDs as identifiers.

    The technical implementation is not complex. We need wrappers for the CRUD functions, ‘meta_query’ support in get_terms(), an update routine to create the database table, metadata pre-caching (‘update_term_meta_cache’) when fetching terms, and maybe a few other small items.

    The larger challenge is to build a core solution that minimizes conflict with third-party tools. Developers have wanted termmeta for a long time, so there are many public plugins and private libraries that provide it. Many of them use unprefixed function names like update_term_meta(), and many of them use a database table called wp_termmeta. We should do a survey of publicly available plugins to get a sense of usage statistics and schema compatibility. We’ll need to organize outreach to developers of known plugins, so that they can add off-switches to their tools before termmeta appears in core. And we may decide to borrow code from one or more of the existing GPL-licensed tools, ideally with the participation of the original author.

    Let’s share this journey

    Many hands make light work. We need code, but more importantly, we need folks who are nuts about strategy and outreach and backward compatibility.

    There’ll be a meeting for all Taxonomy Heroes, on September 3 2015 20:00 UTC, in the #core channel on Slack. If you’re interested in helping out with any of these taxonomy projects, drop a comment below or come to the meeting. We’ll get a team or two together, and make a plan for 4.4 and beyond.

     
    • Scott Taylor 4:36 pm on August 27, 2015 Permalink | Log in to Reply

      You are an American treasure.

    • Felix Arntz 5:08 pm on August 27, 2015 Permalink | Log in to Reply

      That’s an awesome step, standardizing terms (when compared to posts) will make WordPress development a lot more intuitive. I’m looking forward to help, in any way possible! 🙂

    • imath 5:12 pm on August 27, 2015 Permalink | Log in to Reply

      Fantastic!

    • prettyboymp 5:42 pm on August 27, 2015 Permalink | Log in to Reply

      I know there are a lot of smart developers leading this and making these decisions, but I don’t think that adding meta to terms is the best path forward. I think it would be better to move towards a sunset of the terms tables altogether and add the ability to create direct relationships between post objects.

      The addition of term meta will introduce a new way for data to be represented and further reduce compatibility between different themes and plugins. The reason many developers want terms to have meta is because they need them to be more than just a word. Developers will now have to determine whether it is best to represent a data structure as a term or as a post object. The limitation right now is that you can only create a many to many relationship within the current schema by using terms. Wouldn’t it make more sense to move towards treating everything as an object and give the ability to create many to many relationships between any of them?

      • Boone Gorges 5:59 pm on August 27, 2015 Permalink | Log in to Reply

        > I think it would be better to move towards a sunset of the terms tables altogether and add the ability to create direct relationships between post objects.

        I would agree with this more if the post schema (and the “post type” API) had been more explicitly designed for general “object” use. One of the virtues of the taxonomy schema as it currently stands is that it’s fast – it doesn’t store a lot of data (like longtext), and the tables can be joined efficiently. wp_term_relationships is, in fact, a relationship table like what you’re suggesting for posts. The post schema, on the other hand, is loaded with fields that are of questionable value for general objects, fields that make queries cumbersome and resource-intensive. (A related concern, which I think is very legitimate, is that introducing term meta – and especially term meta queries – is going to slow down what is currently a fast API. This is something we should definitely discuss as a part of the initiative.)

        As for the question of whether this “further reduces compatibility between different themes and plugins”, I don’t really agree. In theory, a purely node-based system like Drupal means that all data types can work with all other data types. But how this gets fleshed out by developers and within UIs is far from a foregone conclusion.

        Moveover, by introducing greater parity between the Post and Term APIs, an argument could be made that we’re *increasing* compatibility between various WP components, at least as far as the developer experience is concerned. The API interfaces will be similar enough that it’s possible to imagine building tools that will talk to either terms or posts with a minimal layer of abstraction.

        In any case, these are helpful thoughts, and I hope you’ll think about coming and arguing them next Thursday 🙂

        • Mike Schinkel 6:54 am on August 28, 2015 Permalink | Log in to Reply

          While I am somewhat on the fence about this, I am leaning towards what @prettyboymp said. Rather than blindly adding term meta, it probably makes good sense to first ask if there is actually not a better way.

          For example, what if the post table were split in two, allowing for a lightweight version with limited fields and a heavy version using a join will full fields? It is possible that could also result in significant performance savings when working with posts in addition to making terms less of a special case.

          Note I am not saying this specific idea makes sense (or that it does not), I’m only saying that it would be good to open the floor for alternate strawmen proposals with subsequent discussion before committing to any one particular direction.

          • Boone Gorges 1:55 pm on August 28, 2015 Permalink | Log in to Reply

            I totally agree that we shouldn’t jump into term meta without discussing whether it’s the right thing to do. I meant to say that in the post, but there were so darn many things to say 🙂

            That being said, while I think it’s good to brainstorm and think big, I don’t want to be unrealistic. Massive schema and API changes take huge amounts of effort and time. I don’t want to get so sidetracked talking about a complete rearchitecture of WordPress that we lose track of the very real improvements we can make today – improvements that are often compatible with future changes.

            The one larger item I do want to flag for discussion is a general relationships API. Since Taxonomy already contains a relationship table, I want to make sure that any changes we make in that component don’t block the future development of object-object relationship functionality.

    • SanjayaBhai 6:12 pm on August 27, 2015 Permalink | Log in to Reply

      Wosome Fantastic 😀

    • leemon 6:26 pm on August 27, 2015 Permalink | Log in to Reply

      Many many thanks for championing this feature! 🙂

    • marsjaninzmarsa 6:53 pm on August 27, 2015 Permalink | Log in to Reply

      Count me in of course. 🙂

    • MatheusGimenez 10:57 pm on August 27, 2015 Permalink | Log in to Reply

      Great! Term meta is a very necessary function. 🙂

    • natebald 2:18 am on August 31, 2015 Permalink | Log in to Reply

      Hi, can someone explain what this means for sites that different post types uses the same taxonomy? I am unclear what the end result will be if the site is updated. Thank you in advance.

      • Boone Gorges 12:08 pm on August 31, 2015 Permalink | Log in to Reply

        natebald – The scenario you’ve described here is unaffected by any of these changes. The elimination of “shared terms” is about specific *terms* that are shared between multiple taxonomies.

    • texteditor 2:57 pm on August 31, 2015 Permalink | Log in to Reply

      Greetings. Please count me in with this discussion. I built a site for our university that serves e-textbooks in various download formats. I needed to group the download format types together and associate them with their respective posts. I wrote a query joining term relationships, term taxonomy, terms, and post meta among other things. It serves the purpose very well, but I am certain the upcoming 4.4 changes would affect our site. I can show you our site and the queries during the conference. Thank you in advance.

    • masonjames 10:05 pm on August 31, 2015 Permalink | Log in to Reply

      “We need code, but more importantly, we need folks who are nuts about strategy and outreach and backward compatibility.”

      Welp. You had me at “we need folks who are nuts”

    • Marin Atanasov 8:26 pm on September 3, 2015 Permalink | Log in to Reply

      Wow, this is exciting. I’ve been waiting for that since 2.8.

      It would be awesome to get that in 4.4. But too many things to consider. I’d love to help with any patches, testing or opinion here! 🙂

  • Konstantin Obenland 9:45 pm on May 20, 2015 Permalink
    Tags: ,   

    Dev Chat Summary, May 20 

    Agenda, Slack log.

    Committers Update (#)
    @nacin
    New guest committers: @iseulde, @westonruter, and @obenland, renewed guest committers: @jorbin, @jeremfelt, permanent committers: @pento, @boone, and @johnbillion
    Also see https://make.wordpress.org/core/2015/05/20/new-committers-for-4-3/

    Editor (#)
    @azaozz@iseulde
    No update here. Will discuss goals for this week and next week outside of dev chat.

    Admin UI (#)
    @helen
    @helen is plugging away at some groundwork for the CSS roadmap, @stephdau should be taking a look at the first steps for list tables in the next day or so. Will discuss goals for next week in tomorrow’s UI meeting.

    Network Admin UI (#)
    @jeremyfelt
    They talked through aspects of the Edit Site and Add Site flows yesterday to help @hugobaeta with mock-ups. Hopeful to see a mock up of these soon. They have a couple flows in Make/Flow with more on the way. The 5s flow highlighted an issue with text inputs overflowing. There’s also an updated `WP_Network` patch.

    Things they want to have done by next week:

    • Android and iPad flows.
    • Conversation around updated `WP_Network` patch and a first attempt at `WP_Site`.

    Partial Refresh (#)
    @westonruter
    Now has support for refreshing menus changed by Menu Customizer: https://github.com/xwp/wp-customize-partial-refresh/pull/12/files
    It’s much simpler than partial refresh for widgets, and @westonruter thinks that maybe it could safely be on by default, instead of requiring opt-in as is currently done for widgets. The concern with on-by-default would be if menus get some dynamic behaviors added to them with JS, so maybe it’s just something that theme authors would need to account for.
    Also waiting on feedback and testing from the Menu Customizer, merging the corresponding PR for Menu Customizer, to then merge the PR for Customize Partial Refresh and do a new plugin release.

    Goals for next week: Take what was done for Menus and then abstract a level again to facilitate plugins easily adding their own partial-refreshing.

    Menu Customizer (#)
    @voldemortensen, @celloexpressions
    Lazy loading and error handling were committed. Will discuss goals for next week outside of dev chat.

    Better Passwords (#)
    @markjaquith
    They’ve been working on a mockup of the password UI: http://codepen.io/markjaquith/pen/GJjZbJ
    Probably best to create a temporary hook in core for the password-set UI in the profile, to allow the team to work on this as a plugin. @markjaquith can take care of that core change, and start the plugin on GitHub.
    #32428 is on hold until the Password UI is usable. @voldemortensen started work on expiring reset keys #32429, but hopes to get it showcase-able by the end of the week. @rmarks made a first pass at #32430 but it needs more work.

    Goals for next week:
    1. Hook in core to enable plugin for PW change UI.
    2. Working version of PW change UI on the Profile screen (that is, you can change your password with it… show/hide… back compat for the pw confirmation field… not promising the strength hint stuff yet).
    3. #32430 ready for commit.
    4. Working patch for #32429.

    Favicons (#)
    @johnbillion
    @johnbillion made a start on the site favicon manager. As discussed during dev chat last week and in #16434 it has an API so plugins/themes can register new sizes for favicons/touch icons/etc if the need arises. I’ll be pushed to a GitHub repo by tomorrow. The main thing that will need to be discussed is whether this should just be a customizer setting or not. @johnbillion will post about the repository location and meeting times on this blog.

    Other:
    @ocean90 is looking for feedback on #29783!

    Next chat will be on May 27 2015, 20:00 UTC

     
  • Drew Jaynes 5:44 pm on April 21, 2015 Permalink
    Tags:   

    4.2 Scrub 

    We’ll be scrubbing report 6 in the #core channel on Slack in about 20 minutes at Tuesday 18:00 UTC 2015. Join us!

    @azaozz @dd32 @nacin @helen @sergeybiryukov @ocean90 @wonderboymusic @mark @johnbillion @jorbin @boone @jeremyfelt @pento

     
  • Morgan Estes 12:43 pm on April 19, 2015 Permalink
    Tags: ,   

    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!

     
  • Drew Jaynes 10:00 am on March 18, 2015 Permalink
    Tags: ,   

    Dev Chat Agenda, March 18, 2015 

    Here’s the agenda for Wednesday’s Dev Chat in the #core channel on Slack.

    » Beta 1 was tagged last week as scheduled and we’re heading toward tagging Beta 2 this week.

    Time/Date: March 18 2015 21:00 UTC:

    Reminder for those on Daylight Saving Time – If you’re already on Daylight Saving Time, the core dev chat will be an hour later for you for the next few weeks, though still 21:00 UTC. The above time link should give you the correct time and date for your local timezone.

    Agenda

    1. Ticket Ownership
      • New Trac report, Tickets I Own, primarily for committers
      • Review milestoning best-practices in the testing stages
    2. Bug Scrub/Commit Sprint

    No Open Floor this week – Due to time constraints, we won’t be holding an open floor period during the regularly-scheduled dev chat this week. If you have a ticket on the 4.2 milestone you’d like to get dev feedback on, leave a note in the comments.

     
    • Justin Sternberg 1:04 pm on March 18, 2015 Permalink | Log in to Reply

      Would like to get a decision on https://core.trac.wordpress.org/ticket/31556. Thanks Drew.

    • Joe McGill 1:19 pm on March 18, 2015 Permalink | Log in to Reply

      I think https://core.trac.wordpress.org/ticket/30900 is ready to go in, just needs an owner.

      The second ticket where I’d like to get some feedback is https://core.trac.wordpress.org/ticket/31352 – making media icons retina friendly. Issue being whether it’s better to use SVGs for those icons or to modify the output of `wp_get_attachment_image_src()` to support multiple sources (e.g. icon1x.png, icon2x.png, etc.).

    • Paal Joachim Romdahl 5:58 pm on March 18, 2015 Permalink | Log in to Reply

      I believe there is a lack in people contributing to WordPress core.
      This is a topic that should be discussed.

      It would be informative to ask for feedback on how people experience contributing to WordPress.

      I see two different ways outside of slack we can handle this. Both would be helpful for the community.

      1.
      Creating a survery asking people if they have contributed to WordPress Core in some way.

      • How was your experience?
      • Do you have suggestions on how to improve the experience?
      • Anything else you would like to add?
      • How should we go about encouraging others to contribute?
      • Has your company considered donating employees time to contributing to improve WordPress? Yes/no
      • If so why or why not.
      • Etc…

      2.
      Holding a town hall meeting with the topic “Improving the contributing experience for WordPress Core”.

      Findings will then need to be strongly considered and changes implemented looking at the structure of how things are done in WordPress. All companies need to find ways to better themselves WordPress is also one of them. I am hoping that this can create a serious introspection with the result of adjusting what does not work with a new flow that does.

  • Pascal Birchler 3:37 pm on March 13, 2015 Permalink
    Tags: ,   

    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!

     
  • Morgan Estes 1:37 pm on March 6, 2015 Permalink
    Tags: ,   

    WordPress Core Weekly 

    Howdy, and welcome to this week’s installment of WordPress Core Weekly – covering February 26, 2015 [31545] through March 4, 2015 [31620].

    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.

    Let’s start with a warm welcome to our new Component Maintainers, who play an important role in the development process.

    Build/Test Tools: @voldemortensen
    Comments: @rachelbaker
    Editor – Press This: @Michael-Arestad, @stephdau
    General: @SergeyBiryukov
    I18N: @SergeyBiryukov
    Options, Meta APIs: @MikeHansenMe
    Themes – Customize: @voldemortensen
    Users: @justinsainton

    These maintainers are vital to keeping WordPress development running as smoothly as possible. They triage new tickets, look after existing ones, spearhead or mentor tasks, pitch new ideas, curate roadmaps, and provide feedback to other contributors.

    Dev Chat Notes

    This week’s Dev Chat was a lively one, with updates on the Customizer and Press This (with an emphasis on accessibility, hooray!), Shiny Updates (needs helping hands, see the todo list), Emoji (not just for smiles), and Accessibility (revisiting the age-old a vs button question).

    If you missed the meeting, or need a reminder of what was discussed, take a few minutes to read the transcripts.

    A couple of reminders: we’re a week away from Beta 1, and Daylight Saving Time is coming so make sure to check the time of next week’s Dev Chat so you won’t miss it!

    Tickets needing a look:

    • #5305: permalinks broken when article name is numeric
    • #31349: Screen options posts/pages/etc. per page label
    • #17817: do_action/apply_filters/etc. recursion on same filter kills underlying call
    • #29820: Smooth installation and updating of plugins and themes

    Code Updates

    It’s been a busy week with lots of commits, so let’s get into the ticket overview:

    Media

    • Allow inline editing of width and height parameters while previewing an embed in the media modal. [31620] #31139
    • Media modules: set $ to Backbone.$, instead of jQuery, so fewer globals are imported. [31618] #28510
    • When viewing media in List mode, auto-submit the form for attachment filters when the value of a <select> changes. This makes it behave similar to Grid mode and “feels” more performant, even though it is a full page load. [31582] #30333
    • Allow attachments to be detached from their parent in media grid and list modes. [31619] #6820
    • In the Insert From URL state of the Post frame, add the necessary CSS for focus styles for images. [31585] #28820
    • Build: Let RTLCSS handle swapping the codes for right/left arrows from Dashicons. [31579] #31478
    • Support GIMP files in the Media Library. We already support Photoshop files. [31578] #31146
    • In the ->multi_resize() method of the WP_Image_Editor subclasses, when looping through potential crops, we need to make sure the crop isn’t the exact same dimensions as the original image before copying it as a new crop. [31576] #31296
    • Make a new function, wp_delete_file(). Use it. [31575] #17864
    • Improve get_media_embedded_in_content() so that it returns the media it finds in the same order that it appears in the content. [31574] #26675
    • Customize Widgets: Don’t return undefined items in getWidgetFormControls method. [31570] #31465
    • CSS: Move relevant #sidemenu rules into deprecated-media.css and remove the cruft. [31564] #27956
    • Persist search terms across grid/list modes. [31562] #30583

    Comments

    • Respect comment_date and comment_date_gmt params in wp_new_comment(). [31615] #14279
    • In get_next_comments_link(), ensure proper pagination when no ‘cpage’ query var is found. [31617] #20319
    • wp_insert_comment() should be checking and setting $compacted, not the non-existent $post_data. [31553] #21212

    TinyMCE/Editor

    wpView

    • decode HTML entities before trying to insert view markers. [31612] #31412
    • introduce getText() and remove() methods, improved getInstance(), better docs. [31559] #31412
    • Better structure; simpler “view” registration; better extensibility; better inline documentation; don’t show a placeholder for pasted link until we know the link is “embeddable’. [31546] #31412
    • Remove the (obsolete) get/setViewText methods. Update stopping/pausing of multiple ME media players. [31548] #31412

    wpLink

    General

    • Autocomplete: Update CSS based on both jQuery UI and general visual changes. [31611] #31427
    • Add wp.a11y.speak() for audible alerts/updates in screen readers. [31594] #31368
    • Remove the once-placeholder-esque “tag hint”, which has not worked in quite some time. [31607] #31485
    • When sanitizing a URL to redirect to, UTF-8 characters can be URL encoded, instead of being removed. [31587] #31486
    • Introduce get_object_terms filter in wp_get_object_terms(). [31581] #18828
    • In get_avatar_data() and get_avatar(), allow height and width to be specified separately (both default to size). Also allow arbitrary attributes on the <img> via the extra_attr arg. [31561] #31469
    • Permalinks: In wp_get_attachment_url(), convert to HTTPS when possible. [31614] #15928

    Posts, Post Types

    • List tables: Display front and posts page indicators. [31610] #30190
    • Hide irrelevant UI and display a message when editing the page for posts. [31550] #17470

    Press This

    • Add missing access modifiers to WP_Press_This. [31552] #31456
    • Add press-this.css to the list of stylesheets that are minified and to list of RTL styles. [31547][31572] #31373
    • Make sure buttons.css is loaded before press-this.css. [31597] #31373
    • Use correct URL for update bookmarklet link. [31556] #31461
    • Go back to loading the minified bookmarklet content with file_get_contents(). Add Grunt task to minify bookmarklet.js on precommit and update it in /src. [31545] #31373
    • Improve handling of the data, both from the bookmarklet and from server-side parsing. [31609] #31373
    • Remove unneeded passing of post formats strings to JS. Set the currently selected post format name with jQuery. [31589] #31373

    [31601] #31493

    • Remove classes from suggested HTML for the editor.
    • Improve the filter, pass an associative array as param.
    • Use <em> instead of <cite>.

    [31595] #31373

    • Simplify getSuggestedContent() and helpers. No need to override the global data.
    • Replace the press_this_source_string and press_this_source_link filters with press_this_suggested_html that allows filtering of the link and the wrapper HTML tags.

    [31588] #31373

    • Backwards compatibility enhancements.
    • Add missing actions for printing styles/scripts.
    • Since $hook_suffix is null, hardcode press-this.php.
    • Restore body classes, add filter.
    • Use wp_json_encode().
    • Update docs for filters in script-loader.php.

    General

    • TinyMCE: set ‘directionality’ and add the LTR button when in RTL. [31580] #31474
    • RTL improvements: [31577] #31478, #31474
    • Fix and update buttons styles. [31598] #31498
    • When there is a protocol mismatch (http vs. https), use server-side media detection instead of submitting a form as it triggers “Unsafe data” warning in some browsers. [31584] #31468
    • Fix selecting a post format (radio buttons) with the keyboard. [31583] #31440
    • Accessibility enhancements [31566] #31449
    • Enable scrollbars in Firefox, remove overflow-x: hidden from the html element. [31565] #31455
    • Fix notices/errors classes. [31549] #31456

    Administration

    • Fix a typo in the $args parameter hash notation description for add_settings_field(). [31593] #28975
    • Nav menus: Better JS performance on initial load of edit screen. [31604] #25698
    • Themes: Avoid jumping when selecting a feature in the feature filter on Add Themes screen. [31603] #31497

    External Libraries

    Administration

    • Settings API: Allow passing a class to add_settings_field() via the $args array. [31560] #30168, #28975

    Build/Test Tools

    • RTL CSS generation: Switch from CSSJanus to RTLCSS. [31573] #31332
    • Run unit tests on Travis CI with PHP nightlies. With PHP7 in active development, this will help us identify issues there. [31558] #31454
    • Update grunt-patch-wordpress to 0.3.0. [31557] #31466

    Thanks to @abhishekfdd, @afercia, @alexkingorg, @atimmer, @azaozz, @boonebgorges, @couturefreak, @doublesharp, @DrewAPicture, @floriansimeth, @GrahamArmfield, @HarishChaudhari, @helen, @ipm-frommen, @iseulde, @joemcgill, @jorbin, @kopepasah, @kraftbj, @Michael-Arestad, @MikeHansenMe, @miqrogroove, @MomDad, @morganestes, @nacin, @ocean90, @kadamwhite, @oso96_2000, @pento, @postpostmodern, @rodrigosprimo, @scribu, @SergeyBiryukov, @sevenspark, @solarissmoke, @stephdau, @swissspidy, @valendesigns, @welcher, @westonruter, and @wonderboymusic for their contributions!

     
  • Drew Jaynes 12:00 pm on February 25, 2015 Permalink
    Tags: ,   

    Dev Chat Agenda, February 25, 2015 

    Here’s the agenda for Wednesday’s Dev Chat in the #core channel on Slack.

    Time/Date: February 25 2015 21:00 UTC:

    1. Feature Plugins – The Customizer Theme Switcher and Press This were merged into core on Tuesday. Please test and create new tickets for any issues you find
    2. Component Updates
      1. Accessibility – @afercia
      2. Mobile – @ryan
      3. Components – All the news that is news with @nacin
    3. Enhancements Deadline Reminder – Beta 1 is 2 1/2 weeks away. Need to start wrapping up enhancements.
    4. Open Floor – Looking for dev feedback on a ticket? Use this part of the meeting to let us know
     
  • Morgan Estes 9:50 pm on February 19, 2015 Permalink
    Tags: ,   

    WordPress Core Weekly 

    Hello everyone, and welcome to this installment of the WP Weekly Roundup! This edition covers February 11th, 2015 [31411] through February 18h, 2015 [31478].

    Right at the top of the list: the release of 4.1.1 rolled out Wednesday. You can read the changelog for full details, but here’s the overview.

    WordPress 4.1.1

    • Tag 4.1.1 [31478]
    • Bump $tinymce_version in the 4.1 branch. [31477]
    • Remove errant string. [31475]
    • About: Add changelog for 4.1.1. [31474]
    • Add SVN eol-style = native where missing. [31471]
    • Add eol-style property and normalize EOLs. [31470]
    • Bump 4.1.1 version numbers & dates. [31431]

    Media

    • Revert [31198] from the 4.1 branch, as it is an incomplete fix that introduces more problems than the tiny issue it was attempting to solve. [31468] #30725
    • Don’t try to read a non-existent Exif:Title tag in wp_read_image_metadata(), as it’s not a part of the Exif standard. [31462] #31043
    • Fix the display of Audio and Video in the Media Library when using IE8 and below. [31444] #31058
    • Prevent IE9 and lower displaying the download file dialogue when attempting to upload using the html4 Plupload handler. [31429] [31430] #31037

    TinyMCE

    • Fire nodeChanged when an embedded iframe is resized so we can adjust the editor height and other UI components. Props iseulde, [31466] #30646
    • Ensure the image toolbar stays visible when the image is much wider than the editor. Merges [31362] to the 4.1 branch. [31437] #30696
    • Select the iframe element by id. Needed as some browser extensions insert extra elements in the page. Merges [31180] to the 4.1 branch. [31436] #30785

    Bundled Themes

    • Update CSS rules for .screen-reader-text to be consistent with current accessibility guidelines. [31464] #31279
    • Remove URLs from reset credits. Closes #30764. [31454] #30764
    • Replace array_shift() with current() for performance. [31453] #31260

    Internals

    • Add inline documentation to clarify the reasoning behind the various conditions that control how WP is loaded. [31463] #30935
    • Improve ‘orderby’ syntax for WP_Comment_Query[31467] #31045, #30478, #31265
    • Replace hardcoded usage of comment-page with the comment pagination base. [31459] #18084
    • Respect ‘default_option’ filters during early sanity checks in add_option() and update_option()[31473] #31047
    • Add $expiration as a parameter to the pre_set_transient_{$transient}filter. [31414] #30576
    • Restore PHP 5.2 to Travis CI. [31472] #31244
    • Return a WP_Error if an empty name is provided when registering a post type. [31450] #31134
    • Posts list table: Add a filter to disable the months dropdown. [31438] #30254
    • In paginate_links(), don’t override custom format arguments when setting up default ‘add_args’. [31433] #30831
    • Avoid a PHP Warning when add_args is passed as false to paginate_links(). [31432] #30831

    Customize

    • Remove margin for hidden controls. [31460] #31330
    • Don’t focus new widgets if they are added programmatically. [31428] #31295
    • Escape Customizer links in the admin menu. Fix usage of add_query_arg(). [31427] #30952
    • Restore showing a login form inside the previewer if an user is logged out. Broken since [31370]. [31421] #31294
    • Widgets: Add return param for widgets admin page to the “Manage in Customizer” link. [31420] #30888
    • Improve [31252] to show the move-widget buttons only if there is more than one rendered sidebar. [31419] #30690

    Query

    • More careful type conversion in WP_Query is_*() methods. [31458] #24674
    • Add tests for some of WP_Query‘s sticky post logic. [31439] #27282

    Toolbar

    • Remove title attributes from ‘About WordPress’, ‘Add New’, and ‘My Account’ items. [31456] #31324
    • Add a label for search field on front-end. [31455] #31323
    • Use require_once() to prevent a fatal error if _wp_admin_bar_init() is called twice. [31411] #31287

    General

    • Provide a secondary sort order for wp_get_archives() when type=postbypost[31452] #30480
    • Update the default admin color scheme for more unity and refinement.
      This removes the red channel from blues and cools the grays a bit for a more cohesive and purposeful color scheme. [31422] #31234

    Taxonomy

    • Return a WP_Error if an empty name is provided when registering a taxonomy. [31449] #31135
    • Split shared taxonomy terms on term update.
      When updating an existing taxonomy term that shares its term_id with another term, we generate a new row in wp_terms and associate the updated term_taxonomy_id with the new term. This separates the terms, such that updating the name of one term does not change the name of any others. #5809

    Networks and Sites

    • Use get_admin_url() to get the correct My Sites URL without calling switch_to_blog() directly. [31448] #31314
    • Create the My Sites URL in the context of a user’s primary site.
      Switch to the user’s primary (or active) site before creating the My Sites URL. This previously linked to the current site’s dashboard, even if a user was not a member of that site. [31445] #31314

    Administration

    • Use correct default values for some admin template functions. [31446] #31308
    • Rename unused argument and remove obsolete global in iframe_header(). [31443] #31309
    • _list_meta_row() should always return a string. [31442] #31310
    • Terminate JS statements in two admin files. [31440] #31311
    • Move the (recently added) .notice admin notices below the first H2, same as the .updated and .error notices. Merges [31023] to the 4.1 branch. [31434] #30885
    • Admin menu: Ensure top level menu item keeps hover color when hovering over or focusing on the submenu. [31424] #31275
    • Introduce a logout_redirect filter so the redirect destination can be changed when a user logs out. [31417] #27617

    Embeds

    • Use RegEx instead of DOMDocumentwhen protecting <pre> tags in WP_oEmbed::_strip_newlines(). It is incredibly difficult to maintain character encoding and whitespace when parsing viaDOMDocument. [31423] #31214
    • After [31415], make sure str_replace() only occurs once for each matched tag to avoid overwriting until <pre>s. [31416] #31214
    • Protect <pre> tags when parsing oEmbed responses in WP_oEmbed::_strip_newlines() in DOMDocument is available. [31415] #31214
    • oEmbed discovery fails on encoded link URLs: decode HTML chars in the HTML-encoded URLs that are returned. [31413] #31213

    Dev Chat Notes

    The merge period for Feature Plugins has opened. The two candidates, Customizer Theme Switcher and the revamped Press This were both approved and will be “shepherded” in over the next week.

    Also discussed were the possible switch in build tools from CSSJanus to RTLCSS (#31332), using the button element for buttons (instead of <a href="#">) and recruiting release leads for 4.3 and 4.4, with a reminder that this isn’t necessarily a developer position.

    Yeah, so, the leads are already thinking about who might lead 4.3 and 4.4. The goal was always to announce these ahead of time, and hopefully see overlap with releases, but if nothing else, the release lead for next major +n can be looking at feature plugins, tracking them, pushing them, etc.

    With 4.3 starting development in less than 3 months, now would be the time to throw your hat into the ring. I think, ideally, there is an announcement before 4.2 hits beta. This wouldn’t be about doing nothing for the next 3 months, but already getting started in terms of laying the groundwork.

    If you are interested in leading a release in 2015, now would be the time to say something. Same if you are interested in helping to lead a release in 2015.

    Tickets needing a look

    These tickets were specifically mentioned by developers looking for assistance or an extra set of eyes:

    • #31218: nav-menu.js menu item added event
    • #27282: WP_Query returns more results when there are sticky posts
    • #17817: do_action/apply_filters/etc. recursion on same filter kills underlying call
    • #31332: RTL CSS generation: Switch from CSSJanus to RTLCSS
    • #23367: Remove message parameters from admin URl’s in the browser address bar
    • #31233: Dismissable admin notices
    • #31251: Show username in wp_dropdown_users when deleting users, not display name
    • #22768: EXIF/IPTC captions should populate caption/post_excerpt on upload, not description/post_content

    Thanks to @adamsilverstein, @afercia, @azaozz, @barrykooij, @boonebgorges, @boonebgorges, @clifgriffin, @cweiske, @danielbachhuber, @dd32, @dlh, @DrewAPicture, @GregLone, @helen, @herbmillerjr, @hugobaeta, @Idealien, @ipm-frommen, @iseulde, @jdgrimes, @jeremyfelt, @johnbillio, @johnbillion, @johnjamesjacoby, @jorbin, @lancewillett, @mattheweppelsheimer, @mboynes, @melchoyce, @mgibbs18, @MikeHansenM, @morganestes, @nacin, @netweb, @norcross, @nunomorgadinho, @obenland, @ocean90, @r-a-y, @SergeyBiryukov, @simonwheatley, @sippis, @stevehickeydesign, @tywayne, @tyxla, @webord, @westonruter, and @wonderboymusic for their contributions!

     
  • Jeremy Felt 5:50 am on February 18, 2015 Permalink
    Tags:   

    Multisite Objective: Defining Network Types 

    We’ve been having a rolling conversation about the concept of different network types for a long while. @nacin covered it as part of the potential roadmap for multisite in 2013 and described two sections—“Registration and Open Networks” and “Trusting Users in a Closed Network”—that describe the overall intent of this conversation pretty well.

    At WCSF this year, we covered the topic a few times during the contributor days, trying to really nail down what “open” and “closed” meant or if “trusted” and “untrusted” were better words. We even committed wp_is_trusted_network() to core for about a month in #30145 as a guess at starting to figure out what it should do. 🙂

    This repeating conversation has usually started as one of confusion. We have different meanings for open/closed, so we can’t use that. We have different meanings for trusted/untrusted, so we can’t use that.

    How do we figure out what we’re talking about?

    While all of this discussion has been happening, we’ve been exploring the different ways of phrasing things. A use case discussion for network types on GitHub. A breakdown of open/closed network functionality. A categorization of every is_multisite() use in core.

    During our office hours today, we made some great progress.

    We’re going to skip our attempts at binary classification. The future we’re looking at is one in which installing a network is the choice of a pre-configured network type.

    Long winded intro aside—this thread you are reading is a place to have this discussion. We need to work out answers to a few questions so that we can move forward:

    • What network types are there?
    • Which of these should be pre-configured in core?
    • What are possible ways of managing these network types?
    • What kind of experience can we introduce during network installation that makes this simple.

    I’d encourage you to read some of the previous discussions linked above, especially today’s #core-multisite logs, and then refocus the discussion in the comments here. This will be our main topic in next week’s multisite office hours, so brainstorm away! The more input the better.

     
    • John James Jacoby 1:39 pm on February 18, 2015 Permalink | Log in to Reply

      Thanks for getting this started Jeremy.

      As far as network types go, the original (and current) vision for WordPress multisite was for it to easily enable anyone to create and manage a network of blogs, for blogging. The more modern use case for WordPress multisite is as a utility for managing multiple sites using one installation, sites that may-or-may-not be related to one-another. There are a few assumptions we can make about the differences:

      • Blogging networks likely have open registration & blog creation. Utility networks likely have closed registration & blog creation.
      • Blogging networks assume an untrusted user might “own” a site. Utility networks assume a trusted staffer, employee, or client are using a site on your network.
      • Blogging networks likely limit upload space. Utility networks likely should not be limited.
      • Blogging networks likely will have very few users on each site. Utility networks likely will have several to many. (Both installations could have millions of users in general.)
      • Blogging networks may-or-may-not allow access to control plugins. Utility networks likely have plugins and themes locked down.
      • Blogging networks mean relinquishing site control to your users. Utility networks mean a trusted group is likely in control of each site, and site-administrators provide as-needed access to wp-admin areas.

      You’ll see lots of “likely” and “may-or-may-not” here. This is because most of us have architected installations and designed experiences around some common directions, but have also deviated far and away from any beaten path for anything from intranets and social networks to complete application frameworks using sites only to store and retrieve data.

      As Jeremy eluded to, what to do about multisite has been a years long thought process, and our current conclusion is approximately as follows:

      • Define at least two network “types” – one being the blogging network we currently have.
      • Define future-proof verbiage for related functionality. wp_get_network_type() and such.
      • Maybe provide constant or UI for installing multisite and picking between network types.
      • Maybe provide API for registering network types as a “package” of predetermined network and site settings.

      Another thing to consider, is if what we are talking about is a “network” type or an “installation” type. Because WordPress multisite supports multiple networks (swoon) is one of our goals to allow each network to operate with its own unique restrictions? WordPress.org is kind-of like this now, with several different networks running on global user tables. I *think* the answer to this question is “yes” but I also think it’s a decision worth being more confident about.

      • Jeremy Felt 4:02 am on February 24, 2015 Permalink | Log in to Reply

        Blogging networks mean relinquishing site control to your users. Utility networks mean a trusted group is likely in control of each site, and site-administrators provide as-needed access to wp-admin areas.

        This is an interesting duality of sorts. I agree with this statement, though I’ll also point out that users of a utility network will often have a higher expectation of immediate capability than users of a blogging network. So, relinquishing mediated control of the full site (blogging network) and allowing full control of a mediated site (utility network). Maybe?

        Define at least two network “types” – one being the blogging network we currently have.

        My current thought is that 3 would be a perfect number. 🙂

        Maybe provide constant or UI for installing multisite and picking between network types.

        Tools -> Network Setup -> “Select Network Type”, done.

        Another thing to consider, is if what we are talking about is a “network” type or an “installation” type.

        I think network type is the way forward. At least in my multi-network use case, I have a handful of different types I could define at the moment.

    • John James Jacoby 1:56 pm on February 18, 2015 Permalink | Log in to Reply

      Functionally, this could start off using some global array of keys and values used to filter pre_option_ and pre_site_ calls the way bbPress currently allows.

      This gives us the opportunity to write some code as a plugin first, touch options directly, and create some predefined groups of them to later turn into “network types.” This exercise should help us determine what type of interface would be most useful for the type of user who will most likely be interacting with it.

      • Jeremy Felt 4:05 am on February 24, 2015 Permalink | Log in to Reply

        Your mention of wp_get_network_type() above brought me to thinking about a series of network_supports() checks throughout core that checked the current network type for its support of a concept.

        I like the idea of hooking in early with a plugin to test the concepts out.

    • Ipstenu (Mika Epstein) 4:23 pm on February 18, 2015 Permalink | Log in to Reply

      What network types are there?

      Today we have a loosely connected set of blogs that share a common potential user base, common possible plugins and themes.

      The ones I see people wanting the most (excluding the ‘shared media/posts’ which I think is out of scope, and yes that includes a multi-network-store site) would be as follows.

      • ‘Traditional’ Network – One super admin, each site admin has all the access they have today. They can run any plugin that’s installed and any theme that’s active. This is what we have today.
      • Blog Network – Same as traditional, starts with allowing new users AND users to create blogs. Sites would be unrelated. This is the WPCOM option 🙂
      • Sole Admin Network – One person running multiple different sites. Generally they have to log in as the super-admin all the time to get things done. Functionally this may be the same as traditional, but all registration etc would be locked down.
      • Company/School Network – Each site has it’s own admin, but the admin has limited rights. They cannot mess with plugins that may not be network activated (think plugins acting like themes do – network activated or available on a per-site basis).
      • Private ‘Family’ Network – Less restrictive than the company site, you make a network for your group of people and you maintain it, but you have closed registrations and limit things.
    • Mike Schinkel 4:24 pm on February 18, 2015 Permalink | Log in to Reply

      Following up on what Ipstenu said on Guithub, it seems that all these presumed “Network Types” are simply a collection of potential (programmer level) configuration options (so as not to violate the “Decisions, not Options” principle.) If we looked at all potential types, envisioned and not yet envisioned, we would come up with a finite list of (new?) configuration options.

      It would seem the first step then would be to identify and document all these potential configuration options at an atomic level. From there we could then “map” Network Types to their associated configuration settings.

      Even better, Network Types could then be registered just like how Post Types, Post Statuses and Taxonomies are registered which would make missing out on an important use-case in core much less problematic.

      With this proposed approach everyone both pro and con network types can get their cake and get to eat it too.

      • Gabriel Mays 9:37 pm on February 18, 2015 Permalink | Log in to Reply

        I agree. We could spend a lot of time thinking about different permutations that could exist, we’re better off just making it flexible.

        Each network type is just a collection of options with their corresponding values that make that network type unique. So as new popular use cases arise it’d be fairly simple to add new ones or let people add their own (i.e. import network type via XML).

      • Fabien Quatravaux 8:37 am on February 19, 2015 Permalink | Log in to Reply

        That’s a really great idea ! Let’s put power into the right hands (the developer ones).

      • MartyThornley 4:38 pm on February 20, 2015 Permalink | Log in to Reply

        You beat me to it! +100 for this. Core could define a few then plugins could create new types or option sets. I think of it as comparable to user roles and capabilities. There are network types which are like roles and options which are basically defining what that type is capable of.

      • Jeremy Felt 4:12 am on February 24, 2015 Permalink | Log in to Reply

        I think the concept of “registering” network types rather than defining all of the possible permutations is appropriate. We can decide on 2 or 3 very specific configurations that meet the “blogging network” vs “utility network” vs …. and then provide an easy way to filter that list of network types—through register_network_type() or something similar.

    • Mike Schinkel 4:25 pm on February 18, 2015 Permalink | Log in to Reply

      Another Network Type that I’ve seen is what I’d call the “Shared Server” network type. This is a network of completely unrelated sites, often developed by completely different people, but hosted on a single multisite because of a misguided opinion that this makes sense.

      I do not advocate this use-case and have even actively fought against it, but it seems there are business consulting firms recommending to IT shops at at least one Fortune 100 company the use of Multisite as a way to have one server host multiple WP sites in part so they can then bill out for IT services to each department that needs a site (in this particular case all sites were intranet sites.)

      I have also seen numerous people in forums, on mailing lists and at meetups advocating the use of a single Multisite for hosting all their unrelated clients sites. And I can only assume it is because they don’t understand the pros and cons of multisite. Ugh.

      So I would either like to see this made easier (i.e. by being able to export and elsewhere import a single site’s data and being able to have plugin that are limited to one site) or better yet, make changes in core that somehow make this use-case impossible in future versions and thus force new installations to use multiple single sites and an admin console instead of one multisite.

      • Jeremy Felt 4:18 am on February 24, 2015 Permalink | Log in to Reply

        While I agree generally that this is a misguided use of multisite, there may still be validity in helping to define boundaries for these types of networks. I don’t think it’s a network type that we should account for by default, but it could be cool to see someone create a plugin that helps to nail down problem areas.

        able to have plugin that are limited to one site

        This does need to happen. A+++++ I would like to see #14569 in 2015. 🙂

    • Mike Schinkel 4:29 pm on February 18, 2015 Permalink | Log in to Reply

      Regarding the “Social Network” type proposed by JJJ on GitHub, if we ignore that Multisite is a requirement for BuddyPress then nothing about a social network actually requires Multisite (other than potentially allowing them their own blog.) Thus it would be great is there is anything added that is not Multisite-specific to support the Social Network use-case would also be applied to Single site.

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

      It seems we need a starter wizard that covers the most basic options when the user activates a new multisite. Options that also later can be adjusted.

    • Gabriel Mays 4:54 pm on February 18, 2015 Permalink | Log in to Reply

      For the starter wizard, here’s an idea of what it might look like along with the network settings (originally posted in slack): http://imgur.com/PCnU4rZ

      Idea with tabs is that it’s easy to add more settings in the future, i.e. a domain mapping tab, etc.

      Where the network types are just “bundles” of individual options. But I def think user reg settings and site reg settings should be separated, they’re combined now which is a bit confusing/limiting.

    • Gabriel Mays 4:57 pm on February 18, 2015 Permalink | Log in to Reply

      Regarding network types, I guess it comes down to how different are the network types from each other? I think we should only add a new network type if they are different enough that we believe it’d be complicated for a user to select the options pertaining to that particular type. If we don’t filter then in some way we’ll end up with too many.

      Additionally, just like the admin color schemes plugin there’s nothing preventing people from creating their own network types and letting others use them.

      • Ipstenu (Mika Epstein) 8:44 pm on February 18, 2015 Permalink | Log in to Reply

        In my head, the ‘types’ would pre-fill certain options. So for the wizard you’d pick what you want from the pre-defined ones, or click on ‘customize’ and be a wizard yourself. Or an elf.

        • Gabriel Mays 9:29 pm on February 18, 2015 Permalink | Log in to Reply

          I agree, but why would the “customize” option have to be on the wizard? If the user dismisses the wizard couldn’t we just assume they want to roll their own?

          And the “network type choice isn’t final, it’s just a set of options, which they can change anytime or “reset” to see the wizard (ahem, elf) again. And whether or not they choose a network type I think we expect them to customize at least something, whether it’s the network title, upload quota, welcome message, etc.

          As I understand it, all “customize” means is that at some point they decide to change a setting instead of using the install or network type defaults, which I believe is inevitable. The goal of the network types wizard is just to get them 80% of the way without researching what every option does, right?

          To make it more intuitive we could just call it “Multisite Quick Start” or something since they’re just bundles of recommended settings.

          • Ipstenu (Mika Epstein) 9:39 pm on February 18, 2015 Permalink | Log in to Reply

            Customize clicks you out of the wizard.

            As much as I hate to say it, I worry because of the NUX headaches with the Welcome Panel. Do you know how many people leave it alone? We need to make sure it’s ‘used’ or dismissed, and making an alternate to pick-a-setting may help.

        • Jeremy Felt 4:30 am on February 24, 2015 Permalink | Log in to Reply

          I’m wary of having a customizer wizard of sorts. I can see several plugins springing up to allow other network types to be registered, but it would be nice to avoid managing a lot of options.

    • Frank 9:38 pm on February 18, 2015 Permalink | Log in to Reply

      I see much benefits of the network types for different scenarios on real world examples, there I develop, create for customers. My idea is, that we not get a network type solution with settings ui and confining possibilities.
      I think a small solution like post types, taxonomies to register a custom network type is much easier to create and useful for a lot of scenarios.
      I think is not helpful for the default multisite to have much more settings, ui elements. Network types is sure a helpful type for custom solutions, in the first way for developers. I would see this feature in the core, but not visible on default and usable via the register network type functionality, like post type – no options, decisions.

      • Jeremy Felt 4:31 am on February 24, 2015 Permalink | Log in to Reply

        Completely agree! I think we can decide on a few defined network types and provide ways for plugins to register new types.

    • rosyteddy 2:21 am on February 19, 2015 Permalink | Log in to Reply

      “‘Traditional’ Network – One super admin, each site admin has all the access they have today. They can run any plugin that’s installed and any theme that’s active. This is what we have today.”

      This is so true and it holds good. And is so much needed and so much used.
      However, we need one more : one network plugin or network feature that lets any wordpress site using wordpress downloadable from wordpress.org do the following :
      1) login to wordpress site 1 with wordpress site 2 credentials, provided the sites have mutually enabled this plugin to be ON. (Drupal used to have this type of plugin)
      2) we can follow or befriend anyone on wordpress site1 even if I am a member of wordpress2
      for example:
      friends of userA@worpresssite1 : userA@worpresssite2, userA@worpresssite3, userA@worpresssite4…
      You get the idea
      3) userA@worpresssite1 can comment on a blogpost by userA@worpresssite2 on his site as userA@worpresssite1
      http://gnu.io/social/ diaspora and others already let you do this, same thing can be done if you have logged in using wordpress.com login and other sites also use wordpress.com login
      Just extend that from wordpress.com login to any wordpress site login
      4) Same about “likes”
      For example: This blog post has been liked by userA@worpresssite1, userA@worpresssite2

      Note: userA@worpresssite1 and userA@worpresssite2 are completely different users – the similarity in name is just coincedental 🙂

      If this can be done it will be a potentially useful and popular network, even larger than FB but only if implemented right now without the years of delay that Buddypress has done.

    • Fabien Quatravaux 9:23 am on February 19, 2015 Permalink | Log in to Reply

      I agree with @bueltge and @gmays : what I like the most in WordPress is that the admin UI is very simple (not so many options, all options are easily understandable), and real power is hidden for non-developers. For example, there is not UI to create new Post Types, taxonomies, or shortcodes, but that’s what make WordPress so flexible.

      We could write an infinite list of different network types and still missing some cases. So let’s just list the discrete options that should be available. Later, we could chose 3 or 4 network types to be present in core to ease the installation of popular network types.

      Here is my list of options :
      1. Allow new users to register (already available)
      2. Moderate new user registration requests
      3. Allow approved user to create a new site (already available)
      4. Moderate new site creation (with the option to automatically allow site creation for some user, the same way comments are moderated)
      5. Allow site admins to manage their site users (already available)
      6. Each theme can be provided to each site independently (already available)
      7. Each plugin can be provided to each site independently
      8. Site access restriction : public OR only to logged-in users OR only to site admin OR completely offline OR in construction (today only public OR completely offline options exist, and they are managed by super-admin not by the site admin)
      9. Add some filters to customize the `wp-admin/network/site-info.php` page : adding some site options, adding or removing tabs, …
      10. Allow access to admin area for each role (typical use case : subscribers will be able to log-in but won’t have access to admin area)

      And here is what the API could look like:

      {{{
      register_network_type( ”,
      array(
      ‘allow_new_users’ => ‘always’, // always, moderate or never
      ‘allow_new_sites’ => ‘always’, // always, moderate or never
      ‘admins_can_manage_users’ => true,
      ‘wp_admin_access’ => array( // list of roles
      ‘super-admin’,
      ‘administrator’,
      ‘editor’,
      ‘author’,
      ),
      ‘admin_menu’ => array( // list of default available menus
      ‘themes’ => array(‘twentyfifteen’), // list of default available themes
      ‘plugins’ => array(‘akismet’), // list of default available plugins
      ),
      ‘sites_options’ => array( // list of options available in the sites admin UI
      array(
      ‘label’ => ‘A site option’,
      ‘type’ => ‘checkbox’,
      ‘default’ => ‘checked’,
      // this part could be similar to the settings API ?
      ),
      ),
      )
      );
      }}}

    • faospark 10:18 am on February 19, 2015 Permalink | Log in to Reply

      “What network types are there? ”

      -Maybe we should start from what we have.
      In the network settings page, particularly the registration settings. right from there we can start to see of what is an example of Open Network and a Closed Network.
      the first two options in the registrations settings (i.e. disabled registrations and user accounts may be signed up ) essentially constitutes an example of a Closed Network while the two succeeding ones constitutes (i.e. users may sign up new sites, sites & user accounts can be Sign uped.)an Open Network.

      For the purpose of discussion i will refer to the default blog on multisite as the parent network and subdomains or sub directories as child sites or sibling sites.

      Closed Network Examples: Organizational Type/ Collaborative Type and Task Oriented Type
      In a Closed Network. what essentially fundamental to it is that everything that is happening is intrinsically from the Parent Network and the identity of the child sites is almost always attached to the Parent Network or its Sibling sites. In real world example the best way for you to visualize this is how an Organization with Chapters work. the chapters almost always has to collaborate with the parent org. will call this example as Organizational Type of Network or Collaborative Type.
      Furthermore. Child sites of Closed network can also Task oriented. where in by which a child site performs a very specific task. Examples are customer support on a sub domain,general forums on sub-domain. user account management on a subdomain. I would call this example as Task Oriented Type of Network
      The key thing about Closed Networks is that the creation of child sites is influenced by factors intrinsic to the parent network and the maturation of child sites does not necessitate of it being mapped on own domain.

      Open Network: Open Showcase and Moderated Showcase
      in comparison Closed Networks, in an Open Network, the creation of child sites is more influenced by an external factor. The main function of the parent network is a showcase site of its children sites.
      its only a matter whether it would moderated or free brawl. in an open Network, The maturation of child sites is very likely and child sites is almost independent content wise from its parent network and sibling sites.

      Summary :
      2 main network types : 1)Open 2)Closed
      Closed Network Examples: Organizational Type/ Collaborative Type and Task Oriented Type
      Open Network: Open Showcase and Moderated Showcase

      “Which of these should be pre-configured in core?”
      -I think we already have based from what i said above , but it would be a lot better if we make multisite installs by default a closed network type;

    • joesell89 10:27 am on February 19, 2015 Permalink | Log in to Reply

      First off, I am not a developer, but I do use multisite. I thought it may be useful to just contribute how I use multisite. Just to add to the mix 🙂

      We use multisite to link websites and blogs within our company. We have a membership site a blog and an internal team website. Blog creation is closed but registration is open.

      In the future we would love it if when someone was given a role on one site and had it everywhere else on the network.

      Having a multisite network makes sense because it is easier to setup and configure a new or temporary site and many of the plugins and themes we use are shared anyway.

      Hope this point of view is helpful.

    • ivanblagdan 11:07 am on February 24, 2015 Permalink | Log in to Reply

      Im a developer on a few long term corporate multisite projects, and I’d just like to add my two cents here, even if it might be a little off track and late.
      To start off, I’d state that in my experience, multisite installations easily spiral out of control in terms of complexity. They require more effort and consideration, than in non-multisite, to corral client requests into something that doesn’t end up a mess to be maintained down the road. I’m talking about growing, long term site networks rather than a network of private blogs.

      Most of these have their blogs created by network admins, and in some cases allow user registration on specific sites for various capabilities (commenting, or uploading files, RVSPs etc.).
      Some of these networks are groups of site localizations that share 99% of configuration.

      I think that the use case for preset network options is rather weak and that a certain level of technical ability is to be expected from the person setting up/running the network. I’d rather see this get more flexible, but from the ground up on a API level.

      A few weak spots I encounter:

      • Media asset management, sharing and editorial permissions among specific sites.
      • General user and permission management
      • Configuration management of various sites.
      • Content/data exchange between sites

      All of these are certainly possible, and to a degree mitigated by a few great plugins, but in all honestly it always feels like hacking around something, not actually extending it.
      I feel much of the discussion here should trickle down to API requirements and modularization of these underlying mechanisms and allow flexibility to grow from there, in form of either replacing them by third parties completely or by plugin extensions.

      I also feel that looking at the code, this duality of WordPress in terms of blog/multisite is really apparent and disruptive to the overall architecture, and it would be made worse by introducing another fork in this code path with things like wp_get_network_type().

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