Agenda, Slack log.
Editor (#)
@azaozz, @iseulde
Want to concentrate on mobile improvements, especially the toolbar, other buttons around the editor, and ajax saving. @iseulde will publish a list of all items they’ll work on. We will need to test on many mobile devices in couple of weeks, so please join them in the #core-editor Slack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/. channel where they’ll also have weekly chats on Tuesday, 20:00 UTC.
Admin (and super admin) UI User interface (#)
@helen
- Better responsive list tables – this involves some PHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher-side API An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways. changes as well as UI work. The base thought here is that a narrow screened device is also often a mobile device, which may have limited bandwidth. That’s exactly the situation in which you don’t want to have to load more pages to see important information, and our current strategy of truncation is in direct conflict A conflict occurs when a patch changes code that was modified after the patch was created. These patches are considered stale, and will require a refresh of the changes before it can be applied, or the conflicts will need to be resolved. with that.
- Getting rid of
media-new.php and exploring what a better list table+upload experience might be, both for JS JavaScript, a web scripting language typically executed in the browser. Often used for advanced user interfaces and behaviors. and no-JS.
- Getting started on the admin CSS Cascading Style Sheets. clean up roadmap @helen will be spinning up a kick off for that as well.
- Screen-by-screen sweep on touch and small screen devices, grabbing low-hanging fruit like “the spacing is off here” or “font sizes are inconsistent”.
UI chats are going to be spun up again to further this effort, stay tuned for when and where.
Network (versus site, blog) Admin UI (#)
@jeremyfelt
- Piggyback on other Admin UI improvements. The network admin often seems quite a bit behind everything else. Responsive list tables would be fantastic.
- Start looking at network admin screens on mobile. There are many places where workflow can be reimagined. @boren has shared some great thoughts previously, let’s have more conversation around that.
- It may be possible to start working on what a future site switcher would look like. Especially on mobile, providing context can be tough when working on a network of many sites.
- #22383-core and #31240-core for nicer ways of creating and editing sites. Might lead to some domain/path validation, which could be useful elsewhere and help address older tickets.
- Under the hood, significant progress on
WP_Network, WP_Site, WP_Site_Query, and maybe WP_Network_Query would be nice.
@jeremyfelt will come up with a consumable list of 4.3 priorities by next week. Regular multisite Used to describe a WordPress installation with a network of multiple blogs, grouped by sites. This installation type has shared users tables, and creates separate database tables for each blog (wp_posts becomes wp_0_posts). See also network, blog, site office hours are Tuesday, 20:00 UTC in #core-multisite.
Partial Refresh (#)
@westonruter
This greatly improves performance of previewing changes in the Customizer Tool built into WordPress core that hooks into most modern themes. You can use it to preview and modify many of your site’s appearance settings. for non-postMessage transport settings (JS-applied changes) by just refreshing the area of the page that has been changed. As such it eliminates some of the need to do postMessage in the first place, while also reducing the amount of duplicated logic that would have to be implemented in JS to mirror what is being done in PHP. This resurrects some code from the old Widget A WordPress Widget is a small block that performs a specific function. You can add these widgets in sidebars also known as widget-ready areas on your web page. WordPress widgets were originally created to provide a simple and easy-to-use way of giving design and structure control of the WordPress theme to the user. Customizer feature plugin A plugin that was created with the intention of eventually being proposed for inclusion in WordPress Core. See Features as Plugins. developed for 3.9. Writeup and feature plugin are available at https://wordpress.org/plugins/customize-partial-refresh/
Customizer Transactions (#)
@westonruter
A low-level re-architecture of the Customizer plumbing that has a lot of side benefits and bugfixes, introducing some exciting possibilities for future feature plugins like scheduled settings, setting revisions The WordPress revisions system stores a record of each saved draft or published update. The revision system allows you to see what changes were made in each revision by dragging a slider (or using the Next/Previous buttons). The display indicates what has changed in each revision., and drafted/pending settings. Partial Refresh is a dependency for this. Pull request available, but needs refresh. See proposal at https://make.wordpress.org/core/2015/01/26/customizer-transactions-proposal/. This was previously worked on for 4.2.
Customizer office hours are on Friday, 18:00 UTC in #core-customize.
Better Passwords (#)
@markjaquith
- Make “user chooses own password” non-default. We can generate better passwords than they can, and writing as secure password down on a sticky note is in general more secure than memorizing a weak password. So the default should be “give me a new password”, and “let me choose” should be something they specifically choose.
- When the use is generating their own password, we should encourage strong passwords more forcefully. Right now we just have a meter. We don’t tell them why it’s “weak”. We don’t tell them how to fix that. Simple feedback like “too short — add more characters!”, “Try adding some numbers and symbols!”. Not only that, we could actually make the addition for them. Show them their password attempt with some additions that would make it better.
- In order to help the user modify their chosen password, we need it to be visible. If they click “hide”, they can input it hidden for an “over shoulder” situation. Also gets rid of the annoying “enter twice” thing.
- Let’s not send passwords via e-mail anymore, it’s insecure. We’re not getting around “full access to e-mail means you can reset”, but we can stop passwords from sitting around in e-mail accounts forever.
Discussions will happen in #core-passwords. Time and day for regular meetings TBA.
Open Floor (#)
@jorbin has set up a Call for Tickets. Please feel free to add the tickets you want to work in the comments there.
#4-3, #meeting
