Jump to content

Skipper

Members
  • Posts

    27
  • Joined

  • Last visited

Skipper's Achievements

Newbie

Newbie (1/14)

0

Reputation

  1. Nah, no crashes. Sort of disappointing, all runs well.
  2. http://www.ebrueggeman.com/article_php_image_optimization.php And because you mention it: I know about image compression. And I also know that most people don't know anything about PPI and DPI. Have you checked gigo ?
  3. PS uses standard PHP functions for image manipulation, so it is sufficient that you have someone change PHP. Or do it yourself, of course. Another possibility is to upgrade your PHP to a higher version, maybe. And make sure that GD is enabled. Check /images.inc.php to verify that there is no hidden or mysterious parameter playing tricks on you. Maybe you just have a gigo problem.
  4. Better do a deep copy of /themes/prestashop/ to /themes/whateveryouwant/ and set the theme to 'whateveryouwant' in the backoffice of PS. Then work on 'whateveryouwant'. If you change the 'prestashop' theme, you risk, no, you'll lose, your changes on the next upgrade of the shop software.
  5. Paul is right. Pixel dimensions is all that is needed for an online shop. The DPI, or more correctly PPI, are defined by the screen's hardware and are invariable, just like the DPI depends on the printers hardware. PPI typically varies between 72 and 85. If the perceived image quality decreases, then I would dare a bet that this is a problem in either the quality of the original image or in the concert between image resize dimensions and the template code, or more precisely the size parameters.
  6. Below is what I did to get S/M/L correctly: 1/ Add a field position to the database : ALTER TABLE `ps_attribute_lang` ADD `position` TINYINT NOT NULL DEFAULT '0' AFTER `id_lang` ; 2/ Modify the fields 'position' in table 'ps_attribute_lang' using phpmyadmin to fit the row order. Smaller numbers will show first. Personally, I find the ps_attribute_lang not the right table, it should probably be in ps_attribute, but I was too lazy. 3/ Change the file /classes/Attribute.php : Find function getAttributes($id_lang, $notNull = false) and change ORDER BY agl.`name` ASC, al.`name` ASC'); to ORDER BY al.`position` ASC, agl.`name` ASC, al.`name` ASC'); Done. A simple refresh will probably not show the new order because Smarty's caching does not catch this. Try with another product instead.
  7. That is really funny "Frequent bug fixes" as a feature. You can not fix bugs faster than you introduce them. When will 1.3 come ? Waiting for new bugs ...
  8. Each time you (the shop owner !) look at a product, a category, whatever ... your page counters get increased, and you polute your own statistics. For the view counts, these steps get yourself out of your way: First, add your backoffice's maintenance IP address into the backoffice preferences. Then add the following lines right after the { of public static function setPageViewed($id_page) in file /classes/Page.php /* Skipper : don't update stats for the backoffice computer */ if($_SERVER['REMOTE_ADDR'] == Configuration::get('PS_MAINTENANCE_IP')) return;
  9. True. I didn't even try to decipher this after a good sleep.
  10. Ajoutes #attributes select { font-size: 12px; } dans ton global.css, par exemple /themes/prestashop/css/global.css, et changes le font-size selon tes besoins.
  11. Check if the products, which you call "locked", have attributes. I guess they have. Stock levels are either at product level or at attribute level, which makes sense for most cases.
  12. Unless someone smarter than me has a different opinion, I'd say that tweaking PS into this functionality would be tricky, to say the least. Have a look at the Avactis shopping cart instead. This cart has builtin possibilities to convert any existing site into an online shop, ie. add buy buttons without redesigning the site, still with full featured backoffice and administrative functions. Open Source, of course, but only free as in "free as freedom", not free as in "free as free beer".
  13. Boran, FirePHP is just like syslog, only to the browser. Which makes it particularily useful for webdevelopment. I have never noticed any performance hit, at least not on the server. For the client, this is a different story and depends on the amount of log data. Upgrades are a different subject, at least to me: - First of all, and in this specific case, I consider PS extremely bad written from that point of view. As long as templates are splattered all around, most notibly in the modules, PS customization is heavily restricted. PS is using OO, but offers no way to safely extend objects. PS offers a bugtracker, but no feedback about fixes. Stable releases are declared to be "free of significant bugs". The list goes on ... only to say that you should find a organizational solution to the technical shortcomings. My solution is a multi-stages git. I have the stable in trunk, branch into "changes" and work there. At a next stable, I make a diff between former stable and "changes" and try to apply the diff against the new stable. I recommend git over subversion because branch operations are far cheaper and faster. Keeping debug statements is a strange idea to me: I debug when I have a problem, once fixed I don't need them anymore, so I kick them out. If you want to keep info, dump them to a file. If you want permanent, but not necessarily continuous access, and have server access, then look at something like nettail, whick you can find on Gna.
  14. I swear by a Firebug PHP extension http://www.firephp.org
  15. why aren't all characters in product and category names allowed? What's wrong with having a #-sign in a name. artistic liberty of the programmer or lazyness to properly escape the database queries? just curious ... for the records, the file /classes/Validate.php, function isCatalogName() is the culprit. I took the # out and am now waiting for the crash.
×
×
  • Create New...

Important Information

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