tss68nl

So, you want to be able to select products and put that on a pro-forma to a client. Seeing the complex structure of products and the time that was invested in making sure that ordering one product, displays compatible accessoires in a tonne of products it is much preferred to use the front-end, instead of the back-end product search option. So, * You create a cart as the shop owner * You pick the cart up in the backend, and chose to convert it to an order * The order is on the owners account, but we can pick an existing client at the top. * The new client is selected, now the order is totally gone. * You pick the order again from the list below, now the order is still on your client, but the products are loaded from the selected cart * You finalize the order, only to find that the order is now in your own account again?! What is happening? I selected the correct client. It displays it's full details even after I inserted the cart.....*why* is it still made in my name? I cannot change the client of an order afterwards as well. This is driving me nuts....simple basic things not working.

Dat had ik inderdaad al gezien dat de centrale mail functie wordt gebruikt. De vraag is echter: waarom geeft niet iedere template dezelfde waarden door, en waar kan ik het vullen van de variabelen voor de verschillende templates vinden? Een concreet voorbeeld: ik kan werkelijk niet vinden, waar de variabelen voor "backoffice_order" worden gevuld? Qua logica: Eigenlijk zou het andersom moeten zijn: als een template verwijst naar velden uit een bestelling / klant / etc categorie, dan zou de parser moeten weten hoe deze informatie op te halen is. Ik werk veel met SilverStripe, wat zeer modulair is opgebouwd, en PrestaShop lijkt een soort omgekeerde logica te gebruiken waarin logica verspreid over de gehele code uiteindelijk tot hetzelfde resultaat moet leiden. Maar goed, dat is ontwerp, en gaat toch nooit veranderen. SilverStripe heeft weer geen fatsoenlijke shop mogelijkheden

Ik heb reeds aardig wat afgezocht en uitgeprobeerd, maar kom er echt niet uit helaas. Wat ik wil doen is het volgende: Graag zou ik een aantal email templates toevoegen of veranderen, zodat ik een aantal overzichten van producten, prijzen en kortingen kan sturen zoals een Offerte, Proforma factuur, bestelbevestiging etc. Die laatste zit er natuurlijk al in en heet order_conf, en ook al wil ik die nog wel wat aanpassen, deze heb ik als basis genomen voor de andere templates. Maar als ik de code uit dat template wil gebruiken in bijvoorbeeld backoffice_order (logische template voor een offerte lijkt me) dan worden veel placeholders niet vervangen zoals {orders} en {delivery_block_html} Waarschijnlijk, om dat de betreffende parameters niet gevuld zijn voor dat template. Ik vind dat echter raar, want als ik in de backoffice een status wijzig, dan zijn voor beide templates toch dezelfde gegevens bekend? Met wat zoekwerk op google en het forum ben ik op een aantal plekken uit gekomen, maar kan niet vinden wat ik zoek: AdminOrdersController.php: Ik wijzig de status in dit scherm, dus verwachtte ik daar ook de aanlevering van de variabelen. Ik kan echter geen backoffice_order template afhandeling vinden hier? Mailalerts.php: Wellicht dat deze de afhandeling doet van de mails. Het lijkt er alleen op dat deze alleen de via de database configureerbare teksten mailt? PaymentModule.php: Omdat de forum resources hier naar wijzen. Ik heb rond regel 705 (PS 1.6.1.7) een array gevonden met alle variabelen, maar, daar zitten óók alle variabelen bij die ik juist niet gevuld krijg, zoals {delivery_block_html}. Dus ik weet het even niet meer eigenlijk Ik snap niet zo goed waarom de aangeleverde variabelen niet voor alle templates gelijk zijn. Dat zou het een stuk makkelijker maken. Het lijkt er op dat de mailfunctionaliteit over veel modules verspreid is. Volgens mij zou het voor moeten kunnen komen dat als je in de admin je template goed werkend hebt, dat deze vanuit de klant geïnitieerd tóch problemen geeft. Dat lijkt wat vreemd. Ik zie vast iets over het hoofd, en zou graag begrijpen hoe dit onder water werkt. Kan iemand me helpen? Alvast bedankt voor de hulp en de genomen moeite!

