Skip Navigation

[Resolved] Layout CSS file loads insecurely on https

This support ticket is created 8 years, 2 months ago. There's a good chance that you are reading advice that it now obsolete.

This is the technical support forum for Toolset - a suite of plugins for developing WordPress sites without writing PHP.

Everyone can read this forum, but only Toolset clients can post in it. Toolset support works 6 days per week, 19 hours per day.

No supporters are available to work today on Toolset forum. Feel free to create tickets and we will handle it as soon as we are online. Thank you for your understanding.

Sun Mon Tue Wed Thu Fri Sat
- - 14:00 – 20:00 14:00 – 20:00 14:00 – 20:00 14:00 – 20:00 14:00 – 20:00
- - - - - - -

Supporter timezone: Asia/Ho_Chi_Minh (GMT+07:00)

This topic contains 8 replies, has 4 voices.

Last updated by Beda 8 years, 2 months ago.

Assisted by: Beda.

Author
Posts
#419721

This is a serious bug in Layouts: the CSS file "wp_ddl_layout_fe_css" used by Dashboard-> Layouts-> Layouts CSS loads via http when used on an https site, i.e.

<link rel='stylesheet' id='wp_ddl_layout_fe_css-css'  href='<em><u>hidden link</u></em>' type='text/css' media='screen' />

How can I load this file via https? I tried copying all CSS from the Layouts CSS editor into my child theme, but the empty CSS file still loads.

#419776

G'day @emilyz

I'm a long time Toolset customer, like you, not a support rep.

This isn't a bug in Layouts, mate. I've got Toolset with layouts running on numerous sites that use SSL and I don't experience this problem. It'll be the server setup you're using. There's a lot of plugins that can help fix this out there - but it depends on whether you're using a real SSL cert on your server or an external one (like the one provided by CloudFlare.)

If it's internal you can generally fix it with some tweaks to .htaccess (or the site's .conf if on Nginx.) On shared hosting you may need your hosts' assistance.

#419846

As @scott correctly pointed out, this is not a Layouts BUG.

You can actually see it working just fine on this very site here.
Open your browser console and look for the same <link rel> as you mention.
You will see that it loads with HTTPS.

I added a ScreenShot.

I suggest you check with your Hosting Provider how HTTPS is set up on your end.

We can not assist issues with Servers, but what I can do if all fails, is to ask our Developers for some insight, but please acknowledge that Server Adjustments are not part of our Support.
https://toolset.com/toolset-support-policy/

Please contact your Server Admin and illustrate the issue, I am sure they will be able to help here much better then I do.

You can also check the Code that enqueues that Style Sheet in layouts Plugin in the file Layouts/classes/wpddl.cssmanager.class.php

It should load it with your Site's URL.
https://codex.wordpress.org/Function_Reference/site_url

#420077

Beda,

So you're telling me to fix this myself? Re: "You can also check the Code that enqueues that Style Sheet in layouts Plugin in the file Layouts/classes/wpddl.cssmanager.class.php"

This is a paid, professional support forum. I have asked questions here in the past and have never been told to fix something myself. If you can't fix this or give me a workaround, assign this to someone else at Toolset Support.

I am running Toolset Types, Views, Cred, and Layouts 1.7. This is the only https bug among all the scripts and stylesheets that all those plugins load. Yes, it has something to do with the site_url() function that Layouts uses. That function does not correctly account for the difference between http and https. That's a bug. This did not occur with Layouts 1.6.

I have no other issues with https and the SSL on my site or server; this is not a server or WordPress https configuration issue.

FYI, I had to earlier ask for help with a simialr http/https issue here: https://toolset.com/forums/topic/non-https-output-of-img-url/ The Toolset developers seem to be lacking in being sure Toolset and related plugins support https.

Are you going to provide a fix or workaround?

#420280

No, I do not mean you to fix it.

I meant you to browse as example https://toolset.com (which uses Layouts), and fnd the relevant section in the Browser Console, to see that it loads with HTTPS, as far I can see.

Also the code reference in the Layouts Pluigin, is for reference for you to see that we call site_url(), a function that will load HTTPS if it's available.
See the description:
https://codex.wordpress.org/Function_Reference/site_url

