Jump to content

kmorgen

Members
  • Posts

    110
  • Joined

  • Last visited

Contact Methods

Profile Information

  • Location
    Denmark
  • Interests
    Know more about me and some projects at: https://www.morgen.dk https://www.chill-innovation.com
  • Activity
    User/Merchant

Recent Profile Visitors

6,331,194 profile views

kmorgen's Achievements

  1. Anyone knows how to translate the e-mail SUBJECT on the e-mails send from the Mail Alert module (V2.2.2)?
  2. The bug is created on Github, but not much happening unfortunately: https://github.com/PrestaShop/PrestaShop/issues/19134
  3. Er der nogen der har en god løsning / modul til den årlige lagerstatus opgørelse? Det indbyggede 'statsstock' modul i PS 1.7 er lige skrabet nok, da man ikke engang kan skjule produkter som ikke er på lager og eksportere listen (PDF).
  4. Nice post! I added the <head> code to the Custom Code field and the <body> code to the Tracking code fields which many themes have in the Theme Editor (or alternatively use custom content module and hook the <body> to Footer). This way no need to modify any core files, which might be overwritten during updates. However my biggest challenge is to get any useful content when using the Google Tag Manager?! Did you find a good tutorial to setup this to extract the Enhanced ecommerce data and User ID, Order ID's and value/currency etc. for Analytics, Conversions and remarketing? Not sure if need to create DataLayers and many Variables - which then seem like a huge task compared to use the build in free Google Analytics module. Then challenge would probabaly still be the Google Conversions / Remarketing.
  5. We have recently migrated from PS1.6 to PS1.7 and though using the same theme/design we have noticed quite a big drop in conversions. After some split testing, we can see it is a problem that visitors can no longer see the various Shipping Methods before creating an account - many will just leave the cart instead, when various shipping options are not fully transparent. In PS1.6 the customer could scroll down during checkout to see the various carriers before creating account. In PS1.7 all the checkout columns are collapsed, so shipping methods remain hidden until account creation. When using Geolocation the country is already established prior to creating account, so there should be no problem in also showing the various shipping methods - just like in PS1.6. Anybody knows how to solve/improve this easily in PS1.7 (we prefer to not use a 3rd party OPC module)? 1. Either ability to expand the Shipping Method column in PS1.7 checkout. 2. Alternatively show Shipping Methods in the Cart page
  6. Your tutorial only shows how to change the position - not how to change the actual symbol. One cannot just change the ¤ symbol, as this will just show this value for ALL other available currencies within this language. Furthermore the majority of languages do not contain the mentioned code in this file, but in another one (example: da.xml / da_DK.xml), so guess this content needs to be copy/pasted.
  7. Found a solution to this? Still bugging me in PS 1.6.1.11 :-( - when the tracking number is being returned to PS from the Webservice (carrier), the actual Order Status is being triggered one more time, resulting in the order status email being sent again.
  8. As explained, the API connection is established as a Webservice (Adv. parameters -> Webservice). You can see how it works on their site: https://www.pakkelabels.dk/integration/prestashop/ It's in Danish, but guess Google Translate can handle that :-) Everything works fine back and forth, the only issue is the current 'Order Status' is triggered again (not changed), when the tracking number returns (PS 1.6.1.11) I believe the issue started around 1.6.1.X, and Pakkelabels.dk say they cannot really do anything on their side, since they are just returning the tracking parameter.
  9. Well there is actually no module. The integration is a Webservice / API integration. So basically the shop send the shipping details to pakkelabels.dk, you purchase the shipping label, the site send back the tracking number to PS. And when that occurs the current order status is triggered one more time, it is not changed.
  10. Have a problem with the Order Status being triggered/updated one more time when the carrierr tracking is beeing returned to the shop from the external shipping provider/module (Pakkelabels.dk) This means the custormer will receive the status e-mail one more time. For example if already in "order Processing" Status, this status and thereby e-mail will be triggered again, when the tracking number is automatically received from the forwarder (API). Have contacted Pakkelabels.dk, and they say they have no control of this. Anyone know how to avoid the Order Status being affected by this?
  11. Also suddenly started to get these error messages in 1.6.1.9.
  12. Anyone? Could it be an option to manually alter the ID for the category price rule in mysql? - Not sure if it the ID value will override rules?
  13. Well Black Friday is coming up and we are planning to do 20-30% discount on all products. I was hoping we could just create some Category Price rules to override all other various discounts made under the individual products, but unfortunately these do not seem to override those. Any one have a solution for this, or a method to easily solve this (without having to edit each product manually)? If making a cart rule discount voucher instead, it will not really show the actual prices, and also the discount will be applied to any existing discount, so not the best solution.
  14. I now changed to the Prestashop Google Analytics module again, and the eCommerce data is transferred to Analytics again. So guess some issue (or my google tag configuration) which make the eCommerce data not working with Google Tag in PS. I have enabled the eCommerce in the Google Tag, and the Tag Asistant tool report no errors, so not sure what to do from here. Anybody with can see the eCommerce data in Google Analytics when using Google Tag instead og the PS Analytics module in PS?
  15. Just did a manual flush/delete of the cache folders through FTP (all content eccept index.php) Afterwards all the new cache folders are now permission 771, and not as before (default) 755. Can others confirm this is normal/correct behaviour? If I manually create a folder inside the cache folder it will be 755, so serverside is correct. So it must be the PS cache code overriding this to 771?
×
×
  • Create New...