Jump to content

Paul C

  • Posts

  • Joined

  • Last visited

  • Days Won


Everything posted by Paul C

  1. You could modify an existing module, although you'll need to remember you did this when you upgrade before the end of the class declaration (last }) you could try adding something like: public function hookNavBar($params) { return $this->hookLeftColumn($params); } That is assuming that the output the module would put in the left column is what you want moved into your new "hook". Basically all you're doing is getting the module to do the same thing when called for your new hook as it would do if called in it's "proper" location. Paul
  2. The server logs (accessible from your control panel) should probably have the information without going near Prestashop - just look for repeated accesses to the same page/pages. Paul
  3. How are you trying to "hook a module into this hook"? The module will have to have implemented : function hookNavBar($params) { // display something } Which unless you've written the module it won't. Paul
  4. Why are you including the yourfile.php? Is it to declare other classes or to declare functions, variables, constants etc.? The problem is that if you declare anything in your external php file that might conflict with the Prestshop namespace, then you may well get an error. I had a similar problem when working with including the Wordpress core - it worked in the front office fine, but caused errors in the back office because there were name conflicts between Prestashop global functions and Wordress functions i.e. the second attempt at declaring the same function fails with an error. Ah just re-read your message and noticed you'd deleted the contents of yourfile.php, so it isn't a conflict then..... I've overridden several classes and haven't experienced this though..... strange. I suggest turning on error logging to find out what's going on. You can enable it in .htaccess usually and set a file location for the error_log. Can I ask why you;re trying to override the Tools class anyway? Most methods are declared static in that class and inheritance won't apply anyway. You may be better just to extend Prestashop itself with a new "core" class. MyTools.php in /classes class MyToolsCore { public static function myutility($param) { // Clever code in here } } You should then be able to use it via: MyTools::myutility('foo'); Paul
  5. I love it when I'm right The reason it works differently locally and remotely is that the two systems are using a different priority order when searching for a default page to use. When you go to a directory (including the root directory) of a web site with no file specified, then the web server looks for files starting with "index" to use as a default (and in fact it doesn't have to be index, but it is standard/common). The order of preference might then be to look for index.html and if not found look for index.htm, and if not found look for index.php, and then if not found look for index.cgi etc. etc. The exact order is configured on the server, and in your case they must be different, so a different result on each machine. Have fun, Paul
  6. BendingBetty, I understand where you're coming from, but the principle that Prestashop is coming from is that you sell an item which has X attributes that create Y specific products when combined - what you're trying to do is use something intended for size/colour type variations etc. for another purpose altogether, which is building a product that's made up of multiple sub-products. I think what you need is a layer of functionality that allows a customer to select products from your store in a guided way in order to create a basket of products that when combined form a complete system. None of the carts that I've worked with support that functionality, although you can fool some by bending the principle of attributes to seem to work in that way. Paul
  7. Ah that explains it I was wondering, as most products you would have to try very hard to create lots and lots of choices (or alternatively you could likely structure the products in such a way as you don't have to!). A custom PC is a different matter when using every component as a selectable attribute; I can see that this would be fairly large. In saying that I don't think that using "attributes" to build your custom PC is ideal either, since I'm guessing you have to manage the same items twice - once as a regular product and also as an attribute? It would be better if you could assign particular products as "custom PC options" so you could manage the stock/availability etc. at a single point. Interesting challenge Paul
  8. Out of interest how many do you use for products? If there are lots, then you must have a huge inventory to manage! Paul
  9. Clauf, There are so many fundamental changes to the 1.4 core that I doubt you'll be able to overwrite the 1.4 core files with modified versions of 1.3 files and have much success; which appears to be what you're trying to do? I'm afraid that if you have made changes to core files that will be overwritten by the upgrade, then you're going to have to merge them by hand, and in some cases redevelop the "modifications" based on the new architecture. In certain cases you will be able to use overrides for the classes to avoid having this same issue again, and if there are changes to the files in the root of the store (cms.php, category.php, authentication.php etc.) then you will have to transfer the intent of these into overridden versions of the "front controllers" for them (these files are fundamentally different). There are many changes that might have been made to the core files that you would certainly not do given the new structure. I suggest that you review what changes were made and explore how they could be better done using modules, hooks and overrides, rather than direct changes. I would also urge you to use all of the override features provided including the previously available, but sadly neglected, module template overrides in your theme; you won't regret it Paul
  10. I've had a look at your recent questions and I can honestly say that you would have been no better off had you gone to Magento - in fact the only difference would have been that if you're unable to make the required changes yourself, then with Magento you would have had to pay someone more to do it for you than you may have to with Prestashop. This is likely the reason it was recommended to you in the first place. I think you'll find that the concepts behind what you're asking have been covered in the forum many times before though, and perhaps this is why they aren't being met with enthusiasm. Paul
  11. By editing the module template file (and placing your modified copy in the theme directory if course, rather than changing the core file) you can get it to display whatever you want (within reason, of course unless you want to re-write the module too!). You will need to have knowledge of xhtml/css to be able to get it to display correctly as you'll also have to modify both. Paul
  12. I've also added code in the error message part that should output the current cURL library version and ssl version numbers - just in case you think the error has got worse if it still appears and is longer!! This info may help further if you're still having a problem. Paul
  13. I may be missing a point here, but in Back Office->Preferences-> Image you can set the resolution of the different images within your store (obviously you size these to fit with your theme) - so you can easily set the thickbox settings to be 1260x980 and the image will display like that in the thickbox. That would mean that the only "difference" that could be introduced would be in the jpg compression quality. This is only going to work of course if all your "full size" images are 1260x980. The next issue would be in the maximum limits for file upload. I tend to agree with smiffy that in almost all cases you would never want your product images to be larger than the limits as they are set by default (you should also note that even increasing these within the core may not help, as your web host may place it's own limits). I think it's reasonable that if you're looking at selling items which are somewhat unusual (like full-quality images themselves) then you may need to customise Prestashop beyond what is configurable in the Back Office. It would be nice if under that same admin screen you could set the various image quality settings though, as standard; I can't see any reason for not allowing it. I'm not a great fan of hard-coding limits into applications, as there's always someone who will feel they need to change it Paul
  14. Pradchal. The answer to the first one is yes, it is possible. You would have to modify the module to create a new one with a different name and then perhaps modify the ciriteria for selecting the featured products, otherwise you just get two blocks with random products (which may duplicate) in which case you'd be better modifying the existing module to display twice as many and force a split in the middle within the module .tpl file to add the text. For the second one, it's possible but would require a module written to do it. If you're not up to doing the programming yourself, then why not post in the "Third Party Modules" or "Job offers and paid services" areas to get a quote from someone who may be able to, or find out if anyone has already done something similar? Paul
  15. As I said, I don't know what version or type of PayPal module you're currently using. I've attached two "fixed" modules modified from the current 1.3.6 production release that you could try and see. The archive contains the two modified paypal modules which need to replace the corresponding directories in the modules directory of your store. Just ftp them to overwrite the existing ones: Make sure you keep a copy of the originals as these might not work and you may have to revert back. Paul As usual no guarantees, but it's certainly worth a try PayPal TLS Error.zip
  16. Cheers for that Mark, I'll maybe give Tomer a shout. I hoping that the "expensive" modules developed by Prestashop themselves were more advanced than they maybe are.... Paul
  17. So you want both the last item in the breadcrumb trail AND the product title on the page both to be inside h1 tags? Hmmm interesting. Paul
  18. I would suggest changing them to: RewriteRule ^content/([0-9]+)\-([a-zA-Z0-9-]*) /cms.php?id_cms=$1 [QSA,L] RewriteRule ^content/category/([0-9]+)\-([a-zA-Z0-9-]*) /cms.php?id_cms_category=$1 [QSA,L] I'm pretty sure the isolang parameter isn't needed..... Paul
  19. I would recommend trying the modification I posted up there ^^^. If I knew what version of Prestashop you guys werehaving this problem with I'd happily modify the code to see if it works if you're unsure as to where to put it Paul
  20. I'm working with 1.4 via the SVN right now and I have to say that once I'd migrated the theme to 1.4 I then as a test: - enabled smarty 3, - turned on the smarty optimisations - enabled the first 4 CCC optimisations - set up 3 cdn domains The increase in performance was noticeably significant though -- but in the front office only. The Back Office is less important, but it would be nice if the back office was a little quicker in places, but it's lower priority The problem with some of these performance tools like Yahoo's YSlow and Google's Page speed is that they in some cases give conflicting advice, because there really is no one single ideal solution for every site. As an example YSlow will recommend a CDN, but Google Page Speed will see the extra DNS lookups and recommend you minimise them..... You have to be careful you don't end up optimising an arbitrary score (as calculated by a performance tool) and as a result DE-optimise your site There are parallels with running "SEO analysis" tools on pages and making silly changes to please a bit of software; for no real gain. Paul
  21. Is the sage pay module that's for sale on Prestastore only form integration then and not direct integration? The one that costs 250 euro? Paul
  22. @Pradchal I'd be interested to hear why you would say that; in my experience there are many helpful people who frequent this forum, including the moderators. I think what you have to remember is that most, if not all, users of this forum do so in their spare time while working on their own businesses, so to expect instant free assistance is a little unrealistic no? @newera If I'm being honest, then I will say that Prestashop is still rapidly developing and because of this you have to expect that there may be certain things that aren't perhaps working quite in the way we might wish. If you are a programmer however I'm fairly confident that you can easily build an excellent ecommerce site using it. You might want to check out the development articles on my site (you'll get to it from the links in my signature) which may help get you kick-started with development for Prestashop. I'm hoping that when time allows I can add some more, as I have lots more to publish. In terms of comparison with Magento, then I would say that unless you want or need (as a developer) to commit to Zend, it has little advantage over Prestashop in most cases. For certain more exotic circumstances Magento may have an edge however. Compared to Zen? Well, while it's true that there's a lot of "history" there - to say that the code is rock solid and easily extended would be a mis-truth. I personally think the almost daily bug fixing at the last "stable" release (1.3.9, which raced to 1.3.9h with some major problems that required frantic fixing along the way) clearly demonstrated that Zen is past it's best, and that development on it is finished. We may see a Zen 2.0; who knows? I suspect that even if we do, it will be a long time before it's stable.... All the best, Paul
  23. Keywords in the url has always been a minor ranking factor (on a par with image filenames containing keywords). Even saying that, the current implementation DOES allow your keywords in the urls. I have to agree with Dave Angel, and in my honest opinion the only benefit of NOT having those numbers in there is aesthetics and simply not worth the effort. Many Wordpress blogs (including my own) have numbers in the url along with keywords (I use dates in mine) and rank just fine. Paul
  24. I would be very careful. Sometimes there are pages - like search results that could be of benefit to have indexed. I assume also that you don't have friendly urls enabled? If you do then the bots won't match links with your php files if they've been re-written. Paul
  25. In Google Webmaster tools you can also set the "preferred" domain to www.example.com and they'll fix up the index based on that, but doing a 301 redirect from the example.com form to the www.example.com on via .htaccess would be worth doing as well. Paul
  • Create New...

Important Information

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