Jump to content

Paul C

Members
  • Posts

    801
  • Joined

  • Last visited

  • Days Won

    4

Everything posted by Paul C

  1. That's because in css there's a facility to use a shortcode for colours, which isn't the case in Photoshop. #fff in css == #ffffff in photoshop #fff in photoshop == #000fff in css (which will indeed be some blue-ish shade) Paul
  2. The problem is that you need all that code just to do something simple It isn't actually as hard as it looks. The only things you really need to change are: 1) Name of the module (and maybe the description etc. but that's cosmetic) 2) Decide which parts of the theme you need to insert code into (e.g. html header, left column) 3) Install the hook functions in the install() member function for the areas identified in (2) (i.e. `handlers` to insert js/css in header & markup in leftcolumn) 4) Populate the hook functions with the code you need to produce your markup. Note that you can directly `echo` from them (as is done in the example), or you can assign variables to and pass output through, the smarty template engine (added unnecessary complication if you don't need/want the mark-up to be end-user `tweakable`). It isn't hard really, but without having all that framework overhead in place a module won't work and you'll have to resort to editing the core files directly to add your code. You can do that of course, but I suspect you will regret it when you try and upgrade Paul
  3. You could always read my Writing a Prestashop Module articles and you'll have a framework to download at the end of it to get you started Paul
  4. I would say it's likely the adverts - you have a mix of secure and insecure content => so parts of the page are insecure => you get a warning. You need to make sure that all links on the page use the https protocol when on a "secure" page.
  5. It's because Facebook has tracked that people "liked" the old url and now you've changed it to a "better" one. There's no way to transfer the "likes" to a different url I'm afraid. Paul
  6. You really need to be looking at the server to tell if what you're expecting of it is too much. Things like Gzip compression and memcache could be harming the performance instead of helping it if the server is memory and cpu bound - and busy. Sometimes memory can be the biggest problem - you've said yourself it's shared hosting, so how much of the memory are you actually able to use on there and how often is the server paging to disk? If it were me I would likely start by turning all but the smarty optimisations off. Then do some measurements to determine a) what advantage the other optimisations were providing, and to establish a baseline. If the control panel on your account lets you view the cpu and memory stats (or maybe you have ssh access?) then all the better. Paul
  7. Yes, this is the problem. Another issue you have to be careful about when you remove those numbers is that you could potentially be creating duplicates... The ids actually also serve to keep these little guys unique For 1.4 I have a thought in mind of how it could be done exactly the way you would like it - however - I was coming to the conclusion that you would need to make a huge number of changes in a huge number of places to identify and prompt attention to duplicate urls on the admin entry forms - and in some cases you'd have no option but to use an id to force them unique (e.g. in import scripts where you encounter a clash). The other design issue would be whether or not to also remove any additional parameters at the same time e.g. http://www.example.com/shoes/page/1/sort/price/ascending Which makes the process of identify exactly what the url refers to a lot more complicated. (In this case is "page" a subcategory of shoes or is it a pagination parameter?) It can get "pretty" silly "pretty" quickly - and remember these might be required to be in 5 different languages (and you need to detect the language) plus you'd likely want to keep a redirect chain for when you change the url so you can 301 outdated ones to the new ones...... Paul
  8. Roberto, Not sure if you've solved this or not, can I ask why it needs to be before the page renders? Could it not be done within the page rendering itself? You still have an opportunity to change things even when already in a template file (although it's not particularly good practice). If you need to be doing some serious processing though, you're only real option would be to create such a hook yourself, which is pretty nasty. Paul
  9. Looks like CRELoaded to me; which even if it's by looks only, isn't a huge plus. If it is based on Prestashop then good luck with any upgrades to it as it appears you've renamed almost everything... Paul
  10. Did you run the install script to update the database, and did it complete without errors? The process is: 1. Install the new version files (1.3x or 1.4x) 2. Copy the images, email templates, translations, themes etc. from the old store 3. Copy the config/settings.inc.php across from the old store 4. Import the database into a new (empty) one (and then edit the settings.inc.php for the new DB details) 5. Run the installer to update the database and settings.inc.php file to the new version 6. Cleanup the install directory and admin folder name That should be all you need to do.... if you've changed domain, then you'll likely need to go to the settings tab in the Back office and change the details there. Paul
  11. Check you don't have a file called index.html or index.htm in the web root with that text in it? Paul
  12. Why not use css to do it? text-transform:capitalize or text-transform:uppercase Paul
  13. In 1.3.x it would be a complete hack affecting both the .htaccess file and the various places in the cart where the "friendly" urls are formed. In 1.4.x it would likely be much cleaner to do. It may even be, dare I say it, relatively easy in 1.4.x, depending on how strictly the Link.php class is now being used to form the friendly urls ... Paul
  14. I think performance wins over removing those numbers, for sure. I see quite a few people sweating about what would be a pretty marginal benefit. I do appreciate the point you made about removing a segment of the url and the result being counter-intuitive, but then the more I think about it I start to wonder what would drive an end-user to do such a thing... and I arrive at poorly designed navigation on the site; based on little more than the theory that clicking a button is easier.... Search engines won't do it, they're far too intelligent. I also think that web developers and those with interests in SEM tend to have an unhealthy tendency to obsess about minutiae. Matt Cutts once commented on people having BO - backlink obsession; and you can see where he was coming from. Many small businesses would be better spending their time marketing themselves in other ways. I've seen many more sites owned by the "scientific analyst" fail than I have sites run by the blissfully ignorant - given equal amounts of time, determination and enthusiasm. I think there's a lesson in there Good discussion though, and I am always open to new ideas and opinions, which is why I asked the question If I was feeling in a devilish mood I would make the comment at this point that using the keywords as the filenames for product images is said to have a positive effect on keyword ranking (SEOMoz has it not far off being equal in weight to having keywords in the url). Does anyone fancy putting in a feature request for this and starting a petition? Paul
  15. OK. I see the argument about the category and removing the product resulting in a 404 being bad. To me the solution would then be to fix it by having the store produce: http://www.example.com/09-category/40285-product-whatever.html I know some people object to having the numbers in there, but to me they're a compromise worth making, and I see the above as something that could be implemented without too much trouble. The main reason for keeping those ids in there is performance. Using something that "mostly" works ok on, say, Wordpress (and I say mostly as I've seen some WP sites that perform like dogs because of their ultra-friendly urls) doesn't necessarily scale well to a store with 1,000s or 10,000s of products. The human-friendly argument also mainly doesn't hold up too well; I've seen the urls that these schemes produce and there's no way any human is going to remember (or even bother to write down) something like: http://www.example.com/articles/thoughts-on-writing-a-new-seo-article-that-will-confuse.html Where the human friendly effect does come in is where you see familiar, relevant words in the url in search results- and that's achieved even if there are numbers in there too. In terms of the "SEO benefit" of not having numbers in there - there isn't any. In fact I would go as far as to propose that there's very little direct SEO advantage in having these so-called SEO urls at all- except - Where you can gain from using them is when people link to you without using any anchor text (or using the url as the anchor text) - in these cases having your keywords in the url is very effective as it guarantees relevant anchor text.... Thoughts? Paul
  16. @ometiclan I've just published an article on my site you find interesting regarding using theme plugins as an alternative to hooks for module output in Prestashop 1.4. It seems to work for me in the case of adding the home featured products output at the bottom of cms pages, and saves a lot of work and messing about with custom hooks and database changes. Paul
  17. I think this could be down to a slight misunderstanding as to how hooks work; as to actually display anything the module you're hooking in must support the hook and I'm not sure you have done that? In your module install() function you would execute (OR you can do nothing in the module and rely on the Backoffice "transplant" functionality which does exactly the same thing): $this->registerHook('lala'); But in your module class you would always need to implement: public function hookLala($params) { echo 'la,la,la,la,la'; } If you had used: $this->smarty->assign(array('HOOK_LALA' => Module::hookExec('leftColumn'))); Then you could transplant any module that "supports" rendering to the left column to the hook "lala". The support in the module relies on a public member function that is named "hook", which in this case is "hookLala" (by convention the first letter of your hook name is made upper case - no idea why.... "hooklala" may in fact work just the same and the case may be ignored - haven't ever tried I don't think). Paul
  18. A word of caution: sometimes, especially with shared hosting, you can slow down your site by enabling certain technologies intended to speed your site up. Using compression on pages can be one of them as this is CPU intensive and when used on a busy server can result in the time spent compressing being longer than the reduction in time to transfer the now smaller files. Optimisations like these are actually very hard to analyze properly unless you have the equipment isolated in a test environment and are able to accurately measure the improvements made. A score of 70+ out of 100 wouldn't seem all that bad to me anyway. I would urge you to track the performance of your site over time, just to make sure that you aren;t slowing down your site in pursuit of a "perfect" performance score! Paul
  19. I've asked the question in a similar thread recently, and I'll ask it again: What are you expecting as the benefit of removing those numbers from the urls? You must have huge expectations, since it seems to be a make or break feature for you. Paul
  20. While it's maybe not aesthetically ideal having id's in the "friendly" urls I can't see exactly why anyone would consider this a major "showstopper" of an issue. What exactly is the expectation regarding the amount of "improvement" that would be gained with these removed? You will not be able to "solve" this issue by making changes to the .htaccess file. Paul
  21. Mitchell, You need to process smarty tags using smarty, so in order for your code to work you need to place your code in a .tpl file and then render it via smarty. In saying that I wouldn't necessarily expect the above to cause it to crash. Have you configured php to write errors to a log file on your server? You should seriously consider doing so if not, as it will allow you to perform a post-mortem on the page load and see what errors php is throwing. Paul
  22. While I agree that that particular piece of advice (*ever* setting permissions to 777 willingly is just plain stupid anyway), which is repeated all over the place, is potentially the silliest I have ever seen (posted about it years ago...) you have to also blame PayPal for the confusion, as: Isn't true either.Well not entirely. If you don't set up IPN in your PayPal account at all, then the payment module can (and does) enable it per transaction - the other benefit of doing it this way is that you can have multiple web shops using the same PayPal account and taking advantage of IPN. Lack of documentation has always been, and still is, the biggest issue that Prestashop has. In saying that I don't think I've ever submitted it as a "feature request". Maybe we all should Paul Fellow mushroom
  23. Did you keep the config/settings.inc.php file when you "upgraded" or did you build a new version of your store from a fresh install? Changing the values (or generating new ones) in the settings.inc.php file will mean that your old passwords will no longer work, however if you replace the encryption keys in the new file with the ones from the previous installation it should work. This, of course, may not be your problem... Paul
  24. You should also NOT be modifying the classes/FrontController.php file at all, but providing an override as `override/classes/FrontController.php` The override file could be as simple as (untested): <?php class FrontController extends FrontControllerCore { function displayHeader() { parent::displayHeader(); $this->smarty->assign(array('HOOK_CENTER' => Module::hookExec('center'))); } } As mentioned you also need to add an entry in the database table, so you can actually use it. Paul
  25. See: http://www.prestashop.com/forums/viewthread/90061/integration/paypal_problems/
×
×
  • Create New...

Important Information

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