Issue: XF 1.2.2 upgrade Fatal error: Call to a member function setFetchMode()

Issue Tools
- View Changes

September 26, 2013 5:41 PM

Alfa1

Distinguished Member

XF 1.2.2 upgrade Fatal error: Call to a member function setFetchMode()

The upgrade fails on:

Code:

 Fatal error: Call to a member function setFetchMode() on a non-object in /vault/core/controller/db/xf.php on line 125

ErrorException: Fatal Error: Call to a member function setFetchMode() on a non-object - vault/core/controller/db/xf.php:125
Generated By: Alfa1, 2 minutes ago
Stack Trace

#0 [internal function]: XenForo_Application::handleFatalError()
#1 {main}

Request State

array(3) {
  ["url"] => string(68) "/install/index.php?upgrade/complete"
  ["_GET"] => array(1) {
    ["upgrade/complete"] => string(0) ""
  }
  ["_POST"] => array(0) {
  }
}

Issue Details

Issue Number 3354

Issue Type Bug

Project VaultWiki 4.x Series

Category Install / Upgrade

Status Fixed

Priority 2 - Fatal / Database Errors

Affected Version 4.0.0 Beta 5

Fixed Version 4.0.0 Beta 6

Milestone VaultWiki 4 Beta X

Software DependencyXenForo 1.x

License TypePaid

Users able to reproduce bug 0

Users unable to reproduce bug 0

Attachments 0

Assigned Users (none)

Tags (none)

September 27, 2013 12:33 PM

pegasus

VaultWiki Team

I think this happens during every XenForo upgrade on the upgrade/complete action, since that step reactivates Code Event Listeners and runs any that occur after reactivation. However, Code Events that occurred before reactivation aren't triggered as normally (like init_dependencies), which leads to unexpected results. The stack trace is remarkably unhelpful for some reason, providing no clear information as to where or why the error occurred, and refreshing upgrade/complete does not reproduce the error.

It may be resolved with a small change to the database controller: make it not expect that DB_Controller::ready was already fired by the calling script, and fire it automatically whenever ::get_instance is called and failed. This might seem obvious from an outside perspective, but when VaultWiki is implemented as a separate script (as in vBulletin < 5 and XenForo prior to VW4B5), it is possible to call ::ready before the software has actually created its database connection, which at one point had lead to the same error message we have here.

I will attempt now to see if this change resolves anything, but it may require multiple full upgrades since the error only occurs on upgrade/complete the first time it is loaded.

Reply
September 27, 2013 12:44 PM

pegasus

VaultWiki Team

Confirmed and duplicated consistently.

Resolved in Beta 6.

Reply
September 27, 2013 6:35 PM

Alfa1

Distinguished Member

Is beta 6 about to be released?
Has the XF upgrade been completed or does it need further action?

Reply
September 27, 2013 10:45 PM

pegasus

VaultWiki Team

The upgrade was completed. The error occurs when it executes the code to try to redirect back to the XF admin CP.

Beta 6 is imminent. Probably Sunday.

Reply

+ Reply

All times are GMT -4. The time now is 7:19 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: XF 1.2.2 upgrade Fatal error: Call to a member function setFetchMode()

Issue Tools