Jump to content

Paul C

  • Posts

  • Joined

  • Last visited

  • Days Won


Everything posted by Paul C

  1. You can make a local copy of the .tpl file in your theme directory (in the form /themes/mytheme/modules/editorial/editorial.tpl) and then edit that one however you like. I wouldn't recommend editing the original template files, since they'll get overwritten at the next upgrade. Paul
  2. Cool! Although I thought you needed the trees to grow from the footer the the header! That's why I went into all the detail about the side columns.... Sorted anyway, so Yaay! Paul
  3. Actually I've thought of another, maybe easier way. Here's the "container" markup (this is off the top of my head, so expect mistakes): <-- prestashop header --> <!-- prestashop main content --> <!-- prestashop footer>
  4. Hmm that's a classic problem with dynamic sites. I don't have a complete answer for you, but some ideas to get you going. Firstly. I think you need the three columns (left, middle and right) to always be the same size (height). Currently the left column stops at the end of the categories box and the right column stops at the end of the wishlist block. Have a read of this article for information on how to "fix" this: http://www.search-this.com/2007/02/26/how-to-make-equal-columns-in-css/ Once you have full-length left and right columns you'll need to slice your graphics so that you have a repeatable-y image that you can use as the background which should mean the graphics magically "grows" as the center column gets longer. Well that's the theory anyway! Hope this helps/inspires :-) Paul
  5. I think we may be talking about two different things here I thought I was discussing how to change the product listings on an individual product basis, rather than the over all page for a blog, gallery etc. or am I missing something? Paul p.s. worry not - I haven't and will not stalk you :-P
  6. I tried to download the module linked to that post, but I get an error that it's corrupted! Paul
  7. I knew we'd get there in the end :cheese: I'm assuming that you didn't include the <<>> in the .htpasswd file? That shouldn't work Paul
  8. I should maybe add two configuration options then that are: 'HTML Before' and 'HTML After' :cheese: then the default div that's currently surrounding it would be the default value for this, and you could specify any div, class or id you want. The markup for the actual cloud is tied to the Flash in this case, but yes, it would be handy to be able to modify the "wrapper" code around the "fixed" bit. Does that sound like a reasonable compromise? Paul
  9. Yes, that post was an extreme example of having completely different files for each product. You can build a base template file and use a similar technique to use the category name, for example, to include particular blocks of code that are product specific, that way it's possible to vary the content by product quite easily without creating a template per product. It does all rely on your coding in the template though -- so if you want to implement an optional override, then you'd need to do it yourself. In this example (of using the category to customise) you would also need to add new customisation when you add a new category, or have a default mechanism in your code. This is all assuming that you don't just edit the actual page php itself (/product.php) -- which is an option, but not great when you need to upgrade. The last option is to use the a combination of HOOK_EXTRA_LEFT, HOOK_EXTRA_RIGHT, HOOK_PRODUCT_ACTIONS, HOOK_PRODUCT_TAB AND HOOK_PRODUCT_TAB_CONTENT and code your own customisations in a theme/site specific module. With a bit of care you can also use one of the hooks "higher up" on the page and define variables you want to use throughout the template. That's quite a few options :cheese: One of the compromises with any system is performance, and while "overrides" (a la ZenCart etc.) can be shop owner friendly -- that doesn't mean it makes for good, fast well designed sites! It is a very great pity that we are forced to use a parser (smarty) at all though. I personally feel that it should be optional and that we should be able to pass data direct to php scripts instead of smarty .tpl files. If a generic method of calling the templates had been implemented, then we could have used something like : global $parser; $data = array($var => value, $var => value1); $parser->render('template', $data); Then within the parser class it could detect whether smarty was being used or not and take action appropriately. Sadly this isn't the case :down: Paul
  10. @blaszta It wasn't the CMS I had grief with. The upgrade assumes that some tables are never modified by add-ons or customisations and so they have hard-coded the additional content they want in the upgrade script which overwrites anything you've added in there :-/ Not a huge problem if this fact was highlighted in the documentation - but that's another story isn't it It is the payment module status messages they have hard coded, despite the fact that the key field is set to auto-increment.... at least that's the only one I've found so far. To be fair, in a brutally honest way, it's because the whole order status message code is a mess - why would you define a constant as the key to a field in a database table? It would make more sense for them to either be static (and then there would be no upgrade issues) or have them live purely in the database; I know they've used the database for language support - but the present "solution" to achieve this is a mess. At least there's an upgrade to go wrong I guess Paul
  11. That would be good, but your site might crawl with the overhead of SSL on every page.... If that works, then there is definitely something not right with the module. Paul
  12. hmm. No I would expect it not to be. I did find this after a Google search though: So the path (using the account example above would be: Paul
  13. The reason I didn't use a tpl file was because it doesn't serve any great purpose (doesn't really add any useful function), but does result in a performance hit on your server You should be able to do any css styling you need with the markup that's there Paul
  14. Only problem is that the upgrade code seems to have issues - doesn't seem to accept the fact that most stores may not just contain the "demo" data., and may have had the audacity to actually add data to tables.... I would strongly recommend a trial run on a test server unless you've done little or no customisation of any kind Paul
  15. Changing the css per product is a little bit awkward, but a tpl file per product isn't :cheese: just change product.tpl to only contain: {assign var=productTemplate value="product-`$product->id`.tpl"} {include file="`$tpldir`./`$productTemplate`"} Then just create the product templates as product-1.tpl, product-2.tpl etc. etc. might take a while for 1,000 products though Paul [edited to add the $tpldir variable, just in case anybody tried the above and complained ]
  16. Actually I've noticed a mistake in my instructions to you. The .htaccess file should look like: AuthName "Google checkout Basic Authentication" AuthType Basic AuthUserFile /modules/gcheckout/.htpasswd require valid-user Both the .htaccess and .htpasswd files should go in the /modules/gcheckout/ directory (same directory as the validation.php file we're trying to protect if you like). You'll appreciate that I'm doing this "blind" :-) The will be in the form /home/user/public_html assuming that the store is installed in the root of the site. Paul
  17. Right. Deep breath and step away from the keyboard :cheese: If I'm understanding you, then IF; 1) You remove the lines of code from validation.php, then your store works -- good, as that proves where the problem lies! 2) When you added the .htaccess and .htpasswd files it stopped working -- possibly we haven't got them set up right 3) Now it doesn't work either way -- strange :roll: The last one is possible because of your browser, so for a start you should close it down completely and run it again - that will make it forget the contents of the .htaccess file that was there. I'm confident it isn't anything to do with the htaccess.php being there or not. The htaccess.php file doesn't actually do anything other than manipulate the values you type into it, so it should have no effect either way. Moving on.... Which directory did you put the files in? Paul
  18. Or restore this file from your backup as the only thing that will have changed is the line: define('_PS_VERSION_', ''); Which you can change manually to match the one above Paul
  19. Note that the actual line in the file the script generates for you won;t say: AuthUserFile /.htpasswd But should have the full path to your gcheckout module directory. e.g. /how/user/public_html/modules/gcheckout/.htpasswd Paul
  20. Not quite, and since posting I've had another thought about it You copy the htaccess.php file to the root of your store temporarily. Access it via your browser and fill in the form so it can generate the contents of the .htaccess and .htpasswd files for you. You can delete the htaccess.php file once you've generated the file contents - it's only there as a "tool". The .htaccess that the script will generate may not work as it will require a username and password for all the files in the directory. You should edit the lines at the top and bottom as shown below to limit it to the validation.php file only: AuthName "Google checkout Basic Authentication" AuthType Basic AuthUserFile /.htpasswd require valid-user The .htpaswd file will have a single line in it which will be the encrypted merchant id and merchant key separated by a ':' Hope that clarifies things Paul
  21. Alex, Not a problem. I was getting confused over exactly what the issue was with Google Checkout, and I think that this is the problem, rather than the assumption that it related to SSL. Google checkout - when it doesn't work - is going to be beyond most people to be honest I think the solution is: 1) You need a .htaccess in the gcheckout module directory 2) Now comes the tricky part. You need to authenticate Google checkout by putting the correct credentials in the .htpasswd file you've pointed to in the above. These are "encrypted", so we need to do the same. The file contents will look like: user:password We need to generate the user and password values from the merchant id and merchant key. I've attached a php script that should correctly generate the content of both files for you (it's modified from the google original ones). You'll also need to disable the authentication in validation.php to prevent the script from dying anyway. I think deleting the following lines, should be enough but DO NOT DELETE THESE LINES UNLESS YOU USE THE .htaccess AND .htpasswd FILES GENERATED BY THE ATTACHED SCRIPT. Otherwise you'll be wide open to potential fraud: $status = $Gresponse->HttpAuthentication(); if(!$status) die('authentication failed'); Good luck, and keep me posted Paul htaccess.php
  22. The status codes are defined in /config/config.inc.php (line 108). They are changed with OrderHistory::changeIdOrderState() Paul Les codes d'état sont définies dans /config/config.inc.php (ligne 108). Ils sont modifiés avec OrderHistory::changeIdOrderState().
  23. The loyalty and referralprogram modules both use "updateOrderStatus" -- you need to check the object sent to it though to determine the action to take. en français: Les modules de la fidélité et du referralprogram utilisent "updateOrderStatus" - vous avez besoin de vérifier l'objet qui lui est adressée afin de déterminer si l'action à prendre. Paul
  24. Another thought struck me. Have you tested using the sandbox? If that doesn't work then you know for sure it has nothing to do with SSL :-) Paul
  • Create New...

Important Information

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