the Save (and Stay) button spinning after adding an override

[luksl]

I need more product fields so I've created an override as is described here: https://www.teapot.co.uk/adding-new-field-products-prestashop-1-6/ . After adding the override, the button Save (and Stay) is just spinning. Sometimes it's not spinning on a product which have no custom field filled yet but once I fill the field and Save the change, the button is spinning ever since. I used the override on a fresh install of TB 1.01. This override seems to work with PS 1.6.1.12 with no problems. I am using XAMPP 7.013, Chrome and Firefox.

[luksl]

It seems when Template compilation = Force compilation Smarty compilation usually fails at different templates (files).There is such an error about 4 of 5 savings. Here is Log file (from TB root Log directory): 0149699321160420170608_exception.log

There are "unable to write file" errors too. It´s strange as I run Xampp as the Admin with full rights.

I have noticed there are mixed slashes in paths and I guess it could be the problem.

[yaniv14]

@mdekker I've noticed similar issue on windows with mail translations that seems to be related to path output with backslash and forward slash combined. I think we need to handle directory separators in a way that work both linux & windows globally.

[Traumflug]

I think we need to handle directory separators in a way that work both linux & windows globally.

PHP claims to do this already without requiring code to take care about it.

[yaniv14]

Yes, I know that PHP have it. But are we using is in TB code? DIRECTORYSEPARATOR, PATHSEPARATOR .....

[Traumflug]

It should work without using these constants, see https://alanhogan.com/tips/php/directory-separator-not-necessary. Well, with exceptions.

As always with bugs: such issues have to be hunted down one by one. Going through hundreds of thousands of lines of code for evaluating each line would take years.

[luksl]

@mdekker @Traumflug Now I´m a bit confused. If I understand well in case I want to use TB for my project I just have to use Linux (at least virtualized). We cannot expect windows specific bugs will be addressed (like this one). Is TB intended just for Linux?

[luksl]

@mdekker That´s reasonable. Concerning this bug... will someone adress it? If the bug is caused by mixed slashes in paths it might not take much time if you know what you are doing. :-)

[yaniv14]

@mdekker I don't believe that anyone will host a production TB site on windows server. But in my case (and probably for few others) I use wamp server to run local PHP development, and it would be nice to finish it completely locally before uploading it to linux server for production. I dont think there are too many windows bugs (I did more than 30 PS shops in the last 5 years with the same bugs, or worst), and I believe that most off them have a related issue that once fixed in one place will take care on all of them. In my case, I wasn't able to install TB Blog locally, and wasn't able to translate email templates (those are the only 2 things that bothered me on a certain shop I did). I had to do both of them on the production server. I don't know if it will helps but I know that on wamp server you create a folder for the shop, and then PSROOTDIR is like: 'C:\wamp\www\tbshop' But then the PSBASEURI is '/tbshop/'. when looking at the translation controller: $emailFile = strreplace(PS_BASE_URI, '', _PSROOTDIR.'/').$email; i am getting the base uri twice: 1 from the strreplace and the 2nd from the $email (PSMODULEDIR_) I am not sure it this will lead anywhere.

[Traumflug]

We cannot expect windows specific bugs will be addressed (like this one).

Well, I don't really like to write this. Still it may help to understand what's going on. An empirical rule of thumb from the 3D printer world is that developers run some sort of Unix, while Windows is used by the clueless. Reality is sometimes sad. There are exceptions, of course.

This has two implications, on top of the limitations mdekker mentioned already:

• Windows bugs don't get fixed because developers don't use this OS, so they're simply not aware of these bugs.
• Windows bugs don't get fixed because Windows users struggle to create useful bug reports, much less they manage to (or help to) fix bugs.

That said, I'm pretty sure fixes for these Windows specific bugs are more than welcome. Or bug reports describing how to reproduce the issue at hand.

@yaniv14 - I'm not sure whether it's a good idea to test on a Windows machine for a Linux production server. Ideally, test and production environments are as similar as possible. - If you think PS_BASE_URI should be /, well, change it. It's a setting changeable in backoffice (Preferences -> SEO & URLs).

[yaniv14]

And what if its not a windows only issue (the mail translations)? I mean it seems to me that the path to the email template is wrong when working inside a sub folder as base uri. Now wamp server always works like that but on production server I never used a folder to install TB or PS. Can you please confirm that translation for email template works when TB installed inside a folder (www.yourdomain.com/shop/) on a linux server.

[Traumflug]

Grepping around one can see this:

