[not a bug] Problem with {$systemurl}

[growe]

I am running 6.01

Regardless if I access my site using http:// or https:// the value of {$systemurl} always is http://

This poses a problem with using <base href="{$systemurl}">

 

Is this a bug in this version of WHMCS?

[brian!]

there is another variable that stores the Secure URL - {$systemsslurl}

[growe]

there is another variable that stores the Secure URL - {$systemsslurl}

 

Yes but {$systemurl} is supposed to be an intelligent variable and return the correct value (SSL or Non-SSL) depending on config and access method

[brian!]

Yes but {$systemurl} is supposed to be an intelligent variable and return the correct value (SSL or Non-SSL) depending on config and access method

you mean it did in v5.3 - it doesn't necessarily follow that it's meant to do the same in v6 !

 

if this is the case, I suppose short-term all you can do is to check if $systemsslurl exists and use that, otherwise $systemurl.

 

the only way you'll get a definitive public answer, either way, on this would be to report it as a bug and see what Nate says - if it is a bug, they may fix it in time for v6.0.2; if not, you'll have to go with the above suggestion.

[growe]

I am uncertain how to (or if I can) move a thread from one forum to another so I am posting here what was originally posted at http://forum.whmcs.com/showthread.php?104546-Problem-with-systemurl&goto=newpost

 

I am running 6.01

Regardless if I access my site using http:// or https:// the value of {$systemurl} always is http://

This poses a problem with using <base href="{$systemurl}">

 

The proper usage is supposed to be...

{if $systemurl}<base href="{$systemurl}" />{/if}

however it ALWAYS outputs http://... even when it should output https://...

 

The workaround is...

{if $systemsslurl}

<base href="{$systemsslurl}" />

{elseif $systemNonSSLURL}

<base href="{$systemNonSSLURL}" />

{/if}

 

My support for this being a bug is...

When accessing the site via https://... the following values are output...

{$systemsslurl} outputs https://... (Correct)

{$systemurl} outputs http://... (*** NOT Correct ***)

{$systemNonSSLURL} is non existent (Correct)

When accessing the site via http://... the following values are output...

{$systemsslurl} outputs is non existent (Correct)

{$systemurl} outputs http://... (Correct)

{$systemNonSSLURL} outputs http://... (Correct)

 

Example url with issue... https://gjinternetsolutions.com/home/domainchecker.php?systpl=five

I realize the template used in the URL I supplied is a version 5 template; however, the issue is still present when using a version 6 template.

Edited August 8, 2015 by growe

[growe]

Ok... On your recommendation, I have posted this in the Bug Report forum and have posted more details in that thread.

 

See - Removed - Threads Merged -

[SeanP]

The {$systemurl} template tag seems to be based off of two configuration settings, not off of the URL you used to visit your site. It will show as http, even if you visited the site using https, unless these two settings are correct:

 

Under Setup > General Settings > General tab:

 

WHMCS System URL (Example: http://www.yourdomain.com/whmcs)

WHMCS SSL System URL (Example: https://www.yourdomain.com/whmcs)

 

The {$systemurl} tag will use the SSL address, set in "WHMCS SSL System URL", if you are on a page that requires SSL. If you are not on a page that requires SSL (such as the home page), it will display the URL set in "WHMCS System URL".

 

I have tested this on 6.0.1, in my dev environment, and it is working correctly.

Edited August 12, 2015 by SeanP

[WHMCS Nate]

Hello,

 

SiteOx has done a solid job of explaining how we use the SystemURL and SystemSSLUrl, while they can be confusing, at this time we are not interested in making a change. I would note that they arise from a time when the major issue was page load speeds and the overhead of doing SSL. These days there seems to be a push towards SSL everywhere as CPU speed has increased and the issues around third party monitoring have become more prevalent.

 

Any change to how these variables work or our policy more broadly around SSL, would need to come with a major version - so everyone in the ecosystem has time to adjust. Its something we discuss from time to time internally, but not something I expect to see changed due to a bug report. I recommend alternatively that work be done in the feature request system to build a more concrete alternative that works for a large swath of users.

 

Have a great day,

 

Nate C