Press This: Add filters to allow custom Press This plugins

[kraftbj]

The Press This feature of WordPress was spun out of Core in 4.9 as into a "canonical plugin". The Core side code presumes the canonical plugin is the only implementation.

If a site owner wants a custom version of Press This, they are required to hack the plugin in some way (set the version super high and edit the files, replace it with something of a high version, etc to ensure the plugin is updated back to stock by WordPress).

This also limits what site owners can do—selective versions of Press This based on who is logged in, A/B tests of different Press This's, etc.

Request a few filters added to wp-admin/press-this.php to allow for alternative implementations.

Adds filters to wp-admin/press-this.php to allow for custom Press This plugins to be used without special hacks.

Trac ticket: https://core.trac.wordpress.org/ticket/53076

[poena]

Hi
This ticket was brought up during a bug scrub, but we were not sure how to continue to test this without first creating a custom press-this plugin to test the filter with.

Do you have a sample plugin code for this purpose? Or other testing instructions?

[poena]

Hi @kraftbj will you be able to provide further testing instructions before the 5.8 feature freeze?

[kraftbj]

Hi @poena. I'll move it out of the milestone; a bit of a chicken and the egg where I was looking at add the filters before having the plugin to utilize them, but makes sense to wait.

[SirLouen]

Combined Test Report and Patch Testing

Description

🟠 This report validates that the patch is working with a minor error

I have simply replicated the original "Press This" plugin and added a very trivial modification. We have to remember that the idea here is simply adding the capacity to a user to modifying the "Press This" plugin without risking an update, hence simply changing the basic namespace elements of the plugin. This patch adds the possibility of modifying all the static strings for this purpose.

Patch tested: ​https://patch-diff.githubusercontent.com/raw/WordPress/wordpress-develop/pull/1207.diff

Environment

• WordPress: 6.8-beta1-59933-src
• PHP: 8.2.25
• Server: nginx/1.27.2
• Database: mysqli (Server: 8.0.40 / Client: mysqlnd 8.2.25)
• Browser: Chrome 133.0.0.0
• OS: Windows 10/11
• Theme: Twenty Twenty 2.8
• MU Plugins: None activated
• Plugins:
  • Test Reports 1.2.0

Steps to Reproduce the Patch

1. First install a slightly modified version of Press This. In this case I'm using this one I've uploaded to my repo for the testing purpose: ​https://github.com/SirLouen/press-this-testing/archive/refs/tags/1.0.0.zip
2. Install the Bookmarklet and use the plugin
3. 🐞 Bug occurs as expected ​https://i.imgur.com/lRvokvf.png

Actual Results After adding the patch

First filter: press_this_plugin_slug

1. For the first filter we install the first modified version of this Press This plugin: ​https://github.com/SirLouen/press-this-testing/archive/refs/tags/1.0.1.zip
2. ❌ The test fails with an error.

The problem is that the code forces the use of not only the first filter, but also the second filter. I have added a new patch to sort this out, so the user can simply use the first filter to set a new slug (which is, in fact, the main purpose of this feature, adding the possibility of having an alt-version of Press This without having to edit the versioning over the official Press This plugin)

Second filter: press_this_plugin_slug

1. We install the modified version of this Press This plugin with this test: ​https://github.com/SirLouen/press-this-testing/archive/refs/tags/1.0.2.zip
2. ✅ The test passes correctly

Third filter: press_this_execution_func

1. We install the modified version of this Press This plugin with this test: ​https://github.com/SirLouen/press-this-testing/archive/refs/tags/1.0.3.zip
2. ✅First we do a function for the filter without returning a callable and returns the appropriate error as expected: ​https://i.imgur.com/ksOUYii.png
3. ✅ Second we do a function returning a new callable with a slight class naming mod and the test passes correctly

Supplemental Artifacts

All the required artifacts have been linked in the corresponding tests.

[SirLouen]

