Component Maintainers in 5.3

On the heels of APAC Triage and Bug Scrub Sessions and Bug Scrub Schedule for 5.3, thanks @pento and @davidbaumwald, I’d like to propose something a little bit different.

The WordPress 5.3 release is shaping up to be substantial. There are tons of fixes and improvements in GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/, for both users and developers. Even if 5.3 only included the Gutenberg update, it would have been a very nice, very desirable upgrade.

There is more to this release! Currently there are 632 tickets on the 5.3 milestone on TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress., both open and closed. A few smaller new features and user facing enhancements are in the works, and a lot of bugfixes and under-the-hood improvements are coming up or already done.

I’d like to propose that component maintainers take more “charge” of the tickets in their components. There is a general expectation that if you moved a ticketticket Created for both bug reports and feature development on the bug tracker. to a milestone you are the “lead” for that ticket and will see it through to completion, or move it to a future milestone if not feasible. But that shouldn’t stop component maintainers from helping to keep those tickets moving.

With the scheduled bugbug A bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority. scrubs, and the per-component bug scrubs that usually happen at the components’ meetings, the 329 open tickets aren’t that big of a mountain. 

The 5.3 Challenge

During the next few weeks (by betaBeta A pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process.-1 scheduled for 23 September) join me in making sure all 5.3 tickets in our components will either be resolved or moved to a future milestone. And if there are any hurdles leave a comment on the ticket briefly outlining the difficulties and include a resolution timeline.

It would also be helpful if during this time all component maintainers do a short, concise update about their component on the weekly coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. dev chats. These updates would typically include the number of open 5.3 tickets and whether there are any difficulties with any of them. This will help people know where help is most needed, especially any newer contributors who are having trouble deciding where to spend their time.

Also, we have a Docs Wrangler for our release! After 5.3.0-beta-1 is out, it would be great if component maintainers review all changes to their component (if not already reviewed), then, if possible, help @justinahinon with writing or editing dev. notes. There are currently 301 fixes and enhancements committed to the 5.3 milestone and they will need documentation.

The proposed change for component maintainers is to act early, before beta-1, and to regularly make updates and bring any difficulties to the core dev chat.

#5-3, #bug-scrub, #components, #core

Improve processing of uploaded images

As mentioned in dev chat on May 15 there are quite a few “stalled” tickets on TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. dealing with image processing/resizing after uploading:

All of these, and more, can be “unblocked” by: Save progress of intermediate image creation after upload #40439.

Fixing this will also enable “refreshing” of the way we do responsive images, and will enable improvements in how we generally work with images in the blockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. editor. Then we will be able to enhance the Image block and make it “just work” regardless of the context, see Enhancement: images handling and more importantly https://github.com/WordPress/gutenberg/issues/6177#issuecomment-442953527.

In short: fixing the above tickets will greatly improve user experience especially when uploading large images or the server is slow/busy. It will also open the way for enhancing how we work with images in the editor, and let us show better fitting images on the front-end.

#media, #upload

Roadmap: tools for GDPR compliance

This roadmap is for adding privacy tools to coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress.. These tools will help site owners comply with the GDPR and other privacy laws and requirements.

Main tasks

I. Add tools for creating a privacy policy

The idea is to have a “special” page for the privacy policy, #43435 (initial version of this is already committed), and #43491. The site owners are able to select an existing page or create a new one. There will be wp_get_privacy_policy_page() helper functions for use in themes, etc.

Another idea is to have a “postbox” shown when editing the policy page. All plugins that collect personal data or set cookies can output some concise information about what they collect and store and why. This information should be phrased for inclusion in the site’s privacy policy.

Core will also contain text that the site owners can use to create their policies. The text will be used as the default privacy policy and will be inserted in the privacy policy page when a new one is created. See #43473.

II. Create guidelines for plugins on how to get GDPR compliant

This should be a chapter on privacy in the plugins handbook. Needs text.

III. Add tools to core to facilitate compliance, and privacy in general

There are several plugins that are implementing similar tools. It would be great if the pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party authors participate/contribute to core to include the base tools, so we don’t double the efforts.

These tools will require a confirmation of the email of the person that requests an action, see #43443 (first version is already committed). When a confirmed request is received, the site owner will perform the action.

This could be done automatically. However deleting and anonymizing will be non-reversible. In this case it’s better if the site owners perform the actions themselves, after additional confirmation if required.

There will be two main tools:

  • To export all personal data stored on the site (by email address or user login), see #43438, #43440, #43547, #43547.
  • To delete all personal data and anonymize published/public content (like posts, comments, etc.), see #43637.

Note that registered users (“author” and above) have access to almost all of their personal data on the User Profile screen. They also have access to all posts and comments they have made on the site, and can edit or delete them. Site owners should deal mostly with requests from “contributor” level users and people that have commented on the site.

