Jump to content

Empty language variables

Recommended Posts

I'm experiencing a strange issue with my WHMCS in production environment...

There're a number a language text variables (few defined in lang/overrides , other defined in languages files in modules directory) which seems to be no effective... where they should be displayed, ... empty!!! 😮
but the same code in test environment works fine ... ☹️☹️

just for example: this does not work with the text variables with the string which need to be inserted in <head>

So, in test environment I have:

<title>Domain Registration, Hosting Services, Cloud Hosting</title>
<meta name="keywords" content="domain registration, web hosting, cloud hosting, servers" />

In production, the very same code give:

<meta name="keywords" content="" />

This does not happen with all language variables, but only with a number of them... mostly of them works fine.

 Obviously there should be a difference between test and production environment... but I can't understand what it could be.

Anyone experienced such an issue, just to give an idea about "what" looking for?!



Link to comment
Share on other sites

48 minutes ago, Kian said:

What Smarty variables are you using in your tpl...


The TPL code as follows:

<meta name="keywords" content="{$LANG.meta_keywords_homepage}" />

and the variables in override file as follows:

$_LANG['title_homepage'] = "Domain Registration, Hosting Services, Cloud Hosting";
$_LANG['meta_keywords_homepage'] = "domain registration, web hosting, cloud hosting, servers";


Edited by Remitur
Link to comment
Share on other sites

It seems all correct.

Is it possible that you are watching your WHMCS with a language for which you have no override file or an override file without these two variables? Let me give you an example.

You have overrides/english.php with:

$_LANG['title_homepage'] = "Domain Registration, Hosting Services, Cloud Hosting";
$_LANG['meta_keywords_homepage'] = "domain registration, web hosting, cloud hosting, servers";

It's works as expected with English then you swicth language to Spanish. Since there's no overrides/spanish.php file both language variables will be empty for Spanish. Or maybe even if there's an overrides/spanish.php file but these two variables are missing. Also double-check that:

  • Override files are inside lang/overrides folder (e.g. lang/overrides/english.php, lang/overrides/italian.php, lang/overrides/spanish.php...)
  • The override file must be written in lowercase (english.php is correct. English.php is not)
  • Language file and its override must have the same exact name (e.g. lang/english.php vs lang/overrides/english.php)
Edited by Kian
Link to comment
Share on other sites

6 hours ago, Kian said:

It seems all correct.

This is the reason why I find it so strange... and also because in test environment everything works fine!

Further details:

  • it happens not with every language variable: it happens with some variables at the begininng of the override file, and with other variables at the end of the same file (maybe even with some variable in the middle, but I didn't find it yet)
    So, it seems not to be a parsing problem
  • it happens with some variables in the standard /lang/overrides/ files, and with all the variables regarding client area of an external module (defined in their own language file in the module directory)
  • I have three languages used; the variables affected exist in every one of them (for those defined in standard overide file); just the variables of the module are defined only in two languages out of three, but the issue exists also for the two existing languages
  • production environment has more resources available than test (i.e., memorylimit set to 256 MB, while in test is 128 MB): so it's hard to argue a generic "memory lack" issue
  • there're other few differences between test and production environment:
    • WHMCS 7.5.0 (production) vs 7.4.2 (test)
    • PHP 5.6.34 (production) vs 5.6.36 (test)
    • cURL 7.29.0 (production) vs  7.61.0 (test)

But none of these difference could explain such an issue...

I'll try (just to be able to say "I did it") to create the missing language file for the third language for that module, and then I'll open a ticket to WHMCS (but I know yet the answer: "update to 7.5.1. and retry!" :D )


Link to comment
Share on other sites

57 minutes ago, brian! said:

I suppose the addon in question is compatible with WHMCS v7.5 ?

Yes, it is.

And the issue does exist also with few "normal" language variables defined by me in the "normal" and generic override file (while others works fine)...   :wall1:

Edited by Remitur
Link to comment
Share on other sites

47 minutes ago, Remitur said:

And the issue does exist also with few "normal" language variables defined by me in the "normal" and generic override file (while others works fine)...   :wall1:

at which point, I would throw a {debug} into a relevant template and examine the $LANG array in the popup window - have the overrides/english.php (or other language) open, find where the missing string is in the overrides file, check out the language strings around it and then try find those entries in the popup window... with a bit of luck, if one (or more) of them is corrupt (invalid in some way), it's absence in the popup might indicate where the issue lies.

Link to comment
Share on other sites

11 minutes ago, Remitur said:

The bad thing is that the issue it's in production environment, and not in test... 

then you could always try...

{if $adminLoggedIn}{debug}{/if}

if you are logged into the admin area, and view the client area template you've added the code to, you'll see the popup window; if you are just a client (and hence not logged into the admin area), there will be no popup! ☺️

in any event, add the code, view the page that opens the window, then remove code and save - you've still got your popup window to work from and no client will be any the wiser.

Link to comment
Share on other sites

FIXED!!!!!!!!!!!!!!!!       :D

Using the trick suggested by @brian! I compared the lang variables in test and production environment... those in production environment ended just after the language variables loaded by a third-party module... I disabled that module, and now everything is running fine again.

The module, for reference, is the backorder module by Hexonet: https://hexonet.net/resellers/integration#whmcs

It's provided in source code, so it's possible to investigate how and why this strange issue... but not today.
Now I need a beer. Or even two... 😉

Thank you @brian! and thank you @Kian!


Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Recently Browsing   0 members

    • No registered users viewing this page.
  • Create New...

Important Information

By using this site, you agree to our Terms of Use & Guidelines and understand your posts will initially be pre-moderated