Jump to content

martenBoy

Members
  • Posts

    18
  • Joined

  • Last visited

About martenBoy

  • Birthday 03/04/1980

Profile Information

  • Location
    Bangkok
  • Activity
    Agency

martenBoy's Achievements

Newbie

Newbie (1/14)

2

Reputation

  1. yuppee I think I found the cause of the problem at least for my situation first I strongly recommend reading the guide Troubleshooting the spinning save button in Prestashop 1.6.0.11 and above at the following link https://disqus.com/home/discussion/nemops/troubleshooting_the_spinning_save_button_in_prestashop_16011_and_above/ well the issue for my case was a conflict in one module I downloaded it was the call inside hookHeader($params) $this->context->controller->addJqueryUI('ui.datepicker'); I went to module positions and clicked on “Display non-positionable hooks and removed the module from displayBackOfficeHeader.
  2. just found a temporary solution for my weekend for those who are frustrated by this issue and I imagine there are hundreds as i see in the forum they can try the musicmaster, '[Free Script] Product mass-edit, Category multi-edit, Order Edit https://www.prestashop.com/forums/topic/185401-free-script-product-mass-edit-category-multi-edit-order-edit/ it works kind of fast though the interface is tricky but it s great tool for updating the products.
  3. My host is OVH kind of famous company all other e-commerce software like magneto and others runs as a charm on my current host, I wonder if anyone could develop a simple module to edit the products i don't know it s very hard to change some fields with the old fashioned interface.
  4. same here after 3 weeks of intensive development I m experiencing the same issue, wonder if someone could just develop some simple module to edit the products. I strongly recommend reading the following guide Troubleshooting the spinning save button in Prestashop 1.6.0.11 and above at the following link https://disqus.com/h...6011_and_above/
  5. even though I use a shared hosting things running fast for everything else. updating categories and manufacturers are kind of fast, so far i have to delete all directories and reinstall again then it works kind of fast then it stuck again. removing all modules from ActionProductUpdate didnt help either
  6. Thanks you so much for your help, works greats !!!!
  7. I am having the same issue but this solution did not work for me, I tried to analyze the out on XHR panel and nothing so far interesting any solution please ??
  8. the front end, a module displaying a form and having an datepicker as in one of its input.
  9. how to display a datepicker in a text field inside a TPL file of module using the included JQuery library.
  10. works like a charm Thank you very much for your assistant. Khub khun krup.
  11. yes if I increase the field size in the DB and change the max limit in Mail.php has solved the issue but I think i found the real cause which is the lines $mail = new Mail(); $mail->template = substr($template, 0, 62); $mail->subject = substr($subject, 0, 254); $mail->id_lang = (int)$id_lang; as long as the email subject size is less then the max value then things works fine. I guess there is something is wrong with trimming the text when it is oversize so if I simply change it to $mail->subject = substr($subject, 0, 253); it will works fine, i have checked the resulted Thai text and it has the Unicode FFFD at the end of the trimmed string. string(254) ยืนยันการสั่�" note that this bug is never produced when I use English version even if I choose very long shop name.
  12. so if Tools::strlen($mail_subject) > 254 then the bug is triggered. so if I choose a long shop name the I have the bug string(254) "[demoshop | สาธิตชื่อร้านค้า สาธิตชื่อร้านค้า สาธิตชื่อร้านค้า สาธิตชื่อร้านค้า สาธิตชื่อร้านค้�" so far I had to add $mail_subject = substr($mail_subject, 0, 253); so solve the issue but i am not so sure if it s the right thing to do.
  13. I found the cause of the bug but not the solution if the total email subject character length exceeds 100 characters then this issue is produced, this bug happens everywhere in payment confirmation or in contact form.
  14. the follow up of this bug : / I found out that this bug is produced when the email subject exceeds 100 characters, however i have not yet figured out why the limit of 100 is imposed even though that the limit of 254 is norm.
  15. just to mention that I have found the cause of the problem it s the function inside the class ValidateCore public static function isMailSubject($mail_subject) { return preg_match(Tools::cleanNonUnicodeSupport('/^[^<>]*$/u'), $mail_subject); } could anyone tell what is the pattern I should use so it will accept Thai characters.
×
×
  • Create New...