Couple of tasks can be performed in core without additional tools. For example a registered user’s account can be deleted and all of their posts can either be deleted or reassigned to another (already created) user account. This is sufficient for anonymizing a user account if there are no plugins that store private user data outside user_meta. Also, admins can search for and delete a specific user’s comments.

However having a specialized tools will enable plugins to hook into the performed actions and do their share. This is critical as many of the top 100 plugins seem to store at least some private user data.

IV. Add documentation/help for site owners on how to use these tools

The documentation should be on the new Tools => Privacy screen. Alternatively we can add only a very brief explanation and link(s) to WordPress.orgWordPress.org The community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://wordpress.org/ with more extended help. Needs text.

All GDPR related tickets can be accessed here: https://core.trac.wordpress.org/query?status=!closed&keywords=~gdpr

#gdpr-compliance, #roadmap

Proposed roadmap: Tools for GDPR compliance

This is a proposed roadmap for adding privacy tools to coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress.. The plan is to finalize it at the next #gdpr-compliance chat in SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/..

Main goal

Add tools to help site owners comply with the GDPR and other privacy laws and requirements.

Add notices for both registered users and commenters on what data is collected in core by default, and why.

  • Shorter texts in core with links to more information. Needs text.
  • Create these “more information” pages on WordPress.orgWordPress.org The community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://wordpress.org/. Needs text.

Create some guidelines for plugins on how to get compliant.

A page (or several pages) on WordPress.org. Needs text.

Add tools to core to facilitate compliance, and privacy in general.

There are few plugins that have started implementing these tools, so we have a nice head start.

The requests to see, download and delete/anonymize private data have to be with a confirmation (double opt-in) to avoid misuse. One possible solution would be to send a token by email when a user or a commenter has requested access to or deletion/anonymization of their private data. Then they will have to submit that token as a confirmation of their request.

TBD: shall we make this process automatic or should a site owner perform the action upon receiving the confirmed request?

  • For commenters. The stored private data is emails and IP addresses, the rest is public.
    1. Dialog for requesting to see and download their private data.
      TBD: should that data also contain the public portion?
    2. Dialog for requesting deletion/anonymization of the data.
      TBD: Deletion or anonymization? Or both and let the site owner decide?
    3. Ask for consensus for storing commenter cookies. This can be a (checked) checkbox under the comments form, something like “Save my name, email and site URLURL A specific web address of a website or web page on the Internet, such as a website’s URL www.wordpress.org in my browser for next time I post a comment. More information”.
  • For registered users. All of the data stored by default is already visible in the user profile (except IP addresses if they have commented on the site), and most can be edited or deleted from there.
    1. Button for downloading their private data, including IP addresses if they have commented. Again, should that also contain the public data?
    2. Button for requesting deletion/anonymization of their account.

Add documentation/help for site owners on how to use these tools.

This should probably be another page under the Tools menu and contain short explanation of what privacy tools are available and how to use them. It could also contain the actual tools, for example an input field for anonymizing commenters by email address.

There are a few things that need clarification:

  • IP addresses may be considered personal data so they need to be deleted or anonymized. However do they need to be sent to the user when requesting to see or download their personal data? They are essentially third-party tokens used temporarily to access the Internet and the users have no control over them. Do other websites make them available?
  • Who are considered “controllers”? All admins on single install and all superadmins on multisitemultisite 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? Are admins on multisite controllers for their own site?

Please post your suggestions in comments so we can finalize the roadmap at the next #gdpr-compliance chat on Wednesday. Thanks @casiepa for helping with this!

#roadmaps

GDPR Compliance Agenda: February 14

This is the agenda for the first weekly meeting about WordPress coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. GDPR compliance on February 14, 2018 at 17:00 UTC / February 14, 2018 at 17:00 UTC in the gdpr-compliance channel on SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/..

  1. Introductions. Please introduce yourself with few words and include your field of expertise (developer, documentation specialist, project manager, lawyer, etc.).
  2. Start on a roadmap for GDPR compliance for core. There were few prerequisites identified in the gdpr-compliance channel. We'll need to have clear understanding about:
    • What is considered personal information in WordPress?
      • Emails, IP addresses.
      • Are posts and comments personal information? What about private posts?
      • Are login names personal information?
      • Anything else?
    • Who are the identifiable persons?
      • Are site owners "controllers"?
      • Are all admins site owners?
      • On multisitemultisite 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 installs, who are controllers: site admins or only the networknetwork (versus site, blog) admins?
      • Are people that post comments and don't have accounts "identifiable persons"?

As always, please suggest other agenda items in the comments.

#agenda, #gdpr-compliance

Removing SWFUpload

Development of SWFUpload stopped many years ago. It has been deprecated in coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. since WordPress 3.3 (2011) when we switched to using Plupload. Additionally the latest updates in some browsers default to disabling Flash.

It’s finally time to say Goodbye 🙂

There are several popular plugins that appear to still use SWFUpload after so many years of it being deprecated:

