WordPress.org

Make WordPress Core

Opened 2 months ago

Closed 36 hours ago

Last modified 36 hours ago

#41689 closed task (blessed) (fixed)

Retire Press This

Reported by: azaozz Owned by: kraftbj
Milestone: 4.9 Priority: normal
Severity: normal Version:
Component: Press This Keywords:
Focuses: Cc:

Description

Following the importers and the link manager, it's about time to say goodbye to Press This. Bookmarklets were popular seven - eight years ago, and now are considered mostly "old tech".

The Press This usage was dwindling for the last several years. Currently it is at under 0.2% of the wp-admin requests (as far as I can tell). In that terms it seems best to extract it from core to a plugin, similarly to the importers.

Attachments (2)

41689.diff (131.3 KB) - added by kraftbj 5 weeks ago.
First pass at removing Press This
41689.2.diff (131.1 KB) - added by kraftbj 5 weeks ago.
2nd pass

Download all attachments as: .zip

Change History (20)

#1 @azaozz
2 months ago

Been looking at how to best "extract" Press This and make it a plugin. Think we should keep the URL scanning, but remove/retire the bookmarklet completely. That will make it simpler and easier to maintain and at the same time will keep nearly all of the functionality.

There is also the possibility to completely replace the UI with a browser extension/add-on. That was one of the ideas behind the last major update of Press This couple of years ago.

#2 @kraftbj
2 months ago

Extracting the UI to a plugin would be great and agree in keeping the scanning functions as an API that the plugin can tie into.

With the rewrite a few years back, one idea was to be a "blessed" consumer of the REST API, but PT went on since the REST API wasn't going to be merged on a known timetable back then.

Whether it is extracted out permanently or a new version is made as a plugin that utilizes the REST API, it would likely better serve the community as a REST API consumer than in the current state.

I would suggest leaving enough in so that if someone uses the bookmarklet on an upgraded site, it invites the user to install the blessed plugin. Since PT is only fired after user interaction, we can rely on this instead of trying any tricky efforts to install the plugin upon upgrade and we can avoid the fate of the Links Manager where all of the code is still actually in Core while the blessed plugin is just a filter call.

#3 follow-up: @rmccue
8 weeks ago

One issue with extracting to a REST API consumer currently is that we still do not have authentication in core (nor a solution to distributed clients, but we can bake PT in as a blessed consumer in the meantime, similar to how we're planning on handling the mobile apps). That's likely still a ways out, unless we want to require an auth plugin for PT.

#4 @kraftbj
8 weeks ago

Looking specifically at the class-wp-press-this.php file, we should keep the various internal utility functions (_limit_array, et al),fetch_source_html, source_data_fetch_fallback, get_embeds, get_images, get_canonical_link, get_source_site_name, get_suggested_title, get_suggested_content.

Anything that outputs HTML or handling the ajax-y bits should be extracted ( html, tags_html, categories_html, post_formats_html, add_editor_style, add_category, save_post, side_load_images ), as well as the press-this-editor.css from wp-admin/css, and mentions of PT in wp-admin/tools.php

It doesn't look like anything terrible to do and would just need to account for the class variables properly.

#5 in reply to: ↑ 3 @kraftbj
8 weeks ago

Replying to rmccue:

One issue with extracting to a REST API consumer currently is that we still do not have authentication in core (nor a solution to distributed clients, but we can bake PT in as a blessed consumer in the meantime, similar to how we're planning on handling the mobile apps). That's likely still a ways out, unless we want to require an auth plugin for PT.

At least for the initial extraction (and the foreseeable future with PT as a web-based app), I'd see it still being access via wp-admin/press-this.php with it prompting for the plugin if not installed. If it is installed, the plugin would load up. This would keep up in wp-admin, so we can piggyback off of the cookie auth, I think. A compromise between full extraction, backwards compat, opening the door for using the REST API without having to over-think something that has minor usage these days.

As auth in core advances and if there is still interest, we can look at porting PT to browser apps or other contexts that wouldn't be able to utilize the logged-in cookie.

#6 @rmccue
8 weeks ago

Agreed, I think building it as a plugin right now makes sense, but decoupling as much as possible so that eventually, it could work either way.

This ticket was mentioned in Slack in #core-pressthis by kraft. View the logs.


6 weeks ago

@kraftbj
5 weeks ago

First pass at removing Press This

#8 @kraftbj
5 weeks ago

  • Owner set to kraftbj
  • Status changed from new to accepted

Put up a first pass at retiring PT from the Core side.

Still needed:

  1. Clean up documentation (press-this.php, remove the logic tree, add proper inline docs).
  2. Whitespace cleanup -- looks like something on my end slipped when editing the ajax array.
  3. postbox.js has a reference to PT -- need to determine best way to remove.
  4. l10n.css has reference to PT that needs to be removed.
  5. Publish the replacement plugin.

Publishing this now so @stephdau can have a look.

@kraftbj
5 weeks ago

2nd pass

#9 @kraftbj
5 weeks ago

Latest patch along with the corresponding update to the plugin works in initial testing as expected (currently hitting #41883).

#10 @azaozz
3 weeks ago

In 41584:

Retire Press This and extract it to a plugin. First run.

Props kraftbj, azaozz.
See #41689.

#11 @DrewAPicture
3 weeks ago

  • Keywords ux-feedback added

Of all the things to "retire" from core. Especially after having basically rewritten it only a year or two ago.

As somebody who uses Press This as a first-order authoring tool, I'm disappointed, though all for modularization and removing unused features. So with that in mind, is the aim to completely remove Press This from core without a trace, or at least still make it discoverable as a downloadable tool (like the importers or exporter)?

As of r41584, if you didn't know it was ever there, you might never discover it. Is that the intention? If not, perhaps we should consider leaving some kind of pointer in Tools.

#12 follow-up: @azaozz
3 weeks ago

if you didn't know it was ever there, you might never discover it.

Yes, as with any deprecated feature this is the intention:

  1. Provide a way for existing users to still (partially) use it.
  2. Do not show to new users.

Was thinking if we should add something similar to the importers to the Tools screen, but that would defeat the purpose of deprecating Press This. Thinking its discoverability as a plugin should be enough. New users will be able to find the plugin in the usual ways, including discovering it in the plugins repo.

#13 in reply to: ↑ 12 @DrewAPicture
3 weeks ago

  • Keywords ux-feedback removed

Replying to azaozz:

Thinking its discoverability as a plugin should be enough. New users will be able to find the plugin in the usual ways, including discovering it in the plugins repo.

Alrighty then.

This ticket was mentioned in Slack in #design by melchoyce. View the logs.


2 days ago

This ticket was mentioned in Slack in #core by melchoyce. View the logs.


2 days ago

#16 @melchoyce
2 days ago

@kraftbj Do you know what this still needs?

#17 @kraftbj
36 hours ago

  • Resolution set to fixed
  • Status changed from accepted to closed

@melchoyce We're good to close this. If we missed anything, we can reopen or do a new ticket.

#18 @kraftbj
36 hours ago

Related: https://meta.trac.wordpress.org/ticket/3205 (adding Github repo for press-this plugin for bug reports, etc).

Note: See TracTickets for help on using tickets.