Traumflug

Jungle drums say, Google still ranks layouts with exactly matching image sizes higher than those using one downloaded image for all these small representations/icons. If you changed your theme to get away with fewer image types, don't hesitate to remove the no longer needed ones from the list. Bonus points for also removing them from the theme's config.xml (which gets read at theme installation time, only).

It simply shouldn't matter which image type names a theme uses. There's a database table storing these image types and the whole point of this table is to allow changing these names. A theme can define any image type name it feels a need for. This was "always" the case. Since 1.1.0, the theme name gets prefixed to this image type name. Code for this was also "always" there, it was just entirely broken. With this code being fixed, thirty bees allows now distinct image types in distinct themes. thirty bees features multishop, each shop can have a different theme and each theme can have its own idea of image sizes. Image type 'home' in theme 1 can have an entire different size than image type 'home' in theme 2, after all. And then there are modules entirely ignoring all this and hardcoding image names, as if there was always just one shop, just one theme and this theme always had defined image types the module wants. A static world view, just like 1990. Care was taken of these hardcoded image types as well, of course. Requests for images not existing on disk get forwarded to PageNotFoundController, which then tries to find the best match actually existing. Last resort of this controller is to send this camera image, so in the case discussed here it apparently gets activated as expected. Apparently there's a situation possible where the fallback mechanism doesn't find what it could find. Debugging can start in these two locations: https://github.com/thirtybees/thirtybees/blob/1.1.x/controllers/front/PageNotFoundController.php#L57 https://github.com/thirtybees/thirtybees/blob/1.1.x/classes/ImageType.php#L241

thirty bees has no kernel an never publishes release dates.

Mauro found two glitches in the code: https://github.com/thirtybees/thirtybees/pull/1043 Cheers to him!

Does it continue to work if you turn the cache back on? Or don't turn it off, just reload the page using the reload button? It might be a stale tools.js, which would be a one-time problem.

https://github.com/thirtybees/thirtybees/issues/1047

Yupp, sieht nach einem Problem im Theme aus. Beim alten Theme klappen die Klicks auch nur, wenn man direkt auf den kleinen Kreis klickt. Auf den Text daneben klicken reicht nicht. thirty bees 1.1.0 kann übrigens auch das alte Theme. Einfach unter Voreinstellungen -> Themes umstellen.

"Blutige Liebe". That's how it got translated to German 🙂

https://github.com/thirtybees/thirtybees/issues/1046

This sounds like a bug where the variable for price rounding precision is missing/empty/forgotten. Filed here: https://github.com/thirtybees/thirtybees/issues/1044

Uhm, what is the point of doing this? Updating v1.0.8 to v1.1.0 is pretty simple and straightforward.

The nice thing about the newer updater is, one can reverse updates. If the newer version doesn't work out, just do this, "update" from 1.1.0 back to 1.0.4.

First thing would be to update to 1.1.0.

https://github.com/thirtybees/thirtybees/issues/1031

It should work. If not, it's a bug.

Them saying this can well mean "we didn't even try". Quite a number of PS developers apparently fear new customers using thirty bees. For hardly imaginable reasons, because thirty bees is as compatible as another software can be, sometimes even more compatible than PS its self.

Do you need module "cheque"? If not, uninstall and delete it. Uninstalling and deleting unused modules is generally a good idea. This brings a small, but existing performance advantage over just disabling it.

I think that's called updating and yes, there is a module, of course. It's called "Core Updater" and available in the list of modules in your back office.

We have no magic crystal ball to see which module you mean and how these messages differ from expected messages.

It is already fixed. Thanks, @datakick.

I'd be keen to learn what "failed to load properly" exactly means. We have no magic crystal ball here where we can see what you did, on which page, where you clicked, how the screen looked, which messages appeared, and so on.

Found it: it's a setting in back office -> Localization -> Countries -> (edit country). Which means, one can enable/disable this label for each country individually.

I wonder why you see this at all. A default installation doesn't show this label: https://front.thirtybees.com/gifts/soap

Core Updater is pretty advanced software updating technology and has shown to be quite helpful since it was released. Merchants lost fear to update their shop installation as they can roll back easily. Great! This way, developing the software actually makes sense, merchants can take advantage of all the new stuff. There was always a pimple in the picture, though: provided releases had to be added manually by a thirty bees developer. As so often, stuff to be done manually easily gets forgotten. No longer: over the recent weeks, Core Updater's background machinery has learned to build releases automatically. This is especially helpful for Bleeding Edge: the minute a change gets committed to the Github repository and passes validation, it appears in all the shop back offices. Can't get forgotten, always accurate (knock on wood). Another new thing appeared: issue branches. When tackling issues reported on Github, developers often want to show partial work or provide completed work for testing. Maybe they just add debug messages to find out what's going on in a shop installation. Now they can commit this work as issue branch, merchants will find it in the Bleeding Edge channel in Core Updater listed. Merchants update to this, test, report back their opinion in the issue tracker. Easily fast enough (~6 minutes after push) to allow timely discussions on how to implement this or that the best way. Note to developers: an issue branch is a branch named with exactly 'issue-' (including the dash), followed by a number consisting of digits only. This number should match the Github issue number. Enjoy! P.S.: this is available immediately, no upgrades or whatsoever needed 🙂

The original idea of payment modules was to have one module per payment method, hence restrictions per module. One module handling a plentitude of methods wasn't on the screen a few years back. Regarding your issue, it looks much like beefing up price rules a bit could accomplish that. These are well equipped with conditions already, they just don't allow raising the price ( = negative discount). Can't promise a timely solution, though, our stack of feature wishes is huge already, on top of 100+ known bugs (which are considered to be more crucial to fix). And everybody considers his particular issue as the must have, of course 🙂