30knees

Did you update any modules?

Yeah, it looks like the XML format that the module provides via Google Merchant Combinations is faulty. Manually uploading a combination export gives the error: 1 ERROR: XML formatting error

Hi @datakick, we are testing your module and are struggling with setting it up for Google Merchant with Combinations. The problems we have are: The Combinations feed always fails. A regular Products feed works. Where in Google Merchant do we connect the endpoint URL? When I run the endpoint URL that is generated, it creates an XML file. When I enter that URL in Google, it says the URL is invalid because it would need a file ending. Thank you

@roband7 Thank you for not giving up and checking the code! I'm happy to test the beta module again once this has been fixed.

Hmm, I can't comment, but it sounds like an edge case to me and one that bloats the database. Is the decision then not to change the logic?

@lesley I strongly disagree, especially considering that it prevents modules from relying on an unchanging id_carrier. What historic purposes are there? All old prices can be kept in the old orders, for example.

@traumflug For example if one wants to adjust the shipping price, the weight ranges, etc. There is no reason why changing the shipping price should affect the carrier id.

p.s. Is there a query I can run to eg replace everywhere in the database, so tbcart and tborders and tborderdetail and anywhere else id_carrier 31 with 22?

I edited the price of two carriers and the id_carrier got changed and the old one deleted. Specifically: idcarrier 20 got replaced with idcarrier 29 idcarrier 21 got replaced with idcarrier 30 and then id_carrier 30 got replaced with 31 This messes up modules that rely on the id_carrier and assume it stays stable.

I checked the database to make sure there were no new three digit IDs before processing orders. There were two new ones, all PayPal orders. @mdekker Is there no way that the new beta PayPal module could be doing this?

@mdekker said in tb_cart having non-existing id_carriers: Don't delete old carriers. The software breaks if you do so. I did already, unfortunately. What exactly should I pay attention to to make sure nothing is broken?

@traumflug said in tb_cart having non-existing id_carriers: @mdekker, these three-digit carrier IDs are in table tb_cart. I take there's no actual carrier with such a number. Apparently a problem when a carrier gets selected/added to the cart. Correct, there is no carrier with those three digits.

It looks like it was reported already here: https://forum.thirtybees.com/topic/862/bank-wire-resend-email-does-not-display-bank-information/

Was this ever fixed? It's still here: https://forum.thirtybees.com/topic/1107/bank-wire-resend-awaiting-payment-email-bug/2

Thanks! I'm not using PHP 7, though, so it must be something else. I've also read instructions on how to translate, eg https://www.prestashop.com/forums/topic/460777-tipp-wie-finde-ich-%C3%BCbersetzungen-die-ich-%C3%A4ndern-m%C3%B6chte-gilt-nicht-f%C3%BCr-prestashop-17/ but I did that.

Thanks, guys. I cleaned up the database. @traumflug That's the problem. The orders were untouched by me. The only commonality I see is that they were processed using the beta PayPal module.

Hi, I am having some weird behaviour. Some orders are displaying in tbcart idcarriers that don't exist. This does not affect tb_orders. I have these carriers: In the database under tb_carriers I have all these entries: Question 1: Can I delete the ones that don't exist anymore? But in tbcart some orders have three figure idcarriers: Because the idcarriers for idcarts 307, 317, 319 don't exist, I'm getting problems where some action relies on the idcarriers entry in tbcarts. Question 2: Does anyone have an idea where these idcarriers could be coming from/getting into tbcart (and not into tb_orders)? Of the three carts, one was non-ordered/abandoned and two were PayPal orders using @mdekker new PayPal module (no idea whether coincidence or not - other PayPal orders have been processing fine).

Hi guys, I cleared the cache multiple times and also waited 24h before posting here to be sure it's not a cache issue. @moy2010 That's the thing. I don't understand the structure of the language modules. I think I only edited the translation files - when I go Localization>Translations>Installed Modules>Core>English I see all the "original" entries of the developer and my new ones are translations. But I don't know where to look for the original entries...if I go through the module, it looks like they're scattered here and there in different files. But, to answer your question: In Localization>Translations>Installed Modules>Core>English the translated fields are all filled with my edits in en.php, not with the default ones. In Localization>Translations>Installed Modules>Core>German the translated fields are only partially filled with my edits in en.php ... and not at all from de.php and not from the default ones, either.

What about a link to the store where they can set their own password?

Hi, I have a module with horrible translations. I had already installed it. So I went to the module's translations folder and edited the files there, eg en for English, de for German. However, while this worked for English, it did not for German. I go into Localization>Translations>Installed Modules>Core>German and the German translation fields are partly filled with the core English translations. What might the problem be?

Super, I'll try and report! It's not a lot of reviews. Maybe 60 or so.

The product IDs don't match, but I have them all mapped out. For example, I know that 32 old = 64 new.

Panda theme uses the same email templates. I agree that the standard ones are a bit difficult. I haven't gotten around to editing them yet, but it's on my to do list.

Hi all! Thank you so much for helping out! :) The old system has the following table entries for reviews: reviewsid productsid customersid customersname reviewsrating dateadded reviews_text [As an aside: One nice thing about that is that one could edit customersname independently of customersid ... as I understand tb, the displayed customersname (or the equivalent) for reviews is pulled from the name connected to the customersid, so it's hard for customers to submit a review using a nickname.]

No ideas? :(