Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
Re: Latset version 4.9
Adams wrote #342024:
Here is what I did so far and what I found
That’s brilliant, thank you so much. So, a few things:
1) GD Graphics Library: Unavailable
That is not related to your issue, but I wonder if it might destroy the automatic thumbnail script. I’m not sure if the librarey checks for the existence of GD internally or we need to do it. We should double check what happens when it’s off.
2) Unsupported operand types: string – int
This is more problematic. The reason we use FROM_UNIXTIME(0) is to support dates in the way way waaaaay past, and dates into the way way waaaay future. It was a workaround that Oleg discovered, but maybe we need a workaroundaround to cater for future versions of MySQL that don’t permit this, or to find a way to cast the results so we can safely perform math on the values to keep PHP happy.
Leave it with us, and thank you for sleuthing the issues.
The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.
Hire Txp Builders – finely-crafted code, design and Txp
Offline
#14 2025-12-29 15:50:35
- Adams
- Plugin Author
- Registered: 2024-08-30
- Posts: 58
Re: Latset version 4.9
BTW, there was no sql error; that function FROM_UNIXTIME(0) was returning null and the result was 0 rows.
Offline
Re: Latset version 4.9
Oleg: should we alter the txp_lang.lastmod column to be DATETIME instead of TIMESTAMP? Even though we don’t store lang strings with dates < UNIX Epoch, it means we could potentially alter FROM_UNIXTIME(0) to something else throughout the code without worrying if it’ll produce a timestamp we can’t store.
Then the only issue is finding a replacement statement, or handling the maths differently.
The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.
Hire Txp Builders – finely-crafted code, design and Txp
Offline
Re: Latset version 4.9
Bloke wrote #342028:
Oleg: should we alter the txp_lang.lastmod column to be DATETIME instead of TIMESTAMP?
Would this be easily portable between different time zones? Needs some thinking.
Even though we don’t store lang strings with dates < UNIX Epoch, it means we could potentially alter
FROM_UNIXTIME(0)to something else throughout the code without worrying if it’ll produce a timestamp we can’t store.
This change in MariaDB is rather weird: FROM_UNIXTIME(0) now returns NULL, but FROM_UNIXTIME(1) gives the UNIX 0 timestamp as local date, like 1970-01-01 01:00:00. We could switch to FROM_UNIXTIME(1) awaiting a better solution, eventually adjusting by 1 second.
Offline
Re: Latset version 4.9
I’ll make sure the next demo site server build includes MariaDB.
Offline
Re: Latset version 4.9
Congratulations on the release of 4.9.0.
Hope for the future.
Offline