Error during update from 2.3.3 over 2.3.7 to 2.4.11

I just completed a massive long overdue update from version 2.33, to 2.34, 2.35, 2.36.1, 2.37 and then finally directly to the latest version 2.4.11.

Everything seemed to go smoothly, barring some theme customization I have to put back in, but on the last update the GRPR seems to have broken something.

When I try to post I get this error:

Database error!
Unknown column 'dps_accepted' in 'field list'

I get similar errors when trying to run the queries in phphmyadmin that you suggested as well.

Keep in mind that my setup was at 2.3.3 the last time anyone logged in, so I'm not sure what went wrong during the upgrade, but as of right now it is preventing anyone from posting, with no popups or anywhere that I can see to bypass it or work around it.

Thanks,
Craig

Hello

I just completed a massive long overdue update from version 2.33, to 2.34, 2.35, 2.36.1, 2.37 and then finally directly to the latest version 2.4.11.

Ok, an update from 2.3.7 directly to 2.4.11. Is that correct?

Everything seemed to go smoothly, barring some theme customization I have to put back in, but on the last update the GRPR seems to have broken something.

When I try to post I get this error:

Database error!
Unknown column 'dps_accepted' in 'field list'

The scripts seems to be in an actual state. The column 'dps_accepted' was introduced in the version 2.4.10.

There was many changes between 2.3.7 and 2.4.11 in the database. To identify, what was going wrong, we need several informations about the database structure.

1. The table name list from the file config/db_settings.php

We need the values of the lines starting with ($db_settings['*_table'] = '…';) but WITHOUT the database connection data (the keys "host", "user", "password", "database").

2. An excerpt of the table structure.

You can create this excerpt with phpMyAdmin (or a similar tool). Please report the CREATE-statements for all the tables. Example:

CREATE TABLE mlf2_temp_infos (
  `name` VARCHAR(50) NOT NULL,
  `value` VARCHAR(255) NOT NULL,
  `time` TIMESTAMP NULL DEFAULT NULL,
  PRIMARY KEY (name))
ENGINE=InnoDB CHARSET=utf8 COLLATE=utf8_general_ci;

With knowledge of your real structure, we can identify the step, that broke your update. You can find the function in phpMyAdmin in the tab "export", "adjustments => format specific options" activate "structure" and in "object crceation options" activate "with CREATE-statement" and run the script for every MLF table (real menu point names can differ, translated it myself from the german user interface).

I get similar errors when trying to run the queries in phphmyadmin that you suggested as well.

Which queries you are talking about?

Keep in mind that my setup was at 2.3.3 the last time anyone logged in, so I'm not sure what went wrong during the upgrade, but as of right now it is preventing anyone from posting, with no popups or anywhere that I can see to bypass it or work around it.

I expect us together to be able to make your forum running again. :-)

Tschö, Auge

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

FYI, I resolved the problem by manually running the sql query from the update.sql for 2.49 to 2.4.10:

ALTER TABLE mlf2_userdata ADD tou_accepted DATETIME NULL DEFAULT NULL, ADD dps_accepted DATETIME NULL DEFAULT NULL;
INSERT INTO mlf2_settings VALUES ('data_privacy_agreement', '0');
INSERT INTO mlf2_settings VALUES ('data_privacy_statement_url', '');

For whatever reason, this did not run when updating straight from 2.3.7 to 2.4.11

Hello

FYI, I resolved the problem by manually running the sql query from the update.sql for 2.49 to 2.4.10:

ALTER TABLE mlf2_userdata ADD tou_accepted DATETIME NULL DEFAULT NULL, ADD dps_accepted DATETIME NULL DEFAULT NULL;
INSERT INTO mlf2_settings VALUES ('data_privacy_agreement', '0');
INSERT INTO mlf2_settings VALUES ('data_privacy_statement_url', '');

Thank you for your report, which led me …

For whatever reason, this did not run when updating straight from 2.3.7 to 2.4.11

… to this statement, which led me to an error, I made in the update script. The if-statement for the update to version 2.4.10 (and 2.4.11) excludes the versions below 2.3.99.1 even the update script should update versions from 2.3.5 on. I don't know, why I did this but that is the reason, you ran into the error.

I'll add warnings to the posts here and on Github until I'm able to solve this in the repository (today).

Thank you for your involvement.

Tschö, Auge

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

Thank you for all of your hard work on this great software! One more thing that I noticed is that while the older versions always pulled the current version correctly, it seems that the most recent versions are now using the VERSION file as well as the version meta_key under mlf2_settings.

I'm only mentioning it because the update.sql script seems to stop updating the version at 2.4.0, and doesn't add the smaller incremental version numbers above that. The version in my VERSION file is correct, so I did need to manually update the key in the SQL database in order for the software to recognize the correct version.

Hello

My explanations goes not directly to only you (WorldofBB) but also to further interested people, who are able to compare my explanation with the real code. Maybe someone can find a bug that way.

Thank you for all of your hard work on this great software! One more thing that I noticed is that while the older versions always pulled the current version correctly, it seems that the most recent versions are now using the VERSION file as well as the version meta_key under mlf2_settings.

I'm only mentioning it because the update.sql script seems to stop updating the version at 2.4.0, and doesn't add the smaller incremental version numbers above that. The version in my VERSION file is correct, so I did need to manually update the key in the SQL database in order for the software to recognize the correct version.

The scheme to use the VERSION-file worked since it's introduction with 2.3.99.1. But I had to add an additional function to the update script that compares the version string from the settings with the string from the file VERSION with 2.4.10. Problem was, that the simple comparision ($oldVersion < $newVersion) which string represents the greater (and newer) version number did not work with 2.4.10.

I tested the update to 2.4.10 with an initial installation of version 2.4.8. When the comparement of version numbers took action, the script told me, that the installend version is newer than the one I wanted to install. The script interpreted the version number "2.4.10" as a number and therefore as "2.4.1" (x.10 as x.1) which is a smaller number than 2.4.8.

To compare the numbers in a correct manner with the new function the string gets separated at the points (".") and, as one can see in update.php from line 34 on the array of the separated parts of a version number gets amended with additional elements with "0" as its value. A version string like "2.4" would get separated and amended with an additional "0" to a three elements array with "2", "4" and "0" when compared with a version number with three elements like "2.4.11" that get separated to "2", "4, and "11". Then the first, second and third elements from both arrays gets compared. When an element from the version array of the version one wants to update to is greater than its counterpart from the version string of the installed version the new Version is newer than the installed one. The update would get not stopped at that point and should perform.

The actualisation of the version number in the settings table is the almost last step of the update script (beginning with line 602 in the currently actual version 2.4.12). The value from $newVersion, taken from VERSION at the beginning of the update process gets stored in the table long after the comparision in dispute.

So your scenario should not be possible. It might has something to do with your previous failed update attempt or with the fact, that you updated your forum from a version without the file VERSION to a version, that defines it as mandatory. But the last guess is more a speculation.

Tschö, Auge

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

Ahhh, makes sense.

You are correct, in that thinking back the version number did update correctly the first time I ran the update, but after having my initial problem I ran through all of the update steps manually to make sure that I didn't miss any sql updates, and in so doing reverted the version number that way. I didn't actually run the entire update script again, which is why the version number didn't get updated to the correct number again.

RSS Feed of thread

my little forum

Error during update from 2.3.3 over 2.3.7 to 2.4.11 (General)