product pages suddenly inaccessible 500 error

[Mark]

I was doing a few things like updating CMS, blogs, social feeds (note telegram, Reddit and a few others are missing)  when suddenly...

Boom!! All my product pages became inaccessible with a 500:error.  Grrrrrr!

No idea what caused it but its crucial.

Had not long before that upgraded to latest bleeding edge not sure if that's why.

Roll back to stable solved problem, but this appears to be major flag , not yet resolved or even allocated in GitHub but has been reported by @x97wehner. Bleeding edge should really not be enabled @datakick, roll to stable instead

 

Edited March 10, 2022 by Mark

[datakick]

 

22 minutes ago, Mark said:

Ok @datakicke here we go... Looks like a module, best to to uninstall it?

 

This problem is caused by new column active in table 'tb_category_shop'. This column exits in bleeding edge only, so if you are back on 1.3.0 all you need to do is drop it:

ALTER TABLE tbp5_category_shop DROP active;

But obviously, this module will no longer work on bleeding edge (or future versions of thirty bees). As @wakabayashi wrote, the module author did not specify from which table active column should come -- that's not really their fault, as at the time they wrote the module only one active column existed in context of this query. 

If you want to keep using this module, you will have to modify it, and fully specify table name / alias.

[toplakd]

Bleeding edge works just fine, but there can always be some issues, that's why bleeding edge is not something for everyone.

Have you looked at exception logs?

[Mark]

1 hour ago, toplakd said:

"Bleeding edge works just fine"

A 500 error crashing all your product and Catalog pages is not my definition of things "working fine".

"but there can always be some issues, that's why bleeding edge is not something for everyone"

So far until now ive only used bleeding edge ... and it's proved solid.

Typically bleeding edge doesn't have terminal errors, but may well have other imperfections but in this case a terminal error has slipped through

 

Quote

Have you looked at exception logs?

Nope.

 

Edited March 11, 2022 by Mark

[datakick]

I am using bleeding edge on my store, and I know about a lot of people that are using it as well. Works properly for all of us, as far as I know.

Every store is unique, of course, considering how flexible the module/override system is. If @Mark has 500 error on bleeding edge, then it's most likely some customization issue. Of course, it can be bug in core, that manifests only in some specific use cases. However, without any error message from debug page or php server log file there is no way to tell what's wrong.

Note that currently it's not possible to roll back from bleeding edge back to 1.3.0. The reason is that bleeding edge introduces new database column 'active' in 'tb_category_shop' table. This extra column produces 'ambiguous column' database error on 1.3.0. The fix is to drop this column from db table manually when downgrading from bleeding edge to 1.3.0. Core updater does not do this automatically. Actually, it can't do this, because a lot of third party modules extend core database tables with their own columns. If core updater dropped all of these columns on update... well you can imagine what would happen.

[Mark]

1 hour ago, datakick said:

I am using bleeding edge on my store, and I know about a lot of people that are using it as well. Works properly for all of us, as far as I know.

Every store is unique, of course, considering how flexible the module/override system is. If @Mark has 500 error on bleeding edge, then it's most likely some customization issue. Of course, it can be bug in core, that manifests only in some specific use cases. However, without any error message from debug page or php server log file there is no way to tell what's wrong

I don't touch any code so that's that possibility eliminated, I guess it must be a module then.

I'm happy to try and find traces of evidence somewhere if they still exist since I rolled to stable.Just point me in right direction.

 

1 hour ago, datakick said:

Note that currently it's not possible to roll back from bleeding edge back to 1.3.0.

 

The reason is that bleeding edge introduces new database column 'active' in 'tb_category_shop' table. This extra column produces 'ambiguous column' database error on 1.3.0. The fix is to drop this column from db table manually when downgrading from bleeding edge to 1.3.0. Core updater does not do this automatically. Actually, it can't do this, because a lot of third party modules extend core database tables with their own columns. If core updater dropped all of these columns on update... well you can imagine what would happen.

 

Yep I get that. I guess the column being there won't matter anyway if no 1.3 code refers to it...?

The only thing I can see that looks odd is this. Previously TLS has been fine....

 

Happy to hunt for clues just need few hints. I saw that @x97wehnerhad listed this in GitHub so I presumed I was not alone

 

[datakick]

17 minutes ago, Mark said:

I guess the column being there won't matter anyway if no 1.3 code refers to it...?

That's just it -- it matters. In 1.3.0, there is sql query, something like this:

SELECT active
FROM tb_category c
LEFT JOIN tb_category_shop cs

This query does not fully specify from which table return active column. Because in 1.3.0 this column exists in tb_category table only, it does not really matter. DB server will return the only column available.

But, if you add column with the same name into table tb_category_shop (as bleeding edge did), this query stops working -- now there are two columns, and DB does not know which should be returned.

Extra columns in core tables matter. It should be forbidden to modules to extend standard tables

[Mark]

9 minutes ago, datakick said:

That's just it -- it matters. In 1.3.0, there is sql query, something like this:

SELECT active
FROM tb_category c
LEFT JOIN tb_category_shop cs

This query does not fully specify from which table return active column. Because in 1.3.0 this column exists in tb_category table only, it does not really matter. DB server will return the only column available.

But, if you add column with the same name into table tb_category_shop (as bleeding edge did), this query stops working -- now there are two columns, and DB does not know which should be returned.

Extra columns in core tables matter. It should be forbidden to modules to extend standard tables

Ok should I manually delete the column then? (Or some other manual intervention?)

And presume that when I upgrade back to bleeding edge, the column will be added back?

[Mark]

@datakicki do have the encrypted 500 error message as a txt file is that any good?

Edited March 11, 2022 by Mark

[datakick]

3 minutes ago, Mark said:

@datakicki do have the encrypted 500 error message as a txt file is that any good?

It's good only for you, as only you have the private key needed for decryption. You can decrypt the error message in your back office > Advanced Parameters > Logs.

Or enable debug mode and you will see the error message directly

[Mark]

Ok @datakicke here we go... Looks like a module, best to to uninstall it?

[wakabayashi]

19 minutes ago, Mark said:

Ok @datakicke here we go... Looks like a module, best to to uninstall it?

I would guess that changing SELECT active to "SELECT c.active" could work. But I am not sure, if this is also the intended thing. In general there are two "active" table columns and the dev didn't tell, which one he means...

You should show us the whole SQL query...

Edited March 11, 2022 by wakabayashi

[Mark]

6 hours ago, datakick said:

 

 

This problem is caused by new column active in table 'tb_category_shop'. This column exits in bleeding edge only, so if you are back on 1.3.0 all you need to do is drop it:

ALTER TABLE tbp5_category_shop DROP active;

But obviously, this module will no longer work on bleeding edge (or future versions of thirty bees). As @wakabayashi wrote, the module author did not specify from which table active column should come -- that's not really their fault, as at the time they wrote the module only one active column existed in context of this query. 

If you want to keep using this module, you will have to modify it, and fully specify table name / alias.

Module gone, problem gone... Thanks @datakick am now on bleeding edge

Edited March 11, 2022 by Mark