How can I force admin-ajax.php to load over https?

We're using Elementor Pro which has a pro widget that uses ajax to submit contact and other form requests. This is also common with various woocommerce functionalities and contact form solutions like Contact Form 7.

The problem is I've enabled https on 100% of the site. All assets are loading over https except admin-ajax.php and a few other files from other plugins. Even wordpress core has it hard coded to use http version in its code.

How can I force these ajax requests to use the https version of admin-ajax.php?

I've followed all the advice here: https://codex.wordpress.org/Administration_Over_SSL

I've created an .htaccess rewrite rule for all assets on http to be redirected to https, but even this isn't working. I suspect these won't work since some of these calls are hard coded into the plugin code or because is_ssl() isn't working properly.

Any thoughts on how to fix it?

  • Kasia Swiderska
    • Support nomad

    Hello blue,

    I can see that your site is Multisite and if the admin-ajax.php is still loading from http it suggests that url of the site was not changed to https in all places in database.

    I did a quick test on my Multisite with HTTPS and admin-ajax.php in Contact form 7 loads correctly.

    Please take a look on this article https://www.siteground.com/kb/change-domain-wordpress-multisite/ – it describes how to change url to new domain for Multisite, but because some urls in DB have also http it should be also applied when switching to https.

    Please check if mentioned tables are changed correctly to https – if they are still http, update them.

    Let me know if that will help.

    kind regards,

    Kasia

  • blue
    • Design Lord, Child of Thor

    Thanks for the replies so far. But unfortunately, none of this is working. Although, that’s a great article find, and I’ve definitely bookmarked it for future use. It led me to something I wanted to avoid though, which was a database wide search and replace, but I did. So here is what I’ve done so far to try to solve the issue.

    1) Try everything at https://codex.wordpress.org/Administration_Over_SSL including define(‘FORCE_SSL_ADMIN’, true). Even though these are loading the wp-admin/admin-ajax.php file, this is happening from the front end.

    2) Added the following to my apache config:

    SetEnvIf X-Forwarded-Proto https HTTPS
    RewriteCond %{HTTPS} !=on
    RewriteRule ^/?(.*) https://%{SERVER_NAME}/$1 [R,L]

    3) use wp-cli to do a complete search and replace

    sudo -u www-data wp search-replace 'http://toursoft.co' 'https://toursoft.co' --network

    This replaced 151 items, even in the GUID column, which is highly advised against by WordPress. But it did not work. 0 instances of http:// remain in the database (see screenshot)

    Doing a stacktrace on the javascript code that causes the error shows that the code is correctly calling ‘ajaxUrl’ variable per WordPress coding standards.

    jQuery.ajax({
    url: t.getSettings("ajaxUrl"), <--- correct usage
    type: "POST",
    dataType: "json",
    data: t.getFormData(),
    processData: !1,
    contentType: !1,
    success: t.onSuccess,
    error: t.onError
    })

    somehow the ajaxUrl variable is only returning the http version of the script. How else can I investigate this?

  • Adam Czajczyk
    • Support Gorilla

    Hi blue

    I hope you’re well today and don’t mind me jumping in :slight_smile:

    I’d say that there’s still “something” that needs to be updated in the database. WordPress should properly call admin-ajax.php over http or https connection depending on Site URL/Home settings. If it does not do this this means that something’s interfering here.

    The data in the database may be stored as “plain” data or a serialized array. An array may also be – though it should not – an associative array and it seems that in such cases WP CLI might have issues. I’m not sure how Elementor stores/affects this but I think it might be related.

    Another possibility is that some plugin is affecting the way admin-ajax.php is called (or – rather – the URL of it).

    I’d like to take a closer look at this if you don’t mind but I would need a full access to the site for this, including files and database. If that is something you’re willing to let me do, please send in:

    Subject: “Attn: Adam Czajczyk”

    – Mark to my attention, the subject line should contain only: ATTN: Adam Czajczyk

    – Do not include anything else in the subject line, doing so may delay our response due to how email filtering works.

    – Link back to this thread

    – login URL and admin account login credentials (may be a temporary admin account) data

    – Include FTP log-in details (hostname, username & password)

    – Include hosting control panel access details (login address, username & password) – cPanel’s usually the control panel used for this, but your provider may use something else; I’ll need this for accessing your site’s database, preferably via phpMyAdmin

    – Include any relevant URLs for your site

    Please use our contact form here https://premium.wpmudev.org/contact/#i-have-a-different-question

    Best regards,

    Adam

  • blue
    • Design Lord, Child of Thor

    Just to update, this is now happening with the Hustle Pro plugin. From the modal window, when the form is submitted it calls the http:// version of admin-ajax.php and not the https:// version.

    Reference:

    https://developer.wordpress.org/plugins/javascript/ajax/#url

    https://developer.wordpress.org/plugins/javascript/enqueuing/#localize

    According to that it could suggest that there is PHP code somehow setting the incorrect version of the link? Everything I have read suggests that it’s ok to just call admin_url(‘ajax-admin.php’:wink: for actions on the backend (behind wp-admin/) BUT must use wp_localize_script() for all requests originating from the front end / anon usage. I’ve found a few places in Elementor where that’s happening, and now checking Hustle. It could be the case that not using wp_localize_script doesn’t take into account ssl?

  • blue
    • Design Lord, Child of Thor

    Adam Czajczyk Kasia Swiderska

    Hi everyone, I think Domain Mapping may be the issue here. I’m cross referencing these two posts as they seem to be related:

    https://premium.wpmudev.org/forums/topic/login-form-action-remains-http-for-unmapped-domain-on-https-only-site?replies=14#post-1320822

    https://premium.wpmudev.org/forums/topic/domain-mapping-causing-mixed-content-with-admin-ajaxphp-in-wp-admin

    I can confirm that if I turn off Domain Mapping, everything works as expected. If I turn it back on, everything breaks.

    • ChuckS
      • The Crimson Coder

      The “The link you followed has expired” turned out to be a conflict with the Enhanced Media Library plugin. But only if used on the main site. A continuing Parrot ThemeDomain Mapping conflict still exists, see post below.

  • Predrag Dubajic
    • Support

    Hi ChuckS,

    We do have a beta version ready, but it’s not fully tested yet.

    If you wish to try it out I will attach it below, but as mentioned it’s not fully tested so it’s highly suggested to install it on staging site first, or if you don’t have one make sure that you have full backup of your site before installing it on live site.

    Best regards,

    Predrag

    • ChuckS
      • The Crimson Coder

      Predrag, thank you for the beta plugin. The only Domain Mapping conflict that I see now is with the Upfront Parrot Theme. Unfortunately, the theme is used on the main site. So if I turn it off, I lose mapping to the other subsites. Guess I’m forced now to switch themes! Since the subsites are all live sites, I have not tried the beta.

      Chuck S.

  • blue
    • Design Lord, Child of Thor

    I wanted to mentioned a few additional issues we’re experiencing as we have tested this issue internally.

    In an attempt to discover where the error was, we of course disabled and enabled plugins, including Domain Mapping. Here are the issues we’ve been experiencing since disabling and reenabling Domain Mapping.

    1) With domain mapping off, all network domains that were mapped did not return back to site.example.com as expected. Instead, whenever we tried to access site.example.com it always redirected us back to the Pro Sites sign up page of the primary site. Is there a proper way to disable Domain Mapping so this works as expected when turned off?

    2) After we turned domain mapping back on, we started getting these errors in the error log files:

    [22-May-2018 17:21:25 UTC] PHP Notice:  Undefined index: HTTP_HOST in /var/www/html/wp-content/plugins/domain-mapping/inc/sunrise.php on line 27
    [22-May-2018 17:21:25 UTC] PHP Notice: Undefined index: HTTP_HOST in /var/www/html/wp-content/plugins/domain-mapping/inc/sunrise.php on line 28
    [22-May-2018 17:21:25 UTC] PHP Notice: Undefined index: HTTP_HOST in /var/www/html/wp-includes/ms-settings.php on line 57

    [23-May-2018 13:39:51 UTC] PHP Notice:  Constant COOKIE_DOMAIN already defined in /var/www/html/wp-content/plugins/domain-mapping/inc/sunrise.php on line 28

    I understand why I’m getting that last notice. It’s related to this 3rd issue:

    3) All new clients who have signed up after we reenabled domain mapping are now hitting the multisite login loop as depicted in this blog post: https://tommcfarlin.com/resolving-the-wordpress-multisite-redirect-loop/

    We tried to fix that with the solution in that post, but no luck. Apparently, sunrise.php attempts to take care of this issue. Here is a video of what our new clients experience after we turned domain mapping back on:

    https://www.youtube.com/watch?v=KMPyrWDG3eQ&feature=youtu.be&hd=1

    You can see from the video that despite the loops, a client is indeed eventually logged in. What you can see also is that there is a LOT of redirecting to and from SSL Mixed Content screens. We don’t understand how this is happening and why they aren’t being redirected to the login screen as specified. Another issue is after finally getting logged in, SOMETIMES a client gets this error:

    [image pos=”0″]

    We can’t say for sure if all this is related. We’re pretty sure the SSL Mixed content issue is, however. So we’re deferring to your advice about that. What we can say for sure however is that none of these log errors appeared in the database before we switched Domain Mapping off and then back on. We can also confirm that no user who signed up before domain mapping was turned off then on is experiencing the login issue – only new clients since turning it back on are having problems.

    Please advise.

    Thanks!

    Blue

  • blue
    • Design Lord, Child of Thor

    Issue 4)

    While continuing to test this, we've found an issue with Pro Sites that may be related because of how PS and DM are integrated.

    Our website toursoft.co and all subdomains *.toursoft.co are protected by SSL. A let's encrypt Wildcard certificate protects both.

    We have Pro Sites, New Blog Templates, and Domain mapping all working together to provide a solution.

    We have confirmed that when a new site is setup, Pro Sites (or one of the 3 plugins?) is not detecting that SSL is active and incorrectly setting siteurl and home to the http:// version of the domain and not https://

    Here is a screen shot of what it looks like immediately after being setup. Shouldn't this be https by default?

    For each of our sites we've had to go in and manually change http to https in the database. When we do, the mixed content redirects we see in 3) above lessen. Although, we still can't login.

  • blue
    • Design Lord, Child of Thor

    Kasia Swiderska It’s a production site, so no we didn’t download or install the new beta yet. We’re waiting for the official release of the new version. This still uses the most recent production version.

    We’ve been investigating the interaction between Domain Mapping and Pro Sites pretty heavily. We have found some more issues that may be contributing to the above, but can’t say for sure. Nonetheless, they are in and of themselves their own issues. Stay tuned.

    I will enable support for you.

    • Adam Czajczyk
      • Support Gorilla

      Hello blue

      Thank you for your response and for enabling access. However, since it’s a production site (and we currently also don’t have any other access that would help us revert changes in case anything went wrong) it might be a risk to test things there. I’d also like to suggest waiting for the official release if you cannot install Domain Mapping as testing that with current release (that doesn’t contain fixes) may actually lead to some conclusions that are not necessarily proper. What I mean is that those issue, even if they do appear with updated version, they might need a different “treatment”.

      My point is, the perfect scenario would be if you could actually set a staging site, test beta release of the plugin there and if the issues still occur there, provide us with a full access to it… Would that be possible?

      Kind regards,

      Adam

  • blue
    • Design Lord, Child of Thor

    We have many active, production, paying clients on our site, so we’re skeptical to try the beta version. Really Simple SSL is taking care of the problem for us at the moment, but it’s not without its own problems.

    I know that the plugin has to go through a QA testing process, but is there an estimated target for when a production ready version will be available / released?

Thank NAME, for their help.

Let NAME know exactly why they deserved these points.

Gift a custom amount of points.