Remitur Posted July 23, 2018 Share Posted July 23, 2018 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: <title></title> <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?! 0 Quote Link to comment Share on other sites More sharing options...
Kian Posted July 23, 2018 Share Posted July 23, 2018 (edited) What Smarty variables are you using in your tpl... <title>HERE</title> <meta name="keywords" content="AND HERE" /> ? Edited July 23, 2018 by Kian 1 Quote Link to comment Share on other sites More sharing options...
Remitur Posted July 23, 2018 Author Share Posted July 23, 2018 (edited) 48 minutes ago, Kian said: What Smarty variables are you using in your tpl... ? The TPL code as follows: <title>{$LANG.title_homepage}</title> <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 July 23, 2018 by Remitur 0 Quote Link to comment Share on other sites More sharing options...
Kian Posted July 23, 2018 Share Posted July 23, 2018 (edited) 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 July 23, 2018 by Kian 0 Quote Link to comment Share on other sites More sharing options...
Remitur Posted July 24, 2018 Author Share Posted July 24, 2018 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!" ) 0 Quote Link to comment Share on other sites More sharing options...
brian! Posted July 24, 2018 Share Posted July 24, 2018 weird. I suppose the addon in question is compatible with WHMCS v7.5 ? 0 Quote Link to comment Share on other sites More sharing options...
Remitur Posted July 24, 2018 Author Share Posted July 24, 2018 (edited) 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)... Edited July 24, 2018 by Remitur 0 Quote Link to comment Share on other sites More sharing options...
brian! Posted July 24, 2018 Share Posted July 24, 2018 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)... 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. 1 Quote Link to comment Share on other sites More sharing options...
Remitur Posted July 24, 2018 Author Share Posted July 24, 2018 31 minutes ago, brian! said: at which point, I would throw a {debug} into a relevant template The bad thing is that the issue it's in production environment, and not in test... I'll try debug deep in the night... 0 Quote Link to comment Share on other sites More sharing options...
brian! Posted July 24, 2018 Share Posted July 24, 2018 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. 1 Quote Link to comment Share on other sites More sharing options...
Remitur Posted July 24, 2018 Author Share Posted July 24, 2018 FIXED!!!!!!!!!!!!!!!! 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! 1 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.