Problems with the upgrade procedure from 2.4.x to 2.5

Hello

During the last weeks we saw a few error reports about issues during the upgrade from a 2.4.x version to the currently latest stable version 20220803.1 (2.5.4). Some of these issues are caused by previous tests of a development version of the 2.5-branch and a later downgrade to a 2.4-x version with orphaned but remaining tables for 2.5 in the database. That broke the upgrade script because we never thought about such a situation when writing the code. Some other issues are caused by our (mainly my) carelessness and for us unexpected server configuration.

I opened a pull request on Github as work in progress (unfinished at the time of writing) to solve the issues, where possible. To keep the reports at one place where i can find them easily I will tie them now to this thread.

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

Hello,

I tried the update like written in the subject and experienced two issues. Both issues break the update and leave the database in a state which is not working for the old version.

1. the update script printed out "Database error in line 452: Specified key was too long; max key length is 767 bytes" and the update did not finish.
I noticed that this issue was discussed already, and I also did some googeling. Probably this isuue is somehow related to an old SQL version, in my case it is "Server version: 5.5.62 MySQL Community Server (GPL)", i.e. I agree with the explanation from user Auge.

I did not really understand if there is already a bugfix. If yes, it looks like it did not work properly. Maybe the best solution is a SQL update.

2. just for fun i tried a quick-and-dirty hack (not recommended for others). I changed in the update script line 448 "VARCHAR(256)" to "VARCHAR(255)", because 3 * 255 < 768. And indeed, this error was gone, but another appeared: "Database error in line 452: Duplicate entry 'abcdef@domain.tld' for key 'key_user_email'". It turned out that there are two different usernames with the same email address.
Thats a case of a bad administration, in the first place :-) I will remove the double entry.

But I think it should checked before updating or at least mentioned in the update hints.

I installed the backup of my current forum, so there is no damage and I can prepare the next try without stress. While installing the database backup I noticed the new version added four tables. i.e. PREFIX-akismet_rating, PREFIX-b8_rating, PREFIX-b8_wordlist, and PREFIX-uploads.
It turned out that these tables remained in the database after installing the backup and caused errors at the next try.

I would suggest to offer some short fallback hints in the update description, maybe:
"Before update: back up database and php/html code.
If it did not work:
replace code with your backup
replace database with your backup
delete the newly added tables, if still present"

have a nice day!

Hello

Und ewig grüßt das Murmeltier … Groundhog Day again.

I tried the update like written in the subject and experienced two issues. Both issues break the update and leave the database in a state which is not working for the old version.

1. the update script printed out "Database error in line 452: Specified key was too long; max key length is 767 bytes" and the update did not finish.
I noticed that this issue was discussed already, and I also did some googeling. Probably this isuue is somehow related to an old SQL version, in my case it is "Server version: 5.5.62 MySQL Community Server (GPL)", i.e. I agree with the explanation from user Auge.

I did not really understand if there is already a bugfix. If yes, it looks like it did not work properly. Maybe the best solution is a SQL update.

Yes, I thought I fixed it. But when this problem encountered for you with the latest available version 20220803.1, it obviously doesn't work in every case.

2. just for fun i tried a quick-and-dirty hack (not recommended for others). I changed in the update script line 448 "VARCHAR(256)" to "VARCHAR(255)", because 3 * 255 < 768.

I will check, if this is an appropriate way, a.k.a. a not so quick-and-dirty hack as you think, to solve the issue. I solved the same issue with setting the charset to utf8 (without the appendix mb4). That way the maximum index length does not exceed because of the different charset. But it was obviously the wrong place to do this.

And indeed, this error was gone, but another appeared: "Database error in line 452: Duplicate entry 'abcdef@domain.tld' for key 'key_user_email'". It turned out that there are two different usernames with the same email address.
Thats a case of a bad administration, in the first place I will remove the double entry.

I don't know, if this is really a case of a "bad administration". Until version 20220508.1 (2.5.0) it was simply possible to add more than one account with the same e-mail-address. I for myself used this possibility regulary for testing purposes.

It's a trap when updating to a version in the 2.5 branch.

But I think it should checked before updating or at least mentioned in the update hints.

Yes, you are right.

Once we changed the collation of the column username in the userdata table because the database found the name "Hans" and the fictive name "Häns" to be identical. The update script tested the database for such pseudoidentical values, to enforce the admin to solve the problem in collaboration with the affected users before the update.

This time (making the e-mail-address unique) we didn't checked the values for doublettes. That is a failure. I will have to completely rework the update script.

I installed the backup of my current forum, so there is no damage and I can prepare the next try without stress. While installing the database backup I noticed the new version added four tables. i.e. PREFIX-akismet_rating, PREFIX-b8_rating, PREFIX-b8_wordlist, and PREFIX-uploads.
It turned out that these tables remained in the database after installing the backup and caused errors at the next try.

Hmm. The update script doesn't check for already existing tables. Normally this will not happen, but in your case with a previoulsy partially failed upgrade, it will fail.

I would suggest to offer some short fallback hints in the update description, maybe:
"Before update: back up database and php/html code.
If it did not work:
replace code with your backup
replace database with your backup
delete the newly added tables, if still present"

ACK

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

Well, the next try :-)

my provider offered a transfer to a new database with MYSQL 5.7 (also possible MYSQL 8, or MariaDB 10.6) and I tried the update. I got these errors:


Fehler!

    Database error in line 363: Incorrect datetime value: '0000-00-00 00:00:00' for column 'edited' at row 1
    Database error in line 378: Incorrect date value: '0000-00-00' for column 'birthday' at row 1
    Database error in line 381: Incorrect date value: '0000-00-00' for column 'birthday' at row 1

The forum itself seems to run, however it shown ugly PHP warnings:


Warning: mysqli_fetch_row() expects parameter 1 to be mysqli_result, boolean given in /PATH/includes/main.inc.php on line 259

Warning: mysqli_free_result() expects parameter 1 to be mysqli_result, boolean given in /PATH/forum/includes/main.inc.php on line 260

Warning: mysqli_fetch_row() expects parameter 1 to be mysqli_result, boolean given in /PATH/forum/includes/main.inc.php on line 262

Warning: mysqli_free_result() expects parameter 1 to be mysqli_result, boolean given in /PATH/forum/includes/main.inc.php on line 263

Warning: mysqli_fetch_row() expects parameter 1 to be mysqli_result, boolean given in /PATH/forum/includes/main.inc.php on line 267

Warning: mysqli_free_result() expects parameter 1 to be mysqli_result, boolean given in /PATH/forum/includes/main.inc.php on line 268

Warning: Cannot modify header information - headers already sent by (output started at /PATH/forum/includes/main.inc.php:259) in /PATH/forum/index.php on line 208

Warning: Cannot modify header information - headers already sent by (output started at /PATH/forum/includes/main.inc.php:259) in /PATH/forum/index.php on line 209

remarks:

- Before the update attempt today the forum was O.K., but I did a similar try two weeks ago. I cannot confirm that this try did not touch the databases. However this should be unlikely.

- In the "entries" table there are entries with "0000-00-00 00:00:00" in the edited row.

- in the "uderdata" table there are entries with "0000-00-00" in the borthday row.

Should I set these entries to NULL manually before updating?

Any suggestions?

Hello

Well, the next try

As first: Thank you for your unintentionally tests.

my provider offered a transfer to a new database with MYSQL 5.7 (also possible MYSQL 8, or MariaDB 10.6) and I tried the update. I got these errors:
Fehler!

Database error in line 363: Incorrect datetime value: '0000-00-00 00:00:00' for column 'edited' at row 1
Database error in line 378: Incorrect date value: '0000-00-00' for column 'birthday' at row 1
Database error in line 381: Incorrect date value: '0000-00-00' for column 'birthday' at row 1

That's the pitfalls of the configuration dependent, possible lax data model of MySQL and the default values for columns that was mostly set by Alex years ago (possibly wíthout the necessary knowledge about the corner cases, i.e. much more stringent configurations of MySQL-servers).

The forum itself seems to run, however it shown ugly PHP warnings:


Warning: mysqli_fetch_row() expects parameter 1 to be mysqli_result, boolean given in /PATH/includes/main.inc.php on line 259

Warning: mysqli_free_result() expects parameter 1 to be mysqli_result, boolean given in /PATH/forum/includes/main.inc.php on line 260

Warning: mysqli_fetch_row() expects parameter 1 to be mysqli_result, boolean given in /PATH/forum/includes/main.inc.php on line 262

Warning: mysqli_free_result() expects parameter 1 to be mysqli_result, boolean given in /PATH/forum/includes/main.inc.php on line 263

Warning: mysqli_fetch_row() expects parameter 1 to be mysqli_result, boolean given in /PATH/forum/includes/main.inc.php on line 267

Warning: mysqli_free_result() expects parameter 1 to be mysqli_result, boolean given in /PATH/forum/includes/main.inc.php on line 268

Hmmm, the error in line 259 is the cause of the following errors. This is the complete block in main.inc.php (version 20220803.1).


259 | $count_result = mysqli_query($connid, "SELECT COUNT(*) FROM " . $db_settings['userdata_table'] . " WHERE activate_code = ''");
260 | list($registered_users) = mysqli_fetch_row($count_result);
261 |
262 | if ($settings['count_users_online'] > 0) {
263 |  user_online($settings['count_users_online']);
264 |  $count_result = mysqli_query($connid, "SELECT COUNT(*) FROM ".$db_settings['useronline_table']." WHERE user_id > 0");
265 |  list($registered_users_online) = mysqli_fetch_row($count_result);
266 |  $count_result = mysqli_query($connid, "SELECT COUNT(*) FROM ".$db_settings['useronline_table']." WHERE user_id = 0");
267 |  list($unregistered_users_online) = mysqli_fetch_row($count_result);
268 |  $total_users_online = $unregistered_users_online + $registered_users_online;
269 | }
270 | mysqli_free_result($count_result);

But comparing the line numbers in your error messages with the code one can see, that the messages reports MySQL-errors in lines, where we don't see MySQL-related function calls in the code of version 20220803.1 (as shown above). But when we look into the code of version 2.4.20 (the version from where you started the update) we can see MySQL-related code with a query, that includes columns that are gone with version 2.5. The gone colum is part of the string in the variable $display_spam_query_and, that was generated in the previous block, beginning with line #239.


256 | } else {
257 |  // there are categories
258 |  $count_result = mysqli_query($connid, "SELECT COUNT(*) FROM ".$db_settings['forum_table']." WHERE pid = 0".$display_spam_query_and." AND category IN (".$category_ids_query.")");
259 |  list($total_threads) = mysqli_fetch_row($count_result);
260 |  mysqli_free_result($count_result);
261 |  $count_result = mysqli_query($connid, "SELECT COUNT(*) FROM ".$db_settings['forum_table']." WHERE category IN (".$category_ids_query.")".$display_spam_query_and);
262 |  list($total_postings) = mysqli_fetch_row($count_result);
263 |  mysqli_free_result($count_result);
264 | }
265 | // count spam:
266 | $count_spam_result = mysqli_query($connid, "SELECT COUNT(*) FROM ".$db_settings['forum_table']." WHERE spam = 1");
267 | list($total_spam) = mysqli_fetch_row($count_spam_result);
268 | mysqli_free_result($count_spam_result);

