Jump to content


  • Posts

  • Joined

  • Last visited

Everything posted by elburgl69

  1. The current url is stored in: {$urls.value["current_url"]} Complete content of $urls: Smarty_Variable Object (3) ->value = Array (19) base_url => "http://www.fietsgoed.local/" current_url => "http://www.fietsgoed.local/content/49..." shop_domain_url => "http://www.fietsgoed.local" img_ps_url => "http://www.fietsgoed.local/img/" img_cat_url => "http://www.fietsgoed.local/img/c/" img_lang_url => "http://www.fietsgoed.local/img/l/" img_prod_url => "http://www.fietsgoed.local/img/p/" img_manu_url => "http://www.fietsgoed.local/img/m/" img_sup_url => "http://www.fietsgoed.local/img/su/" img_ship_url => "http://www.fietsgoed.local/img/s/" img_store_url => "http://www.fietsgoed.local/img/st/" img_col_url => "http://www.fietsgoed.local/img/co/" img_url => "http://www.fietsgoed.local/themes/fie..." css_url => "http://www.fietsgoed.local/themes/fie..." js_url => "http://www.fietsgoed.local/themes/fie..." pic_url => "http://www.fietsgoed.local/upload/" pages => Array (32) address => "http://www.fietsgoed.local/adres" addresses => "http://www.fietsgoed.local/adressen" authentication => "http://www.fietsgoed.local/login" cart => "http://www.fietsgoed.local/winkelmandje" category => "http://www.fietsgoed.local/index.php?..." cms => "http://www.fietsgoed.local/index.php?..." contact => "http://www.fietsgoed.local/contact-ons" discount => "http://www.fietsgoed.local/korting" guest_tracking => "http://www.fietsgoed.local/bestelling..." history => "http://www.fietsgoed.local/bestelover..." identity => "http://www.fietsgoed.local/identiteit" index => "http://www.fietsgoed.local/" my_account => "http://www.fietsgoed.local/mijn-account" order_confirmation => "http://www.fietsgoed.local/order-beve..." order_detail => "http://www.fietsgoed.local/index.php?..." order_follow => "http://www.fietsgoed.local/bestelling..." order => "http://www.fietsgoed.local/bestelling" order_return => "http://www.fietsgoed.local/index.php?..." order_slip => "http://www.fietsgoed.local/bestel-bon" pagenotfound => "http://www.fietsgoed.local/pagina-nie..." password => "http://www.fietsgoed.local/wachtwoord..." pdf_invoice => "http://www.fietsgoed.local/index.php?..." pdf_order_return => "http://www.fietsgoed.local/index.php?..." pdf_order_slip => "http://www.fietsgoed.local/index.php?..." prices_drop => "http://www.fietsgoed.local/aanbiedingen" product => "http://www.fietsgoed.local/index.php?..." search => "http://www.fietsgoed.local/zoeken" sitemap => "http://www.fietsgoed.local/sitemap" stores => "http://www.fietsgoed.local/winkels" supplier => "http://www.fietsgoed.local/leverancier" register => "http://www.fietsgoed.local/login?crea..." order_login => "http://www.fietsgoed.local/bestelling..." theme_assets => "/themes/fietsgoed/assets/" actions => Array (1) logout => "http://www.fietsgoed.local/?mylogout=" ->nocache = false ->scope = "file:cms/page.tpl"
  2. Put (on a test environment preferably) {debug} somewhere in your layout.tpl and a window will open with all Smarty verschilt lister. URL Will be there, I'm sturen.
  3. Only *.tpl files are processed by smarty, .js files not. In your module, as you already had: $this->context->smarty->assign('publicKey', Configuration::get('12345678')); In the a template file your module processes add the following: <script> var recaptchapublickey = "{$publicKey}"; </script> The correct value should be available in your front.js.
  4. Make sure that the following code is executed in the module, before rendering the output: $this->context->controller->addJquery(); If it is the module PM_AdvancedSearch4, is the module connected to all hooks? Try reinstalling the module.
  5. Can it be that you once generated wrong URLs (a bug or something). Google indexed at that time your page finding all those URL's. Since those URL are basically valid category URL they return a valid page and google keeps them in the database? Try changing in SEO & URL your category route to: {id}/{rewrite} And the layered nav route to: {id}/{rewrite}{/:selected_filters} You category view is then reached via: <home>/34/evaporation_materials The old routes are invalid, so Google gets real 404's on those pages. But beware. It invalidates all your current category links, impacting your google ranking for those pages. Rg, Leo
  6. You wrote that Google found those links while Crawling the site. Do you have any CMS pages that might contain those strange links. When I analyse the generated HTML of your homepage it does not contain those links. Where does google find those links?
  7. In your database (phpmyadmin?) run the following SQL script. UPDATE `ps_product_lang` SET `link_rewrite` = LOWER(`link_rewrite`) WHERE 1=1; This only works if you have de default _DB_PREFIX of 'ps', else change ps to your prefix. That converts all your friendly URLS (on products) to lower cases. Regenerate your Search Index, Sitemaps, and other search modules you might have, to reflect those changes. Update if necessary you menu's to use lower cases. Since they are basically the same, Prestatshop will 301 the ones with capititals to the lower case ones.
  8. Strange. the pattern I see in the URL is: %25 => % %3F => ? &p=1 The last indicating pagination in your category browsing. What Sitemap.xml module are you using the standard PS one? Have you generated the Sitemap.xml again (best put it under a cron)? What is the URL of your Sitemap.xml. Are there any hidden characters after 'evaporation-materials' Friendly URL? Second issue best write a little script to batch update all friendly URL (link_rewrite in yourDBPrefix_product_lang) to lowercases. And regerenate your sitemap.xml, your search indexes etc.
  9. First issue. The only thing I can think of: %25 is used in HTTP to cater for the % sign in a URL. Check in your Shop Settings - Traffic & SEO - URL Schemes (last section) if any of your URL Skeletons contain a % sign. Replace it with an other separator. => if it solves the issue file a Change Request for not allowing % in URL skeletons. Try to remove the cache. Advanced settings - Performance - Empty Cache. If you have access to your server, remove all the directories in <document root>/app/cache (probable only prod, but perhaps also dev or others). Second issue: 1. Put debugging off. Advanced settings - Performance - Debug Mode - Debug Mode switch. Redirecting now goes transparent. The core problem is that in your Catalog - Products - "cdte-target" - SEO tab - Friendly Url, you have capital letters. HTTP does not support capitals. Try not to put capitals in your freindly urls. Hope this helps, Rg, Leo
  10. Working on assumption here. In you module you redirect to your controller like this? Tools::redirectAdmin($this->context->link->getAdminLink('AdminYourController')); getAdminLink full declaration is: Link::getAdminLink($controller, $withToken = true, $sfRouteParams = array(), $params = array()) If you call it with $params['id_product'] = $id_product; You can access that value in your controller with $id_product = Tools::getValue("id_product"); Don't forget to check if the id_product value is set to begin with (Tools::getIsset('id_product')). rg, Leo
  11. Just tested it on a 1.7.2 install and it picks up the themes ps_searchbar.js file. Can't imagine it changed in higher versions. On which version are you? Look in the generated HTML which version is loaded. Should be a JS loading block at the end of your HTML. If you can't find ps_searchbar.js in the generated HTML, you probably use Smart Cache for Javascript (it is in the section where you clear cache in the back end (I'm on a dutch version so do not know the english term used)). Turn that option of an start reloading pages, until you find ps_searchbar.js. Check the location it loads from (should be the theme directory). Otherwise for one or the other reason your <document_root>/modules is read before <document_root>/themes/<your theme>/modules. Set the option in the back end to only load Prestashop module to check in that solves the problem. If so one of your modules is messing stuff up. Else it is a bug. Rg, Leo
  12. creating the file in: <document_root>/themes/<your theme name>/modules/ps_searchbar/ps_searchbar.js Should have that file being rendered. Clear (Smarty) Cache (and to be sure delete cache on disk (delete all stuff in <document_root>/app/cache), or restart your cache if you use other mechanisms. Rg, Leo
  13. Try this one. Unless your are using Advanced Stock Management, this must do the trick. In case you do use Advanced Stock Management I can help. Did not work with it and I cant oversee the impact of StockAvailable on those cases. Rg, Leo AdminImportController.php
  14. It about Advanged Stock Management. Something with seperate stock locations. Leave the option stock management on an then test.
  15. Have not tested it, no time. But if you do not use advanced stock management feature, this version should add stocks. Succes AdminImportController.php
  16. Ptestashop picks up overrided controllers automatically. Clear cache to be sure. Rg, Leo
  17. It is the "Referencia" field. In my memory it matches on that field. Probably uploading through combinations will not add but over write the stock posistion. I have made a customisation to the upload controller not sure anymore what excactly. I perhaps it concerned the reference field. I attached it. Put it in you <docRoot>/override/controllers/admin/ directory and test. I have no time to have a look in depth, perhaps this weekend. If stocks are overwritten it should be easy to adapt this in controller. Note this is not the earlier mentioned stock syncing code. Rg, Leo AdminImportController.php
  18. Sorry was busy. Do you have the refence field (in combinations.csv) correctly filled? If they macth it should update the existing product. For syncing stocks, this is not really the most appropiate way to go. Do master PHP a bit? I can mail some code that downloads a file from a well known location and processes it the file to update stocks and prices (the latter on product level though). I have it running under cron each 30 minutes. But you can also start it manually by pointing in a browser to it. You could the upload your file manually to your server an start manually, using that file. It uses the barcode (ean-code) to synch. It is of course completely written to my situation, but I guess it could be a starting point. When interested, please drop me a mail. Rg, Leo
  19. I would report this as an bug. One would expect such a including / excluding tax option with all product related prices. A work arround for now: I assume you make your csv files in a spreadsheet program? Then just add a column that caluculates the price ex taxes. On export to csv, export the values (not formulas). At importing the combinations in prestashop.map the price exluding taxed to the imact on price column and set the original price column to ignore. (save that setting as importCombinations for later reuse).
  20. Do you mean selecting the colors with the colored squared in stead of a drop down select? You must do it manual. Go to - Catalog -> Attributes and Features Edit on the Attribute tab the color attribute. Set attribute type to "color or texture", if it's not. Save. View the values of the attribute. Edit the ones without a color/texture assigned (or incorrect collor/texture) and assign one. (Color field or upload a texture in the field). From the combination upload you cannot assign the color/texture to a attribute value. You could override /classes/AdminImportController.php to allow for a third an a forth parameter: - Value (Value:Position:ColorCode:TextureFileURL)* or make a change request at Prestashop for it. For what it is worth. I do no use color types for attribute's. I use a drop down with the commercial color name like "Urban Kaki" or alike. I have my customers also fill a a comma seperated list of primary colors, uniformly named, that the product contains and create a color feature (add them in product.csv) with those colors as values, so customers can search and filter on color properties, but pick the color besed upon the commercial name. Rg, Leo
  21. Delete the folder <documentroot>/app/cache/prod and <documentroot>/app/cache/dev if they exist. Normally such a 500 error is an attempt to load a class that is already loaded in the cache. If that does not help, have a look at your php logfiles. On unixboxes, normally look in /var/log/php* (* for the version). Otherwise put error reporting on (can be nasty in the front end too on production systems...). Edit <document root>/config/defines.inc.php and change the second line: if (!defined('_PS_MODE_DEV_')) { define('_PS_MODE_DEV_', true); } This will give you a cause why the error occurs. By the way, when deleting modules manual in the database, do no forget the named entries in ps_authorization_role table. The SLUG is something like ROLE_MOD_TAB_<MODULE NAME>_<ACTION>. Succes, Leo
  22. Sorry I could not help. On thing, not discussed but I assume you did it already, but have you tried to uninstall an install ps_checkout completely? Rg and success with finding a solution, Leo.
  • Create New...

Important Information

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