Site Categories is not following SSL rules. Can this be fixed?

I have done everything to force https in a MarketPress Pro3 network. I have the kitchen sink in wp-config and .htaccess. I double checked all assets, and installed WP SSL plugin just in case. There is an issue with Pro3 pagebuilder for image uploads, but the #1 cause of browser complaints is a "global site list", tested in 2 ways (as I don't believe I can use store picker in Pro3):

1) Site Categories lists global sites in a pull down menu - using http.

2) Pro3 floating globalstoremodal lists global sites - using http.

Can Site Categories be fixed? (I would like to use it for another category list.)

I noticed this in both php files: $blog, $blog_id, $blog_details

And Pro3 floating menu uses this:

$blog_details = get_blog_details($blog->blog_id);
$output .= '<tr><td>'.$blog_details->blogname.'</td><td><a href="'.$blog_details->siteurl.'" class="btn btn-small pull-right'.

Is there a way to force https somewhere?

Will 'http://' throw a browser fit in a line like this 'https://' : 'http://' ?

Thank you.

  • MoniQ

    I find it works better sometimes to focus in on a specific issue, than deal with all in one thread.

    Site categories will not serve up pages using https, and I do not have enough knowledge of php to force https in the script. I was hoping one with more site categories knowledge could help me.

    The other thread is dealing with WP SSL plugin support, and my site directly. Part of that process is cleaning out all https assets from plugins and theme script pages. Which is what has lead me here.

    I have spent many weeks doing this carefully, but find site categories out of my scope.

    Can someone help me please.

    Thanks.

  • Paul

    @MoniQ,

    Site categories will not serve up pages using https, and I do not have enough knowledge of php to force https in the script. I was hoping one with more site categories knowledge could help me.

    Ok. From what I can tell site categories should be working if your primary site is using SSL on the front-end. At least for the Site Categories landing page links to the various categories. I will look to see what I can figure out or verify it is or is not working under my own development system. Still depending on your specific setup there may still be issues.

  • Paul

    @MoniQ,

    Can you please provide more details on your setup. Specifically which sites within your Multisite have SSL?

    I've tested Site Categories this morning on my own development site and I'm not see in an issue. Here are the details for my own setup. Multisite is install in sub-domain mode. I have SSL enabled only on the primary site. All other sub-sites function as non-SSL http:// I have 5 test sub-sites site1 thru site5.

    Site Categories Landing Page
    When I view the Site Categories landing page on the primary site I see the various site categories which link to the respective site listing. All these links are correct https:// Also confirmed the site category image is linked using https://

    When I click on a specific category and view the new page showing the sites within that category I noted the link to the sites are all non-SSL. Which is correct for my setup.

    Widgets
    When viewing the output of the widgets the links to the respective category pages to the primary site are all https:// also the optional link at the footer of the widget for the 'more categories' is also properly linked with https://

    So I'm a little confused on how you are not seeing theses correctly. Maybe something you changed in your setup.

  • MoniQ

    Thank you Paul for all your hard work as usual :slight_smile:

    In WP network settings,
    Domain: https://artcommons.ca, SiteURL: http://artcommons.ca.
    I assumed Site Categories and the floating menu in my theme was pulling http: from siteurl. Because I did everything I could to turn on SSL throughout the network, I was very confused to see http show up in the "view source code" for both of these.

    Jack helped me catch the last of the SSL issues in a plugin file that installed with my theme.

    I did a test at http://www.whynopadlock.com/ as he recommended. Remaining issue is the security certificate, which has a mismatched domain/account name. I have asked my server admin to fix this.

    The global site floating menu and the site categories pull down menu, show http when I view the page source code. If the padlock test does not say this is an issue - then am I out of the woods?!

    Look forward to your feedback.
    Thank you.

  • Paul

    @MoniQ,

    If there is anything else I can learn form this...

    Sure. One important not is not ALL http:// references need to be make https:// In the case of an anchor it does not need to be https:// in order to pass the 'padlock' security check from the browser. Mostly this only applied to images, and other sources like JavaScript CSS, etc.

    Thought when I visit the URL provided via Firefox I get the same untrusted message saying you have an invalid certificate. This is not the same as something like Site Categories serving up http:// instead of https:// what this means is your SSL certification is not installed correctly.

    See the part of the image I pointed to. "www.artcommons.ca. uses an invalid security certificate."

  • Paul

    @MoniQ,

    So looking at the sidebar drop down finally. I see the non-SSL http:// in the drop down. and I agree these should be https:// I think your other configurations with rewrite rules and such are helping when someone actually selects on of those items in the drop down.

    Can you check or have your admin check the database setup? You want to check the wp_options tables for each of the sites which need to be served as https://. In those tables you need to check the value for 'siteurl' Does the URL value use http:// or https://

  • MoniQ

    Paul it sounds like you are saying Site Categories is working as it should. If there isn't anything else I can do in my wp-config or .htaccess files to help the plugin (see thread), than I think I can close this thread. If you would like to assist with SSL further, please hop over to the other thread - I would like both Jack and I to benefit from your notes.

    My site is padlocked now. But you are still getting a Firefox "get me out of here" warning? Interesting. It seems this is relating to the security certificate again. My server admin found a Firefox bug a few weeks ago, so I assumed this was fixed:

    The issue here is actually a bug in how the latest Firefox handles certificate chains -- Chrome and Opera can validate it fine; Firefox isn't seeing the certificate issuer properly and is thus treating it as a self-signed certificate. It *is* a valid certificate, and buying a second valid certificate would not have solved the problem; you would have seen the same thing.

    I will try to find a workaround.

    [later on...]

    I've found a workaround that seems to work (explicitly specifying the certificate issuer in the web server config, even though it's already given in the certificate itself) -- can you have WPMU Dev verify that it's OK now?

    Also, the problem is apparently specific to the Windows (and maybe Mac?) version of Firefox, which explains why I didn't see it until I dug out the Windows 7 laptop just now. The Linux version of Firefox doesn't have the bug and only gives the "mixed content" warning, not the "get me out of here" warning.

    Paul gave me the http://www.whynopadlock.com to test with, I have since requested my server admin fix a mismatched domain name issue with the security certificate that was found. It is a valid certificate though, so I am told. We'll see if this fixes it.

    Hope this works.
    Please feel free to continue in the SSL thread if you can.

    Thanks Paul.

  • Paul

    @MoniQ,

    Please see my previous reply. I had a trailing '.' on the domain. This is not the same as the referenced Firefox bug. But thanks. I'm getting the closed padlock now.

    Also see my previous comment on the wp_options table. This is where you should be controlling the https:// vs http:// The Site Categories plugin as well as any other plugin does not know or have the ability to read the .htaccess or wp-config.php settings directly.

  • MoniQ

    @Paul we must have been posting at the same time pretty much :slight_smile: Caught up now. I am glad you caught that...ok I think I have a pretty good understanding now of how things are working. I agree, I need to push one more step to resolve http/https, even though site is padlocked.

    Can you check or have your admin check the database setup? You want to check the wp_options tables for each of the sites which need to be served as https://. In those tables you need to check the value for 'siteurl' Does the URL value use http:// or https://

    This is what I see in my WP Network settings (refer to screenshots in other thread):
    Domain: https:// ... and SiteURL: http:// ...

    Would this be the result of installing WP using http?
    Is this fixable after the fact, or do I have to re-install using https?
    Or, can the WP SSL plugin force this change in the tables?

    Can you tell me where to find the tables on my server by any chance? (Server admin is not available at the moment). I can see my WP installation and phpmyadmin, but would not know where to find wp_options tables.

    Can you tell me how to change these values, or rather, whether or not the values can be changed in the tables, once I find them?

    I will pass this along to my server admin in hopes he can respond in 24-48 hours.

    Thanks Paul!

  • Paul

    Would this be the result of installing WP using http?

    Yes, Though most times you always install WP under the http:// then later add the SSL cert.

    Is this fixable after the fact, or do I have to re-install using https?

    Yes, but Im not aware of a way to make this change via anywhere in the WordPress UI. But changing the siteurl directly via the database fixes the issue.

    Or, can the WP SSL plugin force this change in the tables?

    The WP SSL plugin really does not work that way. That plugin like other SSL plugins work to filter the page requests when requested from the browser. It then converts http:// to https:// But when internal plugins like Site Categories query WordPress to ask for the URL for a sub-site within your system. WordPress returns what is stored in the wp_options table.

    Can you tell me where to find the tables on my server by any chance? (Server admin is not available at the moment). I can see my WP installation and phpmyadmin, but would not know where to find wp_options tables.

    If you have access to your phpMyAdmin then you should be able to list all the tables. Under Multisite WordPress creates multiple sets of tables for each sub-site. The primary site used during the initial WordPress install is always the first set of table and the table names look something like wp_options, wp_users, wp_usermeta, etc. The 'wp_' prefix may be different depending on your setup. But all the table in your system will have the same prefix.

    Then for the first sub-site the table have an addition elements. The tables will be named wp_2_options, wp_2_users, wp_2_usermeta, etc.

    Similar to that the next sub-site will be wp_3_options, wp_3_users, wp_3_usermeta, etc. follow?

    I can't tell you exactly how to make the change as I don't want to make assumptions about your setup. Probably best to get your admin to followup. After all you are getting a valid padlock indicator on the browser. We are just talking about getting this issue with Site Categories resolved.

  • MoniQ

    Paul, many thanks. Answers are very helpful :slight_smile:

    Over weekend I did a couple plugin updates. Site barked at a http link in an updated js page. I will have the added task from now on to clean up assets after every update - great! Wish programmers would do one simple thing for secure sites... use '//' for links instead of http://.

    Or do I need to do a setting in the WP SSL plugin to solve this for me?

    Server admin got back to me finally and did search/replace in tables as requested. It broke a few images, but so far all is well. I will be testing the eCommerce backend this week.

    If I install any new plugins, will I have to search/replace again, or is this site good to go?

    Cheers!

  • Paul

    @MoniQ,

    Server admin got back to me finally and did search/replace in tables as requested. It broke a few images, but so far all is well. I will be testing the eCommerce backend this week.

    If I install any new plugins, will I have to search/replace again, or is this site good to go?

    Maybe you misunderstood. You admin should not have needed to search/replace all entries in your table. There is only the one specific entry in the wp_options table for the siteurl used by and controlled by WordPress.

  • MoniQ

    @Paul, hello. I am having issues with my site. I asked the server admin if he did all tables (search replace http/https) and he said:

    Yes, partially -- I omitted the "encoded" content, which I can't easily replace without either possibly corrupting it, or some manual tweaking.

    If it looks like one of these un-replaced areas is causing the current woes I can have a look at it, but I'll need the exact URL of the page where you're seeing a problem.

    What is the best way to clean this up?
    I have other threads that are talking about issues, but I feel they all may lead back here.

    He is getting back to me shortly.
    Thanks.

  • MoniQ

    @Paul, hello. I have been trying to create new sites (using new blog template "shop-template" default, rather unsuccessfully), but all new sites are listed with http in site categories menu and Pro3 floating global site menu (which both work in the same way). The site is padlocked, but browsers don't like the http links so it appears as though the site is unsecured ):

    I won't be able to search/replace in wp_options every time user creates a new shop. Anything I can do? Or is this where I "start over" and re-install using https from the beginning?

    If so, any steps I can do to save plugin and theme work to transfer that into new installation? Or do I build from the ground up?

    Thanks Paul!
    Look forward to hearing from you.

  • Paul

    @MoniQ

    The site is padlocked, but browsers don't like the http links so it appears as though the site is unsecured ):

    That is somewhat of a contradiction. If you are getting/seeing the padlock then the browser is 100% ok with the content. For the padlock not ALL http:// references need to be https:// It is ok to have anchor links using http:// Mostly the padlock requires things like JS and CSS and images to be https://

    I won't be able to search/replace in wp_options every time user creates a new shop. Anything I can do?

    Well first you need to blame WordPress Multisite. It is the one creating the new sites. I'm not really sure how to force it to create the site so the 'siteurl' in the new site wp_option has the correct https:// But that is your issue. Whch has nothing to do with Site Categories.

    Or is this where I "start over" and re-install using https from the beginning?

    I'm not aware of a way to that that. I don't know if you can install a site using https initially. Still it should all be in the database and/or wp-config.php where WordPress obtains its own information. So a full reinstall should not be needed.

  • MoniQ

    Paul, "So a full reinstall should not be needed." Hope so :slight_smile:

    Server admin feels multisite has bug, as it adds http to new sites in an https site.

    If the plugin and theme menus are working fine, great.

    I will focus on trying to get a subsite created without all this mess. I have a new blog template thread I am stumped on, trying to resolve this, and another thread trying to find out why new site admin users only have subscriber permissions - they cannot access menus i setup in easy blogging, and another thread trying to find out if my TT custom login.php and register.php are at fault somehow.

    I am not out of the woods yet!

    Thanks Paul!

Thank NAME, for their help.

Let NAME know exactly why they deserved these points.

Gift a custom amount of points.