Issue: Error on Upgrade

Issue Tools
- View Changes

February 18, 2017 8:51 AM

Mokonzi

Senior Member

Error on Upgrade

Upgrading Stalls at 4.0.1 Ipdate

Hi pegasus,

Been updating VaultWiki and had some issues during the upgrade process. I've had to move across to vBulletin 4.2.5 on my server, and it may be related to that upgrade (we're running PHP 7 now), but the error is at the Step 2 of the 4.0.1 stage of the update, and is as follows:

Code:

Updating data in table: vw_permission
Declaration of vw_vB_DataManager::verify_ipaddress(&$ip) should be compatible with vB_DataManager::verify_ipaddress($ipaddress)
#0: vw_CP_Progress_View->handle_php_error() in [path]/vault/core/controller/dm/vb3.php at line 81
#1: require_once() in [path]/vault/core/controller/dm/vb3.php at line 81
#2: vw_DM_Controller_vB3->create() in [path]/vault/install/lib/upgradepath/steps/4/0/1/base/vw.php at line 59
#3: vw_Install_UpgradePath_Steps_401_base_Controller->{closure}() in [path]/vault/core/controller/progress/steps/vw.php at line 83
#4: vw_Progress_Steps_Controller->call() in [path]/vault/core/controller/progress/steps/vw.php at line 53
#5: vw_Progress_Steps_Controller->execute() in [path]/vault/install/lib/upgradepath/vw.php at line 62
#6: vw_Install_UpgradePath_Controller->exec_script() in [path]/vault/core/controller/progress/vw.php at line 74
#7: vw_Progress_Controller->execute() in [path]/vault/core/controller/cp/progress/vw.php at line 35
#8: vw_CP_Progress_Controller->process() in [path]/vault/core/controller/cp/install/vw.php at line 275
#9: vw_CP_Install_Controller->upgrade() in [path]/vault/core/controller/cp/install/vw.php at line 57
#10: vw_CP_Install_Controller->execute() in [path]/vault/helper/vb/global.php at line 63
#11: require_once() in [path]/vault/install/index.php at line 38

Any suggestions on a fix or work around?

Issue Details

Issue Number 4918

Issue Type Bug

Project VaultWiki 4.x Series

Category Install / Upgrade

Status Fixed

Priority 4 - Warnings / Script Errors

Affected Version 4.0.16

Fixed Version 4.0.17

Milestone (none)

Software DependencyAny

License TypePaid

Users able to reproduce bug 0

Users unable to reproduce bug 0

Attachments 0

Assigned Users (none)

Tags (none)

February 18, 2017 9:53 AM

pegasus

VaultWiki Team

VaultWiki has not had a compatibility release for vBulletin 4.2.5 yet.

However, VaultWiki is only supposed to show messages like this if vBulletin is in debug mode. If vBulletin is in debug mode, please disable while you upgrade.

Reply
February 18, 2017 10:09 AM

Mokonzi

Senior Member

Thanks Pegasus. We're not running vB in debug mode, nor have we any mods that are putting it in debug mode.

:/

Reply

February 18, 2017 10:28 AM

pegasus

VaultWiki Team

In vault/core/view/cp/progress/vw.php, find:

Code:

if ($this->display_php_error($error_type, $file))

Replace with:

Code:

if ($this->display_php_error($error_type, $file, $error_string))

Find:

