Jump to content

Paul C

Members
  • Posts

    801
  • Joined

  • Last visited

  • Days Won

    4

Everything posted by Paul C

  1. Sorry, yes it's in 1.4, not in 1.3.x, although you can easily do similar just by not displaying the add to cart buttons throughout and not enabling any payment methods. There's still the possibility that someone determined enough could form url to add products to the cart, but it isn't going to do anything As I said - develop for 1.4, it will save you a lot of work in the future anyway with upgrades, and the ability to sort pages and group pages in the CMS in 1.4 is probably going to be useful for your project Paul
  2. 1. go to "Back Office > Preferences > Products" 2. Set "Catalog mode" = Yes 3. Have fun designing your theme I would strongly recommend building any new sites in 1.4, even though it is still a release candidate. Paul
  3. Well it will be ready when it's ready, so why not start working on it and contributing to the bug tracker and it will get there that little bit quicker Paul
  4. In 1.4 you would override the Product class to add fields to it, for example. Then you get all the joy of the standard object facilities without the pain of hacking around with adding hooks or modules etc. For example to add a mandatory "Title" field to use instead of radio buttons for gender you could do: class Customer extends CustomerCore { /** @var string Title */ public $title; public function __construct($id = NULL, $id_lang = NULL) { $this->fieldsRequired[] = 'title'; parent::__construct(); } public function getFields() { parent::validateFields(); $fields = parent::getFields(); $fields['title'] = pSQL(Tools::strtoupper($this->title)); return $fields; } } You would then probably write some member functions to manipulate/query the value. Simple Paul
  5. As I understand it; If you want your class to be for example "MyClass" then you create a file called MyClass.php in /classes and use the following declaration: class MyClassCore extends ObjectModel { } You'll notice that we had to add "Core" on the end. To use your class you just use: $myvariable = new MyClass(); The side-effect of this is that you can override your own custom class (but would you really want to that often?), but yes, you're correct in saying that you would have assumed that you could have placed your own new classes directly into /overrides/classes and then extended just ObjectModel.... Paul
  6. Cool, see that wasn't too bad Unfortunately it isn't really as simple as having a list of variables..... The way this works is that the core code OR any installed modules pass variables from the PHP code to the smarty engine on a per page basis, so just because a variable is available at a point on any given page in one case, the same may not be true earlier in the page or on another page. In this case it has passed a product object, so you can use any of the properties of that object in your theme (it could have only passed a subset of the properties though, in which case the above might not have worked). If you want to know what properties a product/category etc. has though you can look at the database tables, as the fields in there will likely (but may not) be available when the object is passed to a smarty template file in the theme. Hope this makes some sort of sense. Paul
  7. Roger, It's work in progress and I'll be updating it shortly - several problems when it came to "real world" use!! Nothing that can't be easily solved though It's a way of easily adding the output from a single module, avoiding the need to mess about with the Prestashop core adding a custom hook. It also has the advantage that the module doesn't need to care where the output is (left, right, header, top etc.); if you have an encrypted paid module that you can't adapt for another hook, then this will be a solution. I'm using it for other little things now too with some success (e.g. using CMS pages as editable blocks in the theme), looking good so far and shouldn;t have much if any performance impact (may even be less overhead calling it this way in many cases). I'll update the site when I've done more research. Paul
  8. If the category structure is only one deep, then you can just check the $category->parent_id value and test for it being '4'. {if $category->id AND $category->active} {if ($category->id_category == 4) OR ($category->id_parent ==4)} Price per pair: {/if} {/if} I think Paul
  9. There's no need to use the new 1.4 overrides for payment modules; they are a kind of special case. A payment module is just a specific type of "module" - you can get a primer on writing a basic Prestashop module and skeleton module code from my site by following my How to write a Prestashop module articles. Payment modules are slightly different and come in two flavours: 1. Synchronous - All control at every step is on your site e.g. cheque payment, bankwire etc. 2. Asynchronous - You implement some form of callback to receive payment status updates e.g. PayPal I would suggest that you look at writing a basic "Hello World" module to get the hang of the Prestashop conventions, then extend the PaymentModule class instead of the Module class in your module later to start work on your creation. It may be useful to dissect the existing modules that are provided with the core to see how the flow works. Modifying the admin area is different again. I would always strongly advise looking into the Prestashop "hook" system to see if you can extend things via a module that way rather than changing the core code (something you really need to avoid at all costs). In the case of the admin tab it calls the hooks "adminOrder" and "invoice" passing the order_id in both cases to give you a chance to do some additional output or processing. Good Luck! Paul
  10. The store I'm working on at the moment is a custom theme upgraded to 1.4 and the images are certainly being rewritten on there "out of the box". Do you have sef urls enabled? You should only have to turn on the friendly urls feature in preferences, then generate a .htaccess file from the tools menu and it should be done. Older themes might not support them if they don't properly form urls via the Link class, but it's fairly easy to go through a theme and update it. Paul
  11. All you should need to do is run the installer on the current (1.2.4) database and the upgrade script will handle it (just point your new install at the old database and run the installer as an upgrade). Remember to keep the settings file from the old install too as the password encryption needs that. You can do this all on a development machine and only move the whole lot over when you're happy that the process works. I've never (touch wood) had a problem with an upgrade yet and have been using Prestashop since pre 1.0 The above is a further step to then verify that the structure of the new database (i.e. the upgraded old database) is identical to one from a fresh install. Not essential, but I have noticed in the past small differences which I like to eliminate! My theory is that small differences building up over several upgrades *might* eventually cause you problems, although most that I have found have been fairly "safe" e.g. a field of size int(11) instead of int(10). Other things like a field that should be set to unsigned *might* however cause a problem in the future. Paul
  12. If you're being particularly fussy (I do this, but then I have been called a bit of a perfectionist) and/or you've had a store for a long time and this is an upgrade of an upgrade of an upgrade, then you might want to consider doing a "fresh" install to another database and then exporting the database structure only (untick the data section in phpmyadmin). You can then do the same on your live site and use file comparison software to check whether the structure of your site matches that of a new install. There may be a few differences that you may wish to fix up by hand. The upgrade scripts aren't perfect, but pretty good. Paul
  13. The log is just the SQL queries executed plus errors and warnings. Not exactly an easy read! In theory for an upgrade is should just be the "changes", although some of the statements may have just been ignored (if things like "IF NOT EXISTS" is used). Paul
  14. Others disagree that having keywords in filenames on your pages does "help". It's just behind having keywords in the page url according to the last SEOMoz roundup (which isn't very much at all really). If your theme and Prestashop version supports it then image names should be getting rewritten anyway though to the product name +decoration.... e.g. http://static.example.com/0324-5834-large/9ct-gold-bracelet.jpg Paul
  15. Cool. Will be good to know if this indeed is the problem. Paul
  16. anson, After you change your subject line I was talking about the Prestashop Admin screens -> The smarty 2 compatibility setting is in the Preferences tab. I'm trying to see if your upgrade is ok but your theme and modules are causing the problem.... If you have given up on getting 1.4 to work, then as a first step I would ignore phpmyadmin and just restore the files back to the version you were using. The database may well be ok, and not to be rude, but if you're not sure what you're doing then messing about in there might just make things worse. Paul
  17. It's a shame it didn't go smoothly for you, but at least you've got things back to "normal" I'm working on an upgrade right now from 1.2.4 to 1.4 and it isn't trivial, especially if the store has core modifications, but it now looks like a thing of beauty with all those nice clean overrides in place Paul
  18. My suggestion would be to first take a deep breath In the admin preferences screens did you set the option to force Smarty 2 to "Yes". If you didn't, then do that now and you may find that your store isn't as bad as you thought it was Also disable any custom modules for now (and don't at this stage replace any standard modules with modified ones). If that fails to impress..... I would never personally contemplate going back a version, but the database upgrade may not have done too much "damage" so after taking yet another backup (just to be sure) you could try just reverting the files and see what happens.... from memory the changes made in 1.4 likely will just be able to be ignored. Remember to manually edit the setting.inc.php file version back to what the old version was. This will make sure any necessary recalculations will be applied the next time you try and upgrade. Paul
  19. Your approach is correct yes. How you transfer the files is personal preference. If you have the files backed up in a folder on the server, then it will be quickest to just move them back into your store folder (delete the new version first, in case there are any new additional files that may cause confusion in the future). I personally use FileZilla as my ftp client of choice - I always force file transfers to be "binary" too as this can prevent problems with incorrect CRLF translations during transfers. Paul
  20. Did you run the installer for the new version? If not then the database will not have been upgraded and that may be causing your problems... If you did run the database upgrade, then to go back to your previous version you'll need to restore the database from backup as well as restoring the files. If you didn't, then all you need to do is restore the files. Paul
  21. As a starting point you should clean out all of the compiled smarty files and delete any cookies (FO and BO) on your machine. The featured products and modules display problems are weird as they should at least display properly in the default theme - have you made any changes to any of the modules etc ? Paul
  22. Have you tried the store using the default Prestashop theme, just to confirm that there's a problem with the theme and not the installation itself? Paul
  23. No idea why you would get the blank screen - module seems to load fine here with the same changes, although not that exact version. One of the problems is that the module version numbers don't change sometimes, even though the code has changed...... Here's another try - the only change in this one is the code to attempt a fix. I downloaded the 1.3.1 version for github, so am hoping that the v1.6 in there is the same as the one you have..... paypal-1-6gtls.zip
  24. Here's the same changes made to the PayPal modules in 1.2.1.0 for testing. Paul PayPal TLS Error(1.2.1.0).zip
  25. I would strongly recommend that you DO NOT disable the check, but instead perhaps try and work towards a solution. It has nothing to do with iPage or any other hosting, but to do with compatibility between components installed on the server(s) affected. You can always inform your hosting company that there appears to have been a change made to the version of system software that is causing an issue, but I suspect that they will be reluctant to install a different version unless the problem is widespread - that is the nature of shared hosting. If you server has the option of remote fopen, then it may be possible to modify the module slightly to optionally ignore cURL and use that method for verification instead. Has anyone tried the patched modules in the download link above? I can't reproduce the error, so it will be up to you guys who have the problem to try out and report back on suggested fixes... Using the sandbox would be the best option. Paul
×
×
  • Create New...

Important Information

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