3d Flipbook Lite
I believe the 3D Flipbook lite plugin is supposed to create an output like this: https://flipbooks.futuresinitiative.org/blog/
We have a group trying to use the plugin to create a flipbook pdf on the Commons on this site: https://cunyhumanitiesalliance.org/
When they try to upload their pdf they are getting an error, see screenshot.
I tried to recreate the error on my test site here: https://classtestbmcc.commons.gc.cuny.edu/2023/05/11/flipbook-post-test/
I could not re-create the same upload error. But even once the flipbook pdf is embedded in a post, the flipbook will still not display. It flashes as it loads and then disappears. I wonder if the Commons blocking of iframes is causing this error?
I am not sure about the other error, I have asked the user for more info on the pdf they are using.
Updated by Boone Gorges 5 months ago
At a glance, it appears that the screenshotted error has to do with domain mapping. It would probably go away if you replaced 'cunyhumanitiesalliance.commons.gc.cuny.edu' in the source file URL with 'cunyhumanitiesalliance.org'.
As for the problem on https://classtestbmcc.commons.gc.cuny.edu/2023/05/11/flipbook-post-test/ - I am seeing the same behavior. But when I try embedding a flipbook on a different Commons site, it works as expected. I suspect that there's a plugin conflict. Perhaps you could try on another Commons site to see what you find?
Updated by Laurie Hurson 5 months ago
I was granted access to the site and still cannot get it to work.
I changed the file url, see screenshot.
And i tested it on the site here: https://cunyhumanitiesalliance.org/?p=4091
Updated by Boone Gorges 5 months ago
- Category name set to Domain Mapping
- Status changed from New to Reporter Feedback
- Assignee set to Boone Gorges
- Target version set to 2.1.7
It looks like you can change the URL, but after saving, it goes back to the old one. It's an interface quirk in the plugin.
Looking more deeply, it appears that the 3d flipbook plugin pulls up information about the source PDF in such a way that Mercator can't apply the mapped domain (technical note: it does
get_post_meta( $post_id ), which bypasses the necessary filter points). Luckily the plugin provides a filter that I was able to use to correct the incompatibility. See https://github.com/cuny-academic-commons/cac/commit/3797ae1b16a48425eb984b989ac692c1fbd9189d. Laurie, this change is live on production for you to verify.
Updated by Laurie Hurson 4 months ago
Thanks so much for taking a look Boone.
I tested it on production and it appears to be working https://sitetest4.commons.gc.cuny.edu/2023/05/15/flip-test-1/
Just confirming this fix will also work on a mapped domain like https://cunyhumanitiesalliance.org/?
Updated by Boone Gorges 4 months ago
- Assignee changed from Boone Gorges to Jeremy Felt
The fix is deployed, but apparently there's some other issue causing the item not to load. (Previously, the Flipbook application wasn't loaded, while now it's loading, but it's not fetching the PDF.)
Jeremy, could you have a look? You might have some experience here, and this could be a good way to try out your server access.
Updated by Jeremy Felt 4 months ago
I configured a mapped domain locally with all of the same plugins activated and everything works as expected with the PDF file from https://cunyhumanitiesalliance.org/flipbook-test/. I've set a few breakpoints in the minified JS, but nothing obvious has popped out (there's a lot of JS).
I'm having trouble accessing log files, and I'd like to check for anything there before digging through the JS any further. We can chat about that on today's call.
For future reference:
wp plugin list --status=active --url=https://cunyhumanitiesalliance.commons.gc.cuny.edu returned:
+------------------------------------------------+--------+------------------------------+--------------+ | name | status | update | version | +------------------------------------------------+--------+------------------------------+--------------+ | interactive-3d-flipbook-powered-physics-engine | active | none | 1.15.2 | | add-category-to-pages | active | none | 1.2 | | authors | active | none | 2.4.8 | | category-posts | active | none | 4.9.15 | | category-sticky-post | active | none | 2.10.1 | | contact-form-7 | active | none | 5.7.6 | | custom-user-css | active | none | 0.2 | | google-docs-shortcode | active | version higher than expected | 0.5-bleeding | | imsanity | active | none | 2.8.2 | | inaccessibility-checker | active | none | 0.0.3 | | posts-in-page | active | none | 1.4.4 | | really-simple-breadcrumb | active | none | 1.0.2 | | shortcodes-ultimate | active | available | 5.12.11 | | table-of-contents-plus | active | none | 2302 | | text-to-speech-widget | active | none | 1.0 | | wp-accessibility | active | none | 2.0.1 | | wp-ms-request-membership | active | none | | +------------------------------------------------+--------+------------------------------+--------------+
Updated by Laurie Hurson 18 days ago
Are there any updates on this? Do we think we can get it working? And if not, maybe we should go with another flipbook plugin?
An alternative might be to make it possible to embed issuu into the commons, which might be a workaround/alternative to another flipbook plugin. Example:
Updated by Boone Gorges 13 days ago
Laurie, thanks for your patience and for the ping.
I think I've found the issue. When editing items in the 3d-flip-book post type, you use the Media Library to select the PDF to be used. At this time, the plugin uses the 'url' returned from the Media Library to fetch the PDF and store metadata about that PDF, which is in turn used when rendering on the front end. In the case of the cunyhumanitiesalliance.org site, this metadata hadn't been properly generated. Looking into why this might be the case, I noticed that the Media Library on mapped sites returned non-mapped versions of attachment URLs. So the URL reported by the media library was
https://cunyhumanitiesalliance.commons.gc.cuny.edu/wp-content/blogs.dir/9457/files/2023/05/C21-showcase-test1.pdf instead of
https://cunyhumanitiesalliance.org/wp-content/blogs.dir/9457/files/2023/05/C21-showcase-test1.pdf. This mismatch was causing the plugin's async fetch to fail, which is why the metadata was never fetched.
What I'm wondering is, what should our strategy be here? Temporarily, I have put a filter on 'wp_prepare_attachment_for_js' that forces the 'url' parameter to use the mapped domain. This seems to fix the immediate problem. But I am unsure about how broad of a fix is appropriate. For example, if I were instead to filter 'wp_get_attachment_url', then the mapped domain would be used in all places, on the front end as well as elsewhere in the Media Library (as in the 'sizes' array). Or, going up one level more, I could apply the filter somewhere in wp_upload_dir, to ensure that baseurl and url are always mapped-domain-specific. Mercator filters 'home_url', 'site_url', 'plugins_url', 'content_url', but
wp_upload_dir() uses the unfiltered
WP_CONTENT_URL constant. Why? Is this a mystery that we want to solve? My gut says that the most conservative fix is at
wp_get_attachment_url(), since then all URLs for attachments will be mapped consistently, yet this is a narrow enough fix that it won't have weird implications. But I would like thoughts from Ray and/or Jeremy about this.
Laurie, could you please test my production hotfix to verify that it's working now?
Updated by Laurie Hurson 13 days ago
I can see the flipbook working on cdev but not on a mapped domain.
I can't reach the humanities alliance site on cdev. I have this in my terminal:
Where am I going wrong? Sorry for this question. Once I can get to the HA site on cdev I can check it out.
Updated by Boone Gorges 12 days ago
- Status changed from Reporter Feedback to Resolved
Thanks for confirming!
Jeremy and Ray, I've put a filter in place that targets
wp_get_attachment_url on all mapped domains. This should mostly affect the Media Library, but might also affect the front end in certain themes or with certain plugins. I've looked through some other filters mentioned by Ray in #15767 but I've determined that either (a) they're not relevant to the current issue (such as the 'custom_header' filters) or (b) they're covered by the filter I've put in place (such as the building of srcset). See https://github.com/cuny-academic-commons/cac/commit/abeb832bbafb6b8ef88c5da9aac3355ebfe3d323. I've deployed this into production and confirmed that it fixes the current issue, so I'm going to run with it for a while and we'll see if we get similar reports, or reports of side effects.
Updated by Raymond Hoh 12 days ago
Thanks for looking into this, Boone.
'wp_get_attachment_url' seems to be the way to go for now.
Or, going up one level more, I could apply the filter somewhere in wp_upload_dir, to ensure that baseurl and url are always mapped-domain-specific. Mercator filters 'home_url', 'site_url', 'plugins_url', 'content_url', but wp_upload_dir() uses the unfiltered WP_CONTENT_URL constant. Why?
But, yeah, I'm not sure why
WP_CONTENT_URL is used instead of
_wp_upload_dir(). I came across a WP Trac ticket talking about
content_url() here: https://core.trac.wordpress.org/ticket/25650#comment:19