Jump to content

Welcome, Guest!

By registering with us, you'll be able to discuss, share and private message with other members of our community.

Traumflug

Administrators
  • Content Count

    1,319
  • Joined

  • Last visited

  • Days Won

    35

Posts posted by Traumflug


  1. 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:

    577486265_Bildschirmfotovom2019-10-0912-39-24.png.69ad47375d566f64a03c18fad593b945.png

    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.


  2. 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.


  3. 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.


  4. 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.


  5. 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.


  6. 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 🙂

    • Like 1

  7. 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.


  8. 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
    

  9. 2 hours ago, datakick said:

    I've just checked @Traumflug's commit, and it did not fix the problem at hand.

    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.


  10. 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.


  11. On 9/16/2019 at 11:14 AM, datakick said:

    it looks to me that a large percentage of windows related issues could be fixed if the _PS_ROOT_DIR_ and _PS_CORE_DIR_ core constants were defined with the forward slash.

    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.

×
×
  • Create New...