#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)
Change History (26)
#2
@
7 years 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:
↓ 5
@
7 years 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
@
7 years 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
@
7 years 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
@
7 years 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.
7 years ago
#8
@
7 years 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:
- Clean up documentation (press-this.php, remove the logic tree, add proper inline docs).
- Whitespace cleanup -- looks like something on my end slipped when editing the ajax array.
- postbox.js has a reference to PT -- need to determine best way to remove.
- l10n.css has reference to PT that needs to be removed.
- Publish the replacement plugin.
Publishing this now so @stephdau can have a look.
#9
@
7 years ago
Latest patch along with the corresponding update to the plugin works in initial testing as expected (currently hitting #41883).
#11
@
7 years 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:
↓ 13
@
7 years 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:
- Provide a way for existing users to still (partially) use it.
- 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
@
7 years 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.
7 years ago
This ticket was mentioned in Slack in #core by melchoyce. View the logs.
7 years ago
#17
@
7 years 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
@
7 years ago
Related: https://meta.trac.wordpress.org/ticket/3205 (adding Github repo for press-this plugin for bug reports, etc).
#19
follow-up:
↓ 20
@
7 years ago
This is my first disastrous experience with WordPress.
The tool I used most for WordPress is gone. The plugin doesn't replicate the functionality, and is completely pointless. Someone really messed up this time.
So I use Facebook instead for posting about articles in media. Or I find other tools, not WordPress. I have held courses for clients using this tool, what to say now?
I used to love WordPress, for almost 15 years. Now, I wonder what the team is thinking, who they ask before making braking changes and what's the goal.
What was the reason for removing this? "Old" is no reason here, as it's just a few years old, and was working. I can only ask, please revert this.
#20
in reply to:
↑ 19
@
7 years ago
Replying to knutsp:
The plugin doesn't replicate the functionality, and is completely pointless. Someone really messed up this time.
What issues are you seeing with the plugin? Its purpose is to port the prior Press This functionality, so if something isn't working then that's definitely a bug that needs fixing.
#21
@
7 years ago
The plugin now says the bookmarklets are deprecated. As I can read on WP Tavern bookmarklets function is removed or not implemented in the plugin. The bad thing here is that this ticket says the functionality will go into a plugin. That's not true, but believed it.
The feature should not have been removed before an alternative was ready. Why the hurry?
Press This is useless without the bookmarklet. That was the whole point of it, wasn't it?
#22
@
7 years ago
"Press This is useless without the bookmarklet."
Yep. It forced me to discontinue my blog. What a terrible, user-hostile decision.
#23
@
7 years ago
Here's more discussion:
https://github.com/WordPress/press-this
Restore Bookmarklet Functionality:
https://github.com/WordPress/press-this/issues/15
#24
@
7 years ago
This went in because of a lie, that the functionality was to provided by a core plugin.
I work with WordPress, but I no longer publish with WordPress, and I can no longer educate clients on how to publish by quoting media articles or non-WordPress blogs/sites. Now it's just, go directly to social media like Facebook or Twitter. A lot easier. WordPress dies or just hosts static sites. WordPress is committing suicide here.
This should be reverted for 4.9.1 and not wait for the plugin to solve it, as this is a severe regression.
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.