Added the changes to the Github PR as a comment (I don't have push perms)

[SirLouen]

Raising attention of @azaozz since he was the creator of press-this.php and current Editor component maintainer.

[azaozz]

Replying to SirLouen:

Hi @SirLouen thanks for the ping here. Frankly I'm not so sure if it is a good idea to still use bookmarklets (i.e. elevated JS code in a browser bookmark). They were pretty popular 10-15 years ago, but have some security problems and generally the way browsers work has changed a lot since then.

Nevertheless, looking at the PR maybe it can be much simpler? Seems all it needs is to allow plugins to replace the wp_load_press_this() function? That can easily be done by running that function on an action, for example on plugins_loaded. Then any plugin will be able to remove the default core callback and add its own.

So generally the code to achieve this would be to replace the loose wp_load_press_this() with something like:

add_action( 'plugins_loaded', 'wp_load_press_this' );

(This idea is untested. Seems to be working at first look but there may be something that is expected to run before plugins_loaded.)

[SirLouen]

Replying to azaozz:

Replying to SirLouen:

Hi @SirLouen thanks for the ping here. Frankly I'm not so sure if it is a good idea to still use bookmarklets (i.e. elevated JS code in a browser bookmark). They were pretty popular 10-15 years ago, but have some security problems and generally the way browsers work has changed a lot since then.

Nevertheless, looking at the PR maybe it can be much simpler? Seems all it needs is to allow plugins to replace the wp_load_press_this() function? That can easily be done by running that function on an action, for example on plugins_loaded. Then any plugin will be able to remove the default core callback and add its own.

So generally the code to achieve this would be to replace the loose wp_load_press_this() with something like:

add_action( 'plugins_loaded', 'wp_load_press_this' );

(This idea is untested. Seems to be working at first look but there may be something that is expected to run before plugins_loaded.)

The reality is that the plugin is almost abandoned but had a minor version update 4 months ago.
​https://github.com/WordPress/press-this/issues and one issue some months ago

Not the most sexy plugin in 2025, not gonna lie :)

This said, I think that the original idea of @kraftbj was simply a copy-paste of the initilization code as a filter. A simply posted a PR with the adapted original code from him

If anyone wants to provide a new PR, I could try to test it. This action/filter hook-based reports are pretty weird to test though (hence most of the stalled reports with patches are mostly of this type)

[kraftbj]

The patch has been brought up to current trunk and included a suggestion from @SirLouen.

Also, for the sake of saying, I'm happy to review PRs into the canonical Press This plugin too! You might need to ping me to nudge me to look. :)

I'm also happy to spin up a separate PR for the hooked approach that @azaozz suggested. I'll work on that now.

This is an alternative approach of the solution in #1207 after feedback from @azaozz. This would replace the freefloating execution of the load function behind a new press_this_init action.

In admin-filters, add a default action which plugins can unhook, etc.

[kraftbj]

I agree that this alternative is cleaner. @SirLouen, what do you think?

[SirLouen]

Replying to kraftbj:

I agree that this alternative is cleaner. @SirLouen, what do you think?

Let me test this with my testing plugin and I will get back asap.

[SirLouen]

✅ I've tested with ​my plugin and everything is working well as expected.

I confirmed the first patch, mainly because the initial use-case, was to have quick solution to add some tweaks to the Press-This OG plugin.

With this new patch, from a code perspective as @azaozz suggested, it's much cleaner, but it's a hassle for the new plugin creator (at minimum, needing to copy/paste the wp_load_press_this, to initialize the same the precursor instance if he is only adding some tweaks to the OG).

Even with just one filter of the starting 3 (the slug one), you could perfectly achieve the initial use-case as long as you preserved the same loading filename and same class name in your tweaked plugin.

Let's remember which was the initial use-case:

If a site owner wants a custom version of Press This, they are required to hack the plugin in some way (set the version super high and edit the files, replace it with something of a high version, etc to ensure the plugin is updated back to stock by WordPress).

