Robbie301

I have a curious problem. After moving our site and having to perform a 301 redirect on more than 1000 URL's, I've been watching our Google Analytics carefully and fretting over our complete loss of all organic visitors. However, Prestashop back office statistics, and our own server data, does not reflect what Google Analytics is telling us. I have Google Real-Time analytics up on my iPad, and while it shows nothing at all happening on the site, Prestashop back office shows 11 online visitors. I even get non-ordered carts while I'm watching no one arriving on G Analytics. Yet, when I visit the site my presence immediately displays on Google live stats. I don't know what to believe. Is Prestashop lying to me about the visitors online right now, or is Google managing to spot me every time, but not some people? Have we really lost all our organic traffic, or is Google just not registering it? Incidentally, we set up entirely new Google analytics/webmaster accounts when we moved, because we wanted a fresh start. Has anyone else experienced this problem? Is there an explanation? I really want to know how we're doing in Google, but I don't know what to believe.

I have found the solution! Hopefully this will assist someone. It's attempting to call customer information from your database, and if you imported data you will likely have NULL columns. In my case, both siret and ape columns all had NULL data, because it was imported when not used. Delete these useless columns of imported data and the password recovery error magically vanishes. So glad I managed to work this one out. EDIT: Wrong solution! Although this resolved the password recovery error, I then had another error when customers attempted to check out, no new data was being allowed, so no one could create an account, siret and ape columns were being used in the new error and preventing data creation. I had to recreate the siret and ape columns (through a process of duplicating a PS install on another server and manually copying the column details). Somehow, this resolved both errors. I wonder if the original problem was due to password length. Numerous passwords imported would have been less than the characters permitted by the PS install (on the previous system I had it was a minimum 4 character password or something, and PS requires longer passwords). I created a longer password and replaced all user passwords, then sent an email informing customers to reset them. After these changes all SQL errors disappeared.

I'm having this same problem, and he debug is telling me at line 846 in file classes/ObjectModel.php 845. throw new PrestaShopException($message); No one seems to have a clue what this problem is or how to fix it. Do we just get rid of that line? Is it in the wrong place?

After buying this and attempting to install it I'm getting the following error: [PrestaShop] Fatal error in module Customer: Cannot redeclare class CustomerCore Can I ask how you installed this module? All information I have found relating to this error and Prestashop tells me that the module is incorrectly designed and should not have certain elements in it, as they are native to Presta already. I can't see how you managed to install this if its design is fundamentally flawed. EDIT: Waited a couple of days to get a response from the developer, who then wanted access to our system to investigate the cause. Obviously, I couldn't supply access because of customer data security and the security of our business. We requested a refund, which PrestaShop SA refused, we escalated it to a claim with PayPal and they found in our favor today. I think it's important to remind people that handing over access to core parts of your business to a complete stranger in another part of the world is not acceptable and certainly not safe. As a trader/retailer you are responsible for the security of all customer data, and anyone potentially having access to it should be an employee who can be legally held accountable. Users of PrestaShop (and PrestaShop itself) should be aware of this. Modules should work, and if they don't you (or an IT person you know and trust, someone who can be accountable) should be supplied with information to rectify any problem, you should never give access to your business to a complete stranger.

I'm having the identical problem, leading to a 500 internal server error. There is something about the link that is just not working. I had to import more than 700 customers without their passwords, so all of them will need to reset it when they return to us (the previous cart system was hosted with no server-side access and passwords could not be exported). I have tried changing the URL settings in back office, checking the email link each time, and everything returns a 500 error. I can't seem to find any information out there about this. Every time I check something it's about customers not receiveing the email in the first place, or about resetting admin passwords. Did you get your problem fixed? Do you recall what you had to do to achieve it? Thanks

I currently have an issue with password recovery, emails go to the right person with no problems, but when they click the link delivered in the email to reset their password it supplies a 500 Internal Server Error. I really need to have this resolved asap as I had to migrate from another system and move all customers without their encrypted passwords, which means that more than 700 customers will need to reset their passwords if they choose to return, or create a new account.

I don't need USPS or UPS modules because this is UK based business. I primarily ship to the UK and Europe. I have set up European delivery and international delivery by weight. UK delivery is set as FREE DELIVERY. Testing the delivery methods, I have disabled international and european and only left UK free delivery available, and still I am getting both of these messages. This should not be happening, it should be as simple as assigning the United Kingdom to FREE Delivery and that's it. I can't understand what other settings there could possibly be to change.

I'm trying to get free shipping to show for UK customers, everything is there and there should be no settings in the options for free shipping, other than selecting free shipping and assigning the UK zone to it. This has been done and it's now giving me both There are no carriers that deliver to the address you selected. No carriers available for the address "My address"

Nothing here is working for me. I don't have the advanced stock management module installed, and I have attempted to assign a default warehous, I'm still getting the No Carriers Available error on checkout. This is pretty rediculous considering being able to BUY is THE fundamental point of a shopping cart system. I think this has been made far too complicated and there are far too many variables able to go wrong. This makes Prestashop one of the most embarassing examples of "too many cooks" I have ever seen.

I would if there was a guarantee it would work. But if EVERY attempt at manually doing this is failing the problem is not likely to be resolved by buying a mod that probably won't work.

Nothing changed. Attemped to create a 301 redirect on a product and it's still going back to 404

I have moved my site from a really bad hosted cart solution to my own Prestashop, but now obviously every link has changed. /category has now become /4-category, and /product-name has now become /6574-product-name-6576746578346537.html I have tried absolutely everything. Every variation either works temporarily, works for one thing and not another, or doesn't work at all. Category redirects work, but then when I use the exact same method for a product it doesn't work. If I get a product review page or article to redirect, I still can't get a product to do it. Then when I do, something else goes wrong - like clicking the product directly in the shop tells me it's resulting in a redirect that will never resolve... Anyone have any ideas?