Traumflug

Writing this I see this usage of realpath() in the snippet cited above. realpath() returns a Windows path on Windows, see example #2 here: http://php.net/manual/en/function.realpath.php Using str_replace() with one string being a Unix path and the other one being a Windows path doesn't work, of course. Bug found :-)

Grepping around one can see this: sh config/defines.inc.php:70:if (!defined('_PS_ROOT_DIR_')) { config/defines.inc.php:71: define('_PS_ROOT_DIR_', realpath($currentDir.'/..')); Which means, _PS_ROOT_DIR_ includes the subfolder of the shop installation. This definition is used for local file accesses, like finding images, themes, such stuff. PS_BASE_URI is used for remote accesses, like generated URLs. It's the path appended to the domain for reaching the shop installation. Which means, if you can follow links on shop pages, PS_BASE_URI is set correctly. Put together, both of these definitions appear to be fine in your installation. If there is a bug, it's in this email generating code.

We cannot expect windows specific bugs will be addressed (like this one). Well, I don't really like to write this. Still it may help to understand what's going on. An empirical rule of thumb from the 3D printer world is that developers run some sort of Unix, while Windows is used by the clueless. Reality is sometimes sad. There are exceptions, of course. This has two implications, on top of the limitations mdekker mentioned already: Windows bugs don't get fixed because developers don't use this OS, so they're simply not aware of these bugs. Windows bugs don't get fixed because Windows users struggle to create useful bug reports, much less they manage to (or help to) fix bugs. That said, I'm pretty sure fixes for these Windows specific bugs are more than welcome. Or bug reports describing how to reproduce the issue at hand. @yaniv14 - I'm not sure whether it's a good idea to test on a Windows machine for a Linux production server. Ideally, test and production environments are as similar as possible. - If you think PS_BASE_URI should be /, well, change it. It's a setting changeable in backoffice (Preferences -> SEO & URLs).

It should work without using these constants, see https://alanhogan.com/tips/php/directory-separator-not-necessary. Well, with exceptions. As always with bugs: such issues have to be hunted down one by one. Going through hundreds of thousands of lines of code for evaluating each line would take years.

I think we need to handle directory separators in a way that work both linux & windows globally. PHP claims to do this already without requiring code to take care about it.

How this make i know, but maybe add this to core function? Sounds like a good idea. How about this? How to get this into official thirty bees? Well, fork the Github project, bring required code changes into this and make a pull request against branch 1.1.x.

Not to forget: multishops use the domain name to find out with which shop they should answer incoming requests.

It has always been this way, so it has to be right :-) I think the original idea was to avoid duplicate content. Y'know, like www.shop.com vs. shop.com, such stuff. Both get searched by search engine spiders and whoops, two sites instead of one. Then this stuff gets compared and dumb engines detect one shop stealing content from another. Also, having visitors spread over two domains produces links to either of these pages elsewhere and as links pointing to the shop are crucial for site ranking, it's a loss for both sites. Such stuff can be done in .htaccess, of course, but a few years ago presence of mod_rewrite wasn't a matter of course, so one couldn't rely on this. Now this redirecting is buried pretty deeply all over the code and can't be removed easily. Redirects happen everywhere, links get added everywhere, all of them absolute links. Also, some code for writing a proper .htaccess section (think of multishops, too) is required, of course.

Teaching the installer to use *automatic* as default value is certainly possible. Maybe it's even better, because it keeps the shop working for those who don't know about these SEO & URL settings, yet.

The pull request got merged! Now it's an official, upcoming feature :-)

Using overrides is a bad idea. They replace the entire class, which means one has to re-do them with virtually every new release. A much better strategy is to use hooks.

Actually there's Backoffice -> Advanced Parameters -> Configuration Information, which does these installation tests entirely without the installer. Just go to that page.

Thanks for the confirmation, @jnsgioia. Marking this thread and the Github issue as solved.

I've created a Github issue for this, so this well done problem description doesn't get lost: https://github.com/thirtybees/thirtybees/issues/252 Looking at the test file provided, it displays as .csv file above, but the link behind this is a .xls file. Surprise, surprise ...

I see no column active in your table, but a column Active (0/1). For a human it's easy to guess these mean the same, for a computer it's not. What happens if you rename that column to just active?

If this module introduces a class "PageCache" or "PageCacheCore", then yes, that's not wanted, but expected.

For transparency, add transparency to the color values (note the 8-digit numbers instead of the default 6-digit ones): Result (with probably too much transparency):

It's "EU Cookie Consent", right in the backoffice list of modules:

No, not sure. I mostly know this from seeing _PS_MODE_DEMO_ in many code files.

Trick #412: Add (please choose) as the first attribute and set available quantity with this attribute to zero. This way a customer can't order the default combination by accident. Adding such a first choice is obviously a worthwhile feature request: https://thirtybees.com/feature-request/

Annoy the customer who complains and say it does not work. If there's no 'add to cart' button, there's also nothing not working.

How do I know if the images were processed by ImageMagick or not? Regenerating thumbnails processes them. If you want to make sure they were actually processed by ImageMagick and not the simpler way, turn off IM first, regenerate thumbnails, note the exact size of a few images, then regenerate with IM on and compare with the previous sizes. JPEGs generated with different methods are always of slightly different sizes.

If these things require no payment I'd replace the "add to cart" button on the product page with the code snippet wakabayashi suggested. Requires some theme modifications (product.tpl), of course. I don't see a need to tweak FrontController. Virtual products can have files associated already, just the link has to move from the backyard to the product page. All the ordering machinery is never used then. @wakabayashi is it technically possible to use smarty variables in html? Yes, of course. That's the whole point of Smarty. If you mean "inside HTML tags", like <a href="{$product.download_link}" ..., then also yes.

There's a demo mode, accessible on the dashboard page in the upper right corner. AFAIK this disables stuff like completing a purchase.

@Traumflug is working on 1.7 theme compability. Don't expect anything soon. It's a complicated matter, especially the set of Smarty variables offered to templates. This set changed by some 90% between 1.6 and 1.7 and offering both depending on the theme version is a rather intrusive change.