The issue

After upgrading Flarum into 1.8.* my site stops fully loading. Instead, I see a bullet-list of the first page of discussions, and a message at the top of the site that reads:
Something went wrong while trying to load the full version of this site. Try hard-refreshing this page to fix the error.

After disabling all extensions then enabling one-by-one, I found that FOF Upload was the culprit. I've dug around and haven't really found any websites, support pages, threads discussing this issue. Curious what folks can help with?

Sharing additional info below

Flarum information

Flarum core: 1.8.9
PHP version: 8.2.20
MySQL version: 10.6.19-MariaDB
Loaded extensions: Core, date, libxml, openssl, pcre, zlib, filter, hash, json, pcntl, random, readline, Reflection, SPL, session, standard, bcmath, bz2, calendar, ctype, curl, dom, mbstring, fileinfo, ftp, gd, gettext, gmp, iconv, imap, intl, ldap, exif, mysqlnd, oci8, PDO, pgsql, Phar, posix, pspell, shmop, SimpleXML, soap, sockets, sodium, sqlite3, sysvmsg, sysvsem, sysvshm, tidy, tokenizer, xml, xmlwriter, xsl, mcrypt, mysqli, pdo_mysql, PDO_OCI, pdo_pgsql, pdo_sqlite, xmlreader, zip, apcu, igbinary, imagick, mailparse, msgpack, trader, zmq, memcached, redis, Zend OPcache
+------------------------------+---------+--------+
| Flarum Extensions            |         |        |
+------------------------------+---------+--------+
| ID                           | Version | Commit |
+------------------------------+---------+--------+
| flarum-tags                  | v1.8.3  |        |
| flarum-mentions              | v1.8.5  |        |
| flarum-subscriptions         | v1.8.1  |        |
| flarum-markdown              | v1.8.1  |        |
| fof-follow-tags              | 1.2.5   |        |
| therealsujitk-gifs           | v4.1.1  |        |
| ianm-follow-users            | 1.4.10  |        |
| fof-user-bio                 | 1.4.2   |        |
| fof-upload                   | 1.2.3   |        |
| fof-split                    | 1.1.1   |        |
| fof-secure-https             | 1.1.3   |        |
| fof-pwned-passwords          | 1.1.1   |        |
| fof-merge-discussions        | 1.4.1   |        |
| fof-links                    | 1.3.0   |        |
| fof-formatting               | 1.0.3   |        |
| fof-drafts                   | 1.2.12  |        |
| flarum-sticky                | v1.8.2  |        |
| flarum-statistics            | v1.8.1  |        |
| flarum-lock                  | v1.8.2  |        |
| flarum-likes                 | v1.8.1  |        |
| flarum-lang-english          | v1.8.0  |        |
| flarum-extension-manager     | v1.0.5  |        |
| flarum-emoji                 | v1.8.1  |        |
| clarkwinkelmann-emojionearea | 1.0.0   |        |
| askvortsov-rich-text         | v2.1.7  |        |
| askvortsov-categories        | v3.1.0  |        |
| antoinefr-online             | v1.0.1  |        |
| acpl-mobile-tab              | 1.4.4   |        |
+------------------------------+---------+--------+
Base URL: redacted
Installation path: redacted
Queue driver: sync
Session driver: file
Scheduler status: Never run
Mail driver: smtp
Debug mode: off

I can share the debug log on request - figured 800+ lines would be a bit much to share. Interestingly, when attempting debug mode, the website would throw a 500 (separate issue seems to be happening with askvortsov-rich-text), but the log still exists in storage/logs

