当我知道哪些文件正在产生错误时，修复PHP中的Wordpress插件的HTTPS错误，混合内容错误？

Question

I am trying to fix another developer's Wordpress plugin that I would like to utilize but being my wordpress blog is 100% HTTPS (Shared SSL Certificate with CDN) it creates mixed content errors on the admin panel as well as if displayed on the website. I am not a PHP guy but I have done a lot of coding over the years and code review so I would like to try to work through this.

All other plug-ins on my website do not require me to use any forced SSL method, and I have already followed the guides for implementing SSL / HTTPS. I have no other SSL/HTTPS or mixed content errors and I do not want to go back to having to use it as it created other issues.

I have used the Firefox Inspector and know which files generate the issue: http:///wp-content/plugins//resources/scripts/.js http:///wp-content/plugins//resources/css/themes/default/jquery-ui.css As well as it serves up images for the plug-in as HTTP.

The Plugins.php file that I open in Firefox shows it registered as HTTP vs. HTTPS.

What I have looked at: I have scanned the code for HTTP and not found any HTTP outside of the header docs and confirmed that the plug-in gets its GoogleFonts and Google CoreChart from https://www.google.com/jsapi .

I have done some reading and am not clear on "this.url" usage or if this is the source or not but have read others have the problem.

I have scanned the code and did not see any paths that were not ended with a \\ that were not parameters to a specific file themselves.

     * sets up the object with the AJAX url and security nonce, also retrieves language properties
 */
setup: function(url, nonce, pluginUrl, userId, callbackFn, skipLoadGlobals) {
    if(!PI.ajaxSetup) {
        // create custom widgets
        initPICustom();

        PI.globals.pluginUrl = pluginUrl;
        PI.userId = userId;
        this.url = url;
        this.nonce = nonce;

        if(!skipLoadGlobals) {
            this.loadGlobalData(callbackFn);
        }
        else {
            callbackFn();
        }
    }
    else {
        alert('Ajax setup function already called');
    }
},

All of the other references to the URL look something like the following:

    getUserOldestResultYear: function(userId, callbackFn) {
    jQuery.ajax({
        type: "post",
        url: PI.Ajax.url

At least one of the files being reported is the Datatables plug-in that is about two years old, and JQueryUI 1.6 or 1.7 that is at least 6 years old.

I do not currently use the plugin and would like to. This plug-in is still updated is updated about once or twice a year, the developer has their freeware code on GitHub. So I would like to take a shot at fixing it or at very minimum give the developer very specific direction on how to fix it if I figure out most of it using my test site.

I cannot provide a link at this time to the specific site because I only activate the plug-in when I am actively working on it due to it resulting in errors on the rest of my site when I due activate it. I am looking for guidance on how to further diagnosis the issue and hopefully also how to fix it.

So my questions are:

1. Is there anything else specific thing I should be looking for in the code to possibly identify the source of these HTTP calls that I may be able to fix relatively easily in the code?
2. Would simply upgrading JQueryUI and DataTables and likely fix the issue or is this a red herring?
3. IF #2 is in the affirmative, I downloaded DataTables and the latest JQueryUI would attempting to upgrade the app to use it being they are so far behind likely end up in a total rewrite or is it something that is relatively managable? (ie I have some time but not a lot of time to try to fix this).
4. If the AJAX thing is related, how do I fix it?

Answer 1

The root of my problem was none of the above and it was a change in the way Wordpress internal variables worked.

The plug-in I was attempting to troubleshoot was utilizing the following:

define('WPA_PLUGIN_DIR', WP_PLUGIN_DIR . '/' . WPA_PLUGIN_NAME);
define('WPA_PLUGIN_URL', WP_PLUGIN_URL . '/' . WPA_PLUGIN_NAME);

New Code which per these two links stating to do not use the internal Wordpress variables and to use these instead took care of it in the primary plugin PHP file.

define('WPA_PLUGIN_DIR', plugin_dir_path( __FILE__ ));
define('WPA_PLUGIN_URL', plugin_dir_url( __FILE__ ));

But to recap my questions:

1. Checking the wordpress codex was what I needed to do to determine depreciated methods were being used.
2. Yes the old versions were red herrings and had nothing to do with it.
3. N/A
4. N/A