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.

  • 0
luksl

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

Question

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.

Share this post


Link to post
Share on other sites

Recommended Posts

  • 0

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.

Share this post


Link to post
Share on other sites
  • 0

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

Share this post


Link to post
Share on other sites
  • 0

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.

Share this post


Link to post
Share on other sites
  • 0

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

Share this post


Link to post
Share on other sites
  • 0

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.

Share this post


Link to post
Share on other sites
  • 0

@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?

Share this post


Link to post
Share on other sites
  • 0

@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. :-)

Share this post


Link to post
Share on other sites
  • 0

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

Share this post


Link to post
Share on other sites
  • 0

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

Share this post


Link to post
Share on other sites
  • 0

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.

Share this post


Link to post
Share on other sites
  • 0

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.

Share this post


Link to post
Share on other sites
  • 0

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 :-)

Share this post


Link to post
Share on other sites
  • 0

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?

Share this post


Link to post
Share on other sites
  • 0

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;
}

```

Share this post


Link to post
Share on other sites
  • 0

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.

Share this post


Link to post
Share on other sites
  • 0

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

Share this post


Link to post
Share on other sites
  • 0

@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

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×
×
  • Create New...