Hermeswein

Danke! Wir versuchen mal unser Glück.

Hallo zusammen, wir sind seit mehreren Jahren Nutzer von Prestashop 1.6.1.5 und möchten gerne eine Änderung an der Versanddienst-Logik durchführen. Wir haben drei verschiedene Lieferanten. Ein bestimmter Lieferant (hier: Lieferant C) soll erst ab einem bestimmten Gesamtgewicht (z.B. 24 kg) dem Nutzer angezeigt werden. Darunter sollen nur die verbleibenden zwei (A und der insgesamt drei Lieferanten angezeigt werden. D.h. zum Beispiel: 10 kg: Lieferant A und B anzeigen 30 kg: Lieferant A, B und C anzeigen Nach allem was wir bisher sehen kann ich jedoch nur folgende zwei Regeln einbauen, die aber nicht weiterhelfen: Versandkosten eines Lieferanten abhängig von der Gewichtsspanne anzeigen lassen (d.h. Kosten für 0 - 24 kg und Kosten für > 24 kg, nicht jedoch "Lieferant für 0 - 24 kg gar nicht erst anzeigen") Einen Lieferanten bei Überschreitung einer Gewichtsspanne deaktivieren (nicht jedoch bei Unterschreitung, das Dropdown bietet jene Option nicht an, siehe Anhang). Hat jemand eine Idee? Viele Grüße, Stefan

Hi there, I'm using the "blocknewsletter" module (2.3.1) on Prestashop 1.6.1.5 to allow users to sign up to newsletters. I observed two strange things (assuming that an eMail address is only registered for a newsletter, and does not have a corresponding customer account with the same eMail address): Let's assume someone signs up for the newsletter, but does not click on the confirmation link that is sent by Prestashop, but instead (accidentally) deletes the eMail. In case he wants to register again, he cannot do this because he only receives the error message "This email address is already registered." when attempting to sign up again. From what I can see, he does not have the possibility anymore to have a proper registration process, unless I delete his eMail address "hardcode" from the SQL table ps_newsletter. Correct? Let's assume someone correctly registers for the newsletter (by clicking on the confirmation link). In that case, there is no possibility for him to unsubscribe from the newsletter? This has to be done manually in the BO (by clicking on the green mark) or by setting his "active"-flag in the SQL table ps_newsletter to 0. Correct? In case I deactivate someone's subscription (because the person cannot do it himself, see above) in "Modules --> Blocknewsletter" by clicking on the green mark, it correctly flags him as "de-active" in ps_newsletter ("active" is set to "0") and makes him disappear from the list in the module. However, in that case, the person cannot sign up again (getting the "This email address is already registered"-error message) and I also cannot re-activate him from the backend, because he completely disappeared from the list (but is still in the SQL table ps_newsletter). So I either have to manually delete his entry from the SQL table ps_newsletter, or set his "active" flag back to "1" in the SQL table ps_newsletter. Correct? All these three observations sound very odd to me, and I'm just wondering if these are bugs, or if I'm just getting something wrong... Best regards, Stefan

You're talking about the "request" or "confirmation" eMails when signing up for the newsletter? I accidentally observed the same thing. My hypothesis: These variables are only "handed-over" (or "filled") during an order process, and therefore cannot be used for newsletter. But just guessing...

Here's an update to the same problem (in the meantime on 1.6.1.5): In the backend (in the "translation"-section, in the "eMail template"-sub section): Although the template "password_query" does contain an edit field to change the eMail subject, the template "password" does not have a similar field. Does anyone know why? But even if you change the subject, e.g. for "password_query" this does not seem to have any effect. Even changing the subject "hard-code" in /mails/de/lang.php does not make a a difference. Does anyone know how to change eMail subjects? Is this a bug?

Hi dusticelli, no, unfortunately not. Let me know if you found something. Best regards

Awesome! Thanks for the hint!

Hmm, interesting. If it's really like this, then it's clearly something that was MUCH better in the old version. Editing complex texts (and having to scroll all the way up whenever more detailed edits are needed) is really a pain with the new editor... :-/ Here's edited tinymce.inc.js function tinySetup(config) { if(!config) config = {}; //var editor_selector = 'rte'; //if (typeof config['editor_selector'] !== 'undefined') //var editor_selector = config['editor_selector']; if (typeof config['editor_selector'] != 'undefined') config['selector'] = '.'+config['editor_selector']; // safari,pagebreak,style,table,advimage,advlink,inlinepopups,media,contextmenu,paste,fullscreen,xhtmlxtras,preview default_config = { selector: ".rte" , plugins : "visualblocks, preview searchreplace print insertdatetime, hr charmap colorpicker anchor code link image paste pagebreak table contextmenu filemanager table code media autoresize textcolor emoticons", toolbar2 : "newdocument,print,|,bold,italic,underline,|,strikethrough,superscript,subscript,|,forecolor,colorpicker,backcolor,|,bullist,numlist,outdent,indent", toolbar1 : "styleselect,|,formatselect,|,fontselect,|,fontsizeselect,", toolbar3 : "code,|,table,|,cut,copy,paste,searchreplace,|,blockquote,|,undo,redo,|,link,unlink,anchor,|,image,emoticons,media,|,inserttime,|,preview ", toolbar4 : "visualblocks,|,charmap,|,hr,", external_filemanager_path: ad+"/filemanager/", filemanager_title: "File manager" , external_plugins: { "filemanager" : ad+"/filemanager/plugin.min.js"}, extended_valid_elements: 'pre[*],script[*],style[*]', valid_children: "+body[style|script],pre[script|div|p|br|span|img|style|h1|h2|h3|h4|h5],*[*]", valid_elements : '*[*]', force_p_newlines : false, cleanup: false, forced_root_block : false, force_br_newlines : true, menu: { edit: {title: 'Edit', items: 'undo redo | cut copy paste | selectall'}, insert: {title: 'Insert', items: 'media image link | pagebreak'}, view: {title: 'View', items: 'visualaid'}, format: {title: 'Format', items: 'bold italic underline strikethrough superscript subscript | formats | removeformat'}, table: {title: 'Table', items: 'inserttable tableprops deletetable | cell row column'}, tools: {title: 'Tools', items: 'code'} } } $.each(default_config, function(index, el) { if (config[index] === undefined ) config[index] = el; }); tinyMCE.init(config); };

Just to make sure that we understood the situation correctly (since we only upgraded some weeks ago from 1.4 to 1.6): The perfectly working Editor in our old 1.4 PS installation was replaced by an editor with not even half the functions, and which has to be "tweaked" / rebuilt step by step to get the old functionality back? I hope I missed something here...

I followed all instructions, and some options did re-appear. However, the full-screen button which you mentioned is still not there (see screenshot)... :-/ Any ideas?

We're using Prestashop 1.6.0.9. Best regards, Stefan

Hallo, ich nutze das Modul "Zahlung auf Rechnung" von Silbersaiten (siehe hier: http://www.silbersaiten.de/prestashop/de/prestashop-module/123-zahlung-auf-rechnung.html). Das Modul funktioniert eigentlich wie es soll, bis auf einen Haken: Direkt nach der Bestellung wird dem Kunden direkt eine Mahnung (heißt im Modul "Payment Reminder") hinterher geschickt (was natürlich nicht so sein soll. Es gibt zwar eine Option in den Einstellungen, die, in Tagen angegeben, jene "Frist" definert (bzw. falls leer oder 0 komplett aufhebt / deaktiviert). Irgendwie scheint diese Option aber wirkungslos zu sein, da die Meldung direkt nach der Bestellung verschickt wird, egal welchen Wert man angibt. Hat jemand eine idee? Edit: Habe das Problem selbst lösen können. Ursache war (auch wenn es in sich nicht logisch ist), dass in den Einstellungen bei "Reminder status" ein Status definiert war. Wenn man das auf "none" setzt, greift das Modul nicht mehr mit Reminder ein. Wie gesagt, 100% verstanden habe ich es auch nicht, aber zumindest werden jetzt nicht mehr wild Reminder verschickt.

Hi there, I'm facing a weird problem: When I try to translate / edit the eMail templates, editing the templates itself works great. However, the subject (which is saved in /themes/theme-name/mails/de/lang.php is not saved. Instead I have to change the subject hard-code in the lang.php. I first thought it's a chmod problem, but the lang.php is already 0777. Any thoughts?

It was the same for me. It now cost me some time to work it out, but now works. As mentioned above just include the line... $_LANGMAIL['New order : #%d - %s'] = 'yourlocaltranslation: Nr. %d - %s'; into the file /themes/theme-name/mails/yourlanguage The "proof" the module reallx expectes "New order : #%d - %s" (with a : and not a = or something else) can also be checked in the source code in modules/mailalerts/mailalerts.php Mail::Send( $id_lang, 'new_order', sprintf(Mail::l('New order : #%d - %s', $id_lang), $order->id, $order->reference), $template_vars, $merchant_mail, null, $configuration['PS_SHOP_EMAIL'], $configuration['PS_SHOP_NAME'], null, null, $dir_mail, null, $id_shop ); Edit: Very odd: Everything worked fine, then I edited some eMails a bit, and now it doesn't work anymore. I also get the impression that the line which I included and which got it working (see above) is again removed from the lang.php. Any ideas?

Ich bin heute beim Anpassen meiner Module auf gleiches Phänomen gestoßen. Kann man jenes Problem ggf. auch ursächlich beheben? Denn wie mein Vorredner bemerkt hat, fehlen häufig ja bei allen Modulen die entsprechenden Einträge in der Datenbank. D.h. durch Hinzufügen jenes Codes kann man vielleicht jenes Modul "fixen", nicht jedoch die anderen?!? Edit 1: Die Zeile, die unter /themes/theme-name/mails/de hinzugefügt werden muss, ist im Übrigen: $_LANGMAIL['New order : #%d - %s'] = 'Neue Bestellung: Nr. %d - %s'; (Unterschied zu oben ist der : anstatt -. Dass dies mit einem : vom Modul so erwartet wird kann man auch in modules/mailalerts/mailalerts.php nachlesen. Edit 2: Langsam wird's komisch. Erst funktionierte alles wunderbar, und dann habe ich im Editor noch ein paar eMails nochmal leicht editiert, und jetzt funktioniert es wieder nicht (und nicht reproduzierbar wird auch der Code aus der lang.php wieder gelöscht). Hat jemand eine Idee?