Roadmap: tools for GDPR compliance

This roadmap is for adding privacy tools to core. 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 plugin 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.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 core. The plan is to finalize it at the next #gdpr-compliance chat in Slack.

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.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 URL 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 multisite? 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 core GDPR compliance on February 14, 2018 at 17:00 UTC / February 14, 2018 at 17:00 UTC in the gdpr-compliance channel on Slack.

  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 multisite installs, who are controllers: site admins or only the network 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 core 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 bug fixes, upstream in TinyMCE, and in core.

#4-8, #editor

Editor API changes in 4.8

A new editor API was added in #35760. It makes it possible to dynamically instantiate the editor from JS. There are two parts to it:

  • All editor related scripts and stylesheets have to be enqueued from PHP 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 UI 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 imageplugin 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 HTML 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 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 Slack.

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 bug fixes and several new features, most notably a new inline theme (changelog).

The wpview editor plugin (that is responsible for showing gallery, video, audio, and oEmbed previews) was updated to use the TinyMCE API for non-editable elements. This brought some small changes and improvements in the UI, 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

Link modal (wpLink) changes in WordPress 4.5

There is a new and improved inline links dialog in the Visual Editor, see #33301. When the users type in the URL field, it uses jQuery UI Autocomplete to search for local posts and pages.

The old modal dialog (a.k.a. wpLink) is still used for “Advanced” link options. It was simplified, the infinite scrolling bottom part was removed. Now this dialog also uses UI Autocomplete on the URL field to search for posts and pages. That makes it consistent with the inline dialog and leaves more space for plugins that want to add additional settings in it.

If your plugin uses or extends wpLink, please test it now to confirm all is working properly.

#4-5, #dev-notes, #editor

Shortcodes roadmap — clarifications

As mentioned in the initial shortcodes roadmap post, the main purpose of this roadmap is to find the best way for improving the shortcodes API and moving it forward. Currently it is slow, fragile, and attempts to handle a lot of edge cases. For this, the most important part is:

  • No shortcodes in HTML tags attributes.
  • No HTML in shortcodes attributes.

There are a few things that deserve to be clarified. Simple shortcodes are great. They are easy to understand and be typed directly by the users. Example: [gallery].

Unfortunately many plugins add complex shortcodes with many attributes and often with nested shortcodes. These are a nightmare for the users. They are not intended be typed directly and can be edited by some sort of UI. Using shortcodes to store this type of data in post_content is not a good idea. Since there is a UI for entering and editing, it would be better to use a simple shortcode to “hold the place”, and save all the data in post meta.

Many of these complex shortcodes also include HTML tags in their attributes. To keep that functionality, the second roadmap draft proposed an extended syntax that allows the shortcodes “content” (the text wrapped by [shortcode] and [/shortcode]) to be additionally separated by delimiters. That would allow for shortcode attributes to contain HTML tags that are stored in the shortcode content.

These delimiters are not intended to be typed directly by the users. They are intended for the plugins that have shortcode editing UI and cannot function without storing HTML in shortcode attributes.

At first look this makes the syntax needlessly complex. However after looking at how complex shortcodes are used now, it is relatively the same: these shortcodes cannot be typed directly and are useless without some sort of UI.

There have been questions about line breaks in shortcode content. It is possible to add support for this. However it will benefit only a very small amount of users. Since shortcodes “live” in HTML context, and line breaks are ignored there, typing in the Text editor and switching to the Visual editor will remove all line breaks. Typing in the Visual editor will add paragraph tags. So only users that never use the Visual editor and have to type long, complex shortcodes will see some benefit.

The Shortcode API Roadmap meeting is in #feature-shortcode today at 17z, which is 2015-10-14 1700.

#meeting, #roadmaps, #shortcodes