That said, we have to assume, that you forgot to upload the script file(s) (at least the main.inc.php).


Warning: Cannot modify header information - headers already sent by (output started at /PATH/forum/includes/main.inc.php:259) in /PATH/forum/index.php on line 208

Warning: Cannot modify header information - headers already sent by (output started at /PATH/forum/includes/main.inc.php:259) in /PATH/forum/index.php on line 209

These are subsequent errors because of the output of the previous error messages. This errors would not occur, if the error in main.inc.php, line 259 would not happen.

remarks:

- Before the update attempt today the forum was O.K., but I did a similar try two weeks ago. I cannot confirm that this try did not touch the databases. However this should be unlikely.
- In the "entries" table there are entries with "0000-00-00 00:00:00" in the edited row.
- in the "uderdata" table there are entries with "0000-00-00" in the borthday row.

Should I set these entries to NULL manually before updating?

Generally this is a proper idea, but I cannot recommend this without knowing the possible side effects (i.e. when a function relies on the format (0000-00-00 (00:00:00)) and does not take a NULL value into account). There are many more places in the database, where setting the default values to NULL would make IMHO much more sense than the current defaults does.

Any suggestions?

I had a few looks into the code of the update script and I have ideas to improve the script without breaking updates, that have aready been made. I will inspect the code with a focus on the date and datetime topics today and will give a report today in the evening or tomorrow.

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

my provider offered a transfer to a new database with MYSQL 5.7 (also possible MYSQL 8, or MariaDB 10.6) and I tried the update. I got these errors:
Fehler!

Database error in line 363: Incorrect datetime value: '0000-00-00 00:00:00' for column 'edited' at row 1
Database error in line 378: Incorrect date value: '0000-00-00' for column 'birthday' at row 1
Database error in line 381: Incorrect date value: '0000-00-00' for column 'birthday' at row 1

Well, I can give an update to this issues.

This is what I did:

- first I made a backup from the database and the php stuff. And indeed, at some step in the following trial-and-error-game I made a mistake and corrupted the database. So I needed the SQL dump!

- since I had already some difficulties, I duplicated both, i.e. the database and the web files. One instance for testing some changes at the database and one instance for porting back in case of success.

- technically spoken, the main point was to obtain a database which is updatable. In my case, I found three obstacles (after migrating from MYSQL 5.6 to MYSQL7 or higher):

-- first: the table PREFIX_userdata contains email the address for every account. In the past, it was no problem to have two different accounts with the same email address. The update script however does not accept this (as I mentioned already somewhere), so this table must contain every email address only once. Google pointed me to this MYSQL snipplet, which lists all email addresses with more than one occurrence:

mysql> select
-> user_email,
-> count(user_email)
-> From
-> PREFIX_userdata
-> group by (user_email)
-> having count(user_email) > 1;

Then, the "double" accounts must removed.

-- second: if the update script does finish with with errors, it may already have changed the database. Especially, it creates some new tables. Loading the backup SQL dump does not remove the newly created tables, but a second run of the update script leads to an error, because it relys on a clean database. Therefore, the newly created tables must be dropped. To my knowledge this are four tables. "drop table PREFIX_akismet_rating,PREFIX_b8_rating,PREFIX_b8_wordlist,PREFIX_uploads" should do the job.

-- third is the most challenging one. Look at the quoted error. The update script (or better, the database) causes problems when some entries with wrong values are present. In my case, this showed up at the "edited" row of table PREFIX_entries and the "birthday" row of table PREFIX_userdata. In both cases, I had some entries with all zeroed, see above. For some reason, SQL has a problem, depending on the particular settings of the database.

It looks like that these date variables have some default value, if not set. In former times (parsimony?) it was probably "all zero". Now, it seems to be NULL, which is a SQL key word. My SQL database seems to accept either "NULL" for 'not set' or, if set, a certain, realistic value, but not 'all zero'.

Unfortunately, my database let me not change the "all zero" values to an other value. It even refused to accept "all zero" in a query - at least with default settings.

Google pointed me to some database settings, i.e. the "sql_mode". It can be queried like that:

mysql> SHOW VARIABLES LIKE 'sql_mode';
+---------------+-------------------------------------------------------------------------------------------------------------------------------------------+
| Variable_name | Value                                                                                                                                     |
+---------------+-------------------------------------------------------------------------------------------------------------------------------------------+
| sql_mode      | ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION |
+---------------+-------------------------------------------------------------------------------------------------------------------------------------------+
1 row in set (0.00 sec)

Here, "NO_ZERO_IN_DATE,NO_ZERO_DATE" is causing the issue.

However, I read warnings when changing the settings in a database which is in use. So I created a new database, changed the settings


 SET SESSION sql_mode = 'ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION';

(thats just the old settings without "NO_ZERO_IN_DATE,NO_ZERO_DATE"), imported the SQL dump, and changed the "all zero" entries to NULL:


UPDATE PREFIX_entries SET edited = NULL WHERE edited = '0000-00-00 00:00:00';

UPDATE PREFIX_userdata SET birthday = NULL WHERE birthday = '0000-00-00';

Now, a check should not find a "all zero" value any more:


select edited from PREFIX_entries where edited = '0000-00-00 00:00:00';
select birthday from PREFIX_userdata where birthday = '0000-00-00';

I made a SQL dump from this change and used it in my testing (and also in my productive) database. It worked without errors.

As indicated, this depends on your individual database settings, so DO NOT SIMPLY COPY&PASTE my hints without looking at your own situation!

After that, I was able to perform the update from 2.4.20 to 20220803.1. At least, the update script finished without error.

Hello Nico,

thank you very much for your investigation and its documentation. 🙏 👍

This gives a clearer picture of the situation. In the long run it is necessary to alter many of the column definitions. Define empty values as NULL instead as 0, 0000-00-00 [00:00:00] or as empty strings would bring us nearer to the safe standards of SQL. I would expect servers to forbid constructions like empty strings or a zero date values but not to forbid NULL values.

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

Hi,

update shows following errors:

Database error in line 298: Table 'mlf2_akismet_rating' already exists
Database error in line 301: Table 'mlf2_b8_rating' already exists
Database error in line 304: Unknown character set: 'utf8mb4'
Database error in line 307: Table 'mlf2_uploads' already exists
Database error in line 327: Table 'w10500-mlf2.mlf2_b8_wordlist' doesn't exist
Database error in line 330: Duplicate entry '1' for key 1
Database error in line 333: Duplicate entry '1' for key 1

Result: Forum no longer accessible.

Hello

update shows following errors:

Database error in line 298: Table 'mlf2_akismet_rating' already exists
Database error in line 301: Table 'mlf2_b8_rating' already exists

You had obviously installed a version from the 2.5-branch (2.4.99.x or a 2022-any-number) before the current update attempt. You might have downgraded the version to a stable version of the 2.4-branch but the then obsolete tables remained.

Database error in line 304: Unknown character set: 'utf8mb4'

What version of MySQL operates on your server?

Database error in line 307: Table 'mlf2_uploads' already exists

Same here for the case of a previous installed 2.5-branch version.

Database error in line 327: Table 'w10500-mlf2.mlf2_b8_wordlist' doesn't exist

The creation of the table failed because of the unknown charset utf8mb4 from the error in line 304.

Database error in line 330: Duplicate entry '1' for key 1
Database error in line 333: Duplicate entry '1' for key 1

If the tables would be new, they would be empty and there would be no entry 1, that could be duplicated. If this error occurs, the akismet rating table as well as the b8 rating table are not empty during the update process. So again: You had obviously installed a version from the 2.5-branch (2.4.99.x or a 2022-any-number) before the current update attempt.

So to confirm or deny my assumptions is the first step to get your forum running again. Beside from that I am quite confused because I test a clean installation and updates from a 2.4.20 and the previous version (in this case the version 20220529.1) before every release of a new version and I never experienced errors like yours or like the errors from other threads. ☹️

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

Hi Auge,

Thanks for the quick reply.
Correct, the tables 'mlf2_akismet_rating' and 'mlf2_b8_rating' as well as 'mlf2_uploads' exist in the database.

You had obviously installed a version from the 2.5-branch (2.4.99.x or a 2022-any-number) before the current update attempt. You might have downgraded the version to a stable version of the 2.4-branch but the then obsolete tables remained.

I don't remember doing that. But it doesn't matter how the tables got into the database.
My question: Can I simply delete these 3 tables, for example with phpMyAdmin?

Database error in line 304: Unknown character set: 'utf8mb4'

What version of MySQL operates on your server?

MySQL 5.0

So to confirm or deny my assumptions is the first step to get your forum running again.

My forum is currently running again in version 2.4.24 after a restore of the database, but of course I want to upgrade to 2.5 to support PHP 8.1.

Cheers
Fritz

Hello

Thanks for the quick reply.
Correct, the tables 'mlf2_akismet_rating' and 'mlf2_b8_rating' as well as 'mlf2_uploads' exist in the database.

You had obviously installed a version from the 2.5-branch (2.4.99.x or a 2022-any-number) before the current update attempt. You might have downgraded the version to a stable version of the 2.4-branch but the then obsolete tables remained.

I don't remember doing that. But it doesn't matter how the tables got into the database.
My question: Can I simply delete these 3 tables, for example with phpMyAdmin?

As you are running MLF in version 2.4.24 again, you can delete all tables, that are generated for version 2.5. These are the tables for uploads, B8-wordlist and rating and the akismet rating table.

Database error in line 304: Unknown character set: 'utf8mb4'

What version of MySQL operates on your server?

MySQL 5.0

I cannot say with certainty, in which version of MySQL the charset utf8mb4 was added but in case of MySQL 5.0 would be not able to handle the charset utf8mb4, you will not be able to upgrade the forum script to version 2.5 or any newer version. On the other hand MySQL 5.0 is a really ancient version. Please ask your hosting service/server admin to upgrade to a recent version of MySQL.

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

Servus Auge,

thank you for your quick and comprehensive reply.

The database is now running MySQL 5.7

Just one more question:
in db_setting.php the following is declared:
$db_settings['b8_wordlist_table'] = 'mlf2_b8_wordlist';
$db_settings['b8_rating_table'] = 'mlf2_b8_rating';
$db_settings['akismet_rating_table'] = 'mlf2_akismet_rating';
$db_settings['uploads_table'] = 'mlf2_uploads';

Should I also delete these lines in db_setting.php prior to upgrading to 20220803.1

Cheers
Fritz

Hello

thank you for your quick and comprehensive reply.

The database is now running MySQL 5.7

Much better. 👍

Just one more question:
in db_setting.php the following is declared:
$db_settings['b8_wordlist_table'] = 'mlf2_b8_wordlist';
$db_settings['b8_rating_table'] = 'mlf2_b8_rating';
$db_settings['akismet_rating_table'] = 'mlf2_akismet_rating';
$db_settings['uploads_table'] = 'mlf2_uploads';

