• Resolved efc

    (@eceleste)


    We are finding that this site, which uses Gutenberg, loads the form correctly in the Gutenberg editor, but loads the form without the stylesheet from the front end.

    When we try to load the page from the front end we get the following console error…

    Mixed Content: The page at 'https://oursite.org/contact/' was loaded over HTTPS, but requested an insecure stylesheet 'https://oursite.org/wp-content/uploads/forminator/165_9649800879847eb74f4d5d5407c34388/css/style-165.css?ver=1701104200'. This request has been blocked; the content must be served over HTTPS.

    The WordPress site is configure with proper “https” URL’s in the general settings. And, to repeat, the form loads fine on the back end in Gutenberg, stylesheet and all. So this feels like a problem with how Forminator is enqueueing the stylesheet on the front end.

    UPDATE

    We discovered that even though the general settings were showing our site as “https” and the site was appearing in browsers as “https”, the database disagreed. Somehow in the WP database the options related to the site URL were both set as “http”. We have no idea how these could be “http” in the database and show as “https” in the GUI settings of WordPress. However, once we edited the database so that it also had “https” values for these options, then Forminator behaved as expected.

    So this was not a Forminator issue at all, but somehow one of the database and GUI disagreeing about the URL of the site! If anyone has an explanation of how that might have arisen, we’d love to hear it. Thanks.

    • This topic was modified 1 year, 3 months ago by efc.
    • This topic was modified 1 year, 3 months ago by efc.
Viewing 3 replies - 1 through 3 (of 3 total)
  • Plugin Support Williams – WPMU DEV Support

    (@wpmudev-support8)

    Hi @eceleste

    I hope you’re well today!

    I’m glad that you found solution and thank you for letting us know about it. I’m sure this will help others experiencing similar issues so I appreciate a lot sharing it.

    Thank you again and I’m glad it wasn’t Forminator ??

    As for why there was such discrepancy between site’s settings and the DB, I admit it’s hard to say but the question is – which exact options were still using “http” instead of “https”:

    – if they were “siteurl” and “homeurl” in _options table – then it’s quite unexpected but could be possibly happening e.g. if site uses some custom code or 3rd-party plugin to force SSL; it’s unlikely and I never came across this but can’t rule it out also

    – if they were other options, then it does happen – due to how various plugins (especially if it comes to various page builders) and may actually require manual update

    But that’s just a guess, it’s really not easy to say without being able to directly check all that including DB (and we cannot do this).

    Kind regards,
    Adam

    Thread Starter efc

    (@eceleste)

    Adam, it _was_ siteurl and homeurl that were different in the database and UI! We’ve never seen this before and did not even know this was possible. We updated the database, but we still have no idea why the WordPress dashboard UI was showing us a setting that was not in the database.

    Just in case you are wondering, we had not set these in the WP config file either. This would have made them uneditable in the UI, which we would have noticed.

    Plugin Support Jair – WPMU DEV Support

    (@wpmudevsupport15)

    Hi @eceleste,

    Thanks for the update.

    A possibility is using a content fixer or SSL plugins, the use of those plugins could be a reason for the discrepancies between the URLs on your WordPress database and settings as they are designed to rewrite and change URLs in your site’s content and settings to use HTTPS, improving the site’s security. However, they might not always update all URLs in the database only those necessary for frontend display. This could lead to the scenario where the URLs in the settings are ‘https’, but those in the database are still ‘http’.

    Another possibility could be a partial or incorrect migration of your website. During a migration, if the settings were not updated properly, or if a change to the website’s address was made without updating the settings, discrepancies could occur between the database and the GUI settings.

    This could also be related to the caching issues, where the value displayed in the GUI was cached and doesn’t represent the actual value in the database.

    Either way, the important part is checking that the site URL and home URL match across both your WordPress settings and your database before installing or updating plugins. This concept also applies for scenarios involving site migrations or URL changes.

    Kind regards,
    Zafer

Viewing 3 replies - 1 through 3 (of 3 total)
  • The topic ‘Forminator stylesheets loading as HTTP on front end’ is closed to new replies.