I am seriously lost in the email templates of version 1.6.1.7 of PrestaShop. What I want to do is, to create different overviews of an order and it's products that are sent as a 'Quote' / 'Pro forma invoice' / 'Confirmation' etc. To do that, I have taken a look at the order_conf template, as it roughly displays the information I want to display for the confirmation. However, if I copy the template code to another email template to backoffice_order for example, most of the fields will display as {orders} and {delivery_block_html}. This is probably due to the params not being filled out before the template is run. But, I cannot find where these fields are loaded? I've searched the net and these forums, and tried close to everything I could find, to no avail. I started with the AdminOrdersController.php, as I expect when the status changes, the mail is sent: There are a couple of mail send initiates here, but I cannot find any handler for the backoffice_order template? I found mailalerts.php, which obviously handles mails, but I get the impression they are only the kinds that have a custom message from the database... So I've taken a look at the PaymentModule.php which a lot of sources indicate this functionality would be in and around line 705 there are a lot of variables filled in. But, these already include the {delivery_block_html} one for example, so this cannot be it. So, I am properly lost. Why doesn't the AdminOrdersController calculate the same fields as params for each and every template? It's a view on the same order, so in essence the data delivered to a template should not be restricted? And why does the functionality seem so scattered in code? A mail handler applying a template for an order...is a mail handler applying a template to an order....in whichever form the template would be right? I am probably missing out on something here. Can someone shed a light on this? I would be interested in understanding the architecture/logic behind the functionality as well, as it makes more sense for future issues. Thanks in advance for your time and help!

