Jump to content

Paul C

Members
  • Posts

    801
  • Joined

  • Last visited

  • Days Won

    4

Everything posted by Paul C

  1. Yes, I've had a look at the code and it doesn't look like you'll be able to override it. Whether it's a bug or not could probably be debated, but it's a good example to use when learning about overriding classes in PHP The problem is that this function is only ever called from within a function defined in OrderOpcController, and the scope is limited by the "self" keyword (it's called from ::preProcess() and ::_assignPayment() in the parent OrderOpcController class using the self scope modifier). Try the following: class TestParent{ protected function _getPaymentMethods() { echo ' Function called from Parent.'; } public function testing() { echo 'Try self'; self::_getPaymentMethods(); echo 'Try $this'; $this->_getPaymentMethods(); } } class TestChild extends TestParent{ protected function _getPaymentMethods() { echo ' Function called from Child.'; } } $parent = new TestParent(); $child = new TestChild(); echo 'Parent Test'; $parent->testing(); echo 'Child Test'; $child->testing(); The output you get is: Parent Test Try self Function called from Parent. Try $this Function called from Parent. Child Test Try self Function called from Parent. Try $this Function called from Child. The "self" keyword used with the scope operator means that the "parent" version of the function will always be called when the testing function uses "self::". Now as to whether it's a bug or not.... I don't actually see why this function is called with the self:: scope modifier as the function calling it isn't declared "static", which is normally why you would use the self scope modifier. I suspect that if you replaced the "self::" with "$this->" in the preProcess and _assignPayment() functions it would work fine as you're expecting it to. Note that there are a couple of functions in that class that suffer from the same "problem"., not just this one. Paul
  2. Odjavel, Firstly are you sure that you have placed the OrderOpcController.php override class in override/controllers ? Another thought is that I'm pretty sure redeclaring a protected function as public will cause a problem. Try: <?php class OrderOpcController extends OrderOpcControllerCore { protected function _getPaymentMethods() { exit; } } Paul
  3. Ooh an interesting discussion. I'm in the position to see it from both sides, and sadly "community" works both ways or it doesn't work at all. I've been uncomfortable with the high pricing for some of the modules and add-ons, and made the decision early on not to get involved in the official site. That's not to say that I won't in the future though. When osCommerce was the only game in town it attracted a huge following who put a great deal of effort into providing extra functionality. ZenCart benefited from this work when they branched off the original osCommerce source; the amount of originality you get for free in Zen is minimal in my opinion, with a couple of notable exceptions. The world has moved on maybe. In saying that, the modules I've personally offered to the community for free have been used by many with very, very few (<1%?) even making a token donation to encourage me to continue development of them. Either those that are using them are just dreamers who don't and won't make any money, or they are happy to maintain the code themselves. I don't mind, but it does make me laugh when people complain that they don't work/haven't been upgraded recently.... Open source is a business model just like any other. Open source does not mean everything is free - what it does give you is the freedom to do whatever you want with the source code, and that is a huge advantage over "closed" software products. I recently bought the Sagepay module from Tomer (PrestoChangeo Sagepay module) on behalf of a customer - excellent value for money in my opinion based on the number of hours I would have to spend writing my own. Time is money. The bottom line is that when starting an online retail venture I would suggest that if you intend to have a $0 budget for your site development, then you are immediately in the "most likely to fail" category. Your experience may differ. Paul
  4. There should be a smarty variable {$page_name} defined - it's used in the <body> tag in header.tpl to use as the id for the body of each page. I think you could test that to see if you are on the index page e.g. {$HOOK_TOP} {if isset($page_name) AND $page_name=='index'} {plugin module='slideric' hook='home'} {/if} <!-- Left --> {$HOOK_LEFT_COLUMN}
  5. Sorry DGV, things have indeed moved on since I posted that. The solution was identified in: http://www.prestashop.com/bug_tracker/view/8489/ Adding the PS_INSTALL_VERSION config item to the PREFIX_configuration table and then regenerating the .htaccess file via the tools menu appears to have completely solved the issues I was having. Apparently the .htaccess was being generated differently for older installations and the decision on what the rules generated should be were based on this variable; which didn't exist. My .htaccess now has: 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] Which is what we thought the "correct" entries should be, only once that variable is set you don't have to manually edit the file after generation. Paul
  6. As far as I'm aware neither of those do what you describe either. Paul
  7. I thought the originator of this was talking about copying the css and tpl files into a theme automatically. Even that isn't really essential in my opinion, it's more a case that the module will use the default ones (in the module directory) unless a user wishes to override the look/behaviour as necessary in their theme, at which point they should copy the modified files into the appropriate directory in their theme directory. Even if it were to be done automatically, you would have to do it for all themes which seems pointless really, unless there's a need to. On the overrides folder (classes and controllers) it would be easier to manage the class that the new one extends, rather than trying to merge changes but I'm not sure that even this is practical. I see hooks (and modules) as a way of adding (optional) additional functionality and the overrides as a way of replacing or modifying functionality globally. So you would use a module to add an additional step into the authentication process (an additional check perhaps) whereas an override would replace the authentication process completely. Seen in this way, then replacing a replacement makes less sense. Modules should really be self-contained and not depend on changes being made elsewhere. Overrides by their nature are not self-contained and will likely require manual changes to be made to the theme to support them (where they have an impact on the front-end). I suggest that you only want to add an override if it is the only option other than modifying a core file i.e. it doesn't replace modules and hooks. As a developer I also feel that you should minimise the use of both to when absolutely necessary. Paul
  8. If I was being cynical then I would say that for customers the cost of ownership of Magento is higher, so if you're deciding which to work on as a developer/site designer/consultant, then you will make more money choosing Magento. On a less cynical note, if you have a lot of experience with Zend framework then the learning curve will be shallower for Magento. Prestashop's weakness is its lack of developer documentation (certainly in English). If you have no experience of the Zend framework, then you'll have a lot to learn before extending Magento, whereas Prestashop in my opinion is easier to reverse engineer to work out how to do things (even without proper documentation). Purely my personal opinion of course. Both can be used to design fantastic ecommerce sites. Paul
  9. I should warn you that currently it has display_errors turned on and generates an error (displayed at the top of the screen) when you navigate to a category that contains sub-categories... Paul
  10. Yes - that's the layered navigation. Paul
  11. If it's what I think you mean then it's a module called "Layered Navigation Block"- under "Front Office Features" although I would have expected it to be under "Search & Filter".... Paul
  12. It's only beta in 1.4.0.17 (final) with a comment about it being more complete in 1.4.1 so I doubt a working version for 1.3.x will be available soon, if ever - unless someone writes one. I've been playing with it and it has several issues right now. Paul
  13. @taurasmark That facility is available in 1.4 - minification, combination and serving from multiple "cdn" hosts Paul
  14. The mcrypt library isn't installed. But you have it selected for the password encrypting. Going back to the blowfish class should get rid of that error (as would installing mycrypt on the server). Paul
  15. I went and read the thread, yup - although you have to keep re-applying the changes in 1.3 which puts me off, since I'm never working on my own site and the next upgrade would break the customer's site lol I'm looking at a method whereby you can just drop in new plugins to a directory and then they're available - or even have a directory in the theme to allow you to add such extensions, contained within the theme. The problem is that you need to register the smarty plugins BEFORE the theme starts getting rendered so there needs to be something external to enable the whole mechanism (a module may be able to do it I guess). I'm currently working on having the guts of it as a class (Plugin), and then overriding the FrontController with: class FrontController extends FrontControllerCore { protected static $plugin; function __construct() { parent::__construct(); self::$plugin = new Plugin(); } function init() { parent::init(); self::$plugin->init(); } Paul
  16. This reminds me of a mod I did sometime ago: http://www.prestashop.com/forums/viewthread/61808/third_party_modules/placing_modules_anywhere_in_the_tpl_files Great minds think alike - I didn't consider playing with smarty plugins until 1.4 as I absolutely hate hacking the core code and assumed that this would be required to get it to work. I posted about calling module hooks directly on my blog a while back and then couldn't think of a practical way of using it now. Did you do it all via the module? I guess if you ran a module on a hook early enough they would be available from then on? This started because I wanted to replace things like a custom greeting depending on the time of day, content from cms pages inserted conditionally etc. that had been done as little hacky modules before (by someone else on a broken site I inherited to fix); and smarty plugins seemed like a good way of doing it cleanly. The other main thing I'm using it for is displaying Prestashop variables - Again, why hard-code addresses, telephone numbers etc. that are already stored and editable from the back office? The only other way is to write yet another module to assign them to smarty, make sure it's installed, hook it appropriately etc. not very friendly for theme designers who don;t want to have tolearn how the internals of Prestashop works... Paul
  17. The mechanism I'm using would mean that to display the search block in the footer you would write: {plugin module='blocksearch' hook='rightColumn'} anywhere you want the block to display in (e.g. anywhere you care to place it in footer.tpl). No hooks, no changes to core files (except the overrides and additional class to support the functionality) and no manually coded modules - just edit the theme template and it's done. If you wanted the search in both the header and footer, then you would capture the output as in the cart example above, and then display the variable in both template files. The only issue with doing that might be that there may be validation issues with the markup (id's used more than once for example). Paul
  18. I've been using my plugins for this in 1.4 and it has the additional side-effect of being able to display the output of a block more than once if it makes sense to do so. As an example, to get the cart to run and assign it's variables etc. without displaying anything you can use: {capture name='cart_pre_force' assign='cart_block'}{plugin module='blockcart' hook='rightColumn'}{/capture} Then you can use any of the smarty variables that the module assigns (e.g. $nb_total_products for the blockcart module ) anywhere on the page (or in any subsequent template). Later in the page rendering order (same or subsequent template) you can then just use: {$cart_block} To display the module's output. You would obviously unhook the module from it's default display location to prevent Prestashop trying to display it as a normal hooked module. Unfortunately the latest version, which supports smarty 3, is still in testing but it will be released soon with lots of other helpful goodies to make stunning 1.4 themes a breeze Paul
  19. Only installed payment modules will display there, so are you sure that the others are installed and configured properly? Paul
  20. It doesn't matter that they are in "Other Modules" - do you mean they don't work or are they just not where you want them? Paul
  21. I agree John. There are also many issues relating to hacks people made to core files. I'm sure these all seemed like a good idea at the time.... Paul
  22. I thought it might help to have any tips/suggestions to help with upgrading in one thread. That way, as we come across things that might help to share with the rest of the community we can all add them here. My contribution to get the ball rolling (initial testing should of course be performed on a separate server from your production site!): Many people use 3rd party modules on their site and these may not necessarily be compatible with 1.4. It may seem obvious but it is strongly recommended that you disable all non-standard modules before you start the upgrade process. You should then also back-up and delete their code and directories from the server. The aim at stage 1 of the upgrade process is to get the core verified and stable. You should also switch to the default theme. Once you've managed to get your store running with your upgraded core code, database and the default theme, you should next prepare your custom theme. At this stage you could try installing and enabling your 3rd-party modules, especially if your custom theme layout relies on them. If any of them fail or break the admin screens, then you will need to locate updated versions before you can proceed, or disable and remove them. The first step in upgrading the theme would be to copy the 1.4 default theme into a directory, then overwrite these files with the files from your pre-1.4 custom theme (to ensure that added files are present). You can then use file comparison software to view the changes and merge them in. The level of difficulty will obviously depend on how customised your theme is. In some cases it may even be easier to start from scratch. Paul
  23. Rocky, I've submitted selecting the cookie domain as a feature request for this reason. I had a quick look at the code you're talking about too because I though the same as you, but I can't work out what it's meant to achieve.... Apparently the current behavior isn't a bug (I tried and it got cancelled), but looking at that code I'm not so sure! The other issue I had was that my static subdomains aren't covered by the ssl certificate, so when on an ssl page I got security warnings. I fixed that by ignoring the static domains when serving content on an https page. Paul
  24. If you're using subdomains of the domain your shop is on to serve the static content, then you can't get rid of cookies as the shop cookie is set to .example.com - so applies to all subdomains, not just www. Paul
×
×
  • Create New...

Important Information

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