Code:

	protected function display_php_error($error_type, $file)
	{

Replace with:

Code:

	protected function display_php_error($error_type, $file, $error_string)
	{
		if (PHP_MAJOR_VERSION >= 7)
		{
			// handle errors that were upgraded in PHP 7
			if (strpos($error_string, 'Declaration of') === 0)
			{
				return false;
			}
		}

February 18, 2017 11:19 AM

Mokonzi

Senior Member

That worked, and got me through to 4.0.16 Step 8 and then this error:

Code:

Updating data in table: vw_page
mysqli_query(): (42S02/1146): Table 'mydb.myprfx_vw_groupitem' doesn't exist
#0: vw_CP_Progress_View->handle_php_error()
#1: mysqli_query() in [path]/includes/class_core.php at line 1389
#2: vB_Database_MySQLi->execute_query() in [path]/includes/class_core.php at line 461
#3: vB_Database->query_read() in [path]/vault/core/controller/db/vb3.php at line 236
#4: vw_DB_Controller_vB3->query_read() in [path]/vault/core/model/db/mysql/vw.php at line 27
#5: vw_DB_MySQL_Model->select() in [path]/vault/core/controller/fetch/vw.php at line 325
#6: vw_Fetch_Controller->get() in [path]/vault/core/controller/fetch/vw.php at line 597
#7: vw_Fetch_Controller->get_index() in [path]/vault/core/controller/fetch/vw.php at line 431
#8: vw_Fetch_Controller->return_the_index() in [path]/vault/core/controller/fetch/vw.php at line 235
#9: vw_Fetch_Controller->get() in [path]/vault/core/controller/dm/base/vw.php at line 1883
#10: vw_DM_Base_Controller->affected_nodes() in [path]/vault/core/controller/dm/base/vw.php at line 1275
#11: vw_DM_Base_Controller->rebuild_multiple() in [path]/vault/core/controller/dm/page/vw.php at line 2367
#12: vw_DM_Page_Controller->delete_multiple() in [path]/vault/core/controller/dm/vw.php at line 113
#13: vw_DM_Controller->delete_multiple() in [path]/vault/install/lib/upgradepath/steps/4/0/16/3X/vb3.php at line 297
#14: vw_Install_UpgradePath_Steps_4016_3X_Controller_vB3->{closure}() in [path]/vault/core/controller/progress/steps/vw.php at line 83
#15: vw_Progress_Steps_Controller->call() in [path]/vault/core/controller/progress/steps/vw.php at line 53
#16: vw_Progress_Steps_Controller->execute() in [path]/vault/install/lib/upgradepath/vw.php at line 62
#17: vw_Install_UpgradePath_Controller->exec_script() in [path]/vault/core/controller/progress/vw.php at line 74
#18: vw_Progress_Controller->execute() in [path]/vault/core/controller/cp/progress/vw.php at line 35
#19: vw_CP_Progress_Controller->process() in [path]/vault/core/controller/cp/install/vw.php at line 275
#20: vw_CP_Install_Controller->upgrade() in [path]/vault/core/controller/cp/install/vw.php at line 57
#21: vw_CP_Install_Controller->execute() in [path]/vault/helper/vb/global.php at line 63
#22: require_once() in [path]/vault/install/index.php at line 38

February 18, 2017 11:54 AM

pegasus

VaultWiki Team

I can't see a reason for this. There has not been a vw_groupitem table since 4.0.8 and the file in the stack trace knows that, so there is no reason for it to try to access it. Does this still happen after you refresh the page?

If you use a PHP opcode cache, did you remember to reset it after you uploaded the new files and before upgrading?

Reply
February 18, 2017 12:03 PM

Mokonzi

Senior Member

We run vBOptimise, would that fall into the category of caching that might cause an issue?

Remember I've upgraded from before 4.0.1, so the 4.0.8 upgrade was done in the same run of upgrading that lead to the 4.0.16 Step 8 error.

Refreshing the page let the upgrade continue... I'll keep you posted.

Reply
February 18, 2017 12:06 PM

Mokonzi

Senior Member

The final update process seems to have run through completely.

Reply
February 18, 2017 12:23 PM

pegasus

VaultWiki Team

I had previously marked this as Fixed, but I am reopening until full compatibility with vBulletin 4.2.5 can be confirmed. So far there are a number of things that I found, notably that the option to disable logging of IP addresses will stop applying to wiki content in vB 4.2.5, and those IP addresses will now be logged. If this is inconsistent with a site's privacy policy, the policy should be updated to reflect this until a vBulletin 4.2.5-compatible VaultWiki release is applied.

Reply
February 21, 2017 5:07 PM
pegasus

VaultWiki Team
vBulletin 4.2.5 does not appear to be ready for live use yet. It appears to allow MySQL strict mode (which earlier versions explicitly turn off), which leads to database errors in many add-ons and when posting new threads and replies, due to missing default values for lots of fields. In particular, a problem is vBulletin's indexqueue table, which has no default values, and vBulletin's standard indexer does not attempt to set any.

EDIT: The strict mode problem only occurs if you do not update your includes/config.php file when upgrading from vBulletin 4.2.4 to 4.2.5. To maintain the previous behavior, the following is needed:

Code:

$config['Database']['set_sql_mode'] = '';
Reply
February 22, 2017 11:34 AM

pegasus

VaultWiki Team

I am now marking this as Fixed in the next release.

The only major change I noticed that would have affected VaultWiki was removal of a reference related to IP address verification; a workaround has been applied so that IPs are still logged as intended.

Somewhat minor, the setting which allowed choosing between database- and cookie-based read-marking has been removed, and database-based marking is now used exclusively. VaultWiki has been updated to reflect this behavior.

Otherwise, most other changes in vBulletin 4.2.5 which account for PHP 7.0 compatibility were already supported in the current version of VaultWiki, since we had to make mostly the same changes to test PHP 7 internally 2 years ago.

Reply

+ Reply

All times are GMT -4. The time now is 2:31 AM.

This site uses cookies to help personalize content, to tailor your experience, and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.

Learn more… Accept Remind me later

Welcome to VaultWiki.org, home of the wiki add-on for vBulletin and XenForo!

Issue: Error on Upgrade

Issue Tools