Thanks for any help and guidance!
Caleb

  • luceos replied to this.

    • caleb

    • Best Answerset by caleb

    For anyone who finds this thread. I managed to fix the issue a while back...forgot what I did. Then fof/upload broke again when I updated to flarum 1.8.10. For some reason, fof/upload refused to update past v 1.2.3 even though there was a much newer version. And this was breaking things.

    I was able to resolve the issue after googling and troubleshooting. What ultimately helped was to use:

    composer why-not fof/upload 1.8.2 (the latest version when I resolved my issue)

    This showed that my CLI PHP version was still using PHP 7.3, even though the newer versions of fof/upload required 8.1 or higher. This didn't make sense to me, since I had already set my web app to use a newer version of PHP...and I was pretty sure I had set my CLI to also use a newer version.

    The problem, was that Composer was using a sort of "system default" version of PHP in my managed/shared hosting environment.

    I tested my theory by forcing Composer to run on a newer PHP version and trying "why not" again, using the following:

    php82 ~/bin/composer why-not fof/upload 1.8.2
    (note: your system might call PHP v 8.2 a different way. Additionally, I actually needed to directly call composer from my own install since it wasn't part of the managed hosting package...ie your usage may differ, but the idea is the same)

    I no longer got issue reporting an unsupported version of PHP. Which told me, I now need to run Composer but initiate it from PHP...via the newer version. Running the update but adding php82 ~/bin/composer to the beginning of any composer command resolved my issue.

    Now, if anyone can help me figure out how I can simplify this further so that Composer just uses my own determined version of PHP in the CLI and I can return to just starting my command lines with composer, I would love to know. Again, caveat that I'm running this from managed hosting.

    PS: I love love love why not...how did I never know about this super useful tool!

    caleb it seems to work for me now, did you fix it?

    Usually what you need to do is run

    php flarum migrate
php flarum cache:clear

    And the possibly restart your webserver (if your php uses opcache) while also clearing your browser cache.

      I previously have run those lines before, I'll run them again to be safe (and check all boxes).

      How do I go about restarting the webserver?
      sudo systemctl restart nginx ?

        caleb with nginx you probably need to restart php-fpm instead.

          Also (due to little kids in the background) I am forgetting that I'm on a managed service and don't have sudoer access to restart the server 😛 So I am expecting to get a ping from my provider any moment now 🙂

            caleb they usually don't run opcache because of this though. Just updating and running the commands should be fine on any managed hosting service.

            caleb Also (due to little kids in the background) I am forgetting

            🫢 been there, done that; you're doing great.

                Haha thanks for the understanding there. My sysadmin was also understanding, and incidentally restarted the PHP and web services for me. Sadly, this didn't resolve the issue for me yet.

                I attempted removing and reinstalling the extension - which didn't work either. For reference, I performed these actions:

                composer remove fof/upload
composer require fof/upload "*"
php flarum migrate
php flarum cache:clea

                Interestingly, I'm noticing that the version of the extension on my site is 1.2.3, but the project is itself listing the latest version as 1.6.1 - I'm not sure why the latest doesn't seem to install.

                4 months later

                For anyone who finds this thread. I managed to fix the issue a while back...forgot what I did. Then fof/upload broke again when I updated to flarum 1.8.10. For some reason, fof/upload refused to update past v 1.2.3 even though there was a much newer version. And this was breaking things.

                I was able to resolve the issue after googling and troubleshooting. What ultimately helped was to use:

                composer why-not fof/upload 1.8.2 (the latest version when I resolved my issue)

                This showed that my CLI PHP version was still using PHP 7.3, even though the newer versions of fof/upload required 8.1 or higher. This didn't make sense to me, since I had already set my web app to use a newer version of PHP...and I was pretty sure I had set my CLI to also use a newer version.

                The problem, was that Composer was using a sort of "system default" version of PHP in my managed/shared hosting environment.

                I tested my theory by forcing Composer to run on a newer PHP version and trying "why not" again, using the following:

                php82 ~/bin/composer why-not fof/upload 1.8.2
                (note: your system might call PHP v 8.2 a different way. Additionally, I actually needed to directly call composer from my own install since it wasn't part of the managed hosting package...ie your usage may differ, but the idea is the same)

                I no longer got issue reporting an unsupported version of PHP. Which told me, I now need to run Composer but initiate it from PHP...via the newer version. Running the update but adding php82 ~/bin/composer to the beginning of any composer command resolved my issue.

                Now, if anyone can help me figure out how I can simplify this further so that Composer just uses my own determined version of PHP in the CLI and I can return to just starting my command lines with composer, I would love to know. Again, caveat that I'm running this from managed hosting.

                PS: I love love love why not...how did I never know about this super useful tool!