web.geek

To resolve these errors, save the modified file using "UTF-8 without BOM" encoding. See this post for additional information.

Merci beaucoup! I created an override class and suddenly similar error messages appeared. I changed the encoding in notepad++ from UTF-8 to UTF-8 without BOM, re-saved the file, uploaded, and it worked!

So, I assume you are referring to the columns under the "Featured Games" heading. It's a simple CSS change, and I highly recommend using FireFox with FireBug for testing these types of CSS configurations. I was able to change your layout in my browser from 2-column to 3-column by changing the following code (line 679 in global.css): div#featured-products_block_center ul li { width: 110px; /* was 190px; */ } See the attached before and after. Since you are using a background image for those <li> tags, you will need to resize it for the new column size. Is this what you were looking for?

Your shop is disabled, so we can't view it through the link you provided. Are you using the default theme? Are you using the "Featured products on the homepage" module?

Sorry for hijacking this post, but I wanted to document the problems I ran into when testing the OPs problems Well, this will be fun. After I tested setting catalog mode on (on my test environment) and then turning it back off, I have lost my entire right column. Now I have to investigate whether this is a bug. Anyone seen this behavior before? Update: I can't even view product details. When I try to view a product, I lose the center column as well. Definitely something strange about switching between catalog modes. Update: I thought it might just be a browser cache issue, so I cleared the cache and the columns came back. I soon realized, however, that I was also logged out. When I logged in as a customer again, the same problems returned. Update: So the problem seems to only affect the existing customer. I created a new customer and everything works fine for that customer. Update: Checked the details of the non-functioning customer, and everything looked good. Ended up checking out the shopping carts, and I noticed that the person had a cart, but it wasn't displaying properly in the list of shopping carts (it was truncating the row after the customer name). This brought me to an important lesson learned...always turn on 'display_errors' and '_PS_DEBUG_SQL_' when working in a test environment. Turning on those displays, I found the following error: Warning: key_exists() [function.key-exists]: The second argument should be either an array or an object in /.../classes/Cart.php on line 1088 Fatal error: Call to a member function getOrderShippingCost() on a non-object in /.../classes/Cart.php on line 1091 Checking the database, I discovered the red herring. This customer's cart had selected a carrier that was part of the UPS module. I had removed the UPS module earlier, so the database call was producing an invalid value for the shipping costs that were being passed to the Cart.php class in the error code above. I changed the carrier id to a valid carrier, and the error disappeared and the columns all appeared. I now return you to your regularly scheduled forum post

Check that you aren't in Catalog mode: under the Preferences tab, click Products. The first item should be "Catalog mode:" and it should be set to "No". I just tested setting mine to "Yes," and it changed my site to look just like yours.

Traduit de l'anglais au français par Google: Je voudrais aussi en savoir plus sur ce module. Est-ce que quelqu'un sait à ce sujet? (I would also like to know more about this module. Does anyone know about this?)

I think I may know what you are saying, but I'm not sure whether I'll be able to help. Can you post a screen shot that shows what you are describing? I think I had a similar problem, if I'm understanding correctly. I had customizations, but the "Add to Cart" button would be shown with the default price when the product was displayed in any list (category, new products, specials, home featured). When you viewed the product, you could choose the customizations and the price would be properly adjusted.

