Uploading image: unknown error occurred #2190

Closed
opened 2026-02-05 03:15:46 +03:00 by OVERLORD · 5 comments
Owner

Originally created by @cautiouscoyote on GitHub (Apr 11, 2021).

Yesterday I edited some pages on my BookStack setup, even uploaded an image as a "cover image" for a "book". Everything ran smoothly.
Then I noticed that I was running BookStack version 0.30.7, which has been succeeded by a number of updates since I installed that one, so I updated to v21.04.
Even updated the underlying Apache and PHP packages while I was at it. Now running Apache 2.4.46 and PHP 7.4.16.

Today, I logged in again, added and edited some pages again. Everything seemed to work fine still.
Until I tried to upload an image as a "cover image" for another "book". It responded with:
"An unknown error occurred".

In the system logs I can find little more than "... POST /bookstack/books/<booktitle> HTTP/1.0" 500 12374", which is listed in the Apache access log.
I've tried again with a smaller image file, another file format (jpg vs png) and even the very same file that upladed nicely the day before, but all to no avail.

Any ideas what might be broken or where I should start digging to get more details out of my system?

Thanks for any pointers!
Cheers,

Originally created by @cautiouscoyote on GitHub (Apr 11, 2021). Yesterday I edited some pages on my BookStack setup, even uploaded an image as a "cover image" for a "book". Everything ran smoothly. Then I noticed that I was running BookStack version 0.30.7, which has been succeeded by a number of updates since I installed that one, so I updated to v21.04. Even updated the underlying Apache and PHP packages while I was at it. Now running Apache 2.4.46 and PHP 7.4.16. Today, I logged in again, added and edited some pages again. Everything seemed to work fine still. Until I tried to **upload an image** as a "cover image" for another "book". It responded with: "**An unknown error occurred**". In the system logs I can find little more than "... POST /bookstack/books/\<booktitle\> HTTP/1.0" 500 12374", which is listed in the Apache access log. I've tried again with a smaller image file, another file format (jpg vs png) and even the very same file that upladed nicely the day before, but all to no avail. Any ideas what might be broken or where I should start digging to get more details out of my system? Thanks for any pointers! Cheers,
Author
Owner

@ssddanbrown commented on GitHub (Apr 12, 2021):

Hi @cautiouscoyote,
You can get more details via the methods described here, most notably the log file:
https://www.bookstackapp.com/docs/admin/debugging/

The first thing to check would be that your .env file has an APP_URL set that exactly matches the top-level base URL that you're intending to access BookStack on.

@ssddanbrown commented on GitHub (Apr 12, 2021): Hi @cautiouscoyote, You can get more details via the methods described here, most notably the log file: https://www.bookstackapp.com/docs/admin/debugging/ The first thing to check would be that your `.env` file has an `APP_URL` set that exactly matches the top-level base URL that you're intending to access BookStack on.
Author
Owner

@cautiouscoyote commented on GitHub (Apr 12, 2021):

Hi @ssddanbrown! Thanks for the quick reply.

First I verified the APP_URL setting, as you pointed out, but surely there's nothing wrong with that: I can access my BookStack setup just like before the upgrade to v21.04, can edit pages and what not. So I wouldn't expect anything broken there.

