Closed cybeardjm closed 1 year ago
Thank you for reporting this @cybeardjm! Would you be able to share a link to the Mastodon post you're trying to embed?
Hi @stefanbohacek This is the page I've been playing with: https://www.didiermary.fr/most-favorited-mastodon-posts/ It contains 7 embedded Mastodon posts. It was fine when I first created it a few days ago, and then something (?) happened. Once again, I don't think it's directly the plugin that's causing it, but my blog in some context. I tried disabling all plugins, reinstalling WP 6.3.1 etc. Have no more ideas for potential tests... Sincerely DJM PS: I uninstalled the plugin for the moment.
@stefanbohacek To answer your email, the page contains 7 embedded posts, and this happens for all of them, including for the Profile Image, that appears correctly on my second blog (AMF). I just reactivated the plugin. If you visit the page in the previous comment, you'll see what happens. If you check the source code for any embedded post, and try to open any image via /wp-json/ftf/media-proxy? there's a critical error. DJM
Thank you for providing the details!
Looking at the page, all images seem to be loading okay.
Maybe it was a temporary hiccup on masto.ai?
Hi @stefanbohacek OK, after more investigation, I know the cause of the fatal error, although not its origin, and indeed as your capture shows, images are fine... when called properly... Let me explain below.
1 - On the AMF site, where everything works fine, a call to my profile picture in an embedded post looks like this: https://amf.didiermary.fr/wp-json/ftf/media-proxy?url=aHR0cHM6Ly9zMy5tYXN0by5haS9hY2NvdW50cy9hdmF0YXJzLzEwOS8zMDQvNzY3LzAxNy8xMTIvNjU0L29yaWdpbmFsL2RmMjRmOTJiYWVkODc2NWUuanBn
2 - On the WWW site, where I get fatal errors, the profile picture in embedded posts looks like this: https://www.didiermary.fr/wp-json/ftf/media-proxy?url=https://s3.masto.ai/accounts/avatars/109/304/767/017/112/654/original/df24f92baed8765e.jpg
The difference? In the 1st case, the target URL is encoded. In the 2nd case, it's not...
This means that a function "somewhere on my WWW site" doesn't work or at least allow the proper generation of the target URLs, that are left as "plain text" instead of as encoded values. When the system tries to decode => fatal error...
What function, piece of code etc. is the reason why target URLs are not encoded, I have no idea yet, as it happens even if the plugin is the only one running in troubleshooting mode. What function for coding/decoding should I look for on WordPress?
Sincerely DJM
@cybeardjm Ah, okay, this makes sense. Can you please make sure you have the latest version of the plugin on both sites?
I haven't really been versioning it properly while it's still in development, so it will still say 1.0.0. I've been meaning to wait until my submission to the WordPress plugin directory is approved, but seeing as the development has slowed down, I will start bumping the version number with the next update.
@stefanbohacek - I used the same downloaded file for both blogs. But to be sure, I just redownloaded it, totally removed the previous version (including corresponding FTF table and options), and reinstalled from the new file: it's exactly the same...
I really don't think it's the plugin fault. Something somewhere in my WP config doesn't allow the plugin to encode URLs when creating the object, once again in my context.
The URL is generated in the browser, though, see here.
postText += `<a href="${ postUrl }" target="_blank">
<img
alt="${ media.alt_text || '' }"
loading="lazy"
width="${ media.width }"
height="${ media.height }"
class="w-100 rounded border mb-3"
src="${window.ftf_fediverse_embeds.blog_url}/wp-json/ftf/media-proxy?url=${ window.btoa(media.url) }"
>
</a>`;
window.btoa
has a good browser support, but just to make sure, are you maybe seeing different behavior with different browsers?
It's the same in both Chrome and Firefox and tried with Edge with same result.
the problem is: ${ window.btoa(media.url)} should be encoded like in here
https://amf.didiermary.fr/wp-json/ftf/media-proxy?url=aHR0cHM6Ly9zMy5tYXN0by5haS9hY2NvdW50cy9hdmF0YXJzLzEwOS8zMDQvNzY3LzAxNy8xMTIvNjU0L29yaWdpbmFsL2RmMjRmOTJiYWVkODc2NWUuanBn => window.btoa(media.url) worked
But what I see in the source code is this:
https://www.didiermary.fr/wp-json/ftf/media-proxy?url=https://s3.masto.ai/accounts/avatars/109/304/767/017/112/654/original/df24f92baed8765e.jpg => window.btoa(media.url) didn't work, and It only shows "media.url" in the source code
And this encoding doesn't happen in the browser, but when you generate the object. The encoding part of URL doesn't happen...
Check the source of any embedded Mastodon posts here https://www.didiermary.fr/most-favorited-mastodon-posts/ and you'll see the problem for each included image.
My understanding is that the script/plugin is working properly, but something in my WordPress blocks the btoa() function and it doesn't encode the strings in base-64, the browser is unable to decode something that is not encoded and generates a fatal error.
What is blocking the btoa() function in my case?
PS: just click on the 2 links above here. The first one opens my avatar, the second a blank page (probably when calling the base64_decode in media-proxy...)
FYI, just tried modifying the plugin on my blog directly by editing this call window.btoa(media.url)
1 - window.btoa(encodeURIComponent(media.url)) => same result 2 - base64_encode(media.url) => same result
(reference here: https://stackoverflow.com/questions/63387813/why-wont-window-btoa-work-on-characters-in-javascript )
I see that this URL works:
But this one does not:
Would you be able to confirm that the the includes/Media_Proxy.php
on both of the servers look exactly the same, particularly around here?
AMF (works)
if ($this->archival_mode){ $url = base64_decode($url); $dir = plugin_dir_path(__FILE__) . "../$folder_name"; $file_name = basename($url); $file_extension = pathinfo($file_name, PATHINFO_EXTENSION); $file_name = md5($url) . '.' . $file_extension; $file_path = "$dir/$file_name"; if (!is_dir($dir)) { mkdir($dir); } }
WWW (doesn't work)
if ($this->archival_mode){ $url = base64_decode($url); $dir = plugin_dir_path(__FILE__) . "../$folder_name"; $file_name = basename($url); $file_extension = pathinfo($file_name, PATHINFO_EXTENSION); $file_name = md5($url) . '.' . $file_extension; $file_path = "$dir/$file_name"; if (!is_dir($dir)) { mkdir($dir); } }
Seems indeed identical to me... Just in case, deleted previous plugin and reinstalled from the latest download (earlier today)
And the other problem is that I never get this url=aHR0cHM6Ly9zMy5tYXN0by5haS9tZWRpYV9hdHRhY2htZW50cy9maWxlcy8xMDkvMzg0LzA2NC83MjEvMDE0LzU4My9vcmlnaW5hbC9kMDc2MTQyNjc3NjQwZGZmLnBuZw== in the source code... Instead of the Base64 encoded URL, I'll get the real URL...
=> Critical error is back on WWW...
To summarize: Base64 encoding and decoding doesn't work on this blog... but works fine on the other one...
I just tested this (very basic and just in case): added a Base64 encoded image in a post via an "img src" to see if it renders. It does.
data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAEAAAABACAMAAACdt4HsAAAAz1BMVEUAAAAArO4Cq+8Aq/YArO4Cp+wArPIAtvEAre4ArO0ArO0ArO0Aq+0Are0ArO0Dre0BrO0ArO4ArO0Are0ArO0ArO4Bre4ArO4Are0DrO0Bq+0Aqu4ArO4ArO0ArO4ArO0ArO4Bre4ArO4ArO0ArO0Are4ArO0BrO4Are0Are0Bre0Are4ArOwFru0Iru0Dru4Aq+0Aru8AqvAArO0ArO0ArO0ArO0Aq+4ArOwDrO4Aq+0ArO4fsu8ArO4Aqe0Lr+4BrewArO0Aq+0ArO0ArO2zodcjAAAARHRSTlMA+wsHlA4EAe728Nqsnm4kyY96YuLRsX5dRzksHene1bm2h2hVUM7EvKijdnQ0MSEZFRL48uaCTEM+KVpMOxHNv5pKiyP9SJgAAAKXSURBVBgZ7cFVYttQFAXA88QMlpmZme000Pbuf01N3CqG6DlSPvLVGfz3nWR3OpnOBHyNcGj5w2wjazeDiYJ3goBYlMdtv0InLJ0dlfCXcEgtcdKWcY8Q9HU6M6yOAqjl3fbFEvGmnBmL4JNTabrWDaadsd1dGQWctGjTEsGjjDS6ZWYzBhHzRbxR60TVlgiOToU4sjNAACBrRJR2ZESaexSNWRPF7ewAuPRmk5sjikPR9LqTzw2zBQBFOjGkIj4SMhRN779UV5qjACjSX6yRl3FrwojPyAl4daSQ2SwquDYmPm37hDeyQaFV3SmpuGQTVzr1hBO1R2ea5UxEnDWIx2wJ+GdElyrZ3K+yin/qxDNUEHIrdEX37HGn9KTilUU8Et6pv+mW0bX8cX73OLWJx8fZzKMI62q3b3WJp4mQAuxMSmyMUCnvikGGknpAaGcOU4GtUUIHhKZEetXTKBlWRuhJoy9IiwipDfqCBs7y9AUpnC0ylBh7xIX8mpJKy7ggSIwSsnFlNmCUCCvgWumnQUnUZNwopzxG8aXwgVhoNqoU08bFrf1DJ5AyFJOv4lbezNSqBsWTPuKDsknx5VR85Kworm4ZEZYDimndRqRSg+KRREQrDnSKoeeC59isMfqMuQef3JZ6FUb3VAIV9yz2raatEZc2EvGZiaQRj5YS8InFw2BNPJuUjPvmbckkrpoj4A51UWz9rDHiYfW2iAjz+XK5KB8PbUeqb4ivIhURyQ18SbKtfs2gO/S+M0c0oeBnGN3HvO2jAq5lx/d04lv3mr8E3LUs5CyTURS9NhjtZXxKLD1sB156RZf0am+Yax8VxCO6hSAnDbMv3vPzc69u2f4ov58pSERZuNPDj1eFYmkmq/jve/wB6owEsg4cvccAAAAASUVORK5CYII=
Update: I edited my "reference" post (see above), removed all embeds, and added them again from scratch.
@cybeardjm Any luck resolving this on your end?
Hi Stefan, thx for asking. I retried the other night, after updating various plugins, but no luck... Problem is still here... There's something somewhere that blocks access to the URLs, but have no idea what... DJM
On Thu, Oct 5, 2023 at 9:43 PM Stefan Bohacek @.***> wrote:
@cybeardjm https://github.com/cybeardjm Any luck resolving this on your end?
— Reply to this email directly, view it on GitHub https://github.com/stefanbohacek/fediverse-embeds-wordpress-plugin/issues/22#issuecomment-1749614258, or unsubscribe https://github.com/notifications/unsubscribe-auth/AMQ4RPY4RPFMCVMEFDPDQZLX54LYTAVCNFSM6AAAAAA43E5KBWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONBZGYYTIMRVHA . You are receiving this because you were mentioned.Message ID: <stefanbohacek/fediverse-embeds-wordpress-plugin/issues/22/1749614258@ github.com>
This was resolved. Steps done:
- removed the past plugin
- made sure to clean the DB (table + options)
- redownloaded from Github to have the "latest" version
- installed, checked settings to create options.
- "test embed" works fine!
Thank you @cybeardjm for all your help!
Hi, Here's what I get in my server's errorlog, when I try to view embedded Mastodon posts with the latest FediEmbed plugin on my subdomain WWW.
There's a conflict somewhere but I can't find where...
Context: WP 6.3.1 No Firewall/security plugin. Happens even in troubleshooting mode, with this plugin as the only active one. Have a second blog on a subdomain that works perfectly: see https://amf.didiermary.fr/rss-club/king-juju-music/ Had to change theme, as previously with twenty-twenty, the iframes rendered when editing a post, but didn't render at all in preview mode or once published (not even a blank block, nothing but the text around - although code was present in the source), and even when removing all plugins.