Should I also delete these lines in db_setting.php prior to upgrading to 20220803.1

You can delete these entries without a side effect when you are running a 2.4.x-version. But you can also leave these entries in the database config file because they simply will be ignored in a 2.4.x-version and the file itself will be overwritten when you upgrade to a newer version. So the content would be the same but the bytes would be "new". 😆

Long story short, it is irrelevant.

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

... and one more question:
The tables created by version 2.4.24 use utf8_general_ci throughout, not utf8mb4
Example:
name varchar(255) utf8_general_ci
Do I have to change every collation to utf8mb4 in the database manually, or will this be done by update_2.4.19.1-2.5.php?

Cheers
Fritz

Hello

... and one more question:
The tables created by version 2.4.24 use utf8_general_ci throughout, not utf8mb4
Example:
name varchar(255) utf8_general_ci
Do I have to change every collation to utf8mb4 in the database manually, or will this be done by update_2.4.19.1-2.5.php?

This is one of the tasks, the update script is performing.

Unfortunately there are currently a few pitfalls in the update script, that are caused by MySQL-server-configurations we wasn't aware of and wasn't be able to test before the releases of the first versions of the 2.5-branch (20220508.1 and later). We have to solve these issues first, before we can recommend an upgrade to the 2-5-branch for forum operators, who are not really familiar with PHP, MySQL and the code of the forum script to inspect and possibly solve issues themselfes.

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

Servus Auge,

OK, I can wait. Thanks for the warning.

Cheers
Fritz

OK. I ran the update. No risk - no fun. Everything worked fine. :-)

Habe das selbe Problem beim versuchten Update gehabt (von Version 2.4.0). Wenn ich jetzt versuche zu aktualisieren erscheint folgende Meldung:

Database error in line 298: Table 'mlf2_akismet_rating' already exists Database error in line 301: Table 'mlf2_b8_rating' already exists Database error in line 304: Table 'mlf2_b8_wordlist' already exists Database error in line 307: Table 'mlf2_uploads' already exists Database error in line 312: Duplicate entry 'uploads_per_page' for key 'PRIMARY' Database error in line 327: Duplicate entry 'b8*dbversion' for key 'PRIMARY' Database error in line 330: Unknown column 'spam' in 'field list' Database error in line 333: Unknown column 'spam' in 'field list' Database error in line 339: Can't DROP 'spam'; check that column/key exists

Wenn man das Forum aufruft, funktioniert es nicht mehr: https://www.topfree.de/forum/ ("Unknown column 'spam' in 'where clause'").

Allerdings läuft die neueste Version 20220803.1 > https://www.topfree.de/forum2/ auf meinem Sever.

Hilft jetzt nur ein Backup (und dann?)? Oder kann man die Beiträge und Benutzer in die neue Version irgendwie importieren?

Vielen Dank! :)

Hallo,

entschuldige die späte Antwort, zwischen den Jahren habe ich deine Anfrage gesehen, aber keine Ruhe gefunden, darauf zu antworten.

Habe das selbe Problem beim versuchten Update gehabt (von Version 2.4.0).

Hast du das Upgrade direkt von Version 2.4.0 auf 2.5.x durchführen können oder erst den Zwischenschritt auf eine aktuelle 2.4.x (x = 19.1 oder neuer) gemacht? Direkt dürfte das überhaupt nicht funktioneren, womit sich meine Frage von selbst beantworten sollte, aber man weiß ja nicht, ob sich doch ein Fehler eingeschlichen hat.

Wenn ich jetzt versuche zu aktualisieren erscheint folgende Meldung:

Database error in line 298: Table 'mlf2_akismet_rating' already exists
Database error in line 301: Table 'mlf2_b8_rating' already exists
Database error in line 304: Table 'mlf2_b8_wordlist' already exists
Database error in line 307: Table 'mlf2_uploads' already exists
Database error in line 312: Duplicate entry 'uploads_per_page' for key 'PRIMARY'
Database error in line 327: Duplicate entry 'b8*dbversion' for key 'PRIMARY'
Database error in line 330: Unknown column 'spam' in 'field list'
Database error in line 333: Unknown column 'spam' in 'field list'
Database error in line 339: Can't DROP 'spam'; check that column/key exists

O.k. die Fehler erklären sich mit einer vorherigen Installation einer 2.5-er Version oder einer Testversion 2.4.99.x. Wenn von dort aus ein Downgrade zu einer stabilen 2.4.x-Version erfolgt und die Tabellen für 2.5-er Versionen (die in den ersten vier Meldungen genannten Tabellen) nicht aus der Datenbank gelöscht werden, führt der erneute Versuch sie anzulegen, zu diesen Fehlern. Zudem scheint auch deine Tabelle für die Forumseinträge schon auf dem 2.5-er Stand gewesen zu sein, denn sonst müsste es die Spalte spam (aus den Meldungen sieben bis neun) noch geben.

Und jetzt, während ich das schreibe, stelle ich mir die Frage, ob bei einem ersten Upgrade-Versuch eventuell gemeldet worden sein könnte, dass es eine doppelt benutzte E-Mail-Adresse gibt? Durch die reihenfolge der Datenbankänderungen verbleibt das Forum so in einem unbenutzbaren halb2.4-und-halb-2.5-Status ...

Wenn man das Forum aufruft, funktioniert es nicht mehr: https://www.topfree.de/forum/ ("Unknown column 'spam' in 'where clause'").

... was dann derartige Fehler zur Folge hat.

Allerdings läuft die neueste Version 20220803.1 > https://www.topfree.de/forum2/ auf meinem Sever.

Ja, eine Neuinstallation funktioniert. Bisher gab es dazu jedenfalls keine Fehlermeldungen.

Hilft jetzt nur ein Backup (und dann?)? Oder kann man die Beiträge und Benutzer in die neue Version irgendwie importieren?

Ein Backup der Inhalte der Tabellen (nicht von deren Struktur), die es schon im 2.4-er Zweig gab, ist per se sinnvoll. Damit ließe sich mit etwas Handarbeit [1] ein Forum mit einer stabilen 2.4.x-Version rekonstruieren und wieder in Betrieb nehmen.

Das nur teilweise vollzogene Upgrade sorgt allerdings dafür, dass ein Forum als leer angezeigt wird, obwohl es jede Menge Einträge haben kann, weil relevante Änderungen bezüglich der Spambehandlung nicht erfolgt sein können. Ein händisches Upgrade ist mit Hilfe der Abfragen aus dem Update-Skript prinzipiell möglich, sie können ja schließlich auch mit phpMyAdmin ausgeführt werden, wenn die Tabellennamen eingesetzt wurden. Aber das sollte man nur tun, wenn man sich im Code des Update-Skripts auskennt, in phpMyAdmin die bereits erfolgten Änderungen herauslesen kann und damit enrtscheiden kann, welche Datenbankabfragen noch fehlen.

Ein Upgrade auf Version 2.5.x (a.k.a. 20220-irgendwas.1) ist ohne diese Kenntnisse, so muss ich das mittlerweile sagen, vorläufig nicht zu empfehlen. Ich arbeite aber an einem neuen Upgrade-Skript mit einer korrigierten Reihenfolge der Änderungsschritte. Damit wird eine notwendige Überprüfung von möglichen Stolperfallen an den Anfag eines Upgrades gerückt, womit bei einer notwendigen Vorarbeit das Upgrade erst gar nicht beginnt. Aber das ist leider noch nicht fertig.

Tschö, Auge

[1]: In deinem Backup fehlen ja nun die Werte zum Spamstatus der Einträge und eventuell doppelt benutzte E-Mail-Adressen wären nach wie vor vorhanden.

--
Trenne niemals Müll, denn er hat nur eine Silbe!

It says some errors after finishing installing ! like "Missing Config/VERSION !

I would really want a solution for this thanks !

Hello

It says some errors after finishing installing !

Which errors (beside the missing config/VERSION)?

like "Missing Config/VERSION !

Why didn't you upload this file? The readme says in section Installation, point 2. one has to upload the whole script package (including config/VERSION).

I would really want a solution for this thanks !

Here you go.

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

Output:
"Error in line 42: Missing the file config/VERSION."

But:

https://asciinema.org/a/3mGTiEHRBKnIcpqyDgtVghzp3

Hello

Output:
"Error in line 42: Missing the file config/VERSION."

But:

https://asciinema.org/a/3mGTiEHRBKnIcpqyDgtVghzp3

Ok, you proved me wrong. I see the content of the file in your screencast.

Sorry for insisting, you are sure to run the installation script in the directory /home/shoqni/web/shoqni.com/public_html/forum/install/? The code in the line 41, which causes the error message in line 42, asks only for the existience of this file with a relative path from the installation script to the file in question (if(!file_exists('../config/VERSION')) …).

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

Hello

Output:
"Error in line 42: Missing the file config/VERSION."

But:

https://asciinema.org/a/3mGTiEHRBKnIcpqyDgtVghzp3

Ok, you proved me wrong. I see the content of the file in your screencast.

Sorry for insisting, you are sure to run the installation script in the directory /home/shoqni/web/shoqni.com/public_html/forum/install/? The code in the line 41, which causes the error message in line 42, asks only for the existience of this file with a relative path from the installation script to the file in question (if(!file_exists('../config/VERSION')) …).

Tschö, Auge

Well managed to install it and there is for demo https://shoqni.com/bbs .... but !

My session expires and seems that nothing that I want to apply to forum such as posting or adding categories is working does that have to do that I use nginx instead of Apache2 or !

Hallo Auge,

folgende Randbedingungen:
- 1000 Danke erstmal für die ständige Unterstützung!

- gestartet mit 2.3.5 unter Mysql 5.7
- durch IONOS eingeschränkt in der Auswahl der PHP Version (entweder 5.6 - 7.3 oder 8.1)

Ziel: neueste Version unter MariaDB 10.6 und PHP8.1
- Update auf 2.3.7 - PHP5.6- OK
- Update auf 2.4.24 - Update auf PHP7.3 - OK
- Update auf 20220803 - PHP7.3 und PHP8.1 - fast ok

Forum ist zu Beginn komplett geklont+Backup worden.
Forum läuft grundsätzlich, aber folgende Fehlermeldungen:

[31-Mar-2023 19:00:30 Europe/Berlin] PHP Notice: Undefined index: word_delimiters in xxx/forum_php8/includes/posting.inc.php on line 851
[31-Mar-2023 19:00:58 Europe/Berlin] PHP Notice: Undefined index: word_delimiters in xxx/forum_php8/includes/posting.inc.php on line 840
[31-Mar-2023 19:00:58 Europe/Berlin] PHP Notice: Undefined index: word_delimiters in xxxforum_php8/includes/posting.inc.php on line 851
[31-Mar-2023 19:12:39 Europe/Berlin] PHP Notice: Undefined index: word_delimiters in xxx/forum_php8/includes/posting.inc.php on line 855
[31-Mar-2023 19:12:39 Europe/Berlin] PHP Notice: Undefined index: word_delimiters in xxx/forum_php8/includes/posting.inc.php on line 866