(For the full list see https://core.trac.wordpress.org/ticket/41752.)

If you are using one of these plugins on your site, please contact the authors and ask them to switch to Plupload. Core switched to it… 16 versions ago!

We created the list of plugins by searching the WordPress plugins directory for 'swfupload', and there are probably some “false positives”. Sorry if it includes plugins that are not using SWFUpload any more, or are including that string for other reasons.

Editor changes in 4.8

There are couple of noteworthy changes to the editor in WordPress 4.8.

A much better experience when trying to place the cursor around links. Try inserting a link, then move the cursor with the left and right arrow keys. You can clearly see when it is inside the link element and when it is before or after it.

Following the earlier announcement, support for Internet Explorer 8, 9, and 10 has been removed from the editor.

As always there have been a lot of improvements and bugbug A bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority. fixes, upstream in TinyMCE, and in core.

#4-8, #editor

Editor API changes in 4.8

A new editor APIAPI 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. was added in #35760. It makes it possible to dynamically instantiate the editor from JSJS JavaScript, a web scripting language typically executed in the browser. Often used for advanced user interfaces and behaviors.. There are two parts to it:

  • All editor related scripts and stylesheets have to be enqueued from PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher by using wp_enqueue_editor().
  • Initialization is left for the script that is adding the editor instance. It requires the textarea that will become the Text editor tab to be already created and not hidden in the DOM. Filtering of the settings is done on adding the editor instance from JS.

There are three new methods added to the wp.editor namespace:

  • wp.editor.initialize()
  • wp.editor.remove()
  • wp.editor.getContent()

(See wp-admin/js/editor.js for more info.)

The default WordPress settings are passed to the initialize() method automatically, and can be overridden by passing a settings object on initialization, similarly to using wp_editor() in PHP.

In addition there are several custom jQuery events that are fired at different stages during initialization:

  • wp-before-tinymce-init is fired before initialization and can be used to set or change any editor setting. It passes the settings object.
  • tinymce-editor-setup is fired after initialization has started but before the UIUI User interface is constructed. It passes the editor instance object.
  • tinymce-editor-init is fired when the TinyMCE instance is ready (same as the init event in TinyMCE).

Here’s an example of how to add few of the default TinyMCE buttons to the toolbar:

jQuery( document ).on( 'tinymce-editor-setup', function( event, editor ) {
	editor.settings.toolbar1 += ',alignleft,aligncenter,alignright';
});

Here is another example of how to add a custom button:

jQuery( document ).on( 'tinymce-editor-setup', function( event, editor ) {
	editor.settings.toolbar1 += ',mybutton';

	editor.addButton( 'mybutton', {
		text: 'My button2',
		icon: false,
		onclick: function () {
			editor.insertContent("It's my button!");
		}
	});
});

For more information please see the TinyMCE documentation.

Update: there were four “private event hacks” in the default imagepluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party left over from the initial TinyMCE 4.0 implementation back in WordPress 3.9. These hacks were also removed as that plugin has changed significantly in the latest TinyMCE version.

#4-8, #editor, #tinymce

Editor changes in 4.7

There are a few noteworthy changes to the editor in WordPress 4.7.

Some of the toolbar buttons have been rearranged to make them easier to access and to encourage proper use of the HTMLHTML HyperText Markup Language. The semantic scripting language primarily used for outputting content in web browsers. elements they insert.  The headings drop down is now moved to the top row, and the strike-through and horizontal rule button are moved down. This also reflects their usage.

The underline and justify buttons have been removed from the bottom row. Underlining is a bad practice as readers can confuse it with links (bad accessibilityAccessibility Accessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility)), and it does not insert a semantic element. Justifying has uneven browser implementation, and in many cases is bad for readability. Keyboard shortcuts for both will keep working.

For more information see #27159 that also has links to the discussions in SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/..

Labels for keyboard shortcuts have been added to the tooltips for buttons and inside drop downs to make them easier to discover.

As always, feedback is welcome.

Ella and Andrew

#4-7, #dev-notes, #editor, #tinymce

Editor changes in 4.6

In WordPress 4.6 TinyMCE is upgraded from version 4.3.10 to 4.4.1. There are numerous bugbug A bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority. fixes and several new features, most notably a new inline theme (changelog).

The wpview editor pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party (that is responsible for showing gallery, video, audio, and oEmbed previews) was updated to use the TinyMCE APIAPI 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. for non-editable elements. This brought some small changes and improvements in the UIUI User interface, for example “views” are draggable now. On the back-end the wp-mce-view-unbind event was removed as it doesn’t exist in the API. It was intended for cleanup/unloading but was never very reliable. If a plugin needs to unload instance dependent scripts, it can use mutation observer to monitor when the view node is deleted. See #36434 for more information.

wpview remains an experimental API, though with each iteration it is getting closer to being finalized. As an experimental API, breaking changes are expected. As always, please test your plugin now if it modifies or depends on the editor, especially if you use experimental features like wpview.

#4-6, #dev-notes, #editor, #media, #tinymce