• This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn more.

XF 1.4 Server error when upgrading from 1.4.1 to 1.4.2

Stuart Wright

Well-known member
#1
Server Error
Server Error
Statement contains more than just partial statements and only partial statements were requested

  1. XenForo_Template_Compiler_Statement_Collection->getPartialStatement() in XenForo/Template/Compiler.php at line 456
  2. XenForo_Template_Compiler->compileAndCombineSegments() in XenForo/Template/Compiler.php at line 877
  3. XenForo_Template_Compiler->compileNamedParams() in XenForo/Template/Compiler/Tag/Admin/Abstract.php at line 402
  4. XenForo_Template_Compiler_Tag_Admin_Abstract->_compileChoiceChild() in XenForo/Template/Compiler/Tag/Admin/Abstract.php at line 313
  5. XenForo_Template_Compiler_Tag_Admin_Abstract->_getChoicesCode() in XenForo/Template/Compiler/Tag/Admin/RadioUnit.php at line 45
  6. XenForo_Template_Compiler_Tag_Admin_RadioUnit->compile() in XenForo/Template/Compiler.php at line 641
  7. XenForo_Template_Compiler->compileTag() in XenForo/Template/Compiler.php at line 570
  8. XenForo_Template_Compiler->compileSegment() in XenForo/Template/Compiler.php at line 509
  9. XenForo_Template_Compiler->compileSegments() in XenForo/Template/Compiler.php at line 422
  10. XenForo_Template_Compiler->compileIntoVariable() in XenForo/Template/Compiler/Tag/Admin/Form.php at line 29
  11. XenForo_Template_Compiler_Tag_Admin_Form->compile() in XenForo/Template/Compiler.php at line 641
  12. XenForo_Template_Compiler->compileTag() in XenForo/Template/Compiler.php at line 570
  13. XenForo_Template_Compiler->compileSegment() in XenForo/Template/Compiler.php at line 509
  14. XenForo_Template_Compiler->compileSegments() in XenForo/Template/Compiler.php at line 372
  15. XenForo_Template_Compiler->compileParsed() in XenForo/Model/AdminTemplate.php at line 776
  16. XenForo_Model_AdminTemplate->compileParsedAdminTemplate() in XenForo/Model/AdminTemplate.php at line 662
  17. XenForo_Model_AdminTemplate->compileAllParsedAdminTemplates() in XenForo/Deferred/AdminTemplate.php at line 16
  18. XenForo_Deferred_AdminTemplate->execute() in XenForo/Deferred/Atomic.php at line 66
  19. XenForo_Deferred_Atomic->execute() in XenForo/Model/Deferred.php at line 256
  20. XenForo_Model_Deferred->runDeferred() in XenForo/Model/Deferred.php at line 390
  21. XenForo_Model_Deferred->_runInternal() in XenForo/Model/Deferred.php at line 316
  22. XenForo_Model_Deferred->runByUniqueKey() in XenForo/Install/Controller/Abstract.php at line 34
  23. XenForo_Install_Controller_Abstract->_manualDeferredRunner() in XenForo/Install/Controller/Upgrade.php at line 221
  24. XenForo_Install_Controller_Upgrade->actionRunDeferred() in XenForo/FrontController.php at line 347
  25. XenForo_FrontController->dispatch() in XenForo/FrontController.php at line 134
  26. XenForo_FrontController->run() in /home/sites/avforums/public_html/install/index.php at line 18
 

Brogan

XenForo moderator
Staff member
#3
We have seen one other instance of this and it was related to one or possibly two add-ons - User Essentials and Paygates.

Try disabling those in the ACP.
 

Stuart Wright

Well-known member
#6
Refreshing the halted window didn't do anything, but after disabling about half the addons, I hit the 'Begin Upgrade' link instead and that completed. Chris is on the site now, helping. Many thanks for the quick replies.
 

Chris D

XenForo developer
Staff member
#7
It's sorted now. Yeah the error was still happening during the rebuild after User Essentials was disabled. I decided to just disable everything. So, sadly, we won't know exactly which one caused it.

But I do have a list of add-ons for cross referencing should anyone else experience the same thing.
 

Mike

XenForo developer
Staff member
#8
Refreshing the halted window didn't do anything, but after disabling about half the addons, I hit the 'Begin Upgrade' link instead and that completed.
Just to clarify, you do need to restart the rebuild process to workaround this. By the time the error is triggered, the bad data has been written.

It's something I will look into working around if possible, but the main workaround would slow down template importing so I'm not totally sure of the feasibility. The issue is that while template importing, we don't do a test compile when updating a template as would normally happen when editing a template; we assume that what has been provided is valid. Here, the template modifications made something that was syntactically valid (lexed/parsed) but violated some of second-pass compilation limits. The only way I could see working around this is to do the full test compile when importing but I'm unsure of the potential speed overhead; a mitigation could be to only do it when there are template modifications being applied.

I should note that this isn't a new behavior -- it's worked identically since the template modification system was introduced in 1.2. This may have been the first time where it came up.

It seemed to be User Essentials when I resolved it earlier, but it may have actually been an interaction between User Essentials and Paygates. (I believe there's a regex bug in Paygates' modification.)
 

Stuart Wright

Well-known member
#9
It seemed to be User Essentials when I resolved it earlier, but it may have actually been an interaction between User Essentials and Paygates. (I believe there's a regex bug in Paygates' modification.)
We don't have the Paygates modification. Plenty of others, though.
 

Daniel Hood

Well-known member
#10
I've just released an update to User Essentials that removes the troubled template modification. I meant to remove this template modification before hand, it was actually never used and shouldn't have been included. I apologize for the inconvenience.
 

Daniel Hood

Well-known member
#11
The only way I could see working around this is to do the full test compile when importing but I'm unsure of the potential speed overhead; a mitigation could be to only do it when there are template modifications being applied.
What if you make it a Deferred task for each template mod; it could work like this: disable all template mods, create a deferred task for each one, reenable them as they're verified individually. Granted it may put a board online without all their template mods intact for a moment but it beats the alternatives*, in theory at least.

Alternatives being:
  • This error possibly happening again.
  • Slowing down the upgrade process, keeping boards offline longer.
[Edit]

Also I just remembered. Templates that aren't compiled correctly have a red 1 next to them instead of a green 1. Why not just skip those entirely, treat them as they're disabled or something? Keep in mind I'm tossing these ideas without looking at the code of the current process.
 
#12
Just to clarify, you do need to restart the rebuild process to workaround this. By the time the error is triggered, the bad data has been written.
i'm having the same issue, and i can't get the upgrade to finish. how do i restart the rebuild process? i added the "$config['enableListeners'] = false;" to my config to disable all my plugins, but i'm still getting the error.

is there a way to get into the ACP? i can't think of any other way to upgrade the user essentials plugin since i'm stuck in the upgrade process.
 

Mike

XenForo developer
Staff member
#13
You can get into the control panel by putting this in your config.php file:
Code:
$config['checkVersion'] = false;
 

Alfa1

Well-known member
#15
I can get in the admin panel, but it looks all messed up. Upgrading user essentials to version 211 does not work, because it leads to the same error.
 

Alfa1

Well-known member
#19
Now the board seems upgraded. But I wonder if everything works as it should. Do I need to do anything next like rebuild everything?
 

Chris D

XenForo developer
Staff member
#20
I would do the following:
  • While all add-ons are still disabled reinstall the latest User Essentials
  • Rebuild Master Data (go back to the install page)
  • Re-enable all add-ons