eec

Thank you very much, worked perfectly on our shop as well.

If you are familiar with DB and SQL it is a very simple fix, refer to my post from August 2015 above, and that will work. I do not recommend messing with the import CSV of the BO, instead after your import examine the relevant tables, listed in my previous post, and fix the issues to your liking. Anything marked as CUSTOM = 0; will show on the left column in BO and will be part of the filter. Since these all somehow affect the search, I would recommend recreating your index from BO after you are done with all the changes above. Good Luck, and post here if that solution works for you as well so others will know and utilize it.

It's been a while from your question and probably have got it fixed. I just realized that independent of all the carrier related settings, such as Zones, Ranges and so and so, there is another important step to take to make carriers work on countries. And that would be to make the Country of choice 'Enabled' in Localization--> Countries. You would think this setting could have been placed under shipping or a warning message could have been issued warning you that some countries under the zone that you are working on are not Enabled. But in our cases we just faced few countries were customers could not properly check out and once I investigated the DB table I found this issue.

i am not familiar with Prestashop manager, if you have access to any of the database tables i recommend reading my earlier post you could see that few posts above, there I have explained how the category table can fix this issue.

where do you try to set this value? Back office? Database? Please precisely explain so I might be able to help.

Hello Aerotexextintores Have you noticed that position (order) starts from Zero, the fix might be as easy as as setting the position value to zero not one. But you also need to make sure you only have one item with each position value, in other words position values should be unique. This would be a concern if you are about to edit the DATABASE to change the orders. Having duplicate values might not break the website but it might make PS to choose arbitrarily the order of presenting the products. Hope this helps you.

Hello Marion I saw your screen shot, you can do the following, find the CSS file which define the class "menu-title"; i noticed that in response to vekia you have mentioned you are not using the module that we are referring to, but that is not a problem, still there should be a CSS file where this class is being defined, you can either find out which module is being used for the menu, then search folders of that module. Or do an extensive search on contents of CSS files looking for the class name. Might sound strange but in dealing with different web programs that are using their own MVC implementation and are not easy to follow sometimes this method comes very handy. Once you find the CSS file, the place there that class is being defined is where you would put that code. Note, if you have different types of menu items like I do, and want them to act differently apparently you need to make sure they are not in similar CSS class. If it doesn't make sense now once you implement the above you will realize what I am referring to. Hope this helps, Good Luck

Last few days I was dealing with this problem, surprisingly I could not find any threads on any of the PS forums. Now that I have resolved the issue I decided to share this matter with others. Problem was that our PS used to expose its version. That is how it works servers in their response header normally will share some of their configurations with the world. there are good reasons for most of the information being shared, while some pieces are better kept private. Such as the version of server application e.g. Apache or the version of the PHP compiler. Argument is that these information will add vulnerability and might invite troubles, a specific version of Apache or PHP might be discovered to be vulnerable to a certain attack and by your advertising its version basically it motivates interested people to try their skills which is something administrators are not happy about. So it is best to keep these information secret, and there are easy ways to do so, check your Hosting company's documentation normally simply form the Web hosting management portal you should be able to configure these, for the reference these work as follows on Apache and PHP: Apache setting (httpd.ini): ServerTokens ProductOnly ServerSignature Off PHP settings (php.ini) expose_PHP = Off; Set these on your server instance to fix configurations. In my case I have had done these at the time of installation of the website, and assumed that it should not be providing version specific information, but few days ago I noticed that PS still puts the PHP version information in the response header it looks something like this: X-Powered-By ... All the settings on server and management portals were ok, but still this was being placed in the response header only on the sub-domain of our PS. Lastly I noticed that there is a php.ini file in the root folder of PS installation I do not really know how it works but apparently it is being appended to the system's php config, and placing below line in this PHP.ini finally resolved the matter. expose_php = Off; hope this can save other people's time as it took me half an hour to figure it out. And if anybody knows why and how PS overwrites the server's php configurations it would be nice to share it here. Good Luck to all. P.S. response headers can be easily seen for example in chrome browser's developers tool, check google's documentation if you are not familiar with how to see those messages.