Ik heb een oplossing gevonden, al weet ik nog niet precies wat het probleem nu was: In /controllers/admin/AdminImportController.php, op regel 1006 moet een extra & teken worden toegevoegd: if (!call_user_func_array($funcname, array($row, $k, &$user_data))) { Ziet er naar uit dat dit een fout is die alleen zich manifesteert als er PHP7 wordt gedraaid op je server....

Hallo Mark, Ik probeerde eerder al aan te geven dat ik weet hoe je een import systeem systematisch moet debuggen. Ik heb reeds heel veel kolomsamenstellingen geprobeerd. Ik snap het systeem met templates (die heb ik inmiddels een stuk of 40). Nummer 127 voor het csv bestand was ook niet toevallig. Ik ben bij 1 begonnen. Ik denk niet dat het in het bestand kan zitten of de import parameters. Als dat zo zou zijn, dan had ik al lang een keer een andere foutmelding gehad dan deze. Sowieso wordt het voorbeeldbestand automatisch goed gemapt (zelfde volgorde en aantal kolommen), en zelfs die werkt niet. Thanks voor de dev mode: nu geeft de site als aanvullende melding: public_html/controllers/admin/AdminImportController.php [2] Parameter 3 to AdminImportControllerCore::fillInfo() expected to be a reference, value given Ik heb gekeken in de source, maar het is helaas niet te zien vanuit waar deze functie is aangeroepen. 3e parameter is het object van de informatie die ingevuld moet worden, en die wordt blijkbaar niet meegegeven. In de classes zelf wordt de aanroep op een hele hoop verschillende objecten gedaan, maar mijn gok is dat het de naam van het object zal zijn (gezien de andere foutmelding).

Ik zat te denken, het zal toch niet zo zijn dat PrestaShop een Americano gedaan heeft he? Alsin: we bouwen het product alleen voor de USA, en europese installaties: succes met onze usa inrichting? Is het verplicht de amerikaanse taal, BTW, landen, provincies etc etc in je PrestaShop database te houden om de importer te kunnen gebruiken? Het eerste wat ik namelijk heb gedaan is alle niet nuttige landen uitgezet, taxes die niet gebruikt worden weggedaan etc. Er van uit gaande dat PrestaShop gewoon in het Nederlands kan werken, met een afzetmarkt alleen binnen Europa.

Zoals gezegd in de startpost: ik gebruik 1.6.1.6. Installatie op 1.6.1.4 geloof ik, en via upgrade binnen prestashop naar 1.6.1.6. Dit issue heb ik al vanaf installatie. ISO : Ja en Nee Teken : puntkomma uiteraard als er ; in staat. Ik heb ook bestanden gemaakt met pipes, tildes etc Meerdere waarden: | (pipe), maar ook tildes gebruikt, slash, backslash, etc Verwijder: Nee (maar ook ja geprobeerd) referentie: Nee (maar ook ja geprobeerd) hergenereren: Nee (maar ook ja...) Forceer ID: Nee (maar ook ja...) En eigenlijk alle combinaties van bovenstaand. Ook hele kleine bestanden gemaakt met weinig kolommen, de voorbeeldbestanden, etc etc. Ik werk al 15 jaar met datawarehouses, dus CSV is me niet onbekend, en import modules ook niet. Maar dit heb ik nog nooit meegemaakt. Het gebrek aan duidelijke foutmeldingen is echt vreselijk. Is er iets van een debugmode waarmee je tot in detail kan zien wat hij probeert te doen? Inprikken op mysql gaat volgens mij niet, en de fout hoeft ook niet bij een query te ontstaan natuurlijk? Ondanks dat het afgeraden wordt op de forums, ga ik uitzoeken welke tabellen gevuld moeten worden en schrijf ik wel een eigen importer buiten prestashop om direct op de database. Ik denk dat dat veel sneller en betrouwbaarder werkt. Als dat ook een drama blijkt door het datamodel, dan geef ik het op

Dank voor je antwoord. Ik ben benieuwd of dit werkend te krijgen is. Het is de eerste functie die ik heb geprobeerd, maar het heeft nooit gewerkt. Ik ging er van uit dat ik het uiteindelijk wel werkend zou krijgen, dus de shop is verder al helemaal ingericht....maar, zonder producten anders dan een paar handmatige. Ja, ik heb NL/EN geprobeerd, ISO aan/uit, referentie als sleutel aan/uit. En alle combinaties daarvan. Het bestand wat ik nu eerst werkend probeer te krijgen is het voorbeeldbestand wat je kan downloaden, om uit te sluiten dat het bestandsformaat een probleem kan zijn. De enige aanpassing in dat voorbeeldbestand is het tax-rule ID naar 58, omdat dat mijn nummer is voor de NL belastingregels, ipv de standaard 1. Bijgevoegd de laatste testversie van het bestand. products_import_test_127.zip

Ik snap er werkelijk waar helemaal niets meer van. Ik heb werkelijk alles al geprobeerd, maar ik kom er niet meer uit: Mijn Prestashop 1.6.1.6, wil helemaal niets importeren. Alhoewel, hij zegt dat hij het prima gaat doen, alle kolommen zijn gemapt, en hij komt dan met de melding (voorbeeldbestand): iPod Nano (Nummer: 6) kan niet opgeslagen worden Property Product->name is empty iPod shuffle (Nummer: 7) kan niet opgeslagen worden MacBook Air (Nummer: 8) kan niet opgeslagen worden MacBook (Nummer: 9) kan niet opgeslagen worden Dit doet hij met ieder formaat bestand. Zelfs bestanden die ik maar enkele kolommen heb gegeven, maar óók met de voorbeeldbestanden die ik uit PrestaShop download en upload (zoals het voorbeeld). Als PrestaShop zijn eigen formaat al niet meer snapt.... (en ja, de voorbeeldbestanden zijn engels, dus gebruik ik ook Engels) Ik denk dat ik nu al 5 weken bezig ben met deze importer, en niets werkt. Ik krijg de indruk dat deze importer op een maandagmorgen is geschreven? Als de importer niet werkt, dan gooi ik heel prestashop in de prullenbak. Ik kan onmogelijk prijsbeheer doen zonder die importer.