Jump to content


  • Posts

  • Joined

  • Last visited

Posts posted by Pressed0024

  1. Wow Falgener, 1.2.1 XML is quite powerful. I have not explored deep but if I put XML and cron together, I can in future create many possibilities.


    1. I noticed a bug with Delivery Other. csv does not place the " at the end of it, causing any rows after that to escape weird.

    2. Delivery other also seems to be unable to output numeric value to csv.


    Above 2 issues might also be affected in Invoice other but I have not had the time to verify since I use Delivery other.


    Hopefully fix for post #73 and Excel request for #63 will be out soon (=

  2. Currently, when customers use the Contact Us (indicating their order number) or the Order History to send messages to store owner, we will open the email from our Gmail and reply from there. But when the next reply comes for the SAME order, previous messages are not present in the email. Sometimes customers would forget what they email us about and have to search through their inbox for previously conversed emails to recall.


    It would be good to have a module that is "Smart" like Zendesk's threaded replies so that all past conversation regarding the SAME order number is present in the email. Customers do not have to search through their inbox for previously replied emails to recall the details of the conversation, saving customer time and ease their experience contacting us.


    I have attached a screenshot of a sample how threaded emails should look like.


    Please don't advise using the current Prestashop "Customer Service" feature because the way emails are handled is terrible.

  3. Wow Falgener, 1.2.1 XML is quite powerful. I have not explored deep but if I put XML and cron together, I can in future create many possibilities.


    1. I noticed a bug with Delivery Other. csv does not place the " at the end of it, causing any rows after that to escape weird.

    2. Delivery other also seems to be unable to output numeric value to csv.


    Above 2 issues might also be affected in Invoice other but I have not had the time to verify since I use Delivery other.

  4. Why no one thought of this? CDN images, js and css in BO for faster loading?


    It's pointless each time we view an order in BO or edit products, we have to load the same images and icons (DOMs) in BO. Better still, cache it!


    My servers are in the US for the benefits of my customers but I am not. If the images in BO can be CDNed, my staffs and I would have faster BO loading time. That means being more productive!


    I'm surprised no one ever thought of this since I googled about this and no one brought this up before.


    Anyone willing to share codes how to get this done without breaking the BO?

  5. My servers are in the US for the benefits of my customers but I am not located in the US. BO speeds are naturally slowly due to geo distance. Would love to know if anyone found ways to get the actual browser load time for BO under 2 sec.


    eg. editing codes/classes, more RAM/CPU, Cloudflare Railgun (possible?), APC php accelerator for BO?, changing the way BO queries mysql, CDN selected images/js/css files (there are many images/js/css that are repeats and pointless to load from origin server) ?

  6. Firstly, I'm a speed freak.


    I spent the last 2 days researching a lot how to get my site pop up instantly. Basically this is the equivilent of using http://www.webpagetest.org and checking the video. From the time you press play to the time the white page turns into your Prestashop store. I get about 4.5 sec but want to reduce it down to 2 sec or less. This gives the feeling of near instant load. Testing nodes are set to have it tested in the same country as I'm hosted (USA).


    Let's put all those prestashop CCC, CDN stuff aside. Those are the very prestashop basic. What else can be optimized to get Prestashop to achieve the 2 sec REAL page start load time?


    I'm on 2 cores with 1GB RAM. mysql query cache is at 512mb. Store has less than 500 products. The caching system (memcached, file system, etc) in Prestashop is still bugged so turning them on is useless and counter productive. My db query per page for most pages is about 600+ queries and 100+ queries for home page (standard Prestashop modules enabled and sql queries were not professionally tuned by experts yet). initContent load time average about 600-800ms.


    Has anyone seen a Prestashop that can render in 2 secs or less? If so, how was it achieved? (Railgun, db query tuning, other advanced php cached, db on an ssd, using a Full Page Cache module by bELVG? Which would have the most obvious impact?)


    Many of the bigger Shopify stores are our competitor and they load way faster at under 2 sec REAL page load (from white blank page to store reasonably loaded with enough content to start browsing).

  7. Memcached has not been working on Prestashop released since ages. When are you guys at prestashop going to fix it? It's so important that we cache database queries to offer near instant page load speed on our server.


    Memcached offers a huge speed increase to page loads and offers a lot of benefits to merchants in their BO and customers on the FO.


    Prestashop should prioritize things and get Memcached fixed! None of the 1.5.x version has memcached working properly.


    See all this bug reports, there are a lot more of them if you search:






    The memcached should have as low miss rate as possible and have security loopholes patched to prevent external connections to the memcached server.


    Prestashop Team, memcached bug is long overdue, you guys can't seem to get it right even at 1.4.x. versions.


    Do a solid memcached fix for 1.5.4.x once and for all.

  8. Shacker, your current module is aimed at reducing db data so that less rows will be pulled during a db query. Would you considering working on a module that optimizes the database query instead? Prestashop is notoriously famous to do many db queries. Minimizing the db query on page load would dramatically speed up website load time as less time is taken to query the database.


    Let's aim to get the html file first load "waiting" time from 500ms to 50ms. This means any clicks to the store will result in near instant page load.

  9. States with proper spelling:


    Recommended but go through to quality check data. Eg. For United Kingdom "County Down" is not a state. They didn't phrase it properly.


    Includes Cities for major countries:



    Relevant data:



    The data you used seems to come from here:


  10. 2 suggestions on the next release:


    1. Remove those [ ] square brackets containing the metropolis, municipal, district, etc. It's quite redundant and confuses customers.


    2. There are certain countries with irrelevant states. Eg. Singapore does not have states but your module list North West, Central region etc. Although the country does have such regional categorization but it is never used in addresses and postal system.


    Not too sure where you obtain the data for the states but state names should be spelt the way locals will use to ensure high delivery rates to customers. At the end of the day, it's the local postman that does the sorting. eg. Malaysia. The state is Kuala Lumpur but you listed it as Wilayah Persekutuan Kuala Lumpur. No one ever use the word Wilayah Persekutuan.


    Many other countries in your state database has this issue.


    Most customer just want to get it done and over with their address and not see text like "Federal territory" in their states. You might want to rework on the state data so that it's easy to use for our customers to read. I'm sure many merchants want to make the checkout process as simplified to our customers as possible.


    [update] You first need to identify which countries uses the State system and set the Prestashop Country States requirement correctly. Then trim redundant word(s) in the State such that it is locally or internationally recognized.


    [update1] Another thing to check. Tokyo is spelt as Tôkyô on your demo. Why are there special characters on it? Some countries also face this issue.

  11. Hi Pressed0024,

    I have not seen you for a long time :)


    1/ Yes, will be added

    2/ I have not test, I have not Excel2003, but maybe help You this: http://www.itg.ias.e...racter-encoding


    That's because your module made me busier cos I provided better customer service with your module and gained more customers! :)


    I'm actually on Excel 2013 and can open Excel 2003 files. I tried the URL you suggested but firstly it doesn't import to excel well (the delimiters can't understand the csv well) and secondly it takes a lot more time figuring out the delimiters because some csv may contains certain characters or spacing that confuses Excel (OO is much smarter).


    If the module can export in .xls format directly, it's a lot simpler.

  12. I am currently


    1. Does your module affect current Zone, Countries and States? I use my own custom Zones and have added some States before. No need Countries were added.

    2. Also how does it affect previous orders and previous customer stored addresses?

    3. I use ebewe autocomplete which uses Google API. Are all states exact match to Google API?


    4. For USA states, are they fully compliant to Paypal's state check? (Paypal checks exact spelling for States and declines payment if state spelling is not an exact match)

    5. Is there a demo page for us to test actual load speed since the script will query a database full of states?

  13. Falgener, I just wanted to thank you for such a great module! I use it every single day and look back at how much time your module save me! :)


    I just have 2 suggestions to add:


    1) Add Order Status field (the order's latest order status)


    2) Ability to export in Excel 2003 without problems with UTF-8. You can read previous issues with UTF-8 with excel starting from here: http://www.prestasho...s/page__st__180


    I open the exported csv via openoffice and save as .xls so that I can work in Excel which is a lot more powerful and "talks" well with my other excel spreadsheet. But I feel this can be improved by directly exporting in .xls format, saving me some time converting to .xls format.


    I hope the export to .xls works out well and does not show ???? symbols for those foreign characters (eg. Chinese, Swedish and other utf8 characters)


    p.s. Excel is well known to not work well with csv. We tried many other alternative but currently the only solution is to export in .xls itself to simplify our daily process and reduce possible characters error. Copy and pasting between openoffice and Excel sometimes also don't work well.

  14. Each time an error occurs, the previously typed text all gets forgotten and will have to retype.


    Does Contact Us page create tickets as well? How about Account History order comments and Checkout Page order comments?


    Quite a few errors like this in your demo when replying to tickets:

    Data's processing encountered 1 errors :

    • base: impossible de cr\u00e9er\/mettre \u00e0 jour le ticket \u2013 ce compte Zendesk est arriv\u00e9 \u00e0 expiration;

  15. Suggestion:

    Add Carrier field and Delivery Address Other* fields


    *Customers like to leave notes in the "Delivery Address Other" field when creating address for special delivery instruction to postman. Sometimes we miss this out because it's not exported. I think I requested this before, would be great if you can add this field :)


    Make Fields to Export sortable by position.

  16. Hi,

    You may save some setting (filter, fields etc.) as Setting 1, then You may switch to "Alternative setting" (as Setting 2), select another fields etc and save as "alternative setting". - To quickly change filters, fields etc. settings :)


    Ah i see good idea :)


    Is there any way I can by default have the filter tab appear on configuration page load? Cos I change the dates and order status on a daily basis you see. So having the filter tab expanded by default is a little convenient for me :)

  • Create New...

Important Information

Cookies ensure the smooth running of our services. Using these, you accept the use of cookies. Learn More