Traumflug

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.

:thumbsuptone4: for doing such a video! :thumbsuptone4: for showing how to clone a shop and for working on that clone! :thumbsup_tone4: for the module doing the migration so seamlessly! To those who have a clone already or want to try on a test installation: start at 10:20 in the video.

That said, as a good merchant I should have offered you to implement all four features, take the cash for all of them and implement only the one needed thing.

Right. So you don't want an entire module, but enhance the existing module to allow subscriptions as well. Split payments are (hopefully) transparent to the user, so no module change required. Invoices can be done by 30bz, so no change required either. Entirely different perspective for a developer.

@Havouza now I only need a programmer to make the module https://docs.payza.com/reference#prestashop