I have an SSL https backend, but the frontend is not https for any visitors of the multisite.
I noticed when editing a button within a “call to action” section within the builder that it defaults to an address of https after you type in the name of the page and select the page… On the front end, this link will still be https as I tested it unless you edit it manually in the “Enter a post title to search.” dialog box… this is an issue.
In my case, it needs to default to an address of http as I can easily see website beginners overlooking this or not knowing the difference and it eventually leads to them breaking their subsite links to other pages or other places.
How about this: An option within the network admin config could have 2 drop down boxes, one for the “Frontend SSL” and “Backend SSL” and each dropdown can have 2 choices: http & https or maybe yes & no . And it will apply this to any link that is generated when making a link button or other builder link stuff.
Is there an easy and quick way to fix this in the mean time? I don’t want to tell users to check and edit their links before clicking save when the “Enter a post title to search.” dialog was supposed to properly make the link for them…
I believe we’re pulling in the URL for the link selector using the core WordPress function get_permalink, so there’s not anything we can “fix” as WordPress is returning the HTTPS version. That indicates that there might be an issue with your HTTPS setup. Can you double check that you are correctly setting that up for the admin only? This would affect any plugin or front-end code using get_permalink.
In the wp-config.php, I have this set to make just the backend https:
define(‘FORCE_SSL_ADMIN’, true);
if (isset($_SERVER[‘HTTP_X_FORWARDED_PROTO’]) && $_SERVER[‘HTTP_X_FORWARDED_PROTO’] == ‘https’)
$_SERVER[‘HTTPS’]=‘on’;
There are no other network activated or individual SSL forcing plugins activated for this subsite. I have the wpmudev domain mapping plugin with the force SSL setting NOT set.
Any links generated by WordPress on the blog or page listings when you click “view” goes to the correct http address. The permalinks that show at the top of editing a page or post points to the correct http address. Under the network “My Sites” and under my site’s “Visit Site” link, it points to the correct http address.
Thanks for the detailed follow up. I’m a little stumped here as we are using a WordPress function to generate the links and aren’t doing anything custom.
I looked at the code for get_permalink and it appears that they are using the home_url function to build the link. Is yours set to HTTPS in the admin settings? That could be the issue as home_url checks to see if HTTPS is enabled when building the URL.
To check home_url, I wrote a simple php script with my limited knowledge of making plugins:
<?php
/*
* Plugin Name: Home_url test
* Description: Test for home_url
* Version: 1.0
* Author: Sombody
* Author URI: http://something.com
*/
add_action( 'admin_menu', 'my_URL_menu2' );
function my_URL_menu2() {
global $url;
$url = home_url();
add_submenu_page( 'themes.php', 'test_menu_item', 'Your Home URL', 'manage_options', $url, '', 'dashicons-update', 12 );
}
It makes a submenu item under the ‘Appearance’ menu named ‘Your Home URL’ that links to $url, which is home_url(). And the url that it links to is the non-ssl http version of the home page.
Perhaps there is are a few places in the wpbb plugin where I can modify the scheme of home_url, as this seems like it can be easily modified.
We’re not actually using home_url here, we’re using get_permalink which uses home_url. You might consider checking out the post_link filter to adjust the scheme…
Thanks for the reply! Your answer led me to finally look into what makes the get_permalink function work.
I decided to look into exactly what get_permalink does in wordpress, going so far as to mod the wordpress file that has get_permalink function to force http, but it made no difference. Took that mod out.
Then I looked at the wp-beaverbuilder plugin /classes/class-fl-builder-auto-suggest.php file (auto suggest seemed like the feature in question). Under ‘static public function links()’, I modded the following line:
$data[] = array(‘name’ => $post->post_title, ‘value’ => get_permalink($post->ID));
to be $data[] = array(‘name’ => $post->post_title, ‘value’ => substr_replace(get_permalink($post->ID), ‘http’, 0, 5));
Basically replacing the string’s first 5 characters “https” with “http” when auto suggest puts the url into the text box. First time I modded code with it actually working! Links don’t have the “https” in them, just “http” now. And everything publishes fine.
In my situation, this mod works, but it may not work for everyone: SSL Insecure Content Fixer’s is_ssl() test says false because I am behind a Varnish Cache server with Nginx as a reverse proxy handling SSL. Just about everything I know of in Wordpress itself shows the linking correctly except this function in Beaver Builder.
With every Beaver Builder update (Thanks for that last one!), I’ll have to mod this line. I’m unsure if this a problem other people are having, but is there something your team can do to make this issue a thing of the past?
Thanks for the additional info. To be honest, it feels like it would be bad practice to modify the permalink that way in our code, especially since we’re using a core function to retrieve it.
Why not use the post_link filter to replace https with http?
After some research on how filters work specifically with get_permalink, I put that function and add_filter you provided into the home_url test plugin (changed $url to $url2) I made earlier and it doesn’t change the auto-suggest links to just ‘http’.
Did I put it into the right place?
I think the script you wrote should work, but it’s not changing the permalink ‘https’ text for the auto-suggest.
Hmm… I noticed when I take out the HTTPS in the browser address bar and use HTTP instead, the auto-suggest links show up in HTTP. This still doesn’t explain why the rest of the HTTPS backend shows the permalinks and home links correctly with HTTP in it though.
What I am doing is having someone edit my .htaccess file to rewrite any URL with ‘fl_builder’ appended to the URL to be HTTP instead of HTTPS. Yes, I know this is unsecure for the pages being edited, but I am OK with it since the rest of the backend is secure- Besides, there are several things that keep causing the builder to break SSL with mixed content, most of them being the default images and small things like the image slider arrows and such. This htaccess patch may be one way around it.
That actually sounds like a pretty good solution. I must admit, I’m a bit stumped here as we are using a core function to get the permalink. Let me know how the htaccess solutions works.
I was not able to do what I wanted with htaccess, but was able to do this with editing Varnish’s default.vcl settings. For anyone interested, you can reference this page at the bottom, but reverse to http.
I’m thinking the https always showing up in auto suggest link that pops up + the filter fix not working is do to me having an reverse proxy handling SSL. Perhaps this is why I kept having htaccess issues with redirecting to https, but none with Varnish as it knows there is a reverse SSL proxy. Though, Wordpress itself has no problems redirecting… I’m likely going to stick to modifying BeaverBuilder for every single update unfortunately .
However, after having figured out how to go about this, I do notice that my website can be vulnerable to session hijacking on any non SSL page while logged in. So I finally decided not to have unsecure pages in any of the wordpress backend, setting varnish to rewrite any page that is http to https ONLY while logged in.
This leaves some common issues that I’m sure other people may have noticed: The Builder throws up mixed content errors if it’s under https- This makes the SSL browser padlock broken. As an agency website builder, this surprised me. The sample templates by default link to unsecure pages, and required builder images such as the image slider’s arrows etc., aren’t served over https either. There is no easy way around the mixed content warnings because of this without modifying code. Also, none of the images can even support ssl if you manually change the url to https.
Is this something your team can patch in the near future? What if the images were on some cloud service like Amazon S3 through SSL for example?
If i’m way off and there is some simple solution to this mixed content issue, please let me know!
I’m likely going to stick to modifying BeaverBuilder for every single update unfortunately
I’m sorry about that. I wish there was something more we could do, but since we’re using get_permalink, I don’t think there is regarding that.
The Builder throws up mixed content errors if it’s under https
We’re running Beaver Builder under HTTPS for every page of this site without any issues Can you tell me what specifically is causing that? We’re aware of the templates causing that issue, but haven’t heard of anything else. We will be looking at putting the templates under HTTPS in the future. Basically, we need to get the demo site on HTTPS and rewrite all of the links in the serialized templates data that comes with the builder.
With the auto-suggest I have to modify with every update, might I suggest a tiny new section in the plugin’s admin/network admin area for just the “Auto Suggest” feature where you can choose on a dropdown box “Force http”, “Force https”, and “Auto”. “Auto” would keep everything normal using get_permalink, while the other two selections would force https or http for any auto suggest in a similar manner to the way I did when I modified the builder plugin script. I wonder if there is any other part of the plugin I have not come across yet that could benefit from this URL changing?
Also, I was referring to the sample templates causing mixed content notifications in the browser. On that note, I noticed that many of the images that cause mixed content errors are referenced in the templates.dat file and css file. Do these files change much with every update of the plugin? (I would guess the css one might moreso…)
.
Can you tell me what specifically is causing that? We’re aware of the templates causing that issue, but haven’t heard of anything else. We will be looking at putting the templates under HTTPS in the future. Basically, we need to get the demo site on HTTPS and rewrite all of the links in the serialized templates data that comes with the builder.