Traumflug

This is the problem. Such a redirect shouldn't be there. And all HTTPS, please 🙂

I'm getting redirects as well: At back office -> Preferences -> General, did you turn on Enable SSL as well as Enable SSL on all pages ? IIRC this is the secret. The latter switch is on the list of getting removed, having sites with mixed security made sense 10 years back for performance reasons, but these days are gone.

Forgot a fourth round: images properly connected in the database, but the original image on disk missing. These report an error on thumbnails regeneration and should get removed from the corresponding product, along with a message to the merchant.

This should happen already. At least with discounts set in back office -> Customers -> Groups -> (edit). One can look up back office -> Customers -> Customers -> (click), in one of the panels is a list of groups a customer belongs to.

Also turn off the adblocker for the back office page. Can't do any good there.

Sounds like a universal hook module. All these triggers (should) have a hook already, the module apparently provides some simple way to connect some kind of code on them. I'd expect success of such a module to raise and fall with the way this "code" gets generated. Is it selecting from a list of predefined snippets? Is it moving some control boxes? Is it an actual code editor?

I fear it's not that simple. Each image has a database entry and each image in the database is connected to a product. A first round of cleaning would be to delete all images in the database not connected to a product. A second round of cleaning would delete all image directories on disk which have no corresponding database entry. A third round would delete image types not needed, as you do already. And I hope I didn't forget something with this description. Cleaning the database should be done not with handcrafted SQL, but by using the PHP class as far as possible. Database storage might change a bit in the future, using the class keeps code future-proof. Your idea of scheduling is fine. It's the simple part anyways, as long as code can execute in 3-second-chunks.

Maintenance tasks obviously require server resources, that's true. That's why ShopMaintenance runs these tasks only once a day and why they should get split into many small tasks. Not running these automatically means, however, most merchants never do this. I've seen a client shop (migrated from PS) with no less than 1.2 million stale image directories; just the directory and index.php inside, but no JPEG. For saving query results between requests one can store the result in a cache file, using PHP's var_export() for saving and require or require_once for restoring. Like done e.g. here: https://github.com/thirtybees/coreupdater/blob/master/classes/GitUpdate.php#L146-L173 . This isn't always faster, though, reading a file with 50.000 lines also takes a noticeable fraction of a second. For being less resource hungry, limiting requests to chunks of 100 or 1000 might be an option: http://www.mysqltutorial.org/mysql-limit.aspx

While there isn't much to see on Core Updater's configuration page, this doesn't look right either. There should be a message hinting to the new menu item. Filed here, hints on how to reproduce this always welcome! https://github.com/thirtybees/coreupdater/issues/4

Nice work! Did you notice class ShopMaintenance yet? It's method run() gets executed periodically (triggered by Ajax requests) and is designed to do exactly such cleaning jobs. Removing obsolete images would be a nice fit there. One problem not solved yet: how to search huge file trees in time-limited chunks. No matter how big the tree is, the search should return after three seconds and pick up next time where it left on the previous run. If you could form your code to make it fit into ShopMaintenance I'd happily add this to thirty bees core.

Field for the VAT number should appear as soon as a company name gets entered. That's done by JavaScript and as such, part of the theme. For B2B shops it might be a good idea to always show this field. The idea of hiding it is to reduce the visual complexity of the page, because most B2C customers don't have a company.

In all shops using Page Cache I migrated to far, performance was considerably better than before, without this module and without turning on full page cache. This is my current release test installation in Chromium, with just Smarty cache and CCC turned on on an old Core2Duo server for a full reload of a product page: With a load time of just 0.35 seconds for the base document (that's where full page cache kicks in) it's hard to imagine this can get substantially better. Remaining load time is loading pictures, CSS, JS and processing that in the browser.

If you'd give us a list of the steps required to reproduce this, we could try. As if one would try to explain it to a child: - Click here - Enter this value in that field - Click there - ...

Thanks for the report. I just released an update, should also appear in your back office: https://github.com/thirtybees/donationminer/releases/tag/1.1.0 Which means: BIG thank you to all those merchants trying to increase thirty bees' income, but this module didn't work out (still it was worth trying). It generated less than $1 income/month for all users together, IIRC.

A backslash? That's Windows, isn't it? The solution is to run thirty bees on a supported operating system, like Linux, *BSD or MacOS. Alternative is to debug and fix this yourself. I'm not aware of a thirty bees developer using Windows, so you're predestined to do this.

Just found a regression, or at least a behavior distinct to PS. If there are two (or more) multishops where one shop URL is contained in the URL of another shop, like https://shop.com/ https://shop.com/centre thirty bees would find the first one, while PS found the second, longer one. Not sure whether this applies to the case here, nevertheless thirty bees behavior now matches PS behavior again. This change will go into the next release.

If a customer can log in as another customer s/he can order as that other customer, of course. Adding and address is possible, of course, customers can have many addresses.

Somebody asked where thirty bee stores URLs in the database. It's table shop_url. Location of code files are evaluated on the fly, see https://github.com/thirtybees/thirtybees/blob/1.0.x/config/defines.inc.php#L70-L72 And there might be a file config/defines_custom.inc.php overriding this. This file neither comes with the distribution nor does it get created by thirty bees, but it gets read if it's there.

4 hours ago, Havouza said: But can I do the same search using only Grep via ssh? How? Much easier than with some GUI tool: grep -rn jv74.se

Simply running the installer gives more reliable information about this. It does all required tests as well.

A known issue: https://github.com/thirtybees/thirtybees/issues/776

This can happen, yes. Some back office pages also list uninstalled modules, so they obviously have to load the main code file of uninstalled modules as well. If this main code file of a module is broken enough to interrupt PHP, this back office page doesn't load. All this doesn't apply to your situation, though. You can list these modules already, so all the module main code files load fine. Removing some of them can't make the situation worse.

Pretty much, yes. Modules not installed get listed in the module list, but not called when displaying other pages. Impolite code can load and call a module directly, of course. But for this to happen, this code has to be aware of the module and deal with the case of it being absent. thirty bees core code doesn't do this (if you find code doing this, it's a bug). With this in mind, cleaning modules is a simple (and boring) procedure: Make sure the module is not only disabled, but also uninstalled. Remove it from the modules directory. Easy way is to use Delete in the provided menu. Slightly safer way is to move the module folder into a different directory (e.g. modules.off).

thirty bees wants allow_url_fopen to be enabled. That's the PHP default, but apparently somebody turned it off on your server. See https://www.php.net/manual/en/filesystem.configuration.php

Thanks for reporting! Filed in the issue tracker to not forget this: https://github.com/thirtybees/thirtybees/issues/914