you can call it whatever you want but my little forum is a message board and not a forum

In the end it doesn't matter. Users can write entries/messages and can reply to each other in a kind of answer-stream. Forum likes phpBB, Xenforo, jkBB, multiple other discussion boards, blogs with comment functions, CMS standard websites with guestbook replies, Wiki engines with discussion pages, old school mailing lists.... the concept is more or less always the same. And so MLF. People write, people react, people write again.

And yes, I need and use it. For tiny, small projects with small group of people in closed space/area, but for example also for a small, new online project. The amount of users and feedback is 0 to low and will be low always in the future, but that's the same with blog comments and other social things today (aside of "likes" or troll postings). But they all still exist and live here and there, for the same reason, why a lot of people still play DOS games, build and work with retro or analog computers or programming the next window manager for linux or a cat feeding station, controlled by hand gestures. And somebody will read the posting(s) one day, because he/she is searching for something specific online. Or an AI is using it as source for better answers in the future.

It's just a matter of interest, fun, hobby, personal project and the right combination of people. Sometimes slow and a small amount of activity, but still alive and breathing for good reasons. Doesn't need always the big scope/need/impact - so my personal opinion.

Hello Joe,

Line 40/41 Update
Looks very good. ORDER BY Should generally work either with or without the “ft.”, however including "ft.time" Should eliminate any possible issue here, as you have done. See Line 109 for more info.

This was more to clarify, which column in which table is meant. In the query itself the relation is clear but this part of the query is generated to far away from the rest of the query to be self-explanatory.

Line 88 Update
I Think this looks good, but need to test numerous combinations. The original format should not have caused any issue according to SQL standards, however there have been some SQL / MySQL implementations that required any ORDER BY also be in the SELECT.

I would bet for a configuration issue. Be that as it may, on my webspace/database server the missing columns in the SELECT were reported as an error and adding it was the solution.

I need to make sure adding ft.sticky and ft.time in the SELECT DISTINCT won't change the # of output rows.

No, the change does not change the number of the lines in result. It doesn't because the thread-ID (`mlf2_entries.tid`), selected with DISTINCT in combination with WHERE ft.pid = 0 which ensure to select only the opening posting of a thread, is unique in every case and the additional selected columns doesn't change this in any case.

Line 109 Update
Looks good. The issue may stem from unsafe use of the variable name “time” in the SQL SELECT (Line 109), as this is a Reserved word.

I suspect that the conversion of the column time from the MySQL timestamp type to the Unix integer timestamp under the same name as the column itself makes sorting impossible. When adding the aliased column to the select and ordering by the alias (and so with the original values) the code works.

Some questions as well:

Q1: To avoid potential row result issues arising from the change in Line 88, I'd like to know if you did already try changing Line 40/41 without changing Line 88.

No, I didn't. I hope, my description above about DISTINCT in combination with the WHERE clause clarifies what happens.

From your upgrade notes:
"Only when I called up the main forum page with the overview of threads, which was also empty at this time, the page displayed a database error. It concerned queries with ORDER-BY clauses in which columns are to be sorted that are not contained in the SELECT."

Q2: Do you know if this error occurred on both Line 88 and 109?

Yes, it does. The first error message was for line #88. After solving the error, another error message came up, related to the query in line #109.

Q3: Can you confirm whether you're using MySQL or MariaDB? Trying to wrap my head around these, as I can't duplicate the issues on my existing system (MariaDB, with data). Still need to go through upgrade using an empty DB, but curious if there may be an additional complicating factor between MariaDB and MySQL.

I was able to reproduce the error on both systems, MySQL 8.x and MariaDB 10.5.x on the servers of one hosting company (with an obvioulsy strict configuration).

Testing factors I need to look at (particularly for Line 88 and system not crashing)
Categories (categories disabled, categories enabled but no categories, categories enabled and exist)
Spam (no spam entries, spam entries with view enabled & disabled)
MariaDB vs MySQL. I only have MariaDB 11, so won't be able to test out MySQL 8.

As mentioned in another posting I successfully upgraded a forum with several postings in several threads in different categories and with several users. The only scenario I did not test was to have spam postings in the data. But also these postings would only be postings. There was no change regarding their handling in an upgrade.

Tschö, Auge

Hello Joe

Line 88 Update
I Think this looks good, but need to test numerous combinations. The original format should not have caused any issue according to SQL standards, however there have been some SQL / MySQL implementations that required any ORDER BY also be in the SELECT. I need to make sure adding ft.sticky and ft.time in the SELECT DISTINCT won't change the # of output rows.

I found another case of that type. When reordering the list of threads on the main page by the date of the latest reply (in my testing installation the threads are ordered by the date of the opening posting by default), one gets an error message, I documented on Github in the issue #731.

The message states clearly "this is incompatible with DISTINCT".

Tschö, Auge

Hello

After running the modified queries using different Spam entries in the DB (no Spam. Spam on child records, Spam on parent records, different Spam values in Akismet and B8), the query results match between the old and new code. And looking at the actual SQL, this makes perfect sense. So, I'd say the changes all look good.

Thank you very much for your effort. Your tests confirmed mine and makes it much easier for me to publish the update. In the past there have been errors from time to time that have been overlooked, so I really wanted to hear/read a second opinion from a competent person.

Tschö, Auge

Before upgrading from 2.4.24 to 20240729.1, I changed the engine of all the tables to InnoDB (some were already InnoDB). I used PHP 7.3 for the upgrade.

After the upgrade, this error is appearing above the forum content but only up to PHP 7.4.

You talk about the first of your images with the error in lines #66 and #67 of includes/index.inc.php?

PHP versions greater 7.4 are only showing errors and no forum content. I need it to work on minimum PHP 8.1, which is what my host is providing.

Can you please check in phpMyAdmin, if the tables mlf2_akismet_rating, mlf2_b8_rating, mlf2_b8_wordlist and mlf2_uploads exist?

Tschö, Auge

Hello

The upgrade from 2.4.24 to 20220803.1 was successful after I changed the "engine" of mlf2_userdata from MyISAM to InnoDB. Although I haven't run it afterwords in a live environment, as this was only in my Wampserver.

This error was foreseeable. The task of the query in which the four errors with the non-existent indexes occurred was to determine the tables for which the engine must be switched to InnoDB. If the errors had not occurred, the script could have changed the engine.

Tschö, Auge