With a different slug, this is perfectly sorted. And in terms of total code, is even less than the action hook solution. And I seriously doubt that anyone in 2025 is going to invest time on revamping a full Press-This plugin, instead of just, either PRing the OG or just adding some little tweaks.

Furthermore, with this new version with a hook action, I believe that a dev-note is required 100% to explain what's going on. With filter hooks, I feel that a dev note is optional, but it would be nice as well to inform about this new "feature".

Closing this to defer to #8612

[desrosj]

@kraftbj Could you share a bit more around how this is useful. I agree that the actual code changes in the PR seem reasonable, but I'd like to understand a bit more behind the request since the plugin currently only has 6k active installs.

Right now the reasoning is a bit unclear. Does this change unblock something for the plugin? Is there actual A/B testing going on? Are these theoretical scenarios, or are users actually doing this?

[SirLouen]

Replying to desrosj:

Right now the reasoning is a bit unclear. Does this change unblock something for the plugin? Is there actual A/B testing going on? Are these theoretical scenarios, or are users actually doing this?

The original reasoning was to be able to inject your plugin without having to do shenanigans like using the same plugins slugs and parameters but adding version v1000 to avoid potential unexpected updates.

As I said to @kraftbj, the use of this has declined massive, still there was a feature request for it in 2 months ago, though:
​https://github.com/WordPress/press-this/issues/59

In this case, this patch could add the easier possibility for extenders to “fork” and use their plugins. Although extenders like the one in that ticket, have figured out alternative ways to extend it, BJ suggested that it was easier to do it this way.

Maybe a micro dev-note is required, and we are good to go with this report. Pretty simplistic, as @davidbaumwald commented.

[SirLouen]

I've added a new dev-note for this
​https://github.com/orgs/WordPress/projects/262?pane=issue&itemId=133515116

Personally, I believe this is ready to be deployed.

[westonruter]

In 60990:

Press This: Add press_this_init action so plugins can provide their own implementations.

Developed in ​https://github.com/WordPress/wordpress-develop/pull/8612

Props kraftbj, azaozz, SirLouen, shailu25, mukesh27, poena, desrosj, westonruter.
Fixes #53076.

Committed in ​https://github.com/WordPress/wordpress-develop/commit/6dd1ac6827fa4ce5c78003d6047e26966f32eba1 (r60990)

[desrosj]

Replying to desrosj:

Right now the reasoning is a bit unclear. Does this change unblock something for the plugin? Is there actual A/B testing going on? Are these theoretical scenarios, or are users actually doing this?

I think it’s still worth getting additional clarity around the value this provides to users. I’m not convinced that this benefits a large number of users, never mind the 80/20 rule. While that’s not a steadfast rule, understanding the reasons behind the request would help to better understand the rationale.

This was a feature that was moved to a canonical plugin in 4.9, so it’s been 20 releases now without much demand to add it back (6,000+ installs). Is there no way to accomplish this through an early filter in the plugin itself instead?

I also disagree that this is worthy of a dev note at all. The new hook should be mentioned in a list of new hooks, or in the miscellaneous developer focused changes note. It’s important that we carefully consider which changes deserve their own post to avoid too much noise that offers very little value which can result in developers unsubscribing entirely.

[jorbin]

I agree with @desrosj, I'm unsure if [60990] is a valuable addition. As @azaozz pointed out, bookmarklets are not popular these days and I question if they are a best practice in general.

[desrosj]

With 6.9 beta 1 due out in an hour, I think it's best we revert this one so that discussion can continue. What we are supporting should be more clear. "No" is temporary, but "yes" is something we will need to support forever (or at least a considerable amount of time).

[desrosj]

In 61030:

Press This: Revert [60990] for more discussion.

[60990] introduced a new action, press_this_init. While the code changes adding the hook are straightforward, the actual use cases are not yet clear.

Reverting the change allows for more discussion to clarify what is actually supported through the addition of this new action.

Props jorbin.
See #53076.

[desrosj]

Moving to 7.0 to continue working on this one.