Jump to content

Paul C

Members
  • Posts

    801
  • Joined

  • Last visited

  • Days Won

    4

Everything posted by Paul C

  1. Try entering each of the three sections one by one. You get an "Internal Server Error" for invalid configuration commands in .htaccess - one of them is causing the issue. Paul
  2. Ah sorry John, as I said I didn't go searching, but I do remember us talking about this for 1.4 a while back and I forgot all about it... @capelec Ah yes the 1.3.1 function call would have fetched the subcategories too - that's fixable along with the numbers. To remove the 2-digit number plus period you should be able to use the substr modifier in the template file: {$category.name|substr:3} You need to make sure that the number of characters added to the beginning of your category names (for sorting - not something you need in 1.4) is the same for all of them. You're probably never going to need a number larger than 2 digits though I guess. I need to build a category structure with subcategories to test what happens in both cases. Backwards compatibility is a huge subject for Prestashop now that 1.4 is here - in some cases it just isn't going to be possible, but you can but try! Paul
  3. Right, lets try again. This version should work for 1.3.x versions onwards (tested to 1.4.4 but I don't currently have a 1.3.x install to test on so had to fudge a test on 1.4.4). An interesting exercise Paul homecategories_1_4_2.zip
  4. No luck involved http://www.prestashop.com/forums/topic/2079-frontpage-categories-module-for-v13-and-below/page__st__180__gopid__607887#entry607887 Paul
  5. Related to: http://www.prestashop.com/forums/topic/124143-add-category-description-in-a-module/page__pid__607811#entry607811 I've had a very quick play about with this to update for use with 1.4.x and now the $categories smarty variable contains ALL of the category information. I've also added the css properly from within the module (so no more mucking about with global.css). You can override both homecategories.tpl and homecategories.css in your theme directory (as the PS gods decree). I have made no attempt to keep track of this thread, so the css that's in the archive is minimal at best (I tried to at least match it with the template I used...). As I said above - you can override them both anyway. I added the description into the template as an example, but you can use any or all of the following available fields: id_category id_parent level_depth nleft nright active date_add date_upd position id_lang name description link_rewrite meta_title meta_keywords meta_description Knock yourselves out Paul EDIT: Just looked at your sig Cap Elec and you're using 1.3.1 so this isn't going to work. Will modify it to be backwards compatible too then and post shortly.... have removed this version as it will only confuse...
  6. If you post where you found the module I'm happy to take a look at it. I think I promised someone to do something similar a while back and forgot..... Paul
  7. You could use something like this: http://flowplayer.org/tools/dateinput/index.html But you would need the custom input field (you can define those in the tab in the product page of the admin screen) to be modified. By default Prestashop supports a text fields or file upload fields. Within the product.tpl theme template you would have to add logic to get it to create the required: <input type="date" /> for the customisable field(s) instead of the default "textarea" input. Once that's done though, you should be good to go. Search for "text_fields" in product.tpl to find the related code. It will end up looking something like: <ul id="text_fields"> {counter start=0 assign='customizationField'} {foreach from=$customizationFields item='field' name='customizationFields'} {if $field.type == 1} <li class="customizationUploadLine{if $field.required} required{/if}"> {assign var='key' value='textFields_'|cat:$product->id|cat:'_'|cat:$field.id_customization_field} {if !empty($field.name)}{$field.name}{/if}{if $field.required}<sup>*</sup>{/if} <input type="date" name="textField{$field.id_customization_field}" value="{if isset($textFields.$key)}{$textFields.$key|stripslashes}{/if}" id="textField{$customizationField}" class="customization_block_input" /> </li> {counter} {/if} {/foreach} </ul> Paul
  8. You could have an input field I guess as a customisable field for the customer to enter the date and then use jQuery to convert the input into a pretty calendar date selector? Paul
  9. All you should need to do is enable ecommerce in your Google Analytics profile for the site - the module supplied with Prestashop then just needs your tracking code, and everything else is taken care of. Within the Analytics account screen you should have a list of website profiles - click "Edit" on the right next to the site you want to track, then click the "Edit" box next to "Main Website Profile Information" on the next screen. This will let you select "Yes" in answer to "E-Commerce Website". Paul
  10. You haven't mentioned which version of Prestashop you're using. Ideally you would add something like this via a module, since you can then use the AddJS() and AddCSS() -- these queue the scripts up for combining and minification. Adding to header.tpl should work too though (for all PS versions and foe all pages). I notice from the code you posted that they have relative links... what are they relative to? Looks like it would be in a directory above your store root currently... try adding them as absolute urls to the actual JS and CSS files.... Paul
  11. Is there a reason you can't just use $category->description ? Paul
  12. To be honest if all you're doing is building a cart of products, then it would be better to do that on the external site, wouldn't it? You have to know the product_id on the external site already.... Once you have the external cart built, then you could write module code to accept this as a POST/GET to take the user to the Prestashop site for checkout. The main problem would be if the customer built a cart on the external site, clicked to go to the shop to checkout but then added more products and returned to the external site - in that case they wouldn't see the products added by Prestashop on the external site. I'm not 100% sure I understand what you're trying to achieve though! Paul
  13. You say you "moved" it - does that mean it doesn't exist at the original location any more? It should exist in both places. The correct process is to make a "Copy" or to create a file from scratch with the same name. Paul
  14. I had a quick look and it seems to have a 301 redirect on it to: http://www.sedoparking.com/domparking.php?id=415789&u=http://www.thenorthcol.co.uk/en/ Paul
  15. Have you looked at the settings in Google's Webmaster Tools? Most of these perceived SEO "problems" are purely red herrings. Look at Site Configuration->URL Parameters. Google are not as naive as most people seem to think and their crawling/indexing can sort out situations like this itself quite well -- in some cases actions people take to "improve" their rankings can result in the opposite. I would strongly suggest that this isn't the cause of any issues you are experiencing. You mention a decrease in page rank, but have you also seen a decline in organic traffic? I do know that the last Page rank round did have quite significant impacts on certain sites. Usually a drop is due to the devaluing of certain types of links - there haven't been many of these recently as the quality team were working on a specific traffic hijacking issue that they felt was a priority in cleaning up their search results. Paul
  16. All you need to do is use the standard generated .htaccess with the addition of a test on the HTTP_HOST. If it isn't the main one, then redirect to it -- that will handle any other domain that ends up there. Paul
  17. All you would need to do is change the above to : class FrontController extends FrontControllerCore{ public function displayHeader() { self::$smarty->assign('currentController',get_class($this)); self::$smarty->assign('currentReferrer',$_SERVER['HTTP_REFERER']); return parent::displayHeader(); } } Now you have 2 variables in the header.tpl file to test to determine which header to use The only problem is that the $_SERVER['HTTP_REFERER'] variable isn't very reliable and can easily be spoofed, so I would suggest you might need to clean it up rather than just pass it directly as in the example above. It also may or may not be set at all... The WP Greet Box plugin for Wordpress might be good for some inspiration. Paul
  18. Yes just click the SQL tab and when it shows SELECT * FROM `ps_configuration` WHERE 1 Replace the above with UPDATE `ps_configuration` SET `value` = 'e-shop.mydomain.com' WHERE `name` IN ('PS_SHOP_DOMAIN','PS_SHOP_DOMAIN_SSL') And then click the "Go" button at the bottom right. You will need to clear the cache on your browser (and probably restart) since if there was a 301 redirect the browser will "remember" it. This is true also when you're working with the .htaccess file. It can be really confusing... Paul
  19. I'm not sure why you would want or need to do such a thing. Are you sure you don't need to create a new Carrier module? That function is in the Carrier class and affects all carriers, rather than a specific one. In fact doesn't Carrier::getDeliveryPriceByPrice() do what you're describing already? If you really need to change the core behaviour (potentially affecting all carrier modules) then you would override the class (and that specific member function). Paul
  20. Interesting Do you need to send a form (e.g. product, quantity) or is it just a url to add a single pre-defined product to the cart? I assume that the customer is redirected to the Prestashop site on clicking the link/form submit? Paul
  21. The instructions are based on you moving from one hosting to another with the shop at the same url. If you have changed the url (domain) then you will need to edit the database to reflect this change. In the ps_configuration table (assuming 'ps_' is the database table prefix, may be different if you changed it) there are two records that you will have to change to the new shop domain. You can change these using the following SQL UPDATE `ps_configuration` SET `value` = 'e-shop.mydomain.com' WHERE `name` IN ('PS_SHOP_DOMAIN','PS_SHOP_DOMAIN_SSL') I would try the above first to see if this helps. You can send me the domain name via PM if you like and I can try and see what's happening regarding redirects. Paul
  22. shop.example.com is a sub-domain as as such is no different to www.example.com so that isn't an issue here. My understanding of an "add-on" domain is where you have more than one domain using a single hosting package, and again this is transparent to Prestashop. Paul
  23. Assuming that you're using version 1.4.x.x You could override the functions in the Validate class. In the override/classes folder create a file called Validate.php containing: class Validate extends ValidateCore { } Then you can copy and paste the functions you want to alter the behaviour of e.g. class Validate extends ValidateCore { /** * Check for e-mail validity * * @param string $email e-mail address to validate * @return boolean Validity is ok or not */ static public function isEmail($email) { return empty($email) OR preg_match('/^[a-z0-9!#$%&\'*+\/=?^`{}|~_-]+[.a-z0-9!#$%&\'*+\/=?^`{}|~_-]*@[a-z0-9]+[._a-z0-9-]*\.[a-z0-9]+$/ui', $email); } } (Note I haven't actually changed the above just copied and pasted it ....) Paul
  24. Yes, change it to : /* Debug only */ @ini_set('display_errors', 'on'); define('_PS_DEBUG_SQL_', true); It should give a clue as to what is wrong. It's unlikely that you'll get an "official" answer since what you're trying to do has very little to do with Prestashop specifically, over what has already been said in this thread. Paul
  25. I find it hard to get excited about this as a feature and always have. Do I think it's a fantastic new feature that should be added as a priority? No. Why? Because very few business models will benefit significantly enough (if at all) from it, and fundamentally this is software that's used to run businesses, not for fun. The feedback I mostly get from people about Prestashop is that they would like more "stability" releases and less new feature implementations. Paul
×
×
  • Create New...

Important Information

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