Mila_omni Thanks for the advice. It worked for me but not exactly in the way mentioned above. And I will explain more details here since I believe it will be useful to others as well. In our PS we do have different First Level menu items, e.g. HOME is there which is a non-expanding item, only it gets clicks and sends users to Main page, same holds true for Contact Us item which sends the user to the feedback form page. At the same time some items like PRODUCTS are expandable, which means once user hovers over them they drop down a list of choices. My problem was that not only these items where dropping the choice lists but also they were clickable, so if the user is not familiar with the concept of hovering over an item and waiting for the drop down which more or less people are not, and they tend to click on everything, we could not get the chance to show off our beautiful drop down menu and worse people would have been landed on meaningless intermediate pages to choose the product category whereas the whole thing could have been eliminated if we could make the expandable items of the main menu un-clickable, and at the same time the non-expandable ones clickable. Above solution is wonderfully smart in using CSS to inactive the clickable feature of the anchor tags would affect all items in same manner, this part is undesirable. in our case since expandable items where created by the module through its menu items menu (in back office) "menu top link" and the CMS items were created with "Add a new Link" of the same Back office feature. They had inherently a different class. You need to verify this in your case easily by inspecting your page with firefox or chrome developer tools. in our case "menu top links" were instances of sf-with-ul class, hence adding this piece of CSS to overriden version of superfish-modified.css solved the problem: .sf-menu a.sf-with-ul { pointer-events: none; cursor: default; } I started this thread Dec 2014 and today I am so happy that this issue has been resolved, you are all awesome thanks for your comments and help. all the best

thank you CodeMonkey your step 2 solved my problem, i did not understand why you changed the status name but anyhow the solution is to change the OrderHistory.php Thanks a lot

Thank you PascalVG I could fix my PS1.6 problem with email template with your explanation of the ::Send signature. Awesome

Thanks to sum4444 I just the recommendation and it works, actually i have simplified it due to the fact that our shop does not use customization or grouping of products hence everything is much simpler. And also I have modified the CSS of the email.

Just Today I faced this same issue and while trying to fix it I found these links from the carriers themselves. USPS: https://tools.usps.com/go/TrackConfirmAction?tLabels=<TRACKING NUMBER> UPS: https://wwwapps.ups.com/WebTracking/track?track=yes&trackNums=<TRACKING NUMBER> FedEx: https://www.fedex.com/apps/fedextrack/?tracknumbers=<TRACKING NUMBER> Please note these are not fancy 3rd party pages, these are the original page that each of the carriers provide to customers for tracking purposes, for trust and security reasons in our implementation we have decided to keep these as genuine as possible. As of today these links work, which means if your shop puts the tracking number in assigned location and sends the link to the customer by clicking on that link the tracking should be accessible from the carriers service.

For this to happen first you need to override the page which lists search results and in that page you need to implement the DATATABLES It helps greatly to understand / know that for each search the SEARCH.PHP is called and it basically sends a SQL query to MySQL database and stores the results of products' search in an array of sort. So once you have re-configured your search results page, then you will implement the DataTables JQuery tool there, with products / items returned by Search.PHP, DataTables will provide the filtering and search within results features. Search.php is somewhat commented and documented both in the php file itself and in these forums, also the DataTables has got its own website and forum with many active users which is a great resource. In our case I have overriden both the search.php and search results page's smarty (tpl) file to get the desired outcome. I assumed you are familiar with these concepts of over riding functions/classes in Prestashop and also with SQL queries and SMARTY etc. Otherwise it will take some effort to manage this. But the result is totally worth the effort, visitors will like the feature. hope this helps

There are various scenarios that carriers might not show up in PS 1.6. Basically as one of the earlier posts has highlighted we need to make sure that the warehouse in which the product is located is associated with a Carrier. Most of the times I manage our shop from the Database and not from the Back Office because of number of products that we offer 2,300+ and because I need to have these rapidly changing products connected and in sync with our PLM (Product Life Cycle Management System) due to all these whenever a bug of this sort occurs I need to find out how to fix it from the Database. For this specific issue, I noticed that I need to make sure all products are properly assigned to their warehouse(s); Since we are not utilizing the advance stock management feature of PS it is easier, there are few tables starting with PS_warehouse... names and column names will clear what is the purpose of each one. For my case I made sure all PRODUCT_ID's are listed in the warehouse, and all carriers are properly associated with the carrier. And one last step I needed to make sure ADVANCED STOCK MANAGEMENT is not checked for any of the products, and this feature is both on PS_PRODUCT and PS_PRODUCT_SHOP make sure if you are using SQL / Database to change both of them, very unfortunately PS tables are not properly tied to each other, which could be for a reason but if manipulating the table from Database you need to be aware of these, there is a very helpful SCHEMA drawing of PS tables as well on their website which is really helpful in these kind of fixes. Hope this helps