Jump to content

AMS777

Members
  • Posts

    5
  • Joined

  • Last visited

1 Follower

AMS777's Achievements

Newbie

Newbie (1/14)

18

Reputation

  1. Hi, There are some places in the code that are neither modules nor Smarty templates that may require translations, for example, the php classes under /classes. In this case the $this->l() function may not be used, although it can be used if the class extends the Module class, because PrestaShop won't recognise it as a module and hence won't recognise its translations. PrestaShop only take as modules the classes under /modules and under /themes/YOUR_THEME/modules. Thus, if the $this->l() function is used, the string name will always be used and there will be no possibility to assign a translation to that variable. I've developed a workaround to make available translations everywhere. It is done in three steps: 1 - Create a getExtraTranslation() function in Tools.php. 2 - Create a extratranslations module under /themes/YOUR_THEME/modules. 3 - Use the Tools::getExtraTranslation() anywhere. Explanation: 1 - Create a getExtraTranslation() function in Tools.php. The function goes in Tools.php and is this: /** * Get an extra translation, not in modules or anywhere else * * @param string $string String to translate * @return string Translation */ static public function getExtraTranslation($string) { global $_EXTRA_TRANSLATIONS, $cookie; if ( ! $_EXTRA_TRANSLATIONS) { $id_lang = (!isset($cookie) OR !is_object($cookie)) ? intval(Configuration::get('PS_LANG_DEFAULT')) : intval($cookie->id_lang); $translationsFile = _PS_THEME_DIR_.'modules/extratranslations/'.Language::getIsoById($id_lang).'.php'; if (self::file_exists_cache($translationsFile) AND include_once($translationsFile)) $_EXTRA_TRANSLATIONS = $_MODULE; } $string2 = str_replace('\'', '\\\'', $string); $currentKey = '<{extratranslations}'._THEME_NAME_.'>extratranslations_'.md5($string2); if (is_array($_EXTRA_TRANSLATIONS) && key_exists($currentKey, $_EXTRA_TRANSLATIONS)) $msg = stripslashes($_EXTRA_TRANSLATIONS[$currentKey]); else $msg = $string; return str_replace('"', '"', $msg); } NOTE: The global variable $_EXTRA_TRANSLATIONS may be initialised in /config/config.inc.php like this: global $_EXTRA_TRANSLATIONS; $_EXTRA_TRANSLATIONS = array(); 2 - Create a extratranslations module under /themes/YOUR_THEME/modules. A Smarty template called extratranslations.tpl must be created under /themes/YOUR_THEME/modules/extratranslations/. In this template will be created the extra translations that are used anywhere. For example: {l s='Voucher code:'} {l s='Total discounts'} {l s='No message'} Then, PrestaShop will recognise them as module translations and they will be available at back office when the module translations are updated. Here their values can be set. 3 - Use the Tools::getExtraTranslation() anywhere. Wherever the extra translation is to be used, it will be done with the Tools::getExtraTranslation() function, like this: echo Tools::getExtraTranslation('Voucher code:');
  2. Hi, I had a problem when updating the module languages and wanted to share its solution. A 403 error was launched when updating the module languages. I don't really know why it was produced, but it was fixed activating post_max_size in the general php.ini and setting a php.ini in the specific directory increasing upload_max_filesize and post_max_size of the directory (as my server admin told me). First approach was to check the permissions, but they where right. I test everything I though of, but nothing seemed to work. Finally, I test to remove some modules and leave less module languages. When there were enough few modules, it worked. I continued that way and check the server properties. Everything seemed to be ok, but it was quite odd that the process ran ok with few modules and produced a 403 error, which is a permissions error, when there was all of them. I thought that the problem might be in the POST sending. And so it was. A form with less than 1000 fields was sent ok. A form with 1000-2000 fields was sent, but only the first 1000 fields were received. A form with more than 2000 fields was not sent, and a 403 error produced. I test it with a simple script, which creates a form with a given number of fields. I attach it to this post, just in case it is useful for anyone. So, the number of fields in the form was the key of the problem. Not so the size of the form POST sending, as it was 5-15 KB (for the test script, 167 KB for the module languages). Therefore, I don't understand why the upload_max_filesize must be increased to 64 MB, if the sending was just 5-15 KB. postFormTest.zip
  3. Hi, I want to share a problem I had with the Spanish credit card payment platform 4B. It wasn't working because of a 301 redirection. The payment system was configured for my domain.com address. This address was 301 redirected to my domain.es address. This should have no problem but actually had it. Fixed changing the payment configuration addresses to domain.es.
×
×
  • Create New...