Jump to content

Paul C

  • Posts

  • Joined

  • Last visited

  • Days Won


Everything posted by Paul C

  1. I'm wondering if the order you did the above in was maybe wrong. Try uninstalling and installing the module again - maybe the registerHook() call failed as the hook wasn't set up in the database correctly when the module was first installed? Paul
  2. This is usually an indication that the search engine doesn't consider the description you've provided matches the page content. As Madrileño said above, the generation of the snippets are automated. There are only two ways to "solve" this -- either change the wording of the meta description to be consistent with the keywords on the page or change the page content to be consistent with the description The meta description is only a suggestion, so best make it a good one.... Paul
  3. If it's just static html you have two options. Either code it directly into the smarty template file, or use a module like: http://www.ecartservice.net/free-prestashop-modules/addstuff-for-prestashop/ I do have another later version that's been enhanced slightly by a contributor but haven't uploaded it yet. I'll try and do that in the near future. Paul
  4. Hi there, Yes there's still a problem. umadbro was testing yet another tweaked version - I'm pretty sure it's fixed but didn't want to release yet another version that's identical for en_GB and en_US stores You can grab a copy from: http://www.ecartservice.net/wp-content/uploads/2011/08/googlebase_0_7_3_5_1.zip It's identical to unless your language contains diacritics Paul
  5. The forum is broken, so I can't edit the above. The first mention of CategoryControllerCore is misspelled. and in the code it should read: [color=#000088]class[/color][color=#000000] [/color][color=#660066]IndexController[/color][color=#000000] [/color][color=#000088]extends[/color][color=#000000] [/color][color=#660066]CategoryControllerCore[/color] [color=#660066] [/color]
  6. I don't have time right now to try this but it sounds like fun so I'll write what I would try If I understand correctly - you are using PS 1.4.x and you want the usual "page" for category 8 to be displayed as the homepage of the store? The home page is the index controller, so that's what you would need to override. One strategy could be to override the IndexController and instead of extending the "Core" version of that controller, extend it from CategoryControlerCore instead. The main issue would be that this latter class assumes a category id has been POSTed (as in your code above). You would then likely need to override the preProcess() member function to: a) Set the category id in the _POST array, and Prevent Prestashop from rewriting the url to a category one. class IndexController extends CategoryController { public function preProcess() { // We'll be naughty and fake the category $_POST['id_category'] = 8; $this->category = new Category((int)Tools::getValue('id_category'), self::$cookie->id_lang); FrontController::preProcess(); if((int)(Configuration::get('PS_REWRITING_SETTINGS'))) if ($id_category = (int)Tools::getValue('id_category')) { $rewrite_infos = Category::getUrlRewriteInformations((int)$id_category); $default_rewrite = array(); foreach ($rewrite_infos AS $infos) $default_rewrite[$infos['id_lang']] = self::$link->getCategoryLink((int)$id_category, $infos['link_rewrite'], $infos['id_lang']); self::$smarty->assign('lang_rewrite_urls', $default_rewrite); } } } I've a feeling it would get messy, but the above would be the most elegant way (in my opinion) of doing it. Worth a shot at the very least The second approach would be to write your own custom IndexController class that's based loosely on the CategoryController class, but dedicated to only displaying the top-level of a particular category. Paul
  7. I would throw back to you "What kind of High Availability environment/strategy do you have/want to use?" Paul
  8. Just noticed that the latest version release requires PHP 5.2.x or higher. Just a heads up for anyone who moves from a test server running 5.2 to a production server running an earlier version..... This dependency can be removed by replacing the Tools::packJSinHTML() function with one from an older 1.4 version. Alternatively you could use this replacement: public static function packJSinHTML($html_content) { if (strlen($html_content) > 0) { $htmlContentCopy = $html_content; $html_content = preg_replace_callback( '/\\s*(<script\\b[^>]*?>)([\\s\\S]*?)(<\\/script>)\\s*/i' ,array('Tools', 'packJSinHTMLpregCallback') ,$html_content); // If the string is too big preg_replace return an error // In this case, we don't compress the content //if ( preg_last_error() == PREG_BACKTRACK_LIMIT_ERROR ) { if (!$html_content) { error_log('ERROR: PREG_BACKTRACK_LIMIT_ERROR in function packJSinHTML'); return $htmlContentCopy; } return $html_content; } return false; } Paul
  9. The supplier reference is different from the gtin. The gtin field picks up the UPC database field from Prestashop (if selected). If your catalog has the manufacturers part number in the UPC field, then it isn't going to work. Selecting gtin as "None" is fine though as long as you populate both "manufacturer name" (passed to google as g:brand) and the "supplier reference" (passed to google as g:mpn). Paul
  10. There's something not right as the version doesn't include weights (the shipping section is currently being implemented in the 0.7.4 version along with taxation). Are you certain you're using the latest module version and not an old 0.6 series one? Paul
  11. On the module configuration screen what does it say for {compat=xx} in the title? It may not be picking up the correct version number from the configuration table? It should say "14". The way it calculates that number is a little naughty, so if not I may have to change it Paul
  12. @DorkV Thankfully these are only warning and not actual errors so you should be able to list your products. The shipping_weight attribute is implemented in the next release, but requires that you enter the packaged weight in your product catalog for each product (in the weight field). MPN is the manufacturer part number - you need to enter these in the "supplier reference" field in the product catalog, and ensure that the box is ticked in the module configuration screen. The Google product category is not yet implemented (will require a new look-up table to match your category with the Google standard ones). I'm puzzled about the "Product Type" - this should follow your category structure e.g. "Books > Fiction" - so I would have expected that to be present. I do have a bug report relating to the older version of the module that also has a problem with some product_type, so this could be related. You can PM me the url for your store (and/or the url of the xml produced) and I'll take a look. The url can be copied from the link at the bottom of the module configuration screen (assuming that you've created the file below your web root directory). Paul
  13. Thanks to you, otherwise I'd never be able to create proper data for testing Paul
  14. Was that will fail all products because of the missing "condition" element. Email me the xml file again and I'll try running it through as a test in Merchant Center to see if I can coax it into telling me something Paul
  15. There was a bug in which meant that the "condition" element was being missed out of the feed. I've uploaded which fixes this. I'm working on 0.7.4 currently which (at least attempts) to handle the following: - "Target Country" drop-down to allow feed specifics per country (with additional configuration options for fine-tuning). - US (only) tax requirement that the price must be ex-VAT with regional tax variation included to override defaults (if required). This will generate a country, state (if configure) and county (ZIP code range based) rates. These can optionally be excluded altogether so you fall back to the value configured in Merchant Center. - Shipping groups (per carrier and per country/state) plus a shipping weight. Will be optional should shipping be configured in Merchant Center. - "Online Only" attribute for stores that also have listed physical stores in addition to an online presence. The use of the "county" subdivision is a tricky one and am open to suggestions. Currently I'm ignoring the whole "Zip code" section and assuming a wildcard ZIP Code format that Google use as the county name to allow subdivision of states. An example of the new elements would be: <g:tax> <g:country>US</g:country> <g:region>AL</g:region> <g:rate>17.5</g:rate> </g:tax> <g:tax> <g:country>US</g:country> <g:region>965*</g:region> <g:rate>19.6</g:rate> </g:tax> <g:shipping> <g:country>US</g:country> <g:service>Delivery next day!</g:service> <g:price>7.95</g:price> </g:shipping> <g:shipping_weight>0.5 kg</g:shipping_weight> <g:online_only>n</g:online_only> The above has been set up assuming that a default rate has been applied within Merchant Center. The state of Alabama has been assigned a tax rate of 17.5% and ZIP codes (in this case within Alabama but I'm sure this isn't correct!) starting with '965' are assigned a tax rate of 19.6%. This was created by adding a "county" to Alabama with the name '965*' and then assigning it a specific tax rate. To cut down on the size of the feed it allows you to enter the "default" that's configured in Merchant Center, so only then adds exceptions to this (otherwise it generates groups for the country + one for every sate and county; most of which may be identical anyway). For shipping I'm still working on it, but this should work in the same way - currently this example is showing the standard (sample data) next day delivery to anywhere in the US for $7.95. The shipping weight is explanatory - but it's important to remember that this is the product weight field in the catalog, so these values should be entered as "packaged" weight as a matter of course. Remember that you can post bug reports/suggestions using the form on my site too if you wish to do so directly to me rather than via an open forum. It generates a message to me only. Prestashop Google Product Feed Bug Report Form Many thanks to all those who have taken the time to test so far - I know it can be frustrating when it doesn't work, but it means that he code will be all the more stable! Paul
  16. Is the static HTML page the only such page on your site or do you have several such pages? i.e. Is the site a single static page plus Prestashop store, or is it more complex than that? Paul
  17. No the changes are for encoding specific language characters, so if your feed is in UK or US English there won't be any difference.
  18. Uploaded to first post. change log - Modifications to xml entity encoding (hopefully to finally solve problems with German/French feeds) - Translation support added for <g:condition/> and <g:availability/> (seems to work ok if left as English though) - Minor changes to variable naming Paul
  19. I hadn't come across that first link but the second one I have -- sadly it's in english I've been trying to explore the documentation in German but since I can't read a single word of it navigation is a pain lol Cheers, Paul
  20. @umadbro Yeah it's a minor issue and not what's causing the problem. I'm wondering if I'm going to have to code it to use different character sets depending on the country, or do custom character translations within the code. It appears that it doesn't accept html entities like: É ä Although that doesn't really make sense to me :/ Another thing I noticed though is that the elements <g:condition/> and <g:availability/> are both in English in your feed. I've added code for the availability text so that it's translatable, but condition is a Prestashop field value and I have a feeling it isn't directly translatable - I need to check on that and come up with a solution there too I think. It might be interesting to see if the version output can be made to validate and work back maybe. I haven't found an example german xml feedfile anywhere.... might try and see if there's a french one as the principles should be similar. Paul
  21. Just had a look at the url you sent me before (I'm assuming that it's the latest generated) and there's an issue with the product_type element for sure. Paul
  22. Is it the same issue with the feed format invalid? What I've tried to do is encode the "extra" non-english characters as html entities in UTF-8. By default it was using ISO-8859-1 which is incorrect.
  23. Have uploaded v0.7.3.3 Change log - Fixed call to Tools::convertPrice() (pre-1.4 required a currency object) - Added price compatibility functions (for later support of attribute pricing) Paul
  24. I noticed in the previous file you sent me (with the other issue) that all the prices were 0. Is this still the case? If so, then there's still something not right. What PS version are you currently using? Paul
  • Create New...

Important Information

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