Traumflug

This URL looks entirely fine. I'll have to look at this myself.

I'd consider this to be a broken hosting. Especially when returning 503 instead of just queuing/delaying requests. 15+ simultaneous requests isn't that unusual, could be 20 images on a static page as well.

Could you copy the URL of this not existing page into here, please? If there's something like 'adminXYZ' inside, where XYZ are some random characters, please remove them before posting. Also, did you move the shop in the file system, perhaps? Like renaming its folder or moving it into another folder? One can do this, but there's some extra work required. Renaming the shop is a bit hidden. Go to back office -> Preferences -> Store Contacts, then scroll down the page, there's a tab "Contact Details". First line is the shop name.

Bonus points if you tell us the name of this plugin 🙂

Setting up about 20 carriers (one for each variant) should do this. All these carriers can have the same icon and (AFAIK) even the same name, so customers barely recognize the distinction. And I wouldn't be surprised if eBay does it the same way, just hides this from merchants. Go to back office -> Localization -> Zones and set up a zone with just Ireland. Then set up a carrier which ships to just this zone (the just created zone will appear there), set billing to "According to weight" and limit weight to >= 0.00 kg and < 1.00 kg. For having a distinct carrier for other (cheaper) products, one has to define another carrier with the same settings (except price). On the "Shipping" tab of each product one can set which carriers can ship the product. Select only the ones you want. On cheap products, select the carrier(s) for cheap products, on expensive products select the carrier(s) for expensive products. It's certainly some work for all the combinations possible, but the fine grained control needed for this kind of setup is there.

That's exactly the problem. I take it's futile to tell people that one can't cache dynamic pages as long as there are guys promising miracles. Some merchants have to learn by experience.

Yet another attempt missing the point. Most shop pages are dynamic for a reason, not because programmers are too silly to make them static. We had extended discussions about this with the full page cache, featured directly by thirty bees. Before putting such a module into production, make sure it always gives the expected results, even when using it as distinct customers, from distinct countries, with distinct currencies, with distinct languages, with distinct cart content, with changed featured products, with changed prices, with distinct vouchers, and so on.

While I couldn't reproduce the exact case you describe, this patch indeed removes some odd distortion of the manufacturer description. Probably code which was useful before HTML for these descriptions was introduced. Picked to 1.1.x to get it into the next release, see https://github.com/thirtybees/thirtybees/commit/cba15288e79dc724ea237f78b40e2151bd7140f9

Let's not forget this: https://github.com/thirtybees/thirtybees/issues/1077

Regarding improperly uninstalled modules: residuals in the database are usually harmless. More crucial are not uninstalled overrides, which one can find and uninstall with this module: https://github.com/thirtybees/overridecheck/releases

Got it. This small change to Core Updater fixes it: https://github.com/thirtybees/coreupdater/commit/56ef3e2e1eb0e7ab9175477d9365ae33e6167a4e

The workaround is to shorten the browser window. If I had code to fix this issue, I had committed it already 🙂

A '@' is mandatory part of an email address, obviously. Perhaps you could give us a few examples of addresses which should work, but don't.

This is (kind of a) syntax error message and usually easy to solve. Surprise here is, why was this message found now, while dozens of shops use this module already?

Uhm, nice code, but it solves a not existing problem. Code for properly handling long menus is already there. ... except for browser windows of a certain height. Making the window a bit shorter puts submenus not under, but to the right of the parent menu item on hovering, keeping everything available: Rather than adding yet another interface item to this already pretty complex menu handling code I'd much prefer to fix this length calculation problem. Didn't come around to do it myself, yet, as the workaround is so easy.

I just tried, the server appears to work fine. Could you simply try again? Maybe you've hit a weak spot. Updating multiple times, even after failures, should work fine and give the expected results. If it still doesn't work I'd need access to the server to find out why these packages arrive empty.

This is the fix: https://github.com/thirtybees/niara/pull/17/commits/0d91e2cc3a585cbd998c9b2caf295a6a6f3d5fef The translation is there, just well hidden. The fix moves it into the right place.

It's better to change it to just "home". Then this module works for other themes as well.

Did you try to edit php.ini, like I described in an email to you? No idea which kind of "security issue" they have in mind, it's just a shortcut for more complex web requests. One can easily write code doing the same without this feature enabled, and most of thirty bees' code already does. thirty bees 1.0.7 doesn't test for it on installation, still uses it in a few places.

File manager isn't a back office controller, so it can't get put into a menu item. However, wherever one can edit page content, the editor for this field has a button to open this file manager.

Obsolete files are usually harmless. Only a few exceptions, like template overrides, change behavior. The file you found is apparently a log file generated by some non-thirty-bees code, so it'd be better to look into it, act on the error reported as necessary, then to delete it.

If it's a developer installation, one usually has to deal with web server and you running as distinct users. Which means, files created by them also get distinct privileges. One can deal with this automatically using extended access control lists (ACL): http://jump-ing.com/traumflugs/github_best_practices#file_permissions

Opt-Out ist weiterhin in Ordnung. In diesem Verfahren ging es um ein Cookie-Banner, bei dem der Haken bereits gesetzt ist und das Banner so quasi zu einem Opt-In macht. Denn man muss den Haken aktiv entfernen, um Cookies zu vermeiden.

See themes/niara/sass/partials/_footer.scss, change it, then rebuild the theme. If you don't want to rebuild the theme, see #footer in themes/niara/css/global.css

There were quite a few missing 😳 https://github.com/thirtybees/thirtybees/commit/3ca6967dc8c44badd7e1d8b455320f6660a87b91