#wordpress 2023-03-30

2023-03-30 UTC
#
[snarfed]
I suspect that # source URL issue may be a bug in the WP plugins after all. filed https://github.com/pfefferle/wordpress-webmention/issues/359
#
GWG
[snarfed]: I remember us having urlencode issues ages ago.
RasAlGhoul and Pablo1 joined the channel
#
[pfefferle]
Might be an issue with fragment parsing support in the mf2 parser
#
[pfefferle]
I think it goes to the fragment and interpret only this part and if the author informations are outside of the fragment they will be ignored
[jamietanna] and [marksuth] joined the channel
#
[KevinMarks]
Having a URL encoded # in the url is not great url design. I learned this with the ## version of fragmention
wagle, gRegor, IWSlackGateway, [KevinMarks] and [snarfed] joined the channel
#
[snarfed]
Agreed! This is largely due to mastodon putting fragments in AP object ids and keyIds, which is problematic in its own right. https://github.com/snarfed/bridgy-fed/issues/469
[pfefferle] joined the channel
#
[pfefferle]
[snarfed] I still think it should be decoded, but I agree, that it is problematic... perhaps we should always strip the hash-part or we should disable fragment parsing in the mf2 lib (if possible)
[manton] joined the channel
#
[snarfed]
[pfefferle] understood! the parts that make me think twice are that the Python requests library I'm using doesn't URL-encode the % characters in a form-encoded POST, and that other webmention receivers like www.jvt.me are handling these source URLs fine
#
[pfefferle]
maybe we should send a URL via a form to check how the browser does handle it 😉
RasAlGhoul joined the channel
#
[snarfed]
sure! I'll try that
#
[snarfed]
[pfefferle] you're right, form-encoded POST body do get URL-encoded. I checked and confirmed that in this webmention I'm sending, the # char is getting *double*-URL-encoded to %2523 in the POST body
#
[snarfed]
so you're right, WordPress should indeed URL-decode it once, but not twice, which some part of it seems to be doing now
[tantek], IWSlackGateway, [schmarty], gRegor, RasAlGhoul, [snarfed] and [pfefferle] joined the channel
#
[pfefferle]
GWG what do you mean by "I'm still trying to figure out the upgrade trigger..it isn't working in testing"??? does the code not work or the trigger?
#
GWG
[pfefferle]: I have trouble figuring out how to test it reliably.
#
[pfefferle]
I feared running it on my live system yet!
#
GWG
I keep having to downgrade and reupgrade
#
GWG
[pfefferle]: I would take the risk myself. But is that enough?
#
GWG
This is what I have trouble with.
#
[pfefferle]
the problem is the following
#
[pfefferle]
> Use with caution: When you use the `upgrader_process_complete` action hook in your plugin and your plugin is the one which under upgrade, then this action will run the old version of your plugin.
#
[pfefferle]
it is triggered on the old code and not the new one
[KevinMarks] joined the channel
#
[KevinMarks]
Are fragments in ids some LD range 14 nonsense?
#
GWG
[pfefferle]: That's why I have issues.
[campegg] joined the channel
#
[pfefferle]
do we use that anywhere?
#
[pfefferle]
I thought I have removed it from the Webmentions code?
#
GWG
I was trying to figure out how to trigger the upgrade routine.
#
GWG
We have 2 other ways... but I thought a third made sense.
[tantek], wagle, [jeremycherfas] and [chrisbergr] joined the channel
#
[chrisbergr]
Maybe you can provide a minor update of the previous version. In that update you register the action hook to redirect to a plugin file. If you do your major update, you may access the hook from previous version but the redirect goes to the new file. There you can handle all the stuff you have trouble with. - Sounds plausible in theory
[James_Van_Dyne] and RasAlGhoul joined the channel