Jump to content

Paul C

  • Posts

  • Joined

  • Last visited

  • Days Won


Everything posted by Paul C

  1. A simpler way might be to use the smarty modifier "convertAndFormatPrice". It takes two parameters: the price and the id of a currency. You'll need to know the id of the currency you want to use as the second one, but that shouldn't be too hard to figure out.... The format for modifiers is: {$first_param|modifier-name:param2:param3:....} It would appear that all you need to do is use the following in your template: {if $priceDisplay >= 0 && $priceDisplay <= 2} <span id="our_price_display">{$productPrice|convertAndFormatPrice:2}/{convertPrice price=$productPrice}</span> The above assumes that you non-default currency has an id of '2'. EDIT: Sadly the function used in my original attempt only changes the currency display and not the actual price it would seem.... modified the code which should work now....
  2. Hi Fenix, That was due to adding a feature to display the prices including or excluding tax depending on the store setting. It worked for 1.5 but broke in 1.4. Have fixed in trunk.
  3. Probably worth setting a warning and then skipping that product. Cheers, I'll have a look into it.
  4. Well, what you should do is override the FrontController class and pass the current customer's DEFAULT group to the smarty variable. e.g. <?php // Place the following in: <install-root>/override/classes/controller/FrontController.php class FrontController extends FrontControllerCore { function init() { parent::init(); if (isset($this->context->customer->id) && $this->context->customer->id != 0) { $default_group = Customer::getDefaultGroupId($this->context->customer->id); } else { $default_group = 0; } $this->context->smarty->assign('customergroup', $default_group); } } You can now test this variable on ANY page on the site....
  5. The problem would be that customers can be in more than one group, so what would you expect to happen if the group you're testing isn't their default group... ?
  6. If at all possible I would suggest trying to use the blocklayered module..... There are a few options to filter the list of products displayed by category.tpl (and subsequently product-list.tpl). I have implemented this for filtering on specific product features in the past (e.g. show only products with the feature "Metal" with a value "Gold".) I created an override of the Category class and replaced the Category::getProducts() function with a custom one that filters the products based on criteria which have been POSTed to the page. This was the "easiest" way.... You could also write a module that post-processes the products for display (but it isn't very efficient). The products that will be displayed by product-list.tpl are in the {$products} smarty variable so as long as your module is run before this template file is rendered you can modify this variable and save it back to smarty. To fetch it within your module you can do: if (isset($this->context->smarty->tpl_vars['products'])) $products = $this->context->smarty->tpl_vars['products']->value; else return FALSE; After processing you would set the above smarty template var with your modified product array, although this will affect pagination (you didn't think it was going to be THAT easy). The advantage of the override is that the Category::getProducts() function can return the correct number of products in the pre-filtered list and you don't then have to worry about the detail - as far as Prestashop is concerned there are just less products in the category. The results will also be affected by the product sort options, obviously. The actual filters themselves would be set via a form rendered in category.tpl and POSTed to the current page. If they are checkboxes in the form (from some old code of mine).... <input type="checkbox" name="filter_feature[{$active_filter['id_feature']}]" value="{$active_filter['id_feature_value']}" onclick="submitFilter()" checked="checked" /> (Note that they are checked by default as in my case un-checking them removed them as a filter) ....you can use something similar to the following to then get an array of active filter values. function getFilters() { $filters = array_filter(Tools::getValue('filter_feature', array())); return $filters; } Hope my rambling helps!
  7. And added an "experimental" cron facility
  8. Hi there Totti. I've added it in the latest main (trunk) branch update HOWEVER in the following branch: https://github.com/paulc010/googlebase/tree/beta I have a version that is 1.5.3 specific and it implements "combinations". This is where the product references may start to give problems (although even the method I've used for supplier reference potentially causes problems where there is more than one supplier of the same product in a store). The stock management functionality in 1.5 has actually made this easier in some respects and harder in others...
  9. Hi there folks. My latest version is now hosted at: https://github.com/paulc010/googlebase Feel free to fork it and or make suggestions for inclusion I do have another version in the experimental branch but it is extremely "alpha" and may bot have all the fixes applied to the main branch as the focus is on testing new features. Feel free to steal anything from there that might be useful though. Paul
  10. Thanks Fabien. Packaged it up quickly.. and.... well, you know how it is Well it's all down to your own legal interpretation. The law is about "Privacy" not technology and it has been openly discussed that things such as session cookies to store a shopping cart are exempt (since they are fundamentally essential to the site's operation). What isn't exempt are things like analytics tracking (including 3rd party facilities introduced by your site), cookies used to gather statistics, browsing habits etc. How you interpret the law, of course, is entirely up to you. This is a quick fix, not a solution (anyone who thinks they can install a module and "fix" this is being extremely naive). You need to look at what tracking you are doing and what you can do to make it optional based on an "informed choice". Currently with this module the customer either accepts that you will track them, or they don't; and they leave. You can get users to make "informed consent" on accepting your terms and conditions, so for a user that has an account you will likely be fine with just getting them to agree at registration. Organic visitors to your site on the other hand are more difficult to handle. I don't think you can get away with displaying a message somewhere and hope visitors spot it; You need to force their attention - whether they make a decision or not cannot be optional. Another approach is to not track non-logged in users at all, but that will lose you a lot of valuable information which you could be using to improve your site. Remember your use of things like Google Analytics, Clicky etc. are your responsibility to disclose, not the responsibility of the tracking service provider. A couple of interesting articles on the subject though: Firstly, UK-specific guidance that makes things a whole lot easier: http://www.guardian....implied-consent However, and this is important: Commentary on non-EU websites: http://blogs.wsj.com...u-privacy-laws/ The problem is that these are in huge conflict as the EU courts could take action against a UK (or non-EU site potentially) company even if the UK site follows the Information Commissioner's advice; assuming (and it's a safe bet) that the EU court's interpretation disagrees with that in the UK.
  11. Since it's almost d-day for the UK here's another alternative: http://www.ecartserv...kie-law-module/ Enjoy P.S. This one is free.
  12. It's probably not a good idea to have all of them in the Home category anyway..... If you're at least a little familiar with phpMyAdmin, then you could run a query to clear out all those products from the Home category. Obviously you're going to back things up first before you try...... DELETE FROM `xx_category_product` WHERE `id_category` = '1' xx_ will be the db prefix you're using for your store. Then you can select your actual featured products by adding them to the "Home" category and will have cut down on a lot of unnecessary work for your shop
  13. Interesting discussion guys but as usual with SEO there are so many answers (some might say merely opinions) and not all of the information out there is directly applicable to all types of sites. I would go with the "there's no such thing as too much information" school of thought, so I'll happily include meta tags where I feel they MAY be of benefit - Google may not use them in their search algorithm but may use the geo location information for maps etc. There are lots of talented people out their doing cool stuff with these little snippets of information I'm confused about the assertion that different languages used in backlinks have no effect - that's not true in my experience and Google are smart enough to pick up on people talking about a site, regardless of the language used. They developed their translation tools for a reason, along with a lot of work on synonyms... Their job is to deliver quality search results and they won't willingly ignore data if it could be used to improve the quality of their searches. On the multi-language discussion I would also throw in there there could be benefits from using subdomains for your site translations and reserve the "www" subdomain as the overall parent. This is due to the fact that domains themselves have "quality" data associated with them and that different TLDs will not necessarily be related by the search engines, for example: www.example.com and www.example.fr These could be two completely different organisations, however: www.example.com and fr.example.com MIGHT be a better approach as you may get more credit from the shared domain across the sites (mozRank measures domain authority for example; whether Google or Bing do is an unknown but a credible assumption). It would bear some testing. Google will regardless strive to deliver the best possible search results, so depending on whether you're a brand or not may influence how you approach marketing your site this way. Usability (with respect to how easy it is to remember a site's url) is also worth considering even though it's not strictly concerned with the technical aspects of SEO - it is still a factor which shouldn't be ignored. Matt Cutts has commented several times on multiple storefronts for a single inventory (akin to selling the same washing powder in different branded boxes ala "Lever") and has strongly suggested that he thinks it's a pretty bad idea since it dilutes your efforts, resulting in competing with yourself .... different language sites are, of course, a different matter. Another good way of using this functionality would be to separate out different product lines into separate web stores (optimised for a specific product area) while managing the customers, orders, payments and inventory activities with a single administration view. Paul
  14. If you really want to hand-craft a feed, then I would suggest downloading the data as csv. There's a nice FREE (not trial) piece of software called CSVed available from http://csved.sjfrancke.nl/ that can flip a csv into an xml file (the elements are taken from the column headings, and you specify the item tags)... It's also a really useful tool for just general CSV manipulation operations. Paul
  15. The Google product type is "recommended" i.e. not mandatory and is on the list of things to add. Ideally you would be able to add fields to the admin screens (so you could select a type on each product page), but sadly this isn't trivial to do, and would require versions of the module for every Prestashop release. I'm looking at implementing it at the category level (so you can assign a google product type per category). I'm happy to have suggestions for enhancements/improvements, but do remember that this has been developed in my own time for free, and at times I have to concentrate on making a living too There is a slight problem in the Prestashop version detection code that may affect various things for versions 1.3.x and below. The code is currently: $version_mask = explode('.', _PS_VERSION_, 2); $this->_compat = (int)implode('', $version_mask); But should be: $version_mask = explode('.', _PS_VERSION_, 3); $this->_compat = (int)(($version_mask[0]*10) + $version_mask[1]); On other points. The supplier_reference was chosen as it maps to "manufacturer part number", "reference" would then be used for your own internal stock control. I guess it would work the same the other way around, but seemed to make more sense that way. The manufacturer SHOULD map to the brand, although there only appear to be a few warnings for brand Tina, so maybe some are missing/invalid? In later versions when attributes are expanded out into individual products, then the supplier_reference from the attribute will be used here instead of the "parent" product value. The "gid" (guid is deprecated) that starts with the 'pcxx-' prefix is just to ensure a unique identifier (pc plus the iso language the feed is generated for plus the product id from the database). It can just be the product id if you're comfortable with that, but won;t make any difference to the product listing, except in the case of duplication. If you don't have valid UPC codes, then you should select "none" for the 'Global Trade Item Numbers' field. This is fine as long as you specify a manufacturer part numbers and a brand. I'm working on taxation and shipping at the moment, then I'll be implementing the Google product type and product attributes ("variations"). Paul
  16. @louis3232 Do you mean that your product descriptions, titles etc. are in upper case in the database? If so then really your best option is to change them there, and if you want to display them on your site pages as all upper case, then use CSS. Paul
  17. You could also try out my "plugins" (details on my site) and then you would just need to place the following in the template file that contains the right column: {plugin module='yourmodule' hook='any_public_function_in_module'} {plugin module='blockcart' hook='rightColumn'} {plugin module='yourmodule' hook='any_other_public_function_in_module'} Obviously you will need to unhook the cart block from its default location to prevent it from displaying twice. In your own module you don't need to register ANY hooks in the install() function. Another trick you can use is to "pre-fetch" the cart block. You can include the following in header.tpl for example: {capture name='cart_pre_force' assign='cart_block'}{plugin module='blockcart' hook='rightColumn'}{/capture} That means that you now have access to all the smarty variables defined by the cart block - so you can display cart details in the header (e.g. total price of goods in cart, quantities in cart etc.) To render the right column now though you would use the following instead: {plugin module='yourmodule' hook='any_public_function_in_module'} {$cart_block} {plugin module='yourmodule' hook='any_other_public_function_in_module'} Paul
  18. Upgrades are a two stage process. Firstly you need to upload the new core files (remember NOT to overwrite any files you may have customised such as email templates, translations and images - it is best to remove those files from the distribution prior to upload). If your host requires it you will have to reapply the permissions changes to folders (they may have defaulted back to the server standard, depending on how you perform the file upload). You then have to go to http://www.example.com/install and it should detect an existing installation and offer you the (default) option to perform a database upgrade (rather than a full install). The installer should warn you of any incompatibilities and folder permissions issues which you should fix at this stage. You should not have to reapply changes to your server configuration (in 1.4 additional code for the .htaccess file should be added via the Back Office screen). Remember to regenerate the ,htaccess and robots.txt files as required after the upgrade is complete. Obviously it is strongly recommended that you back up both the filesystem and database before starting the process. Paul
  19. To be honest that's because the question is pretty general. Yes you can implement technology to run Prestashop with High Availability, but I wouldn't hold my breath for someone to come up with a design for you in a forum A full-on solution would involve a combination of MySQL clustering and load-balancing technologies across multiple front-end web servers I would guess. There's no specific barrier to running Prestashop in this kind of scenario that I can think of, although I do wonder if it isn't over-engineering. Separating the database from the front-end (web) servers would allow you to focus your spend on the reliability of the database which, if anything, is more "important". Sometimes just having a "spare" web server ready to swap in on the failure of the primary one is sufficient (in tandem with some sort of network attached or shared storage). I've implemented HA server clusters in the past and in almost all but a few specific cases I've left the project thinking that it had really been a waste of time and money (it was more to provide reassurance for a business analyst/manager than to meet a genuine business requirement). With any technology decision like this I would normally suggest you look at what the cost of downtime means for your business (say @ 90% up-time) and then compare this to the cost to implement technology to increase the figure towards 100%. I suspect you'll find that you'll discover that you need contingency/spares rather than true High Availability. Hope this helps Paul
  20. I think you have to take a little step back and look at this logically. Wordpress and Joomla both have extremely simple databases behind them, especially when compared to ecommerce stores. Just because it "seems" easy to do doesn't mean it actually is. Upgrades should be planned and tested, and if this is done properly, should be fairly painless. Paul
  21. I've integrated with a commercial POS system for stock levels/new product listing via xml exports and it works well, although it had to be custom written. It should also be fairly trivial to write order export queries and schedule them via cron. If your POS system is MySQL based, then all the easier. Neither of your requirements is a barrier to using Prestashop. Paul
  22. @ukbaz - I'm not sure I agree. Most online retailers I shop with do the capture and authorisation in real-time (including 3D Secure) these days. It's a cost of doing business online and can be used as leverage to increase customer confidence and hence sales. I think the original poster is looking for a solution whereby the customer does not have to leave the site, with the authorisation and/or capture performed in real-time. There are obviously PCI implications to this (often ignored). Paul
  23. The supplier object has a name and description - is there a reason why you wouldn't use them instead of changing a completely unrelated field? I'm assuming you mean a description of the supplier of course..... if not and it's a supplier's description of the product, then another option would be to use the short description for one and the long description for the other. If neither of the above works for you, then I agree with hellotheworld that you should only be adding (via an override) fields rather than trying to pervert an existing field for your own use. Paul
  24. There are various elements to the process, here's a summary: A Module can implement any or all of the standard Prestashop hooks they want. e.g. hookRightColumn(), hookLeftColumn(), hookTop() and hookHeader(). Unless you make a call to registerHook() though, the module will do nothing (that's why your output didn't display as the install function is only ever called at install time, so the registerHook() function had never been called for your new hook). The purpose of implementing multiple display hook points is usually so that an end user can choose to move the module around in their store. They can only move it to a hook supported by your module. In general within the install function you only make a registerHook() call for the "default" location your module should display in. It's common to see in a module something like: function hookLeftColumn($params) { // some code to build something useful useful in a variable e.g. $content = 'Hello World'; return $content; } function hookRightColumn($params) { return $this->hookLeftColumn($params); } The hookRightColumn() function just does the same as the hookLeftColumn() function, but implementing it allows the user to move the module output from left to right. In the install function for the above there would be a call to registerHook('leftColumn'); and to display in the right column the end-user would use the Module->positions menu option in the Back Office. In some cases a module will need to register more than one hook though; for example you may always want your module to use hookHeader() so you can insert any necessary css and js (using Tools:addCSS() and/or Tools::addJS() calls) into the page header. Hope this helps, Paul
  25. Well firstly why not just exclude pages from the navigation that you don't want displayed in there - that issue should be easily solved with modifications either just to the template or by creating your own navigation module. CMS pages have the title in the url. Paul
  • Create New...

Important Information

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