igrok, 2 months ago

@Edent if said plugin is packaged by RPM, you could create an empty package that requires plugin-with-fix and then repackage the plugin yourself with your patch and have it also provide plugin-with-fix. Then install both. When you upgrade, the upgrade will fail (notifying you of the update) until you repackage the update. If the original package sources are in git, you could use it to merge your modified package sources with their updates.

Or you could just edit the file and chattr +i

Edent, 2 months ago

@igrok are WordPress files usually packaged with RPM?

igrok, 2 months ago

@Edent if you get them from a Linux distro (I assume Debian packages have similar capabilities)

If not, think of it as brainstorming

Edent, 2 months ago

@igrok WordPress plugins are distributed ZIP files with PHP in them.

Perhaps refrain from trying to brainstorm until you have the basics covered?

mattround, 2 months ago

@Edent Could perhaps use this hook to re-overwrite it after each update..? https://developer.wordpress.org/reference/hooks/upgrader_process_complete/

Edent, 2 months ago

@mattround
Aha! That might do it. Will investigate. Cheers.

kraftner, 2 months ago

@Edent Just to have this out of the way: Patching code like this most of the time isn't a good idea and will cause you pain in the future.
Now: What exactly are you trying to change? In WP usually the way to go is trying to do whatever you are trying to do using actions/filters. If the code is open source I can have a look if that is possible if you point me at the code in question.

Edent, 2 months ago

@kraftner yeah, I know.
This is what I'm trying to do
https://github.com/michelf/php-markdown/issues/387

My patch works (for me) - but the file is deep within JetPack. I'm not entirely sure which filter I would set up to intercept it.

kraftner, 2 months ago

@Edent First: Using the title attribute for tooltips isn't a great idea: https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/title#accessibility_concerns
But back to your actual question. Jetpack by now is a convoluted legacy codebase. So while I'm quite sure it is doable I don't have the time right now to look into it. At first glance it looks as if the parser actually used is instantiated here: https://github.com/Automattic/jetpack/blob/a8c42254e8f804ff2cb1afcee24e1d0f68a52679/projects/plugins/jetpack/modules/markdown/easy-markdown.php#L389-L397
Since it hardcodes the path and saves it in a private property it is hard to alter without replacing everything leading up to there.

kraftner, 2 months ago

@Edent So what I'd actually do is something completely different: Hook on https://developer.wordpress.org/reference/hooks/the_content/ and use https://developer.wordpress.org/news/2023/09/28/the-html-api-process-your-tags-not-your-pain/ to look for links that have the jetpack-footnote CSS class. Then look for the corresponding li in the footer with that ID, extract the text and replace the title tag in the content link.
This should be forward compatible, isn't much code and will just stop working instead of taking your whole site down if Jetpack ever does e.g. a major refactoring.

Edent, 2 months ago

@kraftner
I'm comfortable with the tootips as the link to the text is still present.
Thanks for the other tips. I'll check them out.

Edent, 2 months ago

@kraftner Hmmm. Looks like it might be trickier than I thought.

> it’s not possible for the Tag Processor to return the inner markup inside an element.
https://developer.wordpress.org/reference/classes/wp_html_tag_processor/#design-and-limitations

So I can find the footnote links - and associated li - but I can't get the text of that li.

Will keep fiddling around. Cheers!

kraftner, 2 months ago

@Edent Oh, yeah, right, forgot about that, sorry. Then you'll need https://www.php.net/manual/de/class.domdocument.php or some other library like https://github.com/wasinger/htmlpagedom but I'd still code it in a way that does as much as possible with the HTML API from WordPress so you can swap the rest (getting the text content) if it at some later point gains that feature.

Edent, 2 months ago

@kraftner good tip. Thanks.

darkling, 2 months ago

@Edent It's not particularly sensible, but the big hammer is setting the immutable attribute: chattr +i <file>

Use this only if you can't find another way.

Edent, 2 months ago

@darkling might be a last resort 😆

pwaring, 2 months ago

@Edent Despite the name, I think you can accomplish this using a child theme, which inherits all the plugins of its parent but can override them (you can't have a grandchild theme though, so this doesn't work if you're already using a child theme).

Edent, 2 months ago

@pwaring interesting, I'll take a look.

dominik, 2 months ago

@Edent if there is, I didn't find it, yet. I've tried with automatic patching before, that went about as well as expected. So far the best way I found was to upstream the patch and hope that the maintainer accepts it.

Edent, 2 months ago

@dominik So far, no dice!
https://github.com/michelf/php-markdown/issues/387
(Possibly because my code isn't brilliant and it changes people's expectations.)