TB 1.4 Mechanism needed to fix Attribute/ProductAttribute reference in 3rd party modules before 1.4 release

[Acer]

Hi @datakick

Thought I'd let you know: I encountered another 3rd party module with the Attribute / ProductAttribute issue (CSV Import Products by GloBo).
All was working fine in 1.3 until I tried to do a product attribute update in 1.4 edge with the module and then it threw an error.
The log file revealed that it was the Attribute/ProductAttribute issue, and the module worked again after I followed your fix instructions.

The thing is that most people will think that their 1.3 site upgraded to 1.4 is running fine (mine appeared fine). Until they try to use their 3rd party modules to do something fancy, like updating product combinations/attributes.
I'm not sure what the plan is regarding releasing 1.4, but I know that unless it includes the Mechanism that you mentioned that scans and updates affected 3rd party modules, then people will run into issues with 1.4 sooner or later.

For those encountering an error with "Attribute Class not found", you can follow DataKick's fix instructions here:

 

Edited August 6, 2022 by Theo

[the.rampage.rado]

I think you confuse the class with the product attributes. Neverthless - just keep your shop on php7.4 for time being.

The proposed fix is a demanding job.

[Acer]

TB 1.4 breaks modules that play with that class causing them to error out.
I've had 2 modules break already. If people just update to 1.4, they could encounter problems.

Also, right now I'm running 1.4 (for the benefit of running latest + security patches) on PHP 7.2, but will be running on PHP 7.4 when the site goes Live.
Running on PHP 7.4 isn't the issue, TB 1.4 is... well technically PHP 8 is the issue, but I'm sure you get what I'm saying 😉

Maybe TB 1.4 can have a flag to support Attribute instead of ProductAttribute - for those who want to run 1.4 but aren't running PHP 8.0 currently?
Perhaps this could help in the meantime while a potentially better solution is being worked on?

 

Edited August 6, 2022 by Theo

[led24ee]

This is not TB1.4 originated. This is PHP8 caused situation. So TB can only put warning that some modules can't work and it is very good when they put also short summary about problems, but don't expect that TB will solve these problems. I agree it is hard to understand, but this feels like touchscreen phone with round dialpad, completely useless and completely pointless. I have now little bit more time and i try TB1.4 to find out how many modules will still work. But when they will not work then this is my problem because sooner or later PHP7 will be "out of stock". Shorty don't cry, try to find another module or someone who can make these modules work again. At least I would.

[Acer]

Though I agree it's caused by PHP 8, this is actually a TB 1.4 problem and they appear know it. Or at least they're aware of the seriousness of this in terms of module support. To the point of @datakickmentioning that they're working on a mechanism to 'fix' it on 3rd party modules automatically. Even though that task would be complex and hard.

The point is that there are very few module developers and theme developers still supporting TB and that number is dropping daily. If this was Presta, with devs supporting it, then different story, sure. 

But with hardly any 3rd party module devs willing to support TB, stuff like this could lead to a demise of TB or at best push it into even more of a niche system, that becomes less and less attractive for new users to adopt and existing users to keep it around. Leading inevitably, and unfortunately, to its eventual end 😞

Edited August 9, 2022 by Theo

[datakick]

I just want to point out that the auto-fix mechanism we are talking here about is only for Attribute class rename. This is indeed backwards compatibility issue caused by tb 1.4.0, albeit forced upon us by PHP8 reserving this name in global space. We have prepared mechanism that parses the module code using PHP parser. That way, we can detect any references to Attribute in global space, and replace it by ProductAttribute. Unfortunately, this parsing is a very slow process, and it can easily time-out. And even if it does not timed-out, it makes module uploading process look very slow and sluggish. We need to work a little bit more on this mechanism to make it usable in real world. There are few things that we need to do -- for example caching of already parsed classes, do not parse files in module 'vendor' directory as it it very unlikely that any composer library is using prestashop/thirtybees Attribute class, test files if they are using Attribute text using string functions, and parse only those that do, etc.

 We can fix this particular BC problem. But there will be other problems related to PHP8 that can cause serious issues. PHP8 is much more strict than was PHP5 for which those modules were originally written. 

[Acer]

Thank you @datakick

Your work on TB is big time appreciated

[Acer]

On 8/6/2022 at 11:55 PM, Theo said:

Maybe TB 1.4 can have a flag to support Attribute instead of ProductAttribute - for those who want to run 1.4 but aren't running PHP 8.0 currently?
Perhaps this could help in the meantime while a potentially better solution is being worked on?

What about the flag idea @datakick? 

[datakick]

1 minute ago, Theo said:

What about the flag idea @datakick? 

Not possible

[Acer]

Maybe even more insane but can you intercept the module and run it on some sort of compatibility layer at all? 

[Acer]

Or what about a mechanism that monitors the 500 errors? And fixes it as it comes up, file by file, error by error. It can display a message that it's performing a compatibility upgrade and that it may be a step by step process. 

That way it's less intensive and it's more targeted with less risk of time out. 

@datakick

[wakabayashi]

Just now, Theo said:

Or what about a mechanism that monitors the 500 errors? And fixes it as it comes up, file by file, error by error. It can display a message that it's performing a compatibility upgrade and that it may be a step by step process. 

That way it's less intensive and it's more targeted with less risk of time out. 

@datakick

Well that could take a multiple failed orders till it works again.

I just wanted to add the important php graphic, to illustrate that this issue has not so much todo with TB:

So very soon php7 won't be supported anymore. It means the same trouble for all prestashop 1.6 shops. If you are lucky, some module devs still fix their modules. If not, you should either look for an alternative module or let it fix. I have no experience in this, but I would expect that most modules can be fixed in 1-2 hours. Ofc I might be wrong.

[datakick]

35 minutes ago, Theo said:

Or what about a mechanism that monitors the 500 errors? And fixes it as it comes up, file by file, error by error. It can display a message that it's performing a compatibility upgrade and that it may be a step by step process. 

We do have such mechanism -- error handler collects 500 errors and saves them inside /log/ directory. 

As @wakabayashi wrote -- it is usually very easy to fix php8 issues. If the module is not maintained anymore, you can try fix it yourself or hire external help. Any developer should be able to fix these kind of issues in few hours, or even couple of minutes. We offer such services as well, by the way. 

[Acer]

16 minutes ago, datakick said:

e do have such mechanism -- error handler collects 500 errors and saves them inside /log/ directory. 

What I'm suggesting is the mechanism should maybe monitor the 500 errors / log files and fix automatically instead of having to scan the whole module directory. 

All this is in the context of these errors being fixed automatically.