Fixed is_processing swallows errors from multi-step installer in debug mode

[Xon]

Affected version

2.0.2

When running the installer with the site in debug mode, is_processing can and will hide errors when using multi-step installers*. This makes developing working installers challenging when they are just silently failing.


*Technically "The site is currently being upgraded. Please check back later" is printed, but this isn't useful.

An example of the sorts of errors I've discovered that his "feature" hides;

An exception occurred: [TypeError] Argument 1 passed to SV\xxxxx\Setup::SV\xxxxx\{closure}() must be an instance of XF\Db\Schema\Alter, instance of XF\Db\Schema\Create given, called in /var/www/sites/html/src/XF/Db/SchemaManager.php on line 163 in src/addons/SV/xxxxx/Setup.php on line 64

 

[Sim]

It's not just multi-step installers and not just in debug mode - I had a single step install function and it failed with exactly the same non-error message when attempting to install from CLI. The only way I knew it had actually failed was that the database table wasn't created like it was supposed to.

I ran the install from the web ui and then was presented with a meaningful error - it seems to be CLI only?

An exception occurred: [TypeError] Argument 1 passed to xxxxx\Setup::xxxxx\{closure}() must be an instance of xxxxx\Create, instance of XF\Db\Schema\Create given, called in /srv/www/xf2test/src/XF/Db/SchemaManager.php on line 163 in src/addons/xxxxx/Setup.php on line 11

This is now v2.0.5

Note that even just inserting random typos into the install function was enough to give the "The site is currently being upgraded. Please check back later" non-error.

 

[S Thomas]

It's not even limited to install steps at all. This geniunely covers and hides erros while developing even though $config['debug'] = true; is set.
I manually altered the threads table, added the corresponding structure to my thread entity and now it gives me just that very helpful "error" message every time I view a thread.
Why is it even there when debugging is enabled?

 

[S Thomas]

Urghs, this is really annoying and frustrating. Forgot a semicolon in a widget render() method and well ..
Is there any way to print the correct error message instead? I don't mind editing core files right now since it's only dev and this is really unnecessarily wasting (a lot of) time @Chris D
The thing is, when this occurs, no error is even logged anywhere apparently, so debugging is really, as Xon said, "challenging".

 

[Xon]

@yoloswaggerino there are ~2 locations which set is_processing to true, just comment them out atm.

 

[S Thomas]

No clue why I didn't think of that myself, my brain's probably freezing.

diff --git a/src/XF/Error.php b/src/XF/Error.php
index ec4b4d4..26e8afa 100644
--- a/src/XF/Error.php
+++ b/src/XF/Error.php
@@ -206,14 +206,15 @@ class Error

         @header('Content-Type: text/html; charset=utf-8', true, 500);

-        if ($upgradePending && !$ignorePendingUpgrade)
-        {
-            echo $this->getPhrasedTextIfPossible(
-                'The site is currently being upgraded. Please check back later.',
-                'site_currently_being_upgraded'
-            );
-        }
-        else if ($showTrace)
+        // if ($upgradePending && !$ignorePendingUpgrade)
+        // {
+            // echo $this->getPhrasedTextIfPossible(
+                // 'The site is currently being upgraded. Please check back later.',
+                // 'site_currently_being_upgraded'
+            // );
+        // }
+        // else if ($showTrace)
+        if ($showTrace)
         {
             echo $this->getExceptionTraceHtml($e);
         }

It would be probably enough to re-order the ifs, so showing stack trace would have highest priority.

 

[Mike]

This did appear to be CLI specific. Taking actions via the web interface would display the error and log it as expected. I've fixed this now so that errors triggered via the CLI by the add-on install, upgrade, rebuild, etc will be logged and displayed as expected.