und

[31-Mar-2023 19:32:03 Europe/Berlin] PHP Warning: Undefined array key "word_delimiters" in xxx/forum_php8/includes/posting.inc.php on line 855
[31-Mar-2023 19:32:03 Europe/Berlin] PHP Warning: Undefined array key "word_delimiters" in xxx/forum_php8/includes/posting.inc.php on line 866

Mir raucht da grade der Kopf...
Mein Skill: root Zugang zum Server, etwas Mysql Erfahrung, Linux Erfahrung, nicht genug PHP Erfahrung....

Bei Bedarf kann ich Dir die Webseite sagen, sie ist ja online.
Irgendwelche Ideen?

Gruß
Andi

Hallo

… ohne jetzt in den Code geschaut zu haben …

Die immer wieder selben, nicht vorhandenen Indexe riechen für mich nach nicht aktualisierten *.lang-Dateien. Dort haben wir mitten im 2.4-er Zweig dieses Schlüssel-Wert-Paar eingeführt, weil das Trennen der Worte mit Leerzeichen zu ihrer Überprüfung (Länge, Bad Words) in der chinesischen Sprache nicht funktioniert.

Kopiere bitte noch einmal die Sprachdateien der passenden MLF-Version in deine Installation und teste, ob die Fehler verschwinden.

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

Hi Auge,

nach dem Kopieren nur noch 2 dieser array key Fehler (reproduzierbar):
Die Dateien waren aber im diff identisch...

[01-Apr-2023 10:16:53 Europe/Berlin] PHP Warning: Undefined array key "word_delimiters" in xxx/forum_php8/includes/posting.inc.php on line 855
[01-Apr-2023 10:16:53 Europe/Berlin] PHP Warning: Undefined array key "word_delimiters" in xxx/forum_php8/includes/posting.inc.php on line 866

aber beim ersten Aufruf und nur genau 1 Mal (nicht reproduzierbar):

[01-Apr-2023 10:15:18 Europe/Berlin] PHP Warning: Undefined array key "email_notify_inactive_user_text" in /homepages/34/xxx/htdocs/forum_php8/includes/functions.inc.php on line 204
[01-Apr-2023 10:15:18 Europe/Berlin] PHP Deprecated: str_replace(): Passing null to parameter #3 ($subject) of type array|string is deprecated in /homepages/34/xxx/htdocs/forum_php8/includes/functions.inc.php on line 204
[01-Apr-2023 10:15:18 Europe/Berlin] PHP Warning: Undefined array key "email_notify_inactive_user_subject" in /homepages/34/xxx/htdocs/forum_php8/includes/functions.inc.php on line 209
[01-Apr-2023 10:15:18 Europe/Berlin] PHP Deprecated: str_replace(): Passing null to parameter #3 ($subject) of type array|string is deprecated in /homepages/34/xxx/htdocs/forum_php8/includes/functions.inc.php on line 209
[01-Apr-2023 10:15:19 Europe/Berlin] PHP Warning: Undefined array key "email_notify_inactive_user_text" in /homepages/34/xxx/htdocs/forum_php8/includes/functions.inc.php on line 204
[01-Apr-2023 10:15:19 Europe/Berlin] PHP Deprecated: str_replace(): Passing null to parameter #3 ($subject) of type array|string is deprecated in /homepages/34/xxx/htdocs/forum_php8/includes/functions.inc.php on line 204
[01-Apr-2023 10:15:19 Europe/Berlin] PHP Warning: Undefined array key "email_notify_inactive_user_subject" in /homepages/34/xxx/htdocs/forum_php8/includes/functions.inc.php on line 209
[01-Apr-2023 10:15:19 Europe/Berlin] PHP Deprecated: str_replace(): Passing null to parameter #3 ($subject) of type array|string is deprecated in /homepages/34/xxx/htdocs/forum_php8/includes/functions.inc.php on line 209
[01-Apr-2023 10:15:19 Europe/Berlin] PHP Warning: Undefined array key "email_notify_inactive_user_text" in /homepages/34/xxx/htdocs/forum_php8/includes/functions.inc.php on line 204
[01-Apr-2023 10:15:19 Europe/Berlin] PHP Deprecated: str_replace(): Passing null to parameter #3 ($subject) of type array|string is deprecated in /homepages/34/xxx/htdocs/forum_php8/includes/functions.inc.php on line 204
[01-Apr-2023 10:15:19 Europe/Berlin] PHP Warning: Undefined array key "email_notify_inactive_user_subject" in /homepages/34/xxx/htdocs/forum_php8/includes/functions.inc.php on line 209
[01-Apr-2023 10:15:19 Europe/Berlin] PHP Deprecated: str_replace(): Passing null to parameter #3 ($subject) of type array|string is deprecated in /homepages/34/xxx/htdocs/forum_php8/includes/functions.inc.php on line 209
[01-Apr-2023 10:15:19 Europe/Berlin] PHP Warning: Undefined array key "email_notify_inactive_user_text" in /homepages/34/xxx/htdocs/forum_php8/includes/functions.inc.php on line 204
[01-Apr-2023 10:15:19 Europe/Berlin] PHP Deprecated: str_replace(): Passing null to parameter #3 ($subject) of type array|string is deprecated in /homepages/34/xxx/htdocs/forum_php8/includes/functions.inc.php on line 204
[01-Apr-2023 10:15:19 Europe/Berlin] PHP Warning: Undefined array key "email_notify_inactive_user_subject" in /homepages/34/xxx/htdocs/forum_php8/includes/functions.inc.php on line 209
[01-Apr-2023 10:15:19 Europe/Berlin] PHP Deprecated: str_replace(): Passing null to parameter #3 ($subject) of type array|string is deprecated in /homepages/34/xxx/htdocs/forum_php8/includes/functions.inc.php on line 209
[01-Apr-2023 10:15:19 Europe/Berlin] PHP Warning: Undefined array key "email_notify_inactive_user_text" in /homepages/34/xxx/htdocs/forum_php8/includes/functions.inc.php on line 204
[01-Apr-2023 10:15:19 Europe/Berlin] PHP Deprecated: str_replace(): Passing null to parameter #3 ($subject) of type array|string is deprecated in /homepages/34/xxx/htdocs/forum_php8/includes/functions.inc.php on line 204
[01-Apr-2023 10:15:19 Europe/Berlin] PHP Warning: Undefined array key "email_notify_inactive_user_subject" in /homepages/34/xxx/htdocs/forum_php8/includes/functions.inc.php on line 209
[01-Apr-2023 10:15:19 Europe/Berlin] PHP Deprecated: str_replace(): Passing null to parameter #3 ($subject) of type array|string is deprecated in /homepages/34/xxx/htdocs/forum_php8/includes/functions.inc.php on line 209

Ein anderes Gimmick sind die Prozentzeichen beim Datum/Uhrzeit:

[image]

Gruß
Andi

Hi,

in den Sprachdatei steht aber der Schlüssel word_delimiters bei Dir drin, oder?

Bist Du bereits bei der letzten Version angekommen oder noch bei einer Vorversion? Verschwinden die Fehler, wenn Du wieder auf PHP7.3 gehst?

Viele Grüße
Micha

--
applied-geodesy.org - OpenSource Least-Squares Adjustment Software for Geodetic Sciences

Hallo Micha,

in den Sprachdatei steht aber der Schlüssel word_delimiters bei Dir drin, oder?

ja, tut es. In /lang/german.lang:
[image]

Bist Du bereits bei der letzten Version angekommen oder noch bei einer Vorversion?

sollte die letzte sein:
[image]

Verschwinden die Fehler, wenn Du wieder auf PHP7.3 gehst?

Nein, keine Änderung mit 7.3.33

Die "Undefined index ..." Fehler entstehen beim Antworten oder beim Erzeugen vom neuen Thema.

Danke fürs Kümmern!

Gruß
Andi

Hallo,

die ganzen updates waren letztlich doch nur notwendig, um die Datenbankänderungen alle durchzuführen. Wenn wir davon ausgehen, dass alle UPDATE, INSERT usw. Statements korrekt waren und die SQL-DB auf dem aktuellen stand ist, dann würde ich mal _alle_ Dateien aus der aktuellen version hochladen, sodass wirklich alles vorhanden ist und sich auf die aktuelle Version bezieht. Kannst Du das mal bitte machen?

Viele Grüße
Micha

--
applied-geodesy.org - OpenSource Least-Squares Adjustment Software for Geodetic Sciences

Hallo Micha,

ja, mach ich gleich; soll ich mit PHP7.3 oder 8.1 testen?

Gruß
Andi

Hallo,

mit 8.1, da Du bereits auf der gegenwärtig aktuellen Version bist.

/Micha

--
applied-geodesy.org - OpenSource Least-Squares Adjustment Software for Geodetic Sciences

Hallo Micha,

ich habe aus dem Download nun alle Dateien drüberkopiert.
# cp -vr * /forum

Keine Änderung beim Fehler "Undefined index: word_delimiters".

Neuer Fehler:

[image]

unter dem Feld E-Mail-Benachrichtigung sind nun 3 Radio Buttons ohne Text aufgetaucht.
(identisch wie bei den Einstellungen - anderer Thread hier)

Status ist jetzt mit PHP 8.1

Gruß
Andi

Hi,

kannst Du mal bitte den Inhalt vom "templates_c" Verzeichnis leeren?

/Micha

--
applied-geodesy.org - OpenSource Least-Squares Adjustment Software for Geodetic Sciences

Hallo Micha,

hab ich natürlich vergessen; nachgeholt.
Das Avatar wird jetzt wieder angzeigt.

Fehler "Undefined index..." ist jetzt ein anderen, aber die gleiche Zeile.

[01-Apr-2023 13:29:55 Europe/Berlin] PHP Warning: Undefined array key "word_delimiters" in xxx/forum_php8/includes/posting.inc.php on line 855
[01-Apr-2023 13:29:55 Europe/Berlin] PHP Warning: Undefined array key "word_delimiters" in xxx/forum_php8/includes/posting.inc.php on line 866

Da hab ich aber jetzt nicht aufgepasst, ob das mit dem Wechsel von PHP7 zu PHP8 synchron ging.

Fehler in der Datumsanzeige besteht weiter.
Fehler der Fußzeile besteht weiter.

Gruß
Andi

Hi,

bei 2 Einstellungen (Admin/Einstellungen) fehlt Text.
Diese Einstellung gab es in 2.3.5 nicht.

[image]

Gruß
Andi

Hallo

bei 2 Einstellungen (Admin/Einstellungen) fehlt Text.
Diese Einstellung gab es in 2.3.5 nicht.

#1

Dort sollte analog zu den darüber befindlichen Einstellungen zu den Nutzungsbedingungen jene für die Datenschutzerklärung zu sehen sein. Diese wurden mit Version 2.4.10 eingeführt.

