Jump to content

prestasmart

Members
  • Posts

    15
  • Joined

  • Last visited

Profile Information

  • Location
    Singapore
  • Activity
    Agency

prestasmart's Achievements

Newbie

Newbie (1/14)

1

Reputation

  1. Je confirme ce que troc58 propose "admin\tabs\AdminProducts.php vers la ligne 635 ;". Merci troc58. NB: J'avais commencé en faisant la même modif dans classes\Product.php mais ça a servi a rien. Fonctionne très bien sur 1.2.5. J'ai mis 700 mais vous pouvez mettre ce que vous voulez. Notez bien qu'il fat modifier à deux endroits, soulignés ici : /* Check description short size without html */ foreach ($languages AS $language) if ($value = Tools::getValue('description_short_'.$language['id_lang'])) if (Tools::strlen(strip_tags($value)) > 700) $this->_errors[] = $this->l('the field').' <b>'.call_user_func(array($className, 'displayFieldName'), 'description_short').' ('.$language['name'].')</b> '.$this->l('is too long').' : 700 '.$this->l('chars max').' ('.$this->l('count now').' '.Tools::strlen(strip_tags($value)).')';
  2. Hello all, Problem solved here (works on 1.2.5 + 1&1) , just posted about it [french] : http://www.prestasho...on-des-modules/ I had tried to set new high values for variables "suhosin", didn't work, also tried the method by regenerating a new .htaccess and getting the AdminTranslations from the svn server, same result...none worked except the easy solution I tested and simplified, see link above. Hope it helps.
  3. Hello all, Problem solved here (works on 1.2.5 + 1&1) , just posted about it (french) : http://www.prestashop.com/forums/topic/162104-probleme-de-traduction-des-modules/ I had tried the who .htaccess thing and got a server error, also tried the method by getting the AdminTranslations from the svn server, same result...none worked except the easy solution I tested and simplified, see link above. Hope it helps.
  4. Hello all, Problem solved here, just posted about it (french) : http://www.prestashop.com/forums/topic/162104-probleme-de-traduction-des-modules/ Hope it helps.
  5. Dans la continuité de ce qu'a suggéré scan : Créer un fichier php.ini avec cette ligne, et le mettre dans le dossier admin (cela suffit pour moi scan) , ou rajouter cette ligne si le fichier existe déjà : max_input_vars = 10000 Après de longue recherches, ça marche nikel pour moi sur Prestashop 1.2.5 chez 1&1 HISTORIQUE : Ce problème est sorti de nulle part. Du jour au lendemain certains modules n'avaient plus de traductions, ce qui se voyait en front office...pas très pro de l'anglais en front-office sur un site français. Il semble donc que 1and1 a fait des mises à jour serveur qui affectent les traductions Prestashop. Le pire dans tout ça c'est que j'avais ouvert la page de traduction des modules et elle avait étrangement beaucoup de champs vides (à cause de la variable max_input_vars). Là, j'ai fait l'erreur de sauvegarder. Ceci a visiblement écrasé l'ancienne traduction complète et remplacé par des champs vides... Heureusement, j'ai pu utiliser la fonction "Autofill form" de Safari pour remplir à nouveau les centaines de champs vides, sinon j'aurais pas su comment recupéré les traductions non chargées! Merci encore à scan. J'espère que ça peut aider ! Bonnes ventes à vous.
  6. I have tried: suhosin.request.max_vars = 2048 suhosin.post.max_vars = 2048 on Prestashop 1.2.5.0 hosted with 1&1 : Doesn't work for me. It's strange because I thought I had done all these translations, some of them in the field blanks are even reminded by Safari's autofill so I did do that before. It just doesn't load (blank fields) and whatever I type isn't visible. And I do get a "Saved" message, but nothing is actually saved when I check. It's not a whole text CSS problem, and I am safe within the quotas with the host. If anyone can help... Thanks!
  7. Problème résolu ici : http://www.prestashop.com/forums/index.php?/topic/127379-probleme-module-hipay/page__view__findpost__p__822737 Aller jusqu'au post en anglais que j'ai fait pour résoudre le problème. J'espère que ça vous débloquera. Youcef.
  8. Le vrai problème de base est que "allow_url_fopen is desactived". Cette variable doit être activée et ça ne sert à rien de chercher une parade autour de ça , c'est de là que vient le problème des catégories qui ne se loadent pas. Le problème est décrit en détail ici et sa résolution (en anglais). http://www.prestasho...post__p__822737 J'èspère que ça vous débloquera. Youcef.
  9. Bonjour, J'ai eu exactement le même problème et je décris la résolution (2 minutes de travail) après 12 heures de bidouillages. www.prestashop.com/forums/index.php?/topic/166959-hipay-error-hipay-categories-not-set-for-every-site-id/page__view__findpost__p__822713 Regardez dans mon historique de posts pour des infos complémentaires si besoin, j'ai posté partout sur le forum dans les threads en rapport pour essayer de débloquer un max de gens. C'est à HiPay de le faire normalement, mais faut bien que quelqu'un le fasse. Si vous avez la version 1.2.5 de prestashop voici le module que j'utilise (HiPay 1.0) en pièce jointe Pour les autres versions de prestashop voir le SVN ou la version officielle du module sur addons.prestashop.com (à ce jour HiPay 1.3) Bien à vous ! Youcef. hipayv1.0 for prestashop v1.2.5.zip php.ini.zip
  10. I have answered here to what may be the most common problem with HiPay not working with loading categories in Prestashop. http://www.prestashop.com/forums/index.php?/topic/166959-hipay-error-hipay-categories-not-set-for-every-site-id/page__view__findpost__p__822713 In your case it seems like you had a php.ini somehwere that is gone after the update. If my post doesn't work, you may want to try connecting to the SVN with an SVN client and collect the version in tags > your versions number > modules > hipay or different versions. But really, I think your problem comes from allow_url_fopen as described in the post I did , link above. Cheers !
  11. use a phpinfo(); in hipay.php to see what is the value of allow_url_fopen in my case it was not activated. For 1and1 shared hosting and HiPay v1.0 on Prestashop 1.2.5 I had exactly the same problem as you. HiPay by email told me that allow_url_fopen MUST be active. I spent 12 hours on it and the solution takes 1 line and 1 ftp action !!! Put in the admin folder (at the root of the folder) php.ini file with 1 line : allow_url_fopen = 1 Tadaaaa ! This is maybe 1and1 specific, anyway the most likely root of this evil is allow_url_fopen which must be ON So change your searches and start by 1 trying what I described here, if it doesn't work look for how to activate allow_url_fopen for your host. One way to be sure it's activated is to use phpinfo(); at the start of hipay.php and look for the setting of the variable allow_url_fopen. If I solved your problem, and you're super happy to be able to charge people money, you can contact me to offer a link to improve my SEO I could use that. But that's only if you want to. no pressure...All the best !
  12. for 1and1 shared hosting : you can activate allow_url_fopen with that line in the php.ini : allow_url_fopen = 1 The tricky part is where to put it for the module or code you want to allow this for. Just add phpinfo(); in the php code concerned and put php.ini in the folders likely to call your code then test until your code (trhough phpinfo) finds allow_url_fopen to be 1 or On meaning activated, allowed.
  13. J'avais un problème avec HiPay et allow_url_open est vital pour le faire marcher. Pour moi un php.ini avec à la seule ligne allow_url_open = 1 a bien suffit, MAIS il a fallu -- plutot qu'à la racine du site, ou dans tout les dossiers -- mettre le php.ini dans le dossier administrator ou le nom que vous avez choisi pour ce dossier. Car dans mon cas, le module était chargé depuis le backoffice pour la configuration, donc c'est logique de donner les droits à url open à cette partie là de mon site. Quelque soit votre utilisation, pour vérifier que c'est actif, mettez un phpinfo(); quelque part dans le code qui doit utiliser allow_url_fopen c'est le meilleur moyen de savoir si votre script aura accès à l'url open ou pas. Chez 1and1 c'est possible. Quand ils disent qu'il faut metter le php.ini dans "tous les dossiers" je pense que c'est juste pour avoir l'équivalent d'un php.ini de haut niveau sur tout votre hébergement (pas possible en mutualisé). Mais peut-être que vous en avez pas besoin partout...
  14. Pour moi à la racine ça n'a pas suffit, il a fallu plutot qu'à la racine mettre le php.ini dans le dossier administrator pour vérifier mettez un phpinfo(); quelque part dans le code qui doit utiliser allow_url_fopen c'est le meilleur moyen de savoir si votre script aura accès ou pas.
×
×
  • Create New...

Important Information

Cookies ensure the smooth running of our services. Using these, you accept the use of cookies. Learn More