Here are four patches to the V-tree for Mircea Popescu's Wordpress, which amount to an approximation of the changes I've been running since initial setup of Fixpoint, reground to build upon subsequent improvements by billymg and Diana Coman.
I plan to sign them shortly unless cause for revision comes to light (such as for example server-side selection being implemented outside the theme-specific code).
Quoth the manifest:
624752 mp-wp_remove-textselectionjs-pop3-etc jfw Remove the unreliable JS-based selection, posting by POP3 login, and a stray .php.orig file. Neutralize and comment the example pingback updater.
624752 mp-wp_svg-screenshots-and-errorreporting jfw Allow .svg extensions in theme screenshot search. Don't clobber the user's errorreporting level without WP_DEBUG.
624752 mp-wp_serverside-selection jfw Add server-side text selection to example htaccess and themes, roughly as seen in http://trilema.com/2019/proper-html-linking-the-crisis-the-solution-the-resolution-conclusion/ (xmlrpc.php changes not included)
624752 mp-wp_footnote-link-tweaks jfw Avoid turning double-quotes into backquotes in footnote tooltips. Expand the link part of footnote identifiers to cover the pre_identifier and post_identifier strings, for a larger clickable area.
Update: I've reground the first based on billymg's feedback to prune the wrapper "span" tags originating from mp-wp_add-footnotes-and-textselectionjs.vpatch, and the second trivially to follow the changed antecedent. As I had previously signed these, I've bumped the canonical patch names to avoid confusion. The second two patches remain in a draft state. Current patches and seals:
mp-wp_remove-textselectionjs-pop3-etc -- looks great
mp-wp_svg-screenshots-and-errorreporting -- nice bug fix with the svg screenshots. removing the else block for setting error_reporting seems fine too
mp-wp_serverside-selection -- hopefully we can add this at the plugin level, which seems like a more appropriate place for it.
mp-wp_footnote-link-tweaks -- i like the better escaping of double quotes in this one, the second one makes sense but then why not also do it for the backlinks? it is a usability improvement (larger click area as you mentioned), but perhaps also a style consideration. which brings up something you mentioned here, and that is: what do users of V software do if they want to make small tweaks to their own copies? do they have to maintain a fork for every small adjustment? one could patch locally, with a "personal-config.diff", after pressing a new version, but if a new version changes code that overlaps with the customizations then the conflict would need to be manually resolved, and then "personal-config.diff" updated. Alternatively, these are all pulled into a global variable edited in wp-config.php, as you suggested for the list_style_type flag. Not really sure what the right answer is and i admit that my own workflow is more "manual" when it comes to making personal customization to my running copy of mp-wp.
Comment by billymg — 2020-04-07 @ 17:44
> why not also do it for the backlinks?
As they use a fixed character, they didn't bother me the way the tiny "i" in this font did, but sure, no harm in changing them too that I can see.
> removing the else block for setting error_reporting seems fine too
Without removing this, the thing flatly disobeys one's php.ini and/or wp-config.php settings leaving no way to suppress warning spew for "deprecation" and similar, at least that I found.
> what do users of V software do if they want to make small tweaks to their own copies?
V here only makes more visible the trouble that already exists. Going on your own branch, whether by vpatch or just modifying in place - which so far has been pretty unavoidable here, but the idea is to shrink or at least not grow the problem - increases the pain of adopting someone else's work, and thus the overhead of collaborating with them. And this isn't inherently bad or anything; after all, it could be a sign that they're making stupid changes. But I'm of the notion that there's much room for improvement in MP-WP and it'd benefit your position as maintainer to minimize the friction of following your branch.
Comment by Jacob Welsh — 2020-04-07 @ 21:44
> But I'm of the notion that there's much room for improvement in MP-WP and it'd benefit your position as maintainer to minimize the friction of following your branch.
This is an excellent point and probably means i should be doing a better job of communication, to understand what should be a tunable knob and what should be fixed (and how). I'll have to give this some more thought...
Comment by billymg — 2020-04-08 @ 00:40
Updated.
Comment by Jacob Welsh — 2020-05-11 @ 05:46