Is this also needed on the templateS model?

Is this also needed on the templateS model?

The usage I found was once in the model itself where it was used only as key and in the default.php where it was already casted. So I would say "no", but in general we have this problem on many places I guess (with other fields)

// Client ID is on PDO mySQL not an integer, so enforce here

This doesnt make sense. Not sure exactly what you are trying to say. Guessing at

// Client ID is not an integer, so enforce here

in general we have this problem on many places I guess (with other fields)

Shouldnt they be addressed with this PR - at least the ones relating to the template

in general we have this problem on many places I guess (with other fields)

Shouldnt they be addressed with this PR - at least the ones relating to the template

Do you see any spontanious? It was more a general remark. But I'm happy to fix it, if there are some very obvious ones.

this is a funny one...
i'm not able to replicate it...just tested on a normal cfg ?
even if i'm on mysql pdo
anyway

1. the executed query is

SELECT `extension_id`,`client_id`,`element`,`name`,`manifest_cache`
FROM `#__extensions`
WHERE `extension_id` = :pk AND `type` = 'template'

2. the client_id field is declared as tinyint so cannot be string
   

   joomla-cms/installation/sql/mysql/base.sql

   Line 126 in 126ed6a

   `client_id` tinyint NOT NULL,

oh wait ...probably i'm not on MariaDB ? but
debug tell me this

so it should be digged a bit more deep

I have tested this item ✅ successfully on 8892cea

Tested successfully in Joomla 4.1.3-dev of 21 April in Wampserver 3.2.7 using MySQL 8.0.27 and PHP 8.0.15.

This PR fixes the same issue with MySQL (PDO) selection breaking the path to the template files as the already closed #37489 did - #37489.

I have tested this item ✅ successfully on 8892cea

Tested on the site on which I faced the issue (4.1.2). Path is now correct. Thanks

RTC

still a funny one, my observations... are simply still ignored
i give up

@alikon Well I was able to reproduce the issue. And in past I have observed that depending on the driver and the database kind and Version columns with integer data types had been converted to strings.

i doubt still, anyway....
probably mine are not valid...fine
go forward

mine reply was not in synch with your last one ....probably

still stand anyway... simply ignore my comments mine are lastly ... killed from someone's thumbs down --- even if I declare as a DIRTY fix
Note to myself: stop doing things
?

?

Can we have a chat in 15 min?

Il gio 21 apr 2022, 21:36 Richard Fath @.***> ha
scritto:

?

—
Reply to this email directly, view it on GitHub
#37497 (comment),
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AABMLMJLG7CZQUU57XAIEZLVGGU2NANCNFSM5SWJYWUQ
.
You are receiving this because you were mentioned.Message ID:
@.***>

On Glip? If necessary, ok

thanks @richard67 to listen

We should maybe dig deeper into what causes different behavior of different versions of MySQL and MariaDB, but for the mean time this PR as a quick and maybe dirty fix is ok, I think.

you know i'm the man for a quick & dirty fix
...in some tables --- are called workaround---

So what is here the exact issue that it is considered a dirty hack?

So what is here the exact issue that it is considered a dirty hack?

@laoneo Maybe the wrong words, but as long as we don't know why we get an integer or a string for an integer data type column depending on database type and version, it leaves me with the feeling that we fix the symptom and not the root cause. But that's just a gut feeling and I may be wrong.

Valid concern.

The problem with the MySQL drivers are that it depends if PDO, MySQLi (MySQL) if it typecasts correctly and if we use prepared statements or not. it has been fixed (in a b/c incompatible way) in php 8.1 https://www.php.net/manual/en/migration81.incompatible.php#migration81.incompatible.pdo.mysql

if we fix this here we should add a deprecation notice (or removal notice with J5, where the minimum version will be php 8.1). I'm surprise that this is the only problem found yet for this behavior.

I think @HLeithner 's comment above and the link it refers to explain what happens.

For the mean time, until we have fixed the root cause, which we cleanly could do with J5 as mentioned by Harald, we will need such fixes like provided here.

Therefore I will merge this PR now.

Thanks.