However, you pointing me at the debugging setting in the .env file put me on track for the laravel.log (I've seen it before, but totally forgot that THAT is the actual BookStack log file).
Anyway, even without setting APP_DEBUG=true, I looked at that log file just as it is, and indeed it shows some clear errors, which I can reproduce when uploading a file and watching the log file live. It immediately - and only - dumps this error:

production.ERROR: Method Illuminate\Validation\Validator::validateImageExtension does not exist. {"userId":1,"exception":"[object] (BadMethodCallException(code: 0): Method Illuminate\Validation\Validator::validateImageExtension does not exist. at /opt/local/share/httpd/htdocs/BookStack/vendor/laravel/framework/src/Illuminate/Validation/Validator.php:1308)

Followed by 52 lines of stacktrace which I deem unnecessary to dump here now.

Armed with that new info, I googled again and found this rather short dialogue:
https://www.gitmemory.com/issue/BookStackApp/BookStack/2458/755727903

Before, I couldn't find any similar reported issues, at least not within this github issues collection. But apparently you have been supporting on different discussion platforms as well ;-)

The questions now are, I think:

  1. what package do I need to add, to get that "Image Extension" in place?
  2. why is it suddenly missing while it worked fine - and thus, I suppose, the package was there - before I upgraded BookStack to v21.04?

To give you maybe a little context as to the first question: I'm running OmniOSce (https://www.omniosce.org), a Solaris descendant, where I use the pkgsrc-repository (https://pkgsrc.joyent.com) to provide Apache, PHP and such.
Right now, I have the following PHP 7.4 packages installed to support the BookStack installation:

$ pkgin search php74 | grep =
ap24-php74-7.4.16nb5 = Apache (apache24) module for PHP7.4
php74-bcmath-7.4.16 = PHP extension for bc-style arbitrary precision math
php74-composer-2.0.12 = Dependency Manager for PHP
php74-curl-7.4.16nb9 = PHP extension for curl functions
php74-fpm-7.4.16nb5 = FPM interface for PHP7.4
php74-gd-7.4.16nb1 = PHP extension for GD graphics library
php74-intl-7.4.16nb5 = PHP extension for i18n
php74-json-7.4.16 = PHP extension for JSON serialization support
php74-ldap-7.4.16nb1 = PHP extension for LDAP database access
php74-mbstring-7.4.16 = PHP extension for multibyte characters support
php74-mysqli-7.4.16 = PHP5 extension for MySQL 4.1 and later databases
php74-opcache-7.4.16 = PHP extension for opcode caching
php74-pdo-7.4.16 = PHP extension for PHP Data Objects (base)
php74-pdo_mysql-7.4.16 = PHP extension for PHP Data Objects (MySQL)
php74-pear-1.10.12nb3 = PEAR Base System for PHP
php74-pecl-mcrypt-1.0.4 = Bindings for the libmcrypt library
php74-soap-7.4.16nb2 = PHP extension for SOAP functions
php74-tidy-7.4.16 = PHP extension for tidy functions
php74-xmlrpc-7.4.16nb2 = PHP extension for XML-RPC support
php74-xsl-7.4.16nb2 = PHP extension for XSLT functions
php74-zip-7.4.16nb4 = PHP extension for ZIP archive handling
=: package is installed and up-to-date

I must admit that, when looking a the package requirements for BookStack ("Required Extensions: OpenSSL, PDO, MBstring, Tokenizer, GD, MySQL, SimpleXML & DOM"), there are some that I have a hard time finding in the available packages on pkgsrc (e.g. OpenSSL, Tokenizer, SimpleXML, DOM), but again: uploading an image worked before! So even if some PHP-extensions are missing, the setup has proven that it could digest an image file.

@cautiouscoyote commented on GitHub (Apr 12, 2021): Hi @ssddanbrown! Thanks for the quick reply. First I verified the APP_URL setting, as you pointed out, but surely there's nothing wrong with that: I can access my BookStack setup just like before the upgrade to v21.04, can edit pages and what not. So I wouldn't expect anything broken there. However, you pointing me at the debugging setting in the .env file put me on track for the **laravel.log** (I've seen it before, but totally forgot that THAT is the actual BookStack log file). Anyway, even without setting APP_DEBUG=true, I looked at that log file just as it is, and indeed it shows some clear errors, which I can reproduce when uploading a file and watching the log file live. It immediately - and only - dumps **this error**: > production.ERROR: Method Illuminate\Validation\Validator::validateImageExtension does not exist. {"userId":1,"exception":"[object] (BadMethodCallException(code: 0): Method Illuminate\\Validation\\Validator::validateImageExtension does not exist. at /opt/local/share/httpd/htdocs/BookStack/vendor/laravel/framework/src/Illuminate/Validation/Validator.php:1308) Followed by 52 lines of stacktrace which I deem unnecessary to dump here now. Armed with that new info, I googled again and found this rather short dialogue: https://www.gitmemory.com/issue/BookStackApp/BookStack/2458/755727903 Before, I couldn't find any similar reported issues, at least not within this github issues collection. But apparently you have been supporting on different discussion platforms as well ;-) The questions now are, I think: 1. what package do I need to add, to get that "Image Extension" in place? 2. why is it suddenly missing while it worked fine - and thus, I suppose, the package was there - before I upgraded BookStack to v21.04? To give you maybe a little context as to the first question: I'm running OmniOSce (https://www.omniosce.org), a Solaris descendant, where I use the pkgsrc-repository (https://pkgsrc.joyent.com) to provide Apache, PHP and such. Right now, I have the following PHP 7.4 packages installed to support the BookStack installation: $ pkgin search php74 | grep = ap24-php74-7.4.16nb5 = Apache (apache24) module for PHP7.4 php74-bcmath-7.4.16 = PHP extension for bc-style arbitrary precision math php74-composer-2.0.12 = Dependency Manager for PHP php74-curl-7.4.16nb9 = PHP extension for curl functions php74-fpm-7.4.16nb5 = FPM interface for PHP7.4 php74-gd-7.4.16nb1 = PHP extension for GD graphics library php74-intl-7.4.16nb5 = PHP extension for i18n php74-json-7.4.16 = PHP extension for JSON serialization support php74-ldap-7.4.16nb1 = PHP extension for LDAP database access php74-mbstring-7.4.16 = PHP extension for multibyte characters support php74-mysqli-7.4.16 = PHP5 extension for MySQL 4.1 and later databases php74-opcache-7.4.16 = PHP extension for opcode caching php74-pdo-7.4.16 = PHP extension for PHP Data Objects (base) php74-pdo_mysql-7.4.16 = PHP extension for PHP Data Objects (MySQL) php74-pear-1.10.12nb3 = PEAR Base System for PHP php74-pecl-mcrypt-1.0.4 = Bindings for the libmcrypt library php74-soap-7.4.16nb2 = PHP extension for SOAP functions php74-tidy-7.4.16 = PHP extension for tidy functions php74-xmlrpc-7.4.16nb2 = PHP extension for XML-RPC support php74-xsl-7.4.16nb2 = PHP extension for XSLT functions php74-zip-7.4.16nb4 = PHP extension for ZIP archive handling =: package is installed and up-to-date I must admit that, when looking a the package requirements for BookStack ("Required Extensions: OpenSSL, PDO, MBstring, Tokenizer, GD, MySQL, SimpleXML & DOM"), there are some that I have a hard time finding in the available packages on pkgsrc (e.g. OpenSSL, Tokenizer, SimpleXML, DOM), but again: uploading an image worked before! So even if some PHP-extensions are missing, the setup has proven that it could digest an image file.
Author
Owner

@ssddanbrown commented on GitHub (Apr 13, 2021):

Hi @cautiouscoyote,
Did you have any errors when running the composer install --no-dev step of the update?

The error you're getting generally reflects that some files are out of date or not found. It's either the composer install --no-dev step is not working as expected or the service files are cached. If no errors on the above, you can try the following:

Beware, I'm not familiar with OmniOSce/Solaris at all, so backup and run at your own risk.

# Go to your BookStack install dir
cd my_bookstack_install_dir

# Delete any system cached service files
rm ./bootstrap/cache/*.php

# Double check there's no files in the bootstrap/cache folder within your BookStack install
ls -l ./bootstrap/cache/ | grep php
@ssddanbrown commented on GitHub (Apr 13, 2021): Hi @cautiouscoyote, Did you have any errors when running the `composer install --no-dev` step of the update? The error you're getting generally reflects that some files are out of date or not found. It's either the `composer install --no-dev` step is not working as expected or the service files are cached. If no errors on the above, you can try the following: Beware, I'm not familiar with OmniOSce/Solaris at all, so backup and run at your own risk. ```shell # Go to your BookStack install dir cd my_bookstack_install_dir # Delete any system cached service files rm ./bootstrap/cache/*.php # Double check there's no files in the bootstrap/cache folder within your BookStack install ls -l ./bootstrap/cache/ | grep php ```
Author
Owner

@cautiouscoyote commented on GitHub (Apr 13, 2021):

Hi there again, @ssddanbrown,

It looks like you nailed it. No, there were no errors during the composer install --no-dev step, but I just looked at the ../bootstrap/cache/ directory like you suggested, and there were three *.php files:

config.php
packages.php
services.php

I moved all three out of there, rebooted the BookStack zone (that's Solaris terminology for what is roughly comparable to a container or light VM) for a proper test, logged in again and at least at that point in time everything looked OK: at least the system was not broken due to moving the php files out of the cache.
Then I tried uploading the same cover image onto the exact same page again and behold: it popped in place nicely!
I then looked at the cache folder again and it now holds only two *.php files:

packages.php
services.php

So apparently, the cached config.php file had been screwing up the updated system.

Also, I do understand that I'm somewhat on my own with this OmniOSce-system, but since BookStack uses dependencies that are rather widely available, while in this case via the OS-independent pkgsrc repo, I figured I should be able to run it natively and not need a full-blown Linux VM on top of it. And up until now at least, that works fine indeed. This hiccup could happen on any platform, I suppose.

Thanks a bunch for sorting this out so quickly!
Cheers!

@cautiouscoyote commented on GitHub (Apr 13, 2021): Hi there again, @ssddanbrown, It looks like you nailed it. No, there were no errors during the `composer install --no-dev` step, but I just looked at the ../bootstrap/cache/ directory like you suggested, and there were three *.php files: config.php packages.php services.php I moved all three out of there, rebooted the BookStack zone (that's Solaris terminology for what is roughly comparable to a container or light VM) for a proper test, logged in again and at least at that point in time everything looked OK: at least the system was not broken due to moving the php files out of the cache. Then I tried uploading the same cover image onto the exact same page again and behold: it popped in place nicely! I then looked at the cache folder again and it now holds only two *.php files: packages.php services.php So apparently, the cached config.php file had been screwing up the updated system. Also, I do understand that I'm somewhat on my own with this OmniOSce-system, but since BookStack uses dependencies that are rather widely available, while in this case via the OS-independent pkgsrc repo, I figured I should be able to run it natively and not need a full-blown Linux VM on top of it. And up until now at least, that works fine indeed. This hiccup could happen on any platform, I suppose. Thanks a bunch for sorting this out so quickly! Cheers!
Author
Owner

@ssddanbrown commented on GitHub (Apr 20, 2021):

Thanks for confirming that got things going @cautiouscoyote, Glad to hear it's now working. Will therefore close this off.

Also, I do understand that I'm somewhat on my own with this OmniOSce-system, but since BookStack uses dependencies that are rather widely available, while in this case via the OS-independent pkgsrc repo, I figured I should be able to run it natively and not need a full-blown Linux VM on top of it. And up until now at least, that works fine indeed. This hiccup could happen on any platform, I suppose.

Yeah, That's true. From my perspective I like to keep BookStack fairly operating system abstract, I just won't be able to offer a good level of support for any systems I don't have access to or are not familiar with.

@ssddanbrown commented on GitHub (Apr 20, 2021): Thanks for confirming that got things going @cautiouscoyote, Glad to hear it's now working. Will therefore close this off. > Also, I do understand that I'm somewhat on my own with this OmniOSce-system, but since BookStack uses dependencies that are rather widely available, while in this case via the OS-independent pkgsrc repo, I figured I should be able to run it natively and not need a full-blown Linux VM on top of it. And up until now at least, that works fine indeed. This hiccup could happen on any platform, I suppose. Yeah, That's true. From my perspective I like to keep BookStack fairly operating system abstract, I just won't be able to offer a good level of support for any systems I don't have access to or are not familiar with.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/BookStack#2190