Jump to content

chienandalu

Members
  • Posts

    26
  • Joined

  • Last visited

chienandalu's Achievements

Newbie

Newbie (1/14)

6

Reputation

  1. I was having the same issue. After a long debuging I was able to find out what the problem was. There seems to be a mixing encoding in the mail headers (base64 and qoute printable) wich swiftmailer should be able to deal with. And it does until the very end of the proccess in wich it trims our necesesary trailing "=" from our base64 encoded customer name. It's funny because in my case it depended on the original string length (and I didn't find out exactly why). Anyway, I resolved the issue encoding the whole header as base64 changing this line of code in classes/Mail.php (or its override): Instead of: $message->headers->setEncoding('Q'); this: $message->headers->setEncoding('B'); I don't really know if it's a good procedure but it works!
  2. I had the same problem after updating from 1.4. I just set all the invoice_date rows with date_add value. Like this: UPDATE ps_orders SET invoice_date = date_add The problem was instantly fixed and new orders are registering properly.
  3. I've had the same issue with categories in a store I recently updated. The problem was I had an override for category controller from the old shop. When I disabled overrides everything worked again. In order to avoid future problems I deleted that override definitely.
  4. And when making a var_dump of $params, [product][attributes_smal] doesn't show up in the array...
  5. I'm going a little bit mad with this. I updated the shop to 1.4.11 and now, anytime a product stock goes below threshold the mail sent by mailalerts module doesn't show the product combination if it has one. Indeed it seem to calculate total product stock instead of the particular combination affected. I understand this is the code I have to struggle with, but I don't have a clue on how to debug it further (I assume $params['product']['attributes_small'] is the core of my problem, but don't know where to follow it to catch the bug): public function hookUpdateQuantity($params) { global $cookie; if (is_object($params['product'])) $params['product'] = get_object_vars($params['product']); if (is_array($params['product']['name'])) $params['product']['name'] = $params['product']['name'][(int)Configuration::get('PS_LANG_DEFAULT')]; if (isset($params['product']['id_product'])) $params['product']['id'] = (int)$params['product']['id_product']; $qty = (int)$params['product']['quantity']; if ($qty <= (int)Configuration::get('MA_LAST_QTIES') && !(!$this->_merchant_oos || empty($this->_merchant_mails)) && Configuration::get('PS_STOCK_MANAGEMENT')) { $templateVars = array( '{qty}' => $qty, '{last_qty}' => (int)(Configuration::get('MA_LAST_QTIES')), '{product}' => strval($params['product']['name']).(isset($params['product']['attributes_small']) ? ' '.$params['product']['attributes_small'] : '')); $id_lang = (is_object($cookie) && isset($cookie->id_lang)) ? (int)$cookie->id_lang : (int)Configuration::get('PS_LANG_DEFAULT'); $iso = Language::getIsoById((int)$id_lang); if ($params['product']['active'] == 1) { if (file_exists(dirname(__FILE__).'/mails/'.$iso.'/productoutofstock.txt') && file_exists(dirname(__FILE__).'/mails/'.$iso.'/productoutofstock.html')) Mail::Send((int)Configuration::get('PS_LANG_DEFAULT'), 'productoutofstock', Mail::l('Product out of stock', (int)Configuration::get('PS_LANG_DEFAULT')), $templateVars, explode(self::__MA_MAIL_DELIMITOR__, $this->_merchant_mails), null, strval(Configuration::get('PS_SHOP_EMAIL')), strval(Configuration::get('PS_SHOP_NAME')), null, null, dirname(__FILE__).'/mails/'); } } if ($this->_customer_qty && $params['product']['quantity'] > 0) $this->sendCustomerAlert((int)$params['product']['id'], 0); }
  6. You're welcome. Remember to turn off php display errors. I recommend you to edit your post in wich you published your admin directory also (just for security reasons). And you shouldn't be afraid of enabling order deleting now. ps.: did I win a trip to Maldivas?
  7. There you go. Who knows where this bug comes from anyway. It's not in my 1.4.0.17 shop and not in 1.4.1 version either...
  8. Vale, he estado revisando el código para la firma completa ampliada y estaba mal, ya que compruebo bien la firma pero la estoy mandando mal. A ver si saco un rato luego y lo corrijo.
  9. Well, you can check php errors display in /config/config.inc.php so we'll see what's complaining about. @ini_set('display_errors', 'on');
  10. How could I know? I made a file diff comparison between yours and mine and that's what showd up. Anyway, you could check your file permissions. It should be set to (at least) 644. Maybe once you restored your local file you lost old permissions.
  11. I was implementing this and yet don't see the point of sorting by `id_attribute_group` since it's going to be always the same id for any given attribute group. What I made at last (somebody correct me if I'm missing something) is to sort that query by al.`id_attribute`. The only condition necesary here is to have the attributes created in our desired order, wich is the usual procedure.
  12. Gracias, Francis. Es un poco difícil sin poder hacer pruebas, así que el que mandé nuevo podría no ser funcional siquiera. ¿Podrías mandar un pantallazo del error?
  13. Here's the bug (line 549): echo ''.stripslashes($state['name']).''; It should be like this: echo ''.stripslashes($state['name']).''; $currentStateTab had unclosed quotes and no variable.
  14. It looks like it's crashing for whatever reason. Good news is your order should be safe, though. If you attach your adminOrders.php we can check what's wrong with it.
×
×
  • Create New...

Important Information

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