#2

Dort sollten die Einstellungen zum Gelesen-Status zu sehen sein. Eingeführt wurde die neue Funktion mit einer der ersten Versionen des 2.4-er Zweigs.

Zum Zeitpunkt deines Postings, auf das ich hiermit antworte, fehlten also immer noch Post-2.3.5-Strings. Hat sich das mit dem Leeren von templates_c gänzlich erledigt? Hast du zusätzlich das Forum noch einmal mit [STRG]+[F5] neu geladen, um eventuell im Browser-Cache vorhandene veraltete Versionen von Dateien (z.B. style.min.css oder JS-Dateien) zu aktualisieren?

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

Hallo,

Zum Zeitpunkt deines Postings, auf das ich hiermit antworte, fehlten also immer noch Post-2.3.5-Strings. Hat sich das mit dem Leeren von templates_c gänzlich erledigt?

DAS finde ich total komisch. Für sich sieht es so aus, als würden wir die falschen Dateien abgleichen. Die, die wir uns ansehen, sind nicht die, die das Forum im Livesystem auch verwendet - warum auch immer. Ich kann mir zumindest nicht erklären, warum teile aus einer Datei geladen werden und andere nicht.

/Micha

--
applied-geodesy.org - OpenSource Least-Squares Adjustment Software for Geodetic Sciences

Hallo Micha,

Zum Zeitpunkt deines Postings, auf das ich hiermit antworte, fehlten also immer noch Post-2.3.5-Strings. Hat sich das mit dem Leeren von templates_c gänzlich erledigt?

nein

DAS finde ich total komisch. Für sich sieht es so aus, als würden wir die falschen Dateien abgleichen. Die, die wir uns ansehen, sind nicht die, die das Forum im Livesystem auch verwendet - warum auch immer. Ich kann mir zumindest nicht erklären, warum teile aus einer Datei geladen werden und andere nicht.

da ich offenbar der einzige bin, der das hat: fühlt sich für mich auch so an.

Ich schlage vor, ich beginne nochmal von vorn mit der 2.3.5.
Checke dann das Design und die von mir genannten Dinge.

Dann der Update auf 2.3.7 - prüfen
Update auf 2.4.24 - prüfen

Erst wenn das fehlerfrei ist, (in allen Punkte) - neuer Download, neuer Versuch - prüfen.
Ich melde mich hier dann mit dem Status.

Gruß
Andi

Hallo

DAS finde ich total komisch. Für sich sieht es so aus, als würden wir die falschen Dateien abgleichen. Die, die wir uns ansehen, sind nicht die, die das Forum im Livesystem auch verwendet - warum auch immer. Ich kann mir zumindest nicht erklären, warum teile aus einer Datei geladen werden und andere nicht.

da ich offenbar der einzige bin, der das hat: fühlt sich für mich auch so an.

Ich schlage vor, ich beginne nochmal von vorn mit der 2.3.5.
Checke dann das Design und die von mir genannten Dinge.

Mir schwant etwas. Du führst die Upgrade-Tests in einer separaten Installation aus? Benutzt du als Nutzdaten eventuell die des Livesystems beziehungsweise eine Eins-Zu-Eins-Kopie der Livedaten? Auch die Einstellungen? Vielleicht diese auch gegenüber dem Livesystem unverändert?

Wenn ja, dann stehen dem Testsystem an der einen oder anderen Stelle vielleicht die Pfade des Livesystems und damit falsche Pfade zur Verfügung. Dass im Testsystem laut deinen Angaben die korrekten Sprachdateien installiert sind, aber dennoch (die) Teile fehlen, die nach der Version 2.3.5 hinzugekommen sind, sieht für mich überaus verdächtig aus.

Auch deine Meldungen bezüglich verschobener oder fehlender Elemente sieht für mich danach aus, dass auch die geladene CSS-Datei die falsche ist.

Wenn du das Testsystem für den neuen Durchlauf aufsetzt, gehe bitte nach der Installation in die Einstellungstabelle (am besten mit phpMyAdmin oder einem vergleichbaren Tool, das unabhängig von der MLF-Oberfläche funktioniert) und prüfe die dort bereitgestellten Pfadangaben darauf, dass sie auf das Testsystem verweisen.

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

Hallo Auge,

da ich offenbar der einzige bin, der das hat: fühlt sich für mich auch so an.
Ich schlage vor, ich beginne nochmal von vorn mit der 2.3.5.

Wenn du das Testsystem für den neuen Durchlauf aufsetzt, gehe bitte nach der Installation in die Einstellungstabelle (am besten mit phpMyAdmin oder einem vergleichbaren Tool, das unabhängig von der MLF-Oberfläche funktioniert) und prüfe die dort bereitgestellten Pfadangaben darauf, dass sie auf das Testsystem verweisen.

Das wäre durchaus eine plausibele Erklärung für das Verhalten.
Es war in jedem Fall eine 1:1 Dateikopie vom Pfad des originalen Forum und
eine Backup/Restore Funktion der Datenbank über das Ionos Tool.
Nur die db_settings.php habe ich anschließend von Hand kopiert/angepasst damit die kopierte Datenban genutzt wird;
sonst keinen Pfad.

Da ich noch nicht mit einem erneuten Lauf begonnen habe, kann (würde) ich solche Checks
bei der 2.3.7 und der 2.4.24 machen.
Dabei würde ich (nur um sicher zu gehen) auch die Dateien nach alten/falschen Pfaden durchsuchen
ob evt. ein hardcoded Pfad drinsteckt.

Da ich die SQL Kommandos auf dem Server von Hand ausführen kann, sollte das mit "select * from "
und einem grep hoffentlich sichtbar werden.

Danke für euren Support!

Gruß
Andi

Hallo

Da ich noch nicht mit einem erneuten Lauf begonnen habe, kann (würde) ich solche Checks
bei der 2.3.7 und der 2.4.24 machen.

Mache das einfach direkt nach der Installation des Testforums. Durchforste die Tabelle mlf2_settings nach dem Schlüssel forum_address und passe den Wert auf die reale URL des Testforums an, ändere itte vorsichtshalber auch den Wert des Schlüssels session_prefix, um Kollisionen mit einem eventuell offenen Tab des "echten" Forums zu vermeiden. Hänge einfach noch eine Ziffer an den Session-Namen. Du wirst, falls du das in den erweiterten Einstellungen des Forums tust, nach dem Absenden des Formulars ausgeloggt, kannst dich aber sofort wieder einloggen.

Im weiteren Verlauf der Update-Arie dürfte sich an den Pfaden, die aus den Einstellungen stammen, nichts mehr ändern.

Dabei würde ich (nur um sicher zu gehen) auch die Dateien nach alten/falschen Pfaden durchsuchen
ob evt. ein hardcoded Pfad drinsteckt.

Das sollte nicht der Fall sein … aber wer weiß.

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

Hi,

die Fußzeile ist verschoben.

[image]

nach dem "antworten" scheint ein Zeilenumbruch zu fehlen,
die Ausrichtung des Minimenu ist nicht mehr nach rechts..

[image]

Gruß
Andi

Hi,

das Avatar wird nicht angezeigt.
Das entsprechende Verzeichnis ist mit den Rechten 777 versehen.
Die Datei die im Quelltext genannt wird, ist vorhanden.
Die Datei ist im direkten Zugriff mit dem Browser aufrufbar und wird angezeigt.

[image]

Im Quelltext ist das Avatar aber angegeben....

[image]

Ein Rechteproblem?

Gruß
Andi

Hier hat geholfen:

- aus dem Download der aktuellen Datei alle Dateien ins Verzeichnis vom Forum kopieren
- in templates_c alle Dateien löschen

Gruß
Andi

Bei den Einstellungen ist ein(für mich) neues Symbol wie ein Bild, aber ohne Text.

[image]

darauf klicken, dann sieht man:

[image]

kann die Markierungskästchen klicken und unten "löschen".

Sollten die Bilder hier angezeigt werden?

Gruß
Andi

Hallo

Bei den Einstellungen ist ein(für mich) neues Symbol wie ein Bild, aber ohne Text.

So soll es aussehen.

[image]

darauf klicken, dann sieht man:

kann die Markierungskästchen klicken und unten "löschen".

Sollten die Bilder hier angezeigt werden?

Ja, dort sollen die Bilder als Thumbnails zu sehen sein.

[image]

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

Hi,

danke;
ich werde nochmal komplett von vorne mit den Updates beginnen.
Erst wenn die 2.4.24 fehlerfrei läuft, würde ich hier wieder melden.

Gruß
Andi

Hi,

habe heute einen neuen Versuch gestartet.
Beginnend mit der 2.3.5 bin ich auf 2.3.7 gegangen.

Die Empfehlung auch in der Datenbank die Foren-Adresse anzupassen, berücksichtigt.
Die 2.3.7 lief auch fehlerfrei, keiner der von mir genannten Fehler sind aufgetreten.

Vor dem nächsten Schritt:
theme ist default
templates_c Dateien gelöscht
Backup von Dateien der 2.3.7 und der DB
PHP war aber noch auf 5.6

Der Schritt zur 2.4.24 ist dann allerdings gescheitert.
Verschiedene Fehler, aber der wohl wichtigste: es ist https scheinbar zwingend vorgeschrieben.

Firefox meldet:
Beim Verbinden mit xxx-forum.de trat ein Fehler auf. Die Gegenstelle meldet, dass sie auf einen internen Fehler gestoßen ist.

Fehlercode: SSL_ERROR_INTERNAL_ERROR_ALERT
Die Website kann nicht angezeigt werden, da die Authentizität der erhaltenen Daten nicht verifiziert werden konnte.

Da ich die hierfür genutzte Domäne noch nicht auf https umgestellt hatte, komm ich hier nicht weiter ohne erstmal Geld an Ionos zu zahlen.

Mit Chromium wird das Forum zwar angezeigt, aber sowohl "antworten" als auch "neues Thema" springen um auf "xxx-forum.de/index.php?mode=login&action=tou" (kein Schreibfehler, exakt das).
"der Server hat eine falsche Anwort geliefert".
Sichtbar ist nur ein ausgegrautes Feld und 2 kleine Pseudobuttons drunter.

Als Fehlermeldung im Log:

06-Apr-2023 21:02:03 Europe/London] PHP Fatal error: Uncaught Error: Call to undefined function get_magic_quotes_gpc() in xxx/htdocs/forum_php8/includes/main.inc.php:8
Stack trace:
#0 xxx/htdocs/forum_php8/index.php(35): include()
#1 {main}
thrown in x/htdocs/forum_php8/includes/main.inc.php on line 8
[06-Apr-2023 21:02:12 Europe/London] PHP Fatal error: Uncaught Error: Call to undefined function get_magic_quotes_gpc() in xxx/htdocs/forum_php8/includes/main.inc.php:8
Stack trace:
#0 xx/htdocs/forum_php8/index.php(35): include()
#1 {main}
thrown in xxx/htdocs/forum_php8/includes/main.inc.php on line 8

