OK, so PrestaShop is likely the most awesome script to ever be developed for PHP based e-commerce.
That being said, it can be a royal pain in the ass. When put to the test of the modern web, and of modern web design, PrestaShop 1.3 appears to be unmatched in both versatility and ability. The problem with something so incredibly strong is that it comes with specifics that we didn’t understand when we began using. Add in that most of the support for PrestaShop is written in French or German, and you have long nights using the Google translator to understand a new program. Here are three of our greatest problems with this Sports Clothing and Memorabilia Website and the solutions we found for them.
1.) Data Entry-
The default Preshop CSV Uploader has problems with the use of certain type symbols in the uploaded descriptions. Our client is one of the best Fans Wear and Online Sports Clothing stores in the Chicago Area, so dollar signs and trademark emblems are a must have. The solution is to update these post-upload. You also can’t re-appoint item numbers once the first upload has been completed. This means careful planing and strategy must be incorporated into building your databases. Planning the database well, and having a map of the item numbers and category numbers will make sure that you can more easily find problems and errors within the tables. Brett recommends creating an ID numeric system for the products as well. Uploading the numbers through the CSV uploader will allow you to designate their ID instead of PrestaShop giving them an arbitrary listing. Again, this allows tracking of errors and problem within the tables.
This one was news to me. Most of the minor styling within PShop is still conducted in PHP and Module areas. What this means is that CSS will not save all situations, and sometimes makes it far worse. The PrestaShop Modules are given specific table locations, while still working in the new DIV and Class structure. While the global CSS style sheet is used for most every aspect of design, it’s more of the finishing piece for an already designed build. This seemed limiting in design structure at first because we were so used to using CSS for all web styling. The construct with PHP tables is actually much more decisive than most builds we’ve used in the past. In many ways, it’s like the fundamental Layout of a rails system. For any piece of the site, code can be adopted, or dropped all together when it is intruding. As long as the code is visual and non-functional, the site can function without it. This allows for extra code to be inserted in and multiple expressions to be used in its fashion.
3. The .htaccess will not work on the back side of WordPress.
PrestaShop 1.2 and 1.3 offer a strong set of strings for a working .htaccess and therefore, friendly urls. The problem is that when placed as a back file system of a WordPress build, and any other .htaccess driven sites, the database will always collapse when making categories. While there is some information out there about this phenomenon, Brett and I may have been the first team to really get rapped up in putting PrestaShop shopping carts on the Back side of a blog url.
All we can tell you is this. WordPress is by far the most SEO friendly foundation for any dynamic website or web development. We believe that the wordpress development on the front end of the online store should be more than enough to boost the site relevancy. If anyone has found a way to fix the .htaccess in a way that not only works, but works behind wordpress, please let us know. Up until now, all solutions have been very limited in the amount of categories that they would allow.