Make existing HTML parsing functionality from REST API and Press This reusable

[dshanske]

WordPress already has an HTML parsing function in the form of WP_Press_This::source_data_fetch_fallback and its private called functions.

Suggesting this be split off so it can be used elsewhere. Specifically, my use case is over on the Ping and Trackbacks component. One of the proposals I keep advocating for is improving the presentation.

As we already have this code in WordPress that allows for parsing of HTML for images, embeds, meta tags, etc, it should be used over writing new code to do the same.

But if it were to be called right now, it would reretrieve source HTML already retrieved by the Pingback code and passed into the comment array.

[swissspidy]

Thought the same the other day. A separate class would be very handy for things like automatic link previews.

[dshanske]

@swissspidy If you remember, I chimed in re link previews during the oEmbed discussions, so I completely agree there too.

This should be relatively easy to separate. The code is pretty much written and stable. WP_Press_This will just call another class and focus on the Press This legacy merge and other related things.

[kraftbj]

Noting that while I'm closing out various PT tickets since it is moving to a plugin, I'm leaving this since this is more of an enhancement to Core than strictly PT. I do like this idea though.

[rglennnall]

I'm not a core coder. I just came to this from the link in the PT-in-4-9 thread.

Like many people, I'm sorely disappointed in the loss of the ability to populate the PT plugin like the bookmarklet availed.

WHAT CAN WE DO to get such functionality back - HOWEVER it could be accomplished (vice this bookmarklet ya'll have seen fit to deprecate)?

[swissspidy]

Press This is no longer in core, but there is WP_REST_URL_Details_Controller now that does a similar thing.

[dshanske]

The goal of this at the time when Press This was being split off was to keep some version of the parsing part of the code in Core. If this is built into a REST controller, should the ticket then evolve to that being usable in a non-REST context as well?

[swissspidy]

I think that makes sense to me. It should be possible to abstract that logic and extend it so it's useful for pingbacks/trackbacks and other use cases in core.