sh config/defines.inc.php:70:if (!defined('_PS_ROOT_DIR_')) { config/defines.inc.php:71: define('_PS_ROOT_DIR_', realpath($currentDir.'/..')); Which means, _PS_ROOT_DIR_ includes the subfolder of the shop installation. This definition is used for local file accesses, like finding images, themes, such stuff.

PS_BASE_URI is used for remote accesses, like generated URLs. It's the path appended to the domain for reaching the shop installation. Which means, if you can follow links on shop pages, PS_BASE_URI is set correctly.

Put together, both of these definitions appear to be fine in your installation. If there is a bug, it's in this email generating code.

[Traumflug]

Writing this I see this usage of realpath() in the snippet cited above. realpath() returns a Windows path on Windows, see example #2 here: http://php.net/manual/en/function.realpath.php

Using str_replace() with one string being a Unix path and the other one being a Windows path doesn't work, of course. Bug found :-)

[Traumflug]

Searching for a more general solution raises the question about which paths to use:

1. Store Unix paths on Unix; Windows paths on Windows. This requires to strictly distinguish between filesystem paths and URL paths. ~~PS_BASE_URI would become \tbshop\ on Windows.~~ It also disallows copying a Windows installation to a Linux server (would require to change all DB stored paths).
2. Store Unix-type paths only, but use Windows paths for display purposes. Still complicated, because paths have to be converted for display, and converted back when reading paths entered by the user.
3. Keeping all paths Unix-type, even for display purposes. In this case users have to take care of the conversion, e.g. when entering a path in a backoffice field.

Options 2. and 3. forbid the usage of realpath(). Currently that's used in 174 places. Often apparently out of convenience, e.g. realpath($currentDir.'/..') could be replaced by dirname($currentDir) easily. It's non-trivial, e.g. there's a hint in the example at http://php.net/manual/en/function.dirname.php that dirname() gives a different result on Windows, too. Even if this function doesn't verify a given path against the filesystem.

@yaniv14, what do you think?

[yaniv14]

Like i said before, I didn't notice too many windows only issues with shops i've created. So I guess we can handle each bug at the time. I was able to make the translations work on windows. Tell me what you think.

Original function: ``` public static function getEmailHTML($email) { if (defined('PSHOSTMODE') && strpos($email, PSMAILDIR) !== false) { $emailFile = $email; } elseif (PSBASEURI != '/') { $emailFile = strreplace(PS_BASE_URI, '', _PSROOTDIR.'/').$email; } else { $emailFile = PSROOTDIR.$email; }

$emailHtml = file_get_contents($emailFile);

return $emailHtml;

} ```

New function: ``` public static function getEmailHTML($email) { if (defined('PSHOSTMODE') && strpos($email, PSMAILDIR) !== false) { $emailFile = $email; } elseif (PSBASEURI != DIRECTORYSEPARATOR) { $emailFile = strreplace(strreplace('/', DIRECTORYSEPARATOR, PSBASEURI), '', PSROOTDIR.DIRECTORYSEPARATOR).$email; } else { $emailFile = _PSROOTDIR.$email; }

    if (file_exists($emailFile)) {
        $emailHtml = file_get_contents($emailFile);
    } else {
        $emailHtml = '';
    }

    return $emailHtml;
}

```

[roband7]

Interesting, looks like we might be hitting two bugs that have been discussed in the forum here: Windows installations Subfolder installations

Perhaps we can kill both bugs with these fixes?

I agree on @yaniv14 approach for a short term 1.0.2 type fix, things mostly work, just attack the few problems left one by one.

@Traumflug approach would be the way to go for a release 1.1 type bigger cleanup fix. That one will not be easy.

[Traumflug]

@yaniv14

Tell me what you think.

Well, can't say. It's good for one of the strategies, wrong way for others. I prefer to work with a target in mind, else individual changes tend to pull in different directions.

@mdekker Well written code needs no distinction between Windows and non-Windows. PHP already abstracts this away. It just happens that current code violates this abstraction.

[luksl]

@mdekker @Traumflug @yaniv14 I have found another problem connected with this/an override. It seems when I extend ProductCore class with Product class in override/classes/Product.php: ``` <?php

class Product extends ProductCore { public $kod_vyrobce;

public function __construct($id_product = null, $full = false, $id_lang = null, $id_shop = null, Context $context = null)
{
    self::$definition['fields']['kod_vyrobce'] = array('type' => self::TYPE_STRING, 'validate' => 'isGenericName','size' => 25);
    parent::__construct($id_product, $id_lang, $id_shop);
}

}

?> ```

Any product front page shows like this: ``` Array ( [0] => Array ( [file] => D:\Dev\xampp7013\htdocs\tb10_test01\classes\Product.php [line] => 610 [function] => displayError [class] => ToolsCore [type] => :: [args] => Array ( )

    )

[1] => Array
    (
        [file] => D:\Dev\xampp7013\htdocs\tb10_test01\classes\Product.php
        [line] => 465
        [function] => getPriceStatic
        [class] => ProductCore
        [type] => ::
        [args] => Array
            (
                [0] => 5
                [1] => 
                [2] => 
                [3] => 6
                [4] => 
                [5] => 
                [6] => 1
                [7] => 1
                [8] => 
                [9] => 
                [10] => 
                [11] => 
                [12] => 0
            )

    )

[2] => Array
    (
        [file] => D:\Dev\xampp7013\htdocs\tb10_test01\override\classes\Product.php
        [line] => 10
        [function] => __construct
        [class] => ProductCore
        [object] => Product Object
            (
                [kod_vyrobce] => 0
                [tax_name] => deprecated
                [tax_rate] => 21
                [id_manufacturer] => 1
                [id_supplier] => 1
                [id_category_default] => 11
                [id_shop_default] => 1
                [manufacturer_name] => Fashion Manufacturer
                [supplier_name] => Fashion Supplier
                [name] => Array
                    (
                        [1] => Printed Summer Dress
                        [2] => Printed Summer Dress
                    )

                [description] => Array
                    (

``` etc.

I don´t know if it´s another bug or bug connected to the slashes problem/paths on Windows.

The override is working fine with PS 1.6.1.12 on Windows.

There are errors reported in PHP log like this one: [13-Jun-2017 10:11:06 Europe/Prague] PHP Fatal error: Class 'ProductCore' not found in D:\Dev\xampp7013\htdocs\tb10_test01\override\classes\Product.php on line 3