Auch mit frisch gelöschtem templates_c Verzeichnis, keine Änderung.
Kopieren vom kompletten Dateibaum aus dem Archiv 2.4.24 - keine Änderung.

Würde es was bringen, vor dem Update von 2.4.24 auf PHP7.3 zu gehen?
Den Versuch kann ich ja noch machen.

Gruß
Andi

Hi,
ich werde versuchen, das Forum innerhalb der gültigen https Umgebung zu klonen.
Vielleicht ist dann der Fehler weg.

Gruß
Andi

Hallo

MLF 2.4.24 läuft explizit nicht unter PHP 8. Du musst an dieser Stelle also zwingend bei PHP 7.3 bleiben.

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

Hi,
ok; ich bin bis 2.4.24 gekommen und dort ohne Fehler.

Da ich das Forum erst in 3. Generation übernommen habe und es eben seither lief,
hatte ich mich nicht so intensiv damit beschäftigt.
Es lagen nur Fehler vor, die auf Grund vorheriger Änderungen entstanden sind.
Zusätzlich eben, dass https inzwischen berechtigtiger Weise zum Standard wurde.

Als nächstes steht das Update auf die aktuelle Version an.
Ich werde berichten....

Gruß
Andi

Hallo

ok; ich bin bis 2.4.24 gekommen und dort ohne Fehler.

Sehr schön. Das läuft jetzt unter PHP 7.3?

Da ich das Forum erst in 3. Generation übernommen habe und es eben seither lief,
hatte ich mich nicht so intensiv damit beschäftigt.
Es lagen nur Fehler vor, die auf Grund vorheriger Änderungen entstanden sind.
Zusätzlich eben, dass https inzwischen berechtigtiger Weise zum Standard wurde.

Ich würde dir empfehlen, dich als nächstes um ein Zertifikat zu kümmern. IONOS ist ein großer Hosting-Anbieter. Ich würde vermuten, dass die kostenfreie Let's-Encrypt-Zertifikate anbieten. Wenn ja, sieh zu, dass du etwaige Subdomains in das Zertifikat einbeziehst oder, wenn verfügbar, ein Wildcard-Zertifikat bekommst, das sich automatisch auf alle, auch zukünftig anzulegende, Subdomains bezieht.

Dann hast du erst einmal dieses Thema vom Tisch. Selbst wenn du vorerst bei MLF 2.4.24 bliebest, wäre der Traffic inklusive zu übertragender Zugangsdaten verschlüsselt. Das ist heutzutage einfach Stand der Technik.

Als nächstes steht das Update auf die aktuelle Version an.
Ich werde berichten....

Wir harren der Berichte. :-)

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

Hi,
beim Durchprobieren bin ich hier drauf gestossen:

[image]

Der Beitrag hat keine Antwort, wurde vor Sekunden bearbeitet (als Admin),
kann aber nicht gelöscht werden.
Eine Sperrung ist nicht erkennbar.

Wie lautet die Einstellung für das Sperren(bzw der Zeitablauf dafür)?
Beim Thread ist der Name von Ersteller sichtbar, hier steht er auf "unbekannt".

Gruß
Andi

(Status: 2.4.24 - PHP7.3, sonst keine Fehler mehr gefunden)

Nachtrag:

ich bin dem Eintrag von candleman nachgegangen (gleiches Problem).
Ich habe in der posting.inc.php vom Download der 2.4.24 die entsprechende Zeile NICHT gefunden.

Muss jetzt weg; ich melde mich erneut dazu.

Gruß
Andi

Hallo,

ich bin dem Eintrag von candleman nachgegangen (gleiches Problem).
Ich habe in der posting.inc.php vom Download der 2.4.24 die entsprechende Zeile NICHT gefunden.

Ein Link zu diesem besagten Posting wäre ggf. hilfreich.

/Micha

--
applied-geodesy.org - OpenSource Least-Squares Adjustment Software for Geodetic Sciences

Hi,

vorab: möglicherweise passt die Zeilennummer aus dem Beitrag von candleman nicht.

Der Verweis zum Thread:
https://mylittleforum.net/forum/index.php?id=11863

Der Verweis, wo es in der posting.inc.php stehen soll:
https://github.com/My-Little-Forum/mylittleforum/pull/469/files

Der Query-String den mein Browser anzeigt:
https://xxx.de/index.php?mode=posting&delete_posting=169462&csrf_token=6432aa163870b5.99373782&back=entry

In der von mir mit 2.4.24 eingespielten posting.inc.php befindet sich in Zeile 1373 folgendes:

