Comments on: Selection and other sundries for MP-WP http://jfxpt.com/2020/selection-and-other-sundries-for-mp-wp/ The search for invariants Wed, 15 Apr 2026 16:12:10 +0000 http://polimedia.us hourly 1 By: Jacob Welsh http://jfxpt.com/2020/selection-and-other-sundries-for-mp-wp/#comment-272 Jacob Welsh Mon, 11 May 2020 05:46:23 +0000 http://fixpoint.welshcomputing.com/?p=116#comment-272 Updated. Updated.

]]> By: billymg http://jfxpt.com/2020/selection-and-other-sundries-for-mp-wp/#comment-237 billymg Wed, 08 Apr 2020 00:40:23 +0000 http://fixpoint.welshcomputing.com/?p=116#comment-237 > 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... > 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...

]]> By: Jacob Welsh http://jfxpt.com/2020/selection-and-other-sundries-for-mp-wp/#comment-236 Jacob Welsh Tue, 07 Apr 2020 21:44:17 +0000 http://fixpoint.welshcomputing.com/?p=116#comment-236 > 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. > 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.

]]> By: billymg http://jfxpt.com/2020/selection-and-other-sundries-for-mp-wp/#comment-235 billymg Tue, 07 Apr 2020 17:44:44 +0000 http://fixpoint.welshcomputing.com/?p=116#comment-235 <em>mp-wp_remove-textselectionjs-pop3-etc</em> -- looks great <em>mp-wp_svg-screenshots-and-errorreporting</em> -- nice bug fix with the svg screenshots. removing the else block for setting error_reporting seems fine too <em>mp-wp_serverside-selection</em> -- hopefully we can add this at the plugin level, which seems like a more appropriate place for it. <em>mp-wp_footnote-link-tweaks</em> -- 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 <a href="http://billymg.com/2020/04/updated-patch-code-embed-plugin-for-mp-wp/comment-page-1/#comment-115" rel="nofollow">mentioned here</a>, 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. 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.

]]>