ChatGPT has determined that the PDF Embedder CSS and JS is not being loaded for logged out users.
Link to chat (skip over the 2nd interaction, I was checking custom CSS we inject on our pages): https://chatgpt.com/share/67dca113-22d0-8010-aee0-3333c7ae1dca
We haven’t implemented any MemberPress restrictions on this particular post, nor have we implemented any file-type-wide restrictions using MemberPress, so I can’t figure out what is causing this.
Hello @shamrock82
It looks like PROBLEM 1 and PROBLEM 2 are both a caching issue.
Our plugin does not care whether this is a logged in or logged out user that is currently viewing the file.
Make sure you exclude PDF Embedder assets from the caching mechanism you have set up on your site. Here is a related article: https://wp-pdf.com/docs/using-caching-or-minifying-plugins/
You may also have other plugins that try to control which plugins and their assets are being loaded for different users.
We don’t have caching enabled on our site because MemberPress advise against it and I have disabled the only plugin we had that optimizes/minifies CSS or JS (SWIS Performance).
Have you tested your plugin with Beaver Builder? Are there customizations that need to be made to your plugin or to our Beaver Builder theme in order for PDF Embedder to work properly?
We don’t support Beaver Builder preview mode (when you see a page preview with our PDF Viewer inside the Beaver Builder editing interface), but our plugin should work just fine when you use a shortcode inside of text modules in its builder.
Regarding the assets – that’s definitely some kind of caching for logged out users. Maybe it’s on a network level (Cloudflare) or inside one of the WordPress plugins – we don’t know.
Something is definitely preventing our plugin from loading its CSS files, so you should take a look. Maybe there is something that is bundling your CSS files, or moves them to a different host (I see some CSS files are being loaded from the assets subdomain).
PDF Embedder JS assets are loaded just fine, it’s just the problem with the CSS not being loaded from assets.*.
We’re using WP Offload Media on our site (by WP Engine).
WP Engine are telling me:
[Me] I’m assuming we don’t need to implement any extra customizations to the AWS Cloudfront server for Assets, is that correct?
[WP Engine] Yes, as long as our Assets Pull guide was followed, it should be enough. The Assets Pull will take care of rewriting URLs for styles (CSS) and scripts (JS) which are registered through the WordPress enqueue system. If this isn’t the case for those scripts, you may try using the filter “as3cf_get_asset”, if possible. Please see documentation below on how it’s used:
https://deliciousbrains.com/wp-offload-media/doc/get-asset-url/
It may say at the top that it’s deprecated, but it’s only the old add-on plugin that is deprecated. The filter is still being used on the current code of WP Offload Media.
Does PDF Embedder use the “WordPress enqueue system” to inject CSS calls into pages?
@shamrock82
Yes, the plugin uses wp_enqueue_script() and wp_enqueue_style() functions to register its own JS and CSS assets.
To help others, I wanted to share that I’ve determined this is a conflict between MemberPress and this PDF Embedder plugin. It would be helpful if you could add this to the plugin’s documentation @slaffik
MemberPress Support: “After checking the issue, I noticed a conflict between the PDF Embed plugin and MemberPress. I think that’s because the PDF Embed plugin adds its stylesheets into the body, not into the head, which is not the best practice. So, I came up with this code snippet to load the PDF Embed stylesheet into the head, add it to the site theme’s functions.php file, and the PDF enclosure renders correctly now for logged out users.”
// Load the PDF Embed style add_action('wp_enqueue_scripts', function() { wp_enqueue_style( 'pdfemb_embed_pdf_css', plugins_url('pdf-embedder/assets/css/pdfemb.min.css') ); });
I requested a code fix that would only load the PDF Embedder CSS if a PDF was actually embedded on a page, rather than loading it (potentially when not required) on EVERY page.
// Load the PDF Embed style add_action('wp_enqueue_scripts', function() { if ( has_block('pdfemb/pdf-embedder-viewer') ) { wp_enqueue_style( 'pdfemb_embed_pdf_css', plugins_url('pdf-embedder/assets/css/pdfemb.min.css') ); } });
We opted to load styles inline when the shortcode/block is rendered to avoid extra overhead and performance issues when parsing the page/post content on whether the block/shortcode is present there for each request in order to determine whether we should include our styles or not.
I plan to release today a small hotfix release for Free – 4.9.1.
I’m not sure I will include the proposed fix there.
Could you update this thread or link to your release notes please if you push a fix that negates needing to manually implement the functions.php code fix above please? Thx.
I recoded this case in our internal system. If this change is released, I will definitely mention it in the plugin changelog so it will be clear that you can remove your codesnippet.
