Traumflug

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

Got it. @veganline kindly gave me access to the server. The TLSv1.2 message is a red herring. Test fails, but it's an optional test, which doesn't prohibit installation. Actual issue was a missing error message. The test for ensuring PHP's fopen() takes URLs failed, but didn't report an error, because there is no matching error message. Setting allow_url_fopen in php.ini to 1 should allow installation. And I'll add the missing error message to the sources, of course.

Without looking it up, I'd guess it indeed renames it from 'admin' to something else. This happens right after installation and the user gets notified about this. No idea why people would want to rename this folder to something less safe, like 'admin'. Just don't do it. Renaming it to something not starting with 'admin' breaks a shop installation as well. Don't do this either. It's an e-commerce software, not a funny-user-idea-healing toy 🙂

P.S.: I'd also download a few images and open them in an image viewer to find out whether they're actually JPEGs (or PNGs with suffix .jpg). I've seen shop installations where properly named files were there, but none of them being actual images.

Looking at this page, one image is missing: https://product.solutions.org.nz/remote-car-alarm-with-central-locking-and-engine-disable Digging a bit deeper, this is the image URL: https://product.solutions.org.nz/194-community-theme-default_cart_default/remote-car-alarm-with-central-locking-and-engine-disable.jpg This URL looks fine to me. Shop is apparently using theme community-theme-default, this theme has the old image type names (with _default), so that's what's expected. Also, some other images work, which makes a glitch in image finding unlikely. Broken code usually applies to all images, not just a few. I'd start looking at which images are actually on disk. This image should be in img/p/1/9/4/ and next to index.php and the original file, 194.jpg, there should be one additional file for each image type. Similar to this (this is for image no. 21): 21-community-theme-default_cart_default.jpg 21-community-theme-default_home_default.jpg 21-community-theme-default_home_default_smaller.jpg 21-community-theme-default_home_default_smallest.jpg 21-community-theme-default_large_default.jpg 21-community-theme-default_medium_default.jpg 21-community-theme-default_small_default.jpg 21-community-theme-default_thickbox_default.jpg 21.jpg 21-Niara_cart.jpg 21-Niara_home.jpg 21-Niara_home_smaller.jpg 21-Niara_home_smallest.jpg 21-Niara_large.jpg 21-Niara_medium.jpg 21-Niara_small.jpg 21-Niara_thickbox.jpg index.php

Well, it fixed the problem I found in my development installation. Looks like there's more than one problem involved here. Or I fixed something else, not the issue here.

Excellent analysis! This timestamp was introduced here: https://github.com/PrestaShop/PrestaShop/pull/4267/commits/1e1932559758ce989a8d42d931fd650043234d21 to fix this bug: http://forge.prestashop.com/browse/PSCSX-7050 Such a timestamp doesn't make sense to me. Each image has an individual number, there should be no caching issue (unless one changes the image on the command line or by FTP). I've reverted this commit, which results in loading the right picture. On Bleeding Edge -> 1.1.x in ~10 minutes.

That's actually by design and was removed intentionally: https://github.com/thirtybees/niara/commit/5991643b278f4f0343dc7e90957984013a6db98f Merchants usually want visitors to buy something, so having a delete button looking almost like a close-dialog button isn't too helpful.

This sounds like a good idea. Along with all the usages of realpath() @musicmaster mentioned. Catching issues at the root instead of dealing with them on each instance. Certainly quite some work, but not too hard to do.

Alright. Now we have not one, but two solutions. Solution 1 is another fallback for image types: https://github.com/thirtybees/thirtybees/commit/ba81aad0667658f1f083f8a4a033442bbd4526d2 This loads these images without any change to the theme or the module. Inspired by @datakick's pull request, but only for these fallbacks (I'm not sure which implications the other place might come with). Solution 2 is a fix in the theme, of course: https://github.com/thirtybees/niara/commit/df3c7f79af47ba7dde4454c990d041cc096722f8 Yes, it's that simple. Just replace 'medium_default' with 'medium' in the theme's template. Apparently this spot got forgotten when image types got renamed. And then there are improvements like this (templates of the module and both themes): https://github.com/thirtybees/niara/commit/dd798ad52c103c9e97bd7cf1b0f2bc910f084b27 which move definition of the image entirely into the template and accordingly, into the theme. Defining certain images in PHP as well as in the template doesn't make much sense. For one it's error prone, because the other definition is often out of sight. For two, only the theme template knows which image type fits the theme best. P.S.: these fixes took a while, because my first attempt was to search the best matching image type in PHP: https://github.com/thirtybees/blocknewproducts/commit/58c1069a7b595578f6cf3f5b792a821168e4deb3 https://github.com/thirtybees/blocknewproducts/commit/54708c09a550233db4cc556ea93ed75138f64d47 ... until I recognized that a module can't really know what a theme wants. Sometimes one has to implement something just to find the just written code to be suboptimal. A learning experience.

There is no polemics, just respect to your wishes. You explicitly want broken code and to get this, moving on to PS 1.6 is the best way to proceed.

I think the fallback can catch even these. It just needs a bit more fantasy about how module developers break code.

@Occam, please use PS 1.6. Or better PS 1.5. There is all the broken code you desire so much.

Excellent!

No worries, this is for developers understanding how fallbacks work.