Update 1.1.11 => 2.x-dev fails

[instantflorian]

After Install OpF Dashboard

Warning: Cannot modify header information - headers already sent by (output started at /var/www/web913/.../upgrade-script.php:242) in /.../framework/globalExceptionHandler.php on line 4

Error remains at 2nd try, site is broken afterwards (Frontend/Backend): Fatal error: Uncaught Error: Call to a member function numRows() on null in /.../framework/classes/dbsession.php:110 Stack trace:

0 [internal function]: DbSession->read('e57656f93ea5b2c...')

1 /.../framework/classes/wbsession.php(68): session_start()

2 /.../framework/initialize.php(235): WbSession::Start()

3 /.../config.php(14): require_once('/var/www/web913...')

4 /.../index.php(31): require_once('/var/www/web913...')

5 {main} thrown in /.../framework/classes/dbsession.php on line 110

[ghost]

I can't start the Upgrade.

The following is displayed after calling the upgrade-script:

Fatal error: Uncaught Error: Call to a member function numRows() on null in C:\MAMP\htdocs\framework\classes\dbsession.php:110 Stack trace: #0 [internal function]: DbSession->read('hspeh70ebb6qd74...') #1 C:\MAMP\htdocs\framework\classes\wbsession.php(68): session_start() #2 C:\MAMP\htdocs\framework\initialize.php(235): WbSession::Start() #3 C:\MAMP\htdocs\config.php(14): require_once('C:\MAMP\htdocs\...') #4 C:\MAMP\htdocs\index.php(31): require_once('C:\MAMP\htdocs\...') #5 {main} thrown in C:\MAMP\htdocs\framework\classes\dbsession.php on line 110

[mrbaseman]

with current head of branch 1.2.x I can start the upgrade and it gets past the installation of the OpF Dashboard, but fails a little bit later with the following fatal error:

Upgrade Miniform

Upgrade WB Stats

Fatal error: Cannot redeclare _db_add_field() (previously declared in .../wbce/modules/miniform/upgrade.php:20) in .../wbce/modules/wbstats/upgrade.php on line 19

I can confirm the error reported by @instantflorian and @Colinax when trying to log into the backend once the upgrade script has failed. I have looked through my private conversation with @NorHei and found that I have stumbled over this error already on Apr 10 and at that time I believed that on Apr 7 it had worked. On the other hand I was unsure if I had used an up-to-date code for the test for the upgrade back then. I'm even not sure if there is any relation between the failure of the upgrade script and the broken dbsession. I was believing that the session problem was because I have over and over restored a backup to have a defined starting point for the upgrade (and the session in the backup has expired at some point), but I'll try to further look into this issue.

[mrbaseman]

the problem seems to be the dbsession: I believe there is no mechanism (yet) to fill the session table. At least I didn't find the appropriate call to the write method, and it seems the read method fails due to an empty session table, which fits into the picture. After fixing the causes for the error messages, login is still impossible. Therefore, apart from fixing the upgrade scripts of two modules and the fix inside the dbsession for the above error messages, I have disabled dbsession temporarily, until the question is clarified how the table shall be filled.

[mrbaseman]

I have reverted the workaround because I can't reproduce the error messages mentioned before. However, after doing that I noticed that I can't log in anymore after an upgrade. Looking directly at the tables in mysql I noticed that TABLE_PREFIX.'sessions' was not created during the upgrade. Such a table was created when installing something which was once called the 'dev branch for 1.2' (I didn't verify that with the current 2.x-dev branch again).

[mrbaseman]

I have made a strange discovery about this issue: When I issue the command that creates the sessions table manually in a MySQL shell it returns me an error: ERROR 1050 (42S01): Table 'wbce.wbce_sessions' already exists (note the statement is CREATE TABLE IF NOT EXISTS wbce_sessions ...) However, when I look at the output of show tables it does not show up. Looking into the mysql directory I don't see corresponding files either. When I change the name of the table and use sessions1 instead of sessions mysql happily creates the table with the exact same statement (except for the table name) and does not complain when re-running the create again. Maybe just changing sessions to something else, e.g. dbsessions would be enough to solve this issue, but I haven't tried that yet.

PS: My database name is wbce and my table prefix is wbce_ and I'm using mysql 5.7 on ubuntu 16.04.

[mrbaseman]

yeah, this was the clue! I just gave it a try. The name of the table is hard coded in very few places and the above commit solves the issue at least in my environment. I'd leave this open for a while. @instantflorian could you test it in your environment, too?

[instantflorian]

Trying to update 1.1.11 and 1.2 RC1 on a real webserver both breaks with

Install OpF Dashboard

Warning: Cannot modify header information - headers already sent by (output started at /.../upgrade-script.php:270) in /.../framework/globalExceptionHandler.php on line 4

Trying to update 1.2 RC1 in local test environment (usbwebserver.exe / WBCE Portable PHP7) - upgrade script does not even start, but displays

Fatal error: Uncaught PDOException: SQLSTATE[HY000] [2002] Es konnte keine Verbindung hergestellt werden, da der Zielcomputer die Verbindung verweigerte. in Kopie\root\framework\classes\persistence\wdo.php:34 Stack trace: #0 Kopie\root\framework\classes\persistence\wdo.php(34): PDO->construct('mysql:host=loca...', 'root', 'usbw', Array) #1 Kopie\root\framework\classes\persistence\database.php(126): Persistence\WDO->construct('mysql:host=loca...', 'root', 'usbw', Array, 'wbce_') #2 Kopie\root\framework\classes\persistence\database.php(109): Persistence\Database->connect() #3 Kopie\root\framework\initialize.php(65): Persistence\Database->__construct() #4 C:\Users\Florian\Documents\projekte\wbce\WBCE in Kopie\root\framework\classes\persistence\wdo.php on line 34

[mrbaseman]

Imo $tablePrefix is missing on line 34 of framework/classes/persistence/wdo.php Edit: sorry, I think I was wrong...

[mrbaseman]

I could reproduce the "headers already sent" error: in earlier versions globalExceptionHandler.php contained real content and it could be used in the uninstall.php of the classical output_filter module to prevent unauthorized access. This does not work anymore. Therefore, I have re-added the upgrade.php in a version that actually works to uninstall that module (see above commits). I could however not reproduce the Uncaught PDOException. It sais that it could not connect to the database server on localhost. Probably this is a different issue. I have to see if I can set up a win based VM for debugging this.

[mrbaseman]

Unfortunately after a hardware upgrade and two major software updates I couldn't convince my win VM anymore to start. Maybe someone can try to reproduce the problem and post the webserver log entries here?

[ghost]

The upgrade from 1.2 still works now, so i close this issue