Jump to content

technocracy

Members
  • Posts

    27
  • Joined

  • Last visited

Profile Information

  • First Name
    Steve
  • Last Name
    Evans

Recent Profile Visitors

449 profile views

technocracy's Achievements

  1. I just tried to install this and it installed and all looked well - however when I tried to add a HS Code on a product and hit save it just hung with the "saving wheel" frozen. Basically unusable - thankfully the module manager wasn't affected and could get to the it and uninstall the module and everything returned to normal. Anyone come across this before?
  2. Thank you for this - I just had the same white screen in admin suddenly occur for no apparent reason (1.7.8.7) - this fixed it - I googled around initially and there were all kinds of various things suggested, however, this is simple, to the point and actually fixes the problem! 🤙
  3. @Jeff A - Thanks so much for this! Exactly what I was looking for - I still do not understand why this functionality is not standard by default! I decided I wanted a Red banner across the top of the listing - the same as the default Orange banner that is used for items on sale - if anyone wants that just use this formatting: position: absolute; top: 0px; z-index: 10; font-weight: bold; font-size: 100%; color: #fff; background-color: #c94444; content: "OUT OF STOCK!"; text-align: center; padding: 5px 1em; width: 100%; then it look like this:
  4. OKAY!!!! Weird stuff. It suddenly started working! I just had too nip out and came back and did more testing with generating a code - it still work as expected. I then cleared code and it still worked, I then cleared the specific user that I had it set to for test and it still works! Well, something's a bit buggy, but it's working and that's all I care about! I didn't change anything in the Discount Rule but then suddenly it worked - the rules surely are not cached somehow are they? That's the only thing I can think why it suddenly just started working after "an amount of time".
  5. Ok - so I am trying to apply a discount to any cart that has purchased multiple of the same items. In theory this is simple - create a Cart Discount rule, Select the condition, set the discount etc and sure enough the rule works fine - IF - I generate a discount code and enter it in the cart. However if I leave the discount code in the rule blank, in theory it should then apply to *ANY* cart with those items - it does nothing. So what gives? How do I get this to actually work without resorting to Generating Discount Codes. I am running Prestashop 1.7.7.3 and the classic theme. Cheers Steve
  6. Thanks for the reply - yes I discover the added toggle switches under the module configuration earlier today. It baffles me why they were added in the default of disabled, makes no sense.
  7. Well it's simple in the end: https://github.com/PrestaShop/PrestaShop/issues/14188 Why the hell quietly add these switches to the module disabled?!?!
  8. Anyone find a solution? Agreed incredibly frustrating issue. I have the PHP Intl thing active but the messages just go to the BO Customer Services page and not emails.
  9. Anyone? It's ridiculous that there is no method to forward the customer services emails to my email - I have been so busy with things this month and I have literally forgot to check the Backoffice and had a month full of missed emails simply because they aren't forwarded. This seriously is a step backwards to 1.6 - I am considering just removing the contact page and forcing people to send emails - however people don't always want to write separate emails especially if they are mobile . . So does anyone know of a way of forwarding the Customer Services messages to email?
  10. Hi, I am afraid not - I only have the 5.2.0 version now. Once I got 5.1.5 working the 5.2.0 was release I decided to take the plunge and upgrade and thankfully it's been working ever since.
  11. So one further issue I have discovered is I no longer receive the webmaster & customer services emails in my inbox. I have done some looking around and I vaguely remember back when originally configuring the shop there was some php mail override or something along them lines that had to be done manually (this was about 5 years ago so somewhat vague!!) However since upgrading to 1.7 this appears to no longer work and the only way I know if a someone has sent a request to Customer Services is to log in the BO and check it - obviously this is very inefficient. All my email setting work fine - I can do the test email, I received orders placed email and I can reply to Customer Services messages without issues - so it's not an email config issue just as in 1.6. So surely there is an easy way to enable this in 1.7? Thanks Steve
  12. Well finally! It's fixed! If anyone else comes across this issue - you need to create a new column name id_paypal_order in the ???_paypal_order table and it need to be Integer length 11, auto-incremental (tick the A_I box for those using phpmyadimin) and be a Primary Key for the table. If your issues is the same as mine then order_id would be the current primary key so your need to drop that primary key BEFORE you add the new column, which will allow the new column to be the primary key for the table. 👌
  13. So I appear to be complete over thinking it - looking at the SQL in that statement and looking at the tables I appear to be missing the column id_paypal_order - can anyone let me know what format the column should be?
  14. Ok - after a bit of debugging and looking around I have identified that the underlying issue is related to the paypal_order table. First up - I have noticed that no new records have been written to the table since the upgrade. When I enable debugging on the shop I get the following error whenever I do anything with an order or order status: Unknown column 'id_paypal_order' in 'field list'SELECT id_paypal_order FROM `fqc_paypal_order` WHERE (id_order = 1151) LIMIT 1 at line 769 in file classes/db/Db.php I posted this issue previously but at that time did not know what it was impacting since when you disable debugging the error does not reappear - so could this be an access/rights issue to the table? It seems to be something relating to that as the above error is the same regardless as whether the order in the query exists or not - in the above order no 1151 is not in the table however if I try access a record I know exists I get the same error. Anyone have any pointers on what right/permissions could be possibly missing to cause this? I have attached a full screen capture of the full error output. Thanks
  15. Well I've tried raised a job through the official support channels and after initial promise of assisting that has disappeared and now I am being told somehow "it's a Prestashop issue", hence why I am posting this here! 😞 I fixed the original issues I had with the payments being received but the order sitting in "Awaiting Payment" by performing a uninstall, clearing all possible caches, renaming the /var/cache folder AND deleting the module/paypal folder - then reinstalled, it still gave an error about not being installed but it installed and works fine other than Refunds are not working. When I set an order to Refunded - it does nothing (well other than change the status) - I have even gone into the PayPal module configuration page and set under the Advanced Options that Refunded status should trigger a refund even though that is supposedly the default. Can anyone assist what could be causing this? I wish they had just left the Refund button that is in the 1.6 version. This is the only annoyance I have left following my 1.7 upgrade - I have to say I wish I had upgraded sooner 1.7 is far superior to 1.6! 😃
×
×
  • Create New...