• Was thinking this was a Divi Issue…but now not so sure, perhaps the developers could suggest a fix or a fix for the future version.

    Scenario:

    Using divi theme, I create a gallery and in the setting portion of the module, the thumbnails don’t show (the thumbnails point to the local non s3 path which given my settings to remove local file shows nothing)

    After randomly testing things, I have found that my images in the same site uploaded Sept 11, 2014 and earlier DO show the correct s3 path, then when testing October 10, 2014 and newer same issue.

    So something in the way things are saved in the database probably changed with the plugin that broke the compatibility with Divi…

    Suggestions on how to fix newly uploaded files and everything back to October 10, 2014?

    Running multisite, sub folder install

    Thanks!

    The page I need help with: [log in to see the link]

Viewing 7 replies - 1 through 7 (of 7 total)
  • Plugin Contributor ianmjones

    (@ianmjones)

    Yes, very likely a problem with Divi as it doesn’t use the WP API for handling all Media URLs. It looks like Divi has some support for WP Offload Media Lite, but it does not seem to be complete.

    The paid for WP Offload Media has a built-in integration for Divi Builder that works around its problems.

    https://deliciousbrains.com/wp-offload-media/doc/divi-builder-integration/

    @ianmjones sorry for the delayed response, and thank you for responding:

    I am also finding incompatibility for the basic customizer css in ALL themes, not just Divi.

    Specifically and consistently for:

    background-image: url("FILEPATH");

    Its been going on for quite some time ever since the big change in how files are handled, but perhaps you plugin developers can review this scenario of how css background image paths are handled.

    If in the css I place the full local or remote path, both paths when rendered out go back to local.

    I will also note that i am using this plugin in a sub-blog with domain mapping. And i do believe it is possible that the domain mapping plugin may also try to filter the path from networkdomain.com/subblog/FILEPATH.

    So here are some additional questions for this background css issue:
    1. Is it possible to ensure that a domain mapping plugin doesn’t conflict with your rewriting of the paths. (i am using the wpmudev domain mapping plugin)
    2. Is it possible if the remote path is manually referenced in css, to turn off the “un-filter” that reference? Perhaps this is a bug overlooked in the lite version?

    Thanks Ian

    @ianmjones can you confirm that you are also seeing issue with background-image css urls? Especially when using the domain mapping plugin from wpmu?

    Plugin Contributor ianmjones

    (@ianmjones)

    We thoroughly test the built in customizer on every major release of WP Offload Media Lite.

    We also thoroughly test using WP Offload Media Lite on both subdir and subdomain multisites.

    WP Offload Media doesn’t specifically support any particular domain mapping plugin, it shouldn’t have to if they do their job correctly and late filter outbound domains.

    Where it could get messy is if mapped domains are being written to the database content instead of the canonical domain for the site, then WP Offload Media will see what it thinks are domains from external sites in the media URLs and won’t touch them. In such a scenario the as3cf_local_domains filter may need to be used.

    https://deliciousbrains.com/wp-offload-media/doc/filtering-urls-for-multiple-domains/

    Ian, reviewing this:

    https://github.com/deliciousbrains/wp-amazon-s3-and-cloudfront/issues/467

    Looks like you closed this issue without reviewing the response to your suggestion.

    Further more, the rendered css is not showing the mapped domain, its showing the local network domain path to the local image file.

    Again…the scope of this bug is very narrow and show be quite easy to review: customizer css, background image, network subsite set up, wpmudev domain mapping plugin. Seems to occur with both a cname set up and non c-name set up.

    Everywhere else is working without issue, and perhaps this can expose additional issues with background css images…I don’t know. But surely its worth testing especially since I am giving you such a narrow scope.

    Plugin Contributor ianmjones

    (@ianmjones)

    @jiggaman Thanks for the bump, we do take every bug report seriously and have an internal issue open for this particular problem. Hopefully we’ll have the resources to investigate this compatibility with the WPMU Domain Mapping plugin soon.

    okay…cool. I believe in you!

Viewing 7 replies - 1 through 7 (of 7 total)
  • You must be logged in to reply to this topic.