Jump to content

Paul C

Members
  • Posts

    801
  • Joined

  • Last visited

  • Days Won

    4

Everything posted by Paul C

  1. I think I understand. Caveat: Normally however you would never call Module::hookExec() in your own code as these have been placed in the code to be triggered under certain specific circumstances. In fact calling them manually may cause duplication. This only applies to the hooks that are defined in the core of course; If you create your own hook, then you have complete control over the circumstances that trigger it. Getting back to the original question though, as I said before, what you pass in the Module::hookExec function depends (somewhat) on the implementation of the hook. Using the example above you could omit the second parameter completely e.g. Module::hookExec('updateQuantity'); The above would then assume an empty array for the second parameter. In practice however (and this is historical so could change in the future) module hook functions always get some mandatory parameters passed to them (if they are declared to accept them). Within the implementation of the hookExec function in the Module class the second parameter gets the indices 'cart' and 'cookie' added to it (or if it is empty it will only contain those elements). Both of these are populated by the global 'cart' and 'cookie' variables respectively. This means that if you could have declared your hook function as: function hookUpdateQuantity($params){ $cookie = $params['cookie']; //email stuff here using $cookie->id_lang for internationalisation } Unless those two variables are the only ones your hook function needs though this isn't going to be much help. If you're interested in a core hook function (but see caveat above)then you will need to look at either an implementation in a module, or at what is passed as the second parameter to determine what they are designed to accept. If you wanted to create the "updateQuantity" hook yourself you would have more control and could decide that $params needs to contain a product id and a quantity. Your function (in your module, and any other modules that rely on this) would then look something like: function hookUpdateQuantity($params){ $cookie = $params['cookie']; $product = new Product($params['product_id']); $new_quantity = $params['quantity']; //email stuff here using $cookie->id_lang for internationalisation //Now we have acces to the product details and the new quantity } At the point this needs to be triggered you would then need: $args['product_id'] = $variable_containing_product_id; $args['quantity'] = $variable_containing_new_quantity_for_this_product; Module::hookExec('updateQuantity', $args); Does this make sense? Paul
  2. The upgrade process takes the site from it's current to the version you're installing, so no need to go through each version. The current version should be displayed at the bottom of the admin pages, and will be in the "settings.inc.php" file in the config directory <-- this file must be present for the upgrade to work successfully (everything else could be backed up and deleted, then put back later - e.g. product images, themes etc.) Be aware though that there are significant changes, so be prepared for potentially a lot of work, depending on how heavily customised the site is. Paul
  3. The hook parameters vary depending on the hook unfortunately, so there are no "standards" across them all. I'm a little confused by your example though as you appear to be calling a hook from within a hook which is a little unusual. To update the quantity of the product you would normally instantiate the product, change the value and then "update" it again. e.g. (greatly simplified with no error checking): $product = new Product($product_id_of_product_you_want_to_change); $product->quantity = $product->quantity + 3; $product->update(); Obviously you need to have a valid product_id to do this. I'm puzzled why you would choose the left column hook as this is on every page many of which do not relate to a specific product. Maybe if you post what you're trying to do we could give more specific help on how to implement it? Paul
  4. It would appear that you've chosen the encryption method that requires mcrypt (or maybe this is now the default). I would change the record in the configuration table with name PS_CIPHER_ALGORITHM to '0'. e.g. (assuming the DB_PREFIX is 'ps_') : UPDATE `ps_configuration` SET `value` = '0' WHERE `name` = 'PS_CIPHER_ALGORITHM'; Paul
  5. I would say that the duplicate meta information is far less of an SEO issue than 404 errors on valid pages, so I wouldn't be worrying about that right now. It might even be an idea to ensure that you're monitoring the site's organic performance over the period you have the redirects disabled - you might find that it was having no impact anyway (although if you've made more than one change e.g. SEF urls, it becomes impossible to tell which had any impact, should the performance be worse). The information in webmaster tools is great, but you need to be careful how you interpret it, in my opinion. I think we've all been in the position of shooting ourselves in the foot by trying to fix one (minor) thing and ending up breaking something major at one time or another If possible I would first test the functionality of the store using the default theme, just to make sure that it is in fact your theme that is to blame! If the theme is the problem then I would examine the default theme for the version you're using and determine how the urls are being built in there compared to your custom theme; in most cases the code for the actual link should be identical (the mark-up might not be though). Some themes based on older versions of the default theme fail to update the link generation method which has changed significantly over time. Using WinMerge or something similar greatly helps. Paul
  6. Does it work when you disable the duplicate/redirect module? If so then it would make sense to disable that surely? I'm not sure what you're using it for though.... Paul
  7. I use WinMerge : http://winmerge.org/ you can either compare whole folders (including subfolders if you want) plus it supports exclusion rules - this means you can ignore version control files e.g. those created by version control systems. It's extremely handy when looking for important (relevant) bugfixes in the latest svn version Using the above it should make life a lot easier Have fun, Paul
  8. @netboard This is why I started using my "plugins" rather than having to write trivial modules just to add hooks. Hooks are great for inserting business logic into the execution path (e.g. do X action after Y) but in my opinion are a very weak solution for the front-end. You can read about how I handle such situations here: http://www.ecartservice.net/prestashop-articles/1-4-plugins-revisited-part-1/ If you follow the articles I went on to allow a further extension that lets you place additional code in a "functions.php" file in the theme directory. This is handy for things like adding a Tools::AddCSS() call from within the theme to properly queue additional css (or indeed javascript) so that it benefits from the "CCC" functionality. You can also write your own smarty plugins in here and have them available in all your theme template files. Paul
  9. If you're getting errors similar to digtheweb: [Wed Dec 01 13:57:21 2010] [error] [client xxx.xxx.xxx.xxx] PHP Fatal error: Out of memory (allocated 3407872) (tried to allocate 23904257 bytes) in <dir>/public_html/test/get-file.php on line 339, referer: blah, blah, blah This is due to the amount of memory a process can use which is also set in php.ini (or modified in .htaccess). Many shared hosting configurations limit this amount to prevent individual sites swamping the server (when real physical memory is exhausted, then the slow disk-based swap space is used). You can try and increase this limit, but in many cases you won't be able to beyond the maximum allowed by the server's php configuration e.g. in .htaccess php_value memory_limit 512M If you can't increase this value high enough to prevent your issues (which I suspect is the case for digtheweb), then, unfortunately you'll have to look at an alternative method to distribute the files or change hosting. You can save a little php script on your server called e.g. phpinfo.php containing the following: <?php phpinfo(); ?> If you browse to the above script it will show you all the current active (local - i.e. the values that apply currently by default for scripts) and "master" values for the various variables (under PHP Configuration, PHP Core). You might find that no matter what you have entered in your .htaccess file, you will be unable to increase the value beyond a certain point. Paul
  10. The best option is to first compare your custom theme with the default prestashop theme from 1.2.1 (using a file comparison tool) - this will determine which files were modified - these are the files that you'll need to upgrade. The next step is to make a copy of the 1.4.4 default prestashop theme and then the last stage is to do a line-by-line comparison of the new default theme files and the modified ones you identified at the start and merge your changes - i.e. the tricky part Paul
  11. Unfortunately it isn't just a case of naming the images correctly, but you also need to create records in the database which are linked to the product id.... If you take a look at the AdminImport.php in the admin "tabs" directory you'll see how they are handled. Basically you pass the image and product id to a new Image object. Confusingly in AdminImport.php the images are stored as an array in a variable $product->images - searching for that should get you to the relevant code. You also need to be able to create multi-language fields for the legend which is an added complication. Paul
  12. You just need to run the installer provided in 1.4.4 and it will upgrade the database appropriately (ensure that it's running in upgrade mode and not a new install). I usually then export the structure (only - no data) of the resulting store and compare it to a structure export from a fresh 1.4.4 install - there are usually minor differences that I like to fix (minor things like fields lacking "unsigned" and slight differences in default values). Basically you need to preserve your theme, product and category images, any additional modules, translations, email templates and finally the /config/settings.inc.php file (<-- IMPORTANT)-- everything else can be deleted (but it's a good idea obviously to keep a backup). You can then copy the new distribution to your server, copy your original settings.inc.php file into the config directory and then visit the url http://www.example.com/install and this should start the upgrade process. Usually you actually need to copy the above customised files somewhere safe, ftp the new version and then overwrite with the files you previously saved, otherwise you'll lose your versions when you copy the default files in new distribution. Be aware that there are major differences in the themes (smarty 3 being the "killer"), so it might be best to revert to the default "prestashop" theme prior to upgrade and disable any non-core modules so you can confirm that the upgrade was ok, and then tackle your custom theme and modules. Paul
  13. Shared ssl in my opinion isn't worth even considering, certainly not for a "customer-facing" application. For a dedicated ssl certificate you'll need a unique IP address for your site which should be available from all credible shared hosting providers. There's no need for a dedicated/virtual server, just a unique IP to (uniquely) identify the site. The main thing that SSL brings to your store is credibility. For this reason I would strongly suggest you select a certificate from a well-known provider, as otherwise the benefit will be minimal, or could possibly even be counter-productive. Consider your customer's opinion of you if you have "This site is secured by CheapSSL" displayed Paul
  14. Like jhnstcks I've been happily use scotserve for commercial sites. One often overlooked aspect of choosing hosting is backup and recovery so in my opinion you should select hosting which offers an online backup facility. With scotserve, for example, I can restore a site to within about an hour (or less) of a problem, rather than 24hrs or more.... recovery is really essential for a commercial online site. As with everything you get what you pay for, and choosing on price is never a good bet in my experience. Paul
  15. It really isn't very complicated but there are a few areas that can trip you up. The first thing to check is whether you're moving from similar hosting systems e.g. whm/cpanel. If you are then you should consider getting the two hosting companies to help you as it's merely a case of backing up the whole hosting account on one and "restoring" it on the other - this has the advantage of preserving everything including email accounts, parked domains etc. You should always consider this as your first approach as it is by far the simplest. If the above isn't possible, then you have slightly more work to do. The first step I would take is to do a trial install of the PS version you are using on the new hosting. To do this you need to ftp all the files from your old hosting to the new hosting, and then also ftp the "install" directory from a corresponding PS version download (you can download older versions of Prestashop from here: http://code.google.com/p/prestashop/ ). Temporarily rename the config/settings.inc.php file to something else so the installer thinks this is a new install. At this stage you only have to create a database on the new hosting (empty), as you're only concerned with the code/filesystem. Most hosting control panels have a "wizard" to help create a new empty database. We'll look at the database side of the actual move later though. The above will assist by telling you what, if any permissions and settings you will have to modify on the new hosting, and saves messing about having to change permissions and settings as you discover issues. In theory you could preserve the permissions by creating a tar file on the old server, but even then the different systems may not be configured the same, so even that may not work. Note that you don't have to complete the install - just progress far enough to ensure that you know what changes to permissions/settings, if any, you need to make. Once the above is complete you can move on to migrating the database. The best way is to use phpMyAdmin where available. There are plenty of resources on the net detailing how to do this e.g. http://codex.wordpress.org/Backing_Up_Your_Database which although written for WordPress can equally be applied to any MySQL database. In this case you restore to the database on the new server which you created for the above step. This is the area where you may encounter problems as there are often limits on the size of import/export files allowed. It may be that for a store with a large number of products you might have to backup and restore the tables in groups rather than all the tables in the one file. It's really just a case of trial and error sadly. Once the database has imported correctly you will then have to reinstate the config/settings.inc.php file (which you renamed above) back to its proper name. Because the database details have likely changed as a result of the move you will need to edit this file and change the database settings: define('_DB_SERVER_', '127.0.0.1'); // It's is unlikely but possible that you'll need to change this define('_DB_NAME_', 'new_db_name'); define('_DB_USER_', 'your_db_username'); define('_DB_PASSWD_', 'your_db_password'); These should be the only settings you need to change. Note that if you performed a full install in the first stage above, then the installer will have created a new settings.inc.php file for you. You MUST DELETE this new copy as it does not contain the correct keys required to properly handle your stored passwords. You can however copy the database settings from this new file and use these to replace the ones in your original settings.inc.php file prior to restoring it. The final stage is to recreate any email accounts you have on your old hosting and remember to backup/download any remaining emails you wish to keep - how you do this will depend on the email client software you use obviously. Once the domain name has propagated to the new server's IP address your store should now be exactly as it was before, but on the new hosting. If you want to test before switching the domain name over, then you can manually modify the hosts table on your PC to point to the new server's IP address for your domain name. Remember to delete the entry in the hosts table of your PC once the IP address has propagated though or it might cause confusion in the future.... It is good practice, once the above is complete, to regenerate the .htaccess and robots.txt files just to be safe. Good luck! Paul
  16. If I assume you're on shared hosting, then the extent of the risk will depend on the server configuration. Worst case is that anyone else who has a shared hosting account on the same server will be able to read/write your files at will. In general you should set file and directory permissions to be as restrictive as possible, while still allowing your store to operate..... the exact permissions you can use will depend on your server configuration. Remember that files that do not need to be modified during the normal running of the store could be read-only for everyone.... Paul
  17. Jennyb, You can either obtain/write a module or you could try using my "plugin" mod to add the code that way. One of the things I use my code for is adding css and js to the header in such a way that it can take advantage of the CCC functionality in 1.4 (if you just hard code them in header.tpl they'll just be ignored for minimising etc.). I'm writing up some examples such as this right now, so if you want to send me the code you're trying to implement (via PM), then I could look at including it as a "How-To" example Paul
  18. I would move the database to your local server and upgrade it there (remember to copy the settings.inc.php from your old Prestashop version on the production server too). You can then create a new database on the production server and populate it with the upgraded version you've prepared locally. Ideally when upgrading a production site you should be able to roll back to the previous version (in the event of a problem) instantaneously. I would always have both versions (code and database) online and switch between the two. Paul
  19. It's likely that one or more of the module files is corrupt. I would try comparing the file sizes with a view to using ftp to replace that module with a copy from the download archive. The "problem" file will be in /modules/themeinstaller If not, then to be honest I would try deleting the /modules/themeinstaller folder completely to see if the page displays correctly. It's likely something you could live without anyway Paul
  20. I'm not sure why you want to specify the language in the constructor at all. If you want to update the product name or any of the other multi-language fields, then I believe that you would do them all anyway (if one changes, then surely they all change). The way I would set the name for example, would be: $multiLangName = array('1' => 'name in language 1', '2' => 'name in language 2', '6' =>'name in language 6'); $product->name = $multiLangName; So you only ever need to use the first form. Paul
  21. Well the ajax calls are handled in ::preProcess() so making a copy of that function in your override too should really sort it. Paul
  22. Yes, because by moving those two functions, "self" now refers to the child class not the parent class Ideally you don't want to have to make copies of functions in your override, but in this case at least it gets it working (until maybe the PS developers change the Core class......). I think it would be worth reporting it to the bug tracker to be looked at, because I don't believe that the way this currently works is intentional.... as I said above, it isn't just that function that will suffer from the same problem either (and maybe there are other cases in other classes). Paul
  23. It sounds like you would be better re-developing it as a modification for PS 1.4 You can extend the Product class, and add a new controller fairly easily in 1.4, but as you say in 1.3.x doing this would require modification to the core. I'm not sure that the PS devs would be looking at adding new functionality to 1.3 when 1.4 is released and 1.5 is in development.... It's possible that there's a market for mods to 1.3.x though; for people who don't want to (or can't because of a multitude of undocumented customisations!) upgrade. Paul
  24. With the autoloader you don't have to specifically include the class at all, plus you can also just add your class to the overrides/classes directory directly (i.e. you don't have to create a "Core" version unless you absolutely need it to be overridden like the core classes are). e.g. just create the file /overrides/classes/Postal.php class Postal extends ObjectModel { ....... } And just use it without any includes etc. If you feel that being able to override the class later would be useful, then you can create the following in /classes: class PostalCore extends ObjectModel { ....... } But again, you should never need to use an "include" or "include_once" as the autoloader will find and include it for you Paul
  25. I've written an xml importer, heavily modelled on the CSV importer that ps 1.4.x uses and haven't had a problem. To get a product to modify I just used: $product = Product::getByReference($data['my_unique_reference_field']); You can then test to see if a product to update was found, and if not then create a new product to add. The language really isn't an issue at this stage since you only need to touch that if/when you;re modifying the product title and description. After the above you should just be able to do: if (!$product) { $product = new Product(); self::setEntityDefaultValues($product); // See the AdminImport core tab to see what would be appropriate for a product $product->reference = $data['my_unique_reference_field']; // This is essential in my case as I use this to sync. products } After this point you can treat new or existing products in a similar way, assuming that you want to update all the product properties (name, description, price, category, features, attributes etc.). You can set most of the basic properties to a new product, but there will come a point when you need it to have a valid id (e.g. to map it to categories, add images, add features, add attributes etc.). At this point in the processing you should call the following, but only for new products: $result = $product->add(); Now you have an id for both products and they can share common code again for the rest of your processing. Once you performed all your updates then save the remaining changes: $product->update(); The language should only really come into play when you need to create the arrays for name and description and when generating the friendly urls. @sors You can't set the name to simply a string, as it should be be multi-language array. @jgonze You aren't updating the name and description etc., so I suspect you should use the constructer: $product = new Product($id, true); Otherwise you'll mess up those fields that haven't been loaded.... Paul
×
×
  • Create New...

Important Information

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