I started using PrestaShop with 1.4.0.4, and I've upgraded every 2 or 3 releases as I tested. But I perform upgrades manually by comparing differences in the base code with my current code. I do the same for the database by scripting out the base installed database and my current database and compare them with WinMerge. I also check the /install/sql/upgrade folders and incorporate the scripts from those files. The /install/sql/upgrade/1.4.0.14.sql file has some code in it that I hadn't seen before. /* PHP:add_new_tab(AdminInformation, en:Configuration Information|fr:Informations|es:Informations|it:Informazioni di configurazione|de:Konfigurationsinformationen, 9); */; /* PHP:add_new_tab(AdminPerformance, de:Leistung|en:Performance|it:Performance|fr:Performances|es:Rendimiento, 8); */; /* PHP:add_new_tab(AdminCustomerThreads, en:Customer Service|de:Kundenservice|fr:SAV|es:Servicio al cliente|it:Servizio clienti, 29); */; /* PHP:add_new_tab(AdminWebservice, fr:Service web|es:Web service|en:Webservice|de:Webservice|it:Webservice, 8); */; /* PHP:add_new_tab(AdminAddonsCatalog, fr:Catalogue de modules et thèmes|de:Module und Themenkatalog|en:Modules & Themes Catalog|it:Moduli & Temi catalogo, 7); */; /* PHP:add_new_tab(AdminAddonsMyAccount, it:Il mio Account|de:Mein Konto|fr:Mon compte|en:My Account, 7); */; /* PHP:add_new_tab(AdminThemes, es:Temas|it:Temi|de:Themen|en:Themes|fr:Thèmes, 7); */; /* PHP:add_new_tab(AdminGeolocation, es:Geolocalización|it:Geolocalizzazione|en:Geolocation|de:Geotargeting|fr:Géolocalisation, 8); */; /* PHP:add_new_tab(AdminTaxRulesGroup, it:Regimi fiscali|es:Reglas de Impuestos|fr:Règles de taxes|de:Steuerregeln|en:Tax Rules, 4); */; /* PHP:add_new_tab(AdminLogs, en:Log|fr:Log|es:Log|de:Log|it:Log, 9); */; I'm a DBA by trade, so when I see comment characters (/* */), I know the database engine will ignore them. My question is: do these statements do something when run through the PrestaShop install/upgrade process? More importantly, will I be missing something in my final version if I ignore these statements?

Do you have a sample of what the code was before and after the edit? Do you have a backup of the file you were editing before you started the edits? Do you remember what you changed so you can undo? Are you sure the site was displaying correctly in IE8, FF, and Chrome before the change?

Installing 1.4.0.17, and I understand that the database user during the install process needs all privileges so it can create all of the objects. I would like to change that user in the config/settings.inc.php file after the install to one with fewer privileges for the operation of the site. I imagine it would only need SELECT, INSERT, UPDATE, and DELETE (perhaps REFERENCES) privileges, but I wonder if anyone has a definitive answer. What are the minimum database user privileges needed by the _DB_USER_ for the application to fully function? Thanks

It sounds like a couple of possibilities. It could be calculating that the weight is greater than 7 lbs already and using the highest shipping fee by default. That would also mean that your free shipping after X lbs logic probably isn't working. Or it could be that the weight of the second item is somehow set to 5 lbs. Outside of that, I'm not sure. Are you using any shipping modules? The UPS module has some well known issues in bug tracker, although this doesn't sound like any of those. I've been using 1.4x weight ranges for a couple of months now, and I haven't run into this problem before.

I imagine you might have to do this in the back-end database, but I'm curious why you would take this approach. Of course, I always begin by asking what version you are using, since I am only familiar with 1.4x. In 1.4x, you can limit "qty per each user" when the voucher is created. This limits the "number of times a single customer can use this voucher." That way you only have to e-mail and track one code. Obviously, you may have a good reason to generate unique codes, but I just wanted to make sure you were aware of this functionality.

Not sure what version of PS you are using, but I believe both 1.3x and 1.4x have shipping rates by price and weight ranges. If everything in the shop costs $15 each and always weighs 1 lb. each, you could set up a shipper by weight range or by price range. For instance the setup by price would be something like $0-16 = $5, $16-31 = $8, $31-46 = $11, $46-61 = $14, $61-76 = $17, $76-100 = $20 (the last range would be 76-90, but since you are using $15 increments, anything after $90 is going to be over $100 and get free shipping). Make sense? For weight you would do something similar: 0-2 lb = $5, 2-3 = $8, 3-4 = $11, 4-5 = $14, 5-6 = $17, 6-7 = $20.

The following SQL code will update the cache_default_attribute column with the default attribute id for all products that have defined attributes: UPDATE `DB_PREFIX_product` AS p, `DB_PREFIX_product_attribute` AS pa SET p.`cache_default_attribute` = pa.`id_product_attribute` WHERE p.`id_product` = pa.`id_product` AND pa.`default_on` = 1; Replace DB_PREFIX with your appropriate value (e.g. ps).