1. This is a paid, professional support forum. I have asked questions here in the past and have never been told to fix something myself. If you can't fix this or give me a workaround, assign this to someone else at Toolset Support.

- I never told you to fix this yourself. I mentioned, this is not broken, as working.
- I am an official Toolset Supporter.

2. It "uses" site_url() if using_permalinks() is true, which means, if you do use any permalink structure (i.e. not the default query URIs ?p=n, ?cat=n).
https://codex.wordpress.org/Class_Reference/WP_Rewrite

3. On the website you provided in above links, I do not see the layout CSS you mentioned loaded at all.
But I see the Layouts "ddl-front-end-css" and "menu-cells-front-end-css", both loading with HTTPS

Have you modified it so to not load the CSS?

You mention that this was not the case in a previous version of Layouts, and although I see it working on our own site just fine, I would like to help you and find out why now it's not loading with HTTPS anymore.

Do you have a Develop Server where I can see it working with the older version of Layouts, and then we could update layouts to see what is happening.

If you can not provide this, I can ask our Systems administrators if we can provide a HTTPS test ground for this.

#420533

1) This IS broken.
2) I am using standard WP permalinks of "Month and Name"
3) You don't see the style sheet link in my page source because I disabled the output of the style sheet link in the file wpddl.cssmanager.class.php so my site does not show "insecure element" errors to users.

Before that, I tried removing all CSS from Toolset>Layouts CSS, but Layouts still output the same link to the empty CSS file /wp-content/uploads/ddl-layouts-tmp/...css

4) We do not have a dev server that you can have access to.

The easiest thing for you to do is make the use of site_url() protocol agnostic. In other words, change the function that uses site_url() so it returns //domain.com rather than hidden link or hidden link The style sheet link is only in <head>, so that will work.

#420678

Dear Emily,

I apologise for the delay, I am Toolset Lead developer and I am in on behalf of Beda to help.

The issue you reported is given by a incorrect behaviour of "wp_upload_dir" function, to create the upload directory if it doesn't exist and get its path and url.

Sometimes the function is not able to return the url with the right protocol, to prevent this problem I wrapped the url call into "set_url_scheme" call, that should set the right protocol for us.

This fix will be available in the upcoming release, in the meanwhile you can workaround the issue by uncomment the line you mentioned and change it to:


wp_enqueue_style('wp_ddl_layout_fe_css', set_url_scheme( $this->uploads_obj()->baseurl, 'https' ) . self::CSS_TEMP_DIR . '/' . $md5 . '.css', array(), WPDDL_VERSION, 'screen' );

The "wp_upload_dir" function and "set_url_scheme" without the "https" explicit argument may not work under server behind a load balancer or a reverse proxy (https://codex.wordpress.org/Function_Reference/is_ssl), since they are using "is_ssl" function that may not work under those conditions.

To prevent that I suggest you are using the "https" argument to force the protocol, but for future versions, just to make sure that this problem won't happen again, consider adding this code in your wp-config.php file:

if (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] == 'https')
    $_SERVER['HTTPS'] = 'on';

as suggested here: https://codex.wordpress.org/Function_Reference/is_ssl

This should solve the problem at its root.

I hope this helps, best regards
Riccardo

#420744

Riccardo,

Thanks for the explanation and the workaround. That fix works, either using

$this->uploads_obj()->baseurl, 'https'

or

$this->uploads_obj()->baseurl, ' '

; both show a https link in the browser source.

I'm on WP Engine (managed hosting) and I can't add anything to wp-config.php; the current force SSL line in wp-config.php that WPE uses is

if (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] == 'https') $_SERVER['HTTPS'] = 'on'; 

so maybe that's the load balancer you're talking about. I'm not using any SSL plugins; and I replaced all http URLs in the database with https when I migrated to SSL last year, so I have no other non-https errors.

But this was the second instance in Toolset where I got an http link instead of https; this is a previous post where a dd-layout-cell template file outputed an http URL https://toolset.com/forums/topic/non-https-output-of-img-url/ And where support gave me a function to fix it.

Thanks

#420904

I am happy our Developer could find the issue here and solve this edge case for good.

Please let me know if we can do anything more about this for you, otherwise I will mark this as resolved.

Thank you for your patience

This ticket is now closed. If you're a Toolset client and need related help, please open a new support ticket.