if ($authorization['delete'] === true && isset($_REQUEST['csrf_token']) && $_REQUEST['csrf_token'] == $_SESSION['csrf_token']) {

und das entspricht syntaktisch nicht dem was hier
https://github.com/My-Little-Forum/mylittleforum/pull/469/files
erwähnt wird.
Dort:
if ($authorization['delete'] == true && isset($_REQUEST['csrf_token']) && $_REQUEST['csrf_token'] === $_SESSION['csrf_token']) {

sind die Prüfungen "==" und "===" anders geschrieben.
Scheint aber keine Rolle zu spielen, im Versuch war es das gleiche Ergebnis: nur die Methode 2 (markieren und mit der "markierte löschen") funktioniert mit beiden Schreibweisen.

Meine bescheidenen Versuche das einzugrenzen enden dahingehend, dass in Zeile 1374 der posting.inc.php der $_REQUEST['csrf_token'] scheinbar nicht gesetzt ist.
Das explizit im Logfile auszugeben war nicht möglich.
Den Token für die $_SESSION konnte ich aber anzeigen.

Gruß
Andi

Hallo Andi,

vorab: möglicherweise passt die Zeilennummer aus dem Beitrag von candleman nicht.

Mit scheint, dass auch das Problem nicht kompatibel ist. Bei candleman fehlte doch offensichtlich der Token. Soweit ich Deine URI sehe

Der Query-String den mein Browser anzeigt:
https://xxx.de/index.php?mode=posting&delete_posting=169462&csrf_token=6432aa163870b5.99373782&back=entry
[...]
dass in der posting.inc.php der $_REQUEST['csrf_token'] scheinbar nicht gesetzt ist.

ist dieser bei Dir vorhanden. Insofern erscheint mir das Problem nicht vergleichbar. Du kannst Dir in der PHP-Datei ja gern eine temporäre Ausgabe machen direkt hinter der if-Bedingung:

var_dump($_REQUEST);
exit;

sodass Du den Inhalt von $_REQUEST prüfen kannst.

Viele Grüße
Micha

--
applied-geodesy.org - OpenSource Least-Squares Adjustment Software for Geodetic Sciences

Hi,
hab das mal eingebaut und getestet.
Allerding VOR der IF-Prüfung in Zeite 1372, da diese ja fehl schlägt.

array(8) {
["mode"]=> string(7) "posting"
["delete_posting"]=> string(6) "169462"
["back"]=> string(5) "entry"
["delete_posting_confirm"]=> string(13) "OK - Löschen"
["m237_usersettings"]=> string(9) "0.0.1.0.0"
["m237_last_visit"]=> string(21) "1680856233.1680856233"
["m237_auto_login"]=> string(52) "caDCzn68QrqoPPJ3Ts1lNY2wx3RwITC97hPmx9qih5c2P4wkOc12" ["PHPSESSID"]=> string(32) "9ec3abd3986bf2b1f64f5209ad0a70c9"

}

Gruß
Andi

Hallo Andi,

hab das mal eingebaut und getestet.
Allerding VOR der IF-Prüfung in Zeite 1372, da diese ja fehl schlägt.

Ja, dass ist natürlich noch besser (ich bin davon ausgegangen, dass die Bedingung erfüllt ist)

array(8) {
["mode"]=> string(7) "posting"
["delete_posting"]=> string(6) "169462"
["back"]=> string(5) "entry"
["delete_posting_confirm"]=> string(13) "OK - Löschen"
["m237_usersettings"]=> string(9) "0.0.1.0.0"
["m237_last_visit"]=> string(21) "1680856233.1680856233"
["m237_auto_login"]=> string(52) "caDCzn68QrqoPPJ3Ts1lNY2wx3RwITC97hPmx9qih5c2P4wkOc12" ["PHPSESSID"]=> string(32) "9ec3abd3986bf2b1f64f5209ad0a70c9"

}

Hier fehlt nun leider der Eintrag des Tokens. In Deiner URI steht aber csrf_token=6432aa163870b5.99373782 (natürlich mit einem anderen Token als Inhalt)? Wenn ja, muss der auch im globalen $_REQUEST-Array enthalten sein. Dieses Array enthält schließlich alles, was $_GET, $_POST oder auch $_COOKIE enthält. Es ist also das "übertragungsunabhängige" Array.

Wenn Du auf der Seite bist, auf der Du um Bestätigung zum Löschen aufgefordert wirst, und dort in den Quellcode schaust: Existiert dort ein verstecktes Feld mit dem Token?

/Micha

--
applied-geodesy.org - OpenSource Least-Squares Adjustment Software for Geodetic Sciences

Hallo Micha,

Wenn Du auf der Seite bist, auf der Du um Bestätigung zum Löschen aufgefordert wirst, und dort in den Quellcode schaust: Existiert dort ein verstecktes Feld mit dem Token?

/Micha

ich kuck:

<h1>Eintrag löschen</h1>
<p class="caution">Achtung!</p>
<p>Sicher, dass dieser Eintrag und alle Antworten gelöscht werden sollen?</p>
<p><strong>test 6</strong> - <strong>Andreas Schneider</strong>, Freitag, 07.04.2023, 11:31</p>
<form action="index.php" method="post" accept-charset="utf-8">
<div>
<input type="hidden" name="mode" value="posting" />
<input type="hidden" name="delete_posting" value="169462" />
<input type="hidden" name="back" value="entry" /><input type="submit" name="delete_posting_confirm" value="OK - Löschen" />
</div>
</form>
</div>

nee, das hat mit Deinem Beispiel nur sehr rudimentär was zu tun.
Damit hätten wir wohl die erste Spur.

Gruß
Andi

Hallo,

ja, das ist ein heißes Indiz. Du könntest nun die Template-Datei mal aktualisieren aber andererseits auch das Forum updaten. Ich gehe im Moment davon aus, dass wir es in einer der nachfolgenden Version behoben haben. Ich zumindest entnehme der Antwort von Auge, dass wir das schon mal gefixt hatten.

Viele Grüße
Micha

--
applied-geodesy.org - OpenSource Least-Squares Adjustment Software for Geodetic Sciences

Hallo Micha,

ich lösche mal die erzeugten templates und prüf es nochmal.
Aber Plan A lautet: Update.
Ich mach morgen weiter.

Danke und Gruß
Andi

Hallo,

ja, das ist ein heißes Indiz. Du könntest nun die Template-Datei mal aktualisieren aber andererseits auch das Forum updaten. Ich gehe im Moment davon aus, dass wir es in einer der nachfolgenden Version behoben haben. Ich zumindest entnehme der Antwort von Auge, dass wir das schon mal gefixt hatten.

Viele Grüße
Micha

Hallo

ja, das ist ein heißes Indiz.

Was in mir die Frage aufkommen lässt, wie das so lange unbemerkt geblieben ist. Version 2.4.24 ist am 12.10.2020 erschienen, die erste stabile Version des 2.5-er Zweigs (Version 20220508.1) am 08.05.2022. Wir haben im hiesigen Projektforum knapp 19 Monate mit der Version 2.4.24 gearbeitet. Auch andere Betreiber haben auf diese Version gesetzt. In keinem Forum soll aufgefallen sein, dass eine Version mit einem derart groben Schnitzer eingesetzt wurde?

Ich meine, selbst wenn hier das löschen von eigenen Postings überaus selten vorkommen dürfte, in anderen Foren sollte das hin und wieder vorkommen. Und da hätte es auffallen müssen.

Eines haben wir aber noch überhaupt nicht geklärt. Wie sehen denn die konkreten Einstellungen, die die Möglichkeit, ein eigenes Posting zu löschen, steuern, in Andreas' Forum aus? Und hat er seine Tests eventuell nicht als Admin sondern als normaler Benutzer durchgeführt, der seine eigenen Postings tatsächlich nicht löschen kann? Nicht, dass wir uns hier völlig umsonst die Köpfe heißreden und stattdessen eine Empfehlung zu den Einstellungen zielführend wäre.

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

Hallo

Wenn Du auf der Seite bist, auf der Du um Bestätigung zum Löschen aufgefordert wirst, und dort in den Quellcode schaust: Existiert dort ein verstecktes Feld mit dem Token?

Hmm, ich weiß ja nicht, welchen Commit-Stand du da verlinkt hast, aber in keiner der 2.4.x-Versionen vor 2.4.99.1, deren Stand ich per umschalten zwischen den Tags (Umschalter befindet sich im Screenshot links vor dem Pfad) geprüft habe, gibt es in posting_delete.inc.tpl dieses Feld. In der fraglichen Version 2.4.24 ist es also nicht vorhanden. In der Skript-Datei posting.inc.php ist ein CSRF-Token bei $action == 'delete_posting' auch nicht erforderlich. Das hat sich erst mit Version 2.4.99.1 geändert.

[image]

Erst bei $action == 'delete_posting_confirmed' wird ein CSRF-Token eingefordert, den es, wie schon gesagt im Template posting_delete.inc.tpl der Version 2.4.24 nicht gibt.

Da ich in dem Forum auf meiner Seite immer noch die Version 2.4.24 einsetze, habe ich mal danach gesucht. Stellt sich heraus, ich weiß nicht, wie ich ein Posting so zum löschen "vorschlage", dass ich eine Seite mit dem Template posting_delete.inc.tpl zu sehen bekomme. Wenn ich ein Posting in der Einzel- oder Threadansicht öffne und es über den Link in den Management-Funktionen unterhalb des Postings löschen will, wird mir ein JS-Modaldialog (Sind sie sich sicher … bla bla bla …) angezeigt. Wenn ich es über das Kreuz hinter dem Betreff im Threadbaum löschen will, wird mir ebenfalls dieser JS-Modaldialog angezeigt. Wenn ich Postings im Threadbaum markiere und diese löschen will, wird das Template posting_delete_marked.inc.tpl angezeigt. Gehe ich über den Weg, ein Posting als Spam zu klassifizieren (alter Weg ohne B8-Training), wird posting_delete.inc.php auch nicht benutzt. Bin ich zu doof oder wird das Template vielleicht überhaupt nicht benutzt?

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

Hallo,

Hmm, ich weiß ja nicht, welchen Commit-Stand du da verlinkt hast,

Den aktuellen, welchen sonst. ;-)

Aber klar, ich habe jetzt nicht geschaut, wann welche Modifikation durchgeführt wurde. Insofern kann ich bestimmte Äußerungen auch nicht direkt reproduzieren. Auf meiner Seite versuche ich das Forum aktuell zu halten.

Im Moment plädiere ich daher, mal das Update durchzuziehen. Mir scheint, dass dieses Problem bereits gelöst wurde.

Da ich in dem Forum auf meiner Seite immer noch die Version 2.4.24 einsetze, habe ich mal danach gesucht. Stellt sich heraus, ich weiß nicht, wie ich ein Posting so zum löschen "vorschlage", dass ich eine Seite mit dem Template posting_delete.inc.tpl zu sehen bekomme.

In der aktuellen Version kommt es, wenn man sich im Posting befindet und auf löschen klickt - würde ich sagen. Das konnte ich zumindest in Deinem Forum gerade so nachvollziehen. Hierzu musst Du das Löschen in einem neuen Tab vornehmen, sodass das JS-Alter nicht erscheint (klick mit der mittleren Maustaste).

Viele Grüße
Micha

--
applied-geodesy.org - OpenSource Least-Squares Adjustment Software for Geodetic Sciences

Hallo

Hmm, ich weiß ja nicht, welchen Commit-Stand du da verlinkt hast,

Den aktuellen, welchen sonst.

Aber klar, ich habe jetzt nicht geschaut, wann welche Modifikation durchgeführt wurde. Insofern kann ich bestimmte Äußerungen auch nicht direkt reproduzieren. Auf meiner Seite versuche ich das Forum aktuell zu halten.

Im Moment plädiere ich daher, mal das Update durchzuziehen. Mir scheint, dass dieses Problem bereits gelöst wurde.

So sollte er es auch tun. Vorsichtshalber sollte Andreas aber ein Backup des gegenwärtigen Datenbankstands erzeugen, der die Datenbankstruktur der Version 2.4.24 widerspiegelt. Dann muss er, falls irgendetwas schief läuft, nicht wider am Ausgangspunkt beginnen. Und er muss prüfen, ob sich mehrere Accounts finden, die die selbe E-Mail-Adresse benutzen. Weil dann das Update unweigerlich schief gehen würde.

Das lässt sich in einem Datenbanktool wie der MySQL-Workbench oder phpMyAdmin mit dem folgenden Query prüfen. Die Tabellennamen sind bei Bedarf anzupassen.

SELECT
  `user_id`,
  `user_name`,
  `user_email`
FROM `mlf2_userdata`
WHERE `user_email` IN(
  SELECT
    `user_email`
  FROM `mlf2_userdata`
  GROUP BY `user_email`
  HAVING COUNT(`user_email`) > 1)
ORDER BY `user_email` ASC, `user_name` ASC

Da ich in dem Forum auf meiner Seite immer noch die Version 2.4.24 einsetze, habe ich mal danach gesucht. Stellt sich heraus, ich weiß nicht, wie ich ein Posting so zum löschen "vorschlage", dass ich eine Seite mit dem Template posting_delete.inc.tpl zu sehen bekomme.

In der aktuellen Version kommt es, wenn man sich im Posting befindet und auf löschen klickt - würde ich sagen. Das konnte ich zumindest in Deinem Forum gerade so nachvollziehen. Hierzu musst Du das Löschen in einem neuen Tab vornehmen, sodass das JS-Alter nicht erscheint (klick mit der mittleren Maustaste).

Ahh, das geht tatsächlich nur mit der mittleren Maustaste oder über das Kontextmenü. Wenn ich stattdessen die Kombination [STRG]+[Linksklick] benutze, die ebenfalls einen neuen Tab öffnen sollte, wird mir, wie beim einfachen Linksklick, der JS-Modaldialog angezeigt. Und ja, da gibt es in der Version 2.4.24 keinen CSRF-Token, egal ob in meinem Theme oder dem mitgelieferten.

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

Hi,

habe grade das Update von 2.4.24 auf 20220803.1 durchgezogen.
(Backup der Files und Backup der DB vorher).

Die bei mir aufgetretenen Fehler von damals und die neuen im Schnelldurchgang:

#1 Datumsanzeige mit unerwarteten % Zeichen - fehlerfrei
#2 Fußzeile versetzt - fehlerfrei
#3 Einstellungen ohne Text (Adminbereich - Einstellungen) - fehlerfrei
#4 Adminbereiche Symbol für die Bilder ohne Text - besteht
#5 Symbol ist klickbar - aber es werden weder bestehende, noch frisch hochgeladene Dateien angezeigt (ich kann die Bilder die im html Quellcode genannt sind aber übers Web aufrufen)
#6 neuer Eintrag (Posting) - fehlerfrei
#7 löschen nicht möglich - keine der 3 Methoden funktioniert
(der von Micha genannte "erwartete" hidden Eintrag mit dem csrf_token fehlt)

#8 Geschwindigkeit in der Bedienung ist unterirdisch

Der Hinweis mit var_dump vom Token:
Wird posting.inc.php mit delete_posting aufgerufen, ist der Token vorhanden.
Wird sie mit delete_posting_confirmed aufgerufen - fehlt er.
Testhalber bei den case Varianten "edit" und "posting" - fehlt ebenfalls.

Gruß
Andi

Hi,
da ich von einer fehlenden/falsch kopierten Datei ausgegangen bin,
habe ich ein neues Forum aus den neuesten Quellen aufgesetzt.

#7 löschen nicht möglich - keine der 3 Methoden funktioniert
(der von Micha genannte "erwartete" hidden Eintrag mit dem csrf_token fehlt)

obwohl ich gemäß Anleitung aus den Quellen themes/default/* kopiert hatte,
gab es hier Unterschiede.
Ich habe dann aus der Neu-Installation themes/default/* rekursiv erneut drüberkopiert.

-> Fehler 7 ist verschwunden, der Token steht jetzt korrekt im html-Quellcode.

Im Forum welches die Updates erlebt hat, ist der Dialog zum löschen noch klassisch
(Text mit Button).
Beim neu installierten Forum dunkelt der Browser ab und ein Popup erscheint.

Ich check mal weiter ob die anderen Dinge auch machbar sind.

Gruß
Andi

Hallo

-> Fehler 7 ist verschwunden, der Token steht jetzt korrekt im html-Quellcode.

Ok, es hätte mich auch gewundert, wenn das prinzipiell nicht funktioniert hätte. Es gibt ja einige Installationen und ich gehe davon aus, dass ein solcher Fehler, wäre er im Programmcode verborgen, nicht erst ein halbes Jahr nach Veröffentlichung der aktuellsten Version aufgefallen wäre. Aber schön, dass du es, wenn auch erst einmal im Testlauf, hinbekommen hast.

Im Forum welches die Updates erlebt hat, ist der Dialog zum löschen noch klassisch
(Text mit Button).
Beim neu installierten Forum dunkelt der Browser ab und ein Popup erscheint.

Wie von Micha und mir in den Vorpostings erörtert (meine Frage, Michas Folgeposting und meine Reaktion (im letzten Absatz)), sieht das schon in meiner MLF-2.4.24-Installation so aus. Nur wenn man den Löschen-Link für ein Posting auf eine ganz bestimmte Art öffnet, sieht man die Seite mit dem Formular, das den CSRF-Token enthalten soll. Ansonsten bekommt man den JS-basierten Modal-Dialog zu sehen.

[edit]: Wenn das in deiner Installation, die du mit den Updates auf den neuen Stand gebracht hast, nicht so ist, dann könnte es sein, dass du entweder vergessen hast, die JavaScript-Dateien hochzuladen oder, dass dir dein Browsercache einen Streich spielt und meint, es gäbe keinen neueren Dateistand, als den, der im Browsecache bereits vorhanden ist. Lade die Dateien aus dem Unterverzeichnis javascript bitte noch einmal in deine upgegradete Installation hoch und lade in deinem Browser eine Seite des Forums oder alle geöffneten Tabs mit Seiten des Forums mit [STRG]+[F5] neu. Auf diese Weise werden alle Dateien neu vom Server geholt.

Ich check mal weiter ob die anderen Dinge auch machbar sind.

Mache das bitte.

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

Hallo

Der Verweis zum Thread:
https://mylittleforum.net/forum/index.php?id=11863

Der Verweis, wo es in der posting.inc.php stehen soll:
https://github.com/My-Little-Forum/mylittleforum/pull/469/files

Der Query-String den mein Browser anzeigt:
https://xxx.de/index.php?mode=posting&delete_posting=169462&csrf_token=6432aa163870b5.99373782&back=entry

Bei Candleman war das Problem, dass er offensichtlich vergessen hatte, beim Update einige Subtemplates hochzuladen, was dazu führte, dass der ab der Version 2.4.20 an der Stelle vorausgesetzte Token nicht im Template stand und somit auch nicht an den Server übertragen wurde, als er gebraucht wurde. Das ist bei dir aber der Fall. Das Token steht in der URL als deren Parameter csrf_token drin. Das ist es also nicht.

In der von mir mit 2.4.24 eingespielten posting.inc.php befindet sich in Zeile 1373 folgendes:

if ($authorization['delete'] === true && isset($_REQUEST['csrf_token']) && $_REQUEST['csrf_token'] == $_SESSION['csrf_token']) {

und das entspricht syntaktisch nicht dem was hier
https://github.com/My-Little-Forum/mylittleforum/pull/469/files
erwähnt wird.
Dort:
if ($authorization['delete'] == true && isset($_REQUEST['csrf_token']) && $_REQUEST['csrf_token'] === $_SESSION['csrf_token']) {

sind die Prüfungen "==" und "===" anders geschrieben.

Die Prüfungen sind unterschiedlich streng. Mit zwei Gleichheitszeichen wird in PHP "nur" geprüft, ob die Werte gleich sind, mit drei Gleichheitszeichen zudem, ob sie vom selben Datentyp sind.

Kleiner Exkurs:

Da PHP automatische Typumwandlungen bereitstellt, ist nicht nur "2" == "2" (zwei Zeichenketten, die jeweils aus der Ziffer 2 bestehen) wahr, sondern auch "2" == 2 (eine Zeichenkette, die aus der Ziffer 2 besteht und ein Integerwert 2). Wenn man typsicher vergleicht (mit drei Gleichheitszeichen), ist "2" === "2" wahr, aber "2" === 2 unwahr, da es sich um unterschiedliche Datentypen handelt.

Was den von dir gezeigten Code betrifft, gilt, dass man für die Prüfung der übermittelten Zeichenkette des Tokens gegen eine auf dem Server gespeicherte Version der selben Zeichenkette keine Typsicherheit braucht, für die Prüfung der als boolescher Wert gespeicherten grundsätzlichen Erlaubnis, ein Posting zu löschen ($authorization['delete'] === true), aber schon, da die automatische Typumwandlung in PHP bei der Prüfung mit nur zwei Gleichheitszeichen auch 1 zu true machen würde. Wir wollen aber explizit auf den aus der Funktion get_edit_authorization, in der der Wert für $authorization['delete'] ermittelt wird, gelieferten Wert (true oder false) prüfen.

Meine bescheidenen Versuche das einzugrenzen enden dahingehend, dass in Zeile 1374 der posting.inc.php der $_REQUEST['csrf_token'] scheinbar nicht gesetzt ist.

Woran machst du das fest?

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

Hallo Auge,

mich würde gerade mal interessieren, inwieweit wir alte Versionen supporten. Wenn ich mir die Changelog der Nachfolgeversion ansehe, dann wurde da erneut an der Delete-Funktion gearbeitet (added a CSRF-token to posting delete function calls). Wäre es nicht erst einmal ratsam, auf die letzte version zu updaten und dann zu schauen, ob es noch Probleme gibt?

Frohe Ostern wünsche ich Dir natürlich!
Micha

--
applied-geodesy.org - OpenSource Least-Squares Adjustment Software for Geodetic Sciences

Hi,

würde ich sofort mitmachen; das Update steht bereit.
Ich wollte nur den Fehler nicht mitziehen.

Falls es Sinn ergäbe: in der Testumgebung kann ich für euch ja nen Admin Account
einpflegen; dann könntet ihr wenigstens reinkucken.

Gruß
Andi

Hallo

Ich habe das mal umsortiert.

(Status: 2.4.24 - PHP7.3, sonst keine Fehler mehr gefunden)

Gut, damit kennen wir die Grundlage.

beim Durchprobieren bin ich hier drauf gestossen:

Der Beitrag hat keine Antwort, wurde vor Sekunden bearbeitet (als Admin),
kann aber nicht gelöscht werden.
Eine Sperrung ist nicht erkennbar.

Wie lautet die Einstellung für das Sperren(bzw der Zeitablauf dafür)?

Diese Einstellungen haben mutmaßlich nichts mit dem Problem zu tun, aber die relevanten Einstellungen lauten (Erklärungen sind der Wiki-Seite Configuration entnommen und mehr oder minder exakt übersetzt):

edit_max_time_period

maximale Zeitspanne während der ein Posting bearbeitet werden kann (in Minuten)
ergänzt user_edit und user_edit_if_no_replies

edit_min_time_period

Zeitspanne, während der ein eigenes Posting noch bearbeitet werden kann (in Minuten), obwohl es schon eine Antwort hat und user_edit_if_no_replies nur das Bearbeiten von Postings ohne vorhandene Antwort erlaubt (1)
übersteuert user_edit_if_no_replies für X Minuten

user_edit

Erlaubnis oder Verbot der Bearbeitung eigener Postings
- nicht erlaubt (0)
- erlaubt für registrierte Benutzer (1)
- erlaubt für alle Benutzer und Besucher (2)

user_edit_if_no_replies

Schalter für die Bearbeitung von eigenen Postings
- nur ohne bereits vorhandene Antworten (1)
- oder auch bei bereits vorhandenen Antworten (0)
ergänzt user_edit

Beim Thread ist der Name von Ersteller sichtbar, hier steht er auf "unbekannt".

Ich vermute, dass das die Ursache dieses Problems ist. zu diesem Problem gab es im Laufe der Zeit mehrere Meldungen. Wir haben dann versucht, die Ursache zu finden und Micha hat da auch ein paar Spezialfälle entlarvt und den Code angepasst, damit das nicht mehr geschieht.

Zu deinem Fall habe ich Fragen.

- Gibt es dieses spezielle Posting noch?
- Wenn ja, hat es in der Übersichtsseite einen Autor, der nicht "unbekannt" heißt?
- Wenn ja, was ist bezüglich des Autors in dem zum Eintrag gehörenden Datebankeintrag angegeben? Das ist ja entweder ein Eintrag in dem passenden Feld des Postings in mlf2_entries (nicht angemeldeter Bsucher) oder im selben Eintrag die User-ID aus mlf2_userdata (registierter und eigeloggter Benutzer).

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

Hi,

(Status: 2.4.24 - PHP7.3, sonst keine Fehler mehr gefunden)

Diese Einstellungen haben mutmaßlich nichts mit dem Problem zu tun, aber die relevanten Einstellungen lauten (Erklärungen sind der Wiki-Seite Configuration entnommen und mehr oder minder exakt übersetzt):

danke, da grabe ich mich jetzt durch

Beim Thread ist der Name von Ersteller sichtbar, hier steht er auf "unbekannt".

Ich vermute, dass das die Ursache dieses Problems ist. zu diesem Problem gab es im Laufe der Zeit mehrere Meldungen. Wir haben dann versucht, die Ursache zu finden und Micha hat da auch ein paar Spezialfälle entlarvt und den Code angepasst, damit das nicht mehr geschieht.

Zu deinem Fall habe ich Fragen.

- Gibt es dieses spezielle Posting noch?

ja, gibt es noch; lässt sich jederzeit wiederholen.
Neues Thema schreiben, abschicken. Sofort wieder rein, löschen über die Methode 1+3 nicht möglich.

- Wenn ja, hat es in der Übersichtsseite einen Autor, der nicht "unbekannt" heißt?

korrekt, mein Name steht dort; der Name "unbekannt" wird erst mit der Fehlermeldung angezeigt.
Bis zum drücken von "OK" -> also jetzt löschen steht der korrekte Name dort.

- Wenn ja, was ist bezüglich des Autors in dem zum Eintrag gehörenden Datebankeintrag angegeben?

Das ist ja entweder ein Eintrag in dem passenden Feld des Postings in mlf2_entries (nicht angemeldeter Bsucher) oder im selben Eintrag die User-ID aus mlf2_userdata (registierter und eigeloggter Benutzer).

Wenn ich Dich richtig verstanden habe, folgendes Ergebnis:

SQL-Abfrage:
sql_mlf2 "select id,pid,tid, edited,user_id,name,subject, text,marked,locked,sticky from mlf2_entries where id='169464'"

Antwort der DB:

+--------+---+--------+---------------------+------+--+--------+-------------+------+------+------+
| 169464 | 0 | 169464 | 0000-00-00 00:00:00 |   12 |  | test 8 | asdf asdf a |    0 |    0 |    0 |
+--------+---+--------+---------------------+------+--+--------+-------------+------+------+------+

Es steht die richtige User-id (=12) drin, aber kein Name.

Gruß
Andi

Hallo,

SQL-Abfrage:
sql_mlf2 "select id,pid,tid, edited,user_id,name,subject, text,marked,locked,sticky from mlf2_entries where id='169464'"

Antwort der DB:
+--------+---+--------+---------------------+------+--+--------+-------------+------+------+------+
| 169464 | 0 | 169464 | 0000-00-00 00:00:00 |   12 |  | test 8 | asdf asdf a |    0 |    0 |    0 |
+--------+---+--------+---------------------+------+--+--------+-------------+------+------+------+
Es steht die richtige User-id (=12) drin, aber kein Name.

Ja, dass ist mMn. auch in Ordnung. Das Feld `name` wird nur ausgefüllt, wenn der Eintrag von einem unregistrierten Nutzer erstellt wird. Ist der Nutzer registriert, so wird anhand der `user_id` der Name aus der Nutzertabelle abgefragt und dann eingesetzt - also theoretisch. ;-)

/Micha

--
applied-geodesy.org - OpenSource Least-Squares Adjustment Software for Geodetic Sciences

RSS Feed of thread