webERP Forum
PHP error without warning when logging is enabled - SOLVED - Printable Version

+- webERP Forum (http://www.weberp.org/forum)
+-- Forum: webERP Discussion (http://www.weberp.org/forum/forumdisplay.php?fid=1)
+--- Forum: Problems / Bugs? (http://www.weberp.org/forum/forumdisplay.php?fid=8)
+--- Thread: PHP error without warning when logging is enabled - SOLVED (/showthread.php?tid=9255)

Pages: 1 2

PHP error without warning when logging is enabled - SOLVED - dalescott - 05-06-2022

Hi all, I tried unsuccessfully to delete an old user from my demo system this morning and found a PHP Fatal error in the Apache log, which I presume to be why the user was not deleted (but admit I am more a user than a dev ;-))

I clicked Delete for the user in the Users Maintenance page, then OK in the "Are you sure you wish to delete this user?" pop-up), but the user was not removed from the list.

The Apache error log entry is:

Code:
[Thu May 05 08:22:58.831791 2022] [php:error] [pid 81441] [client 174.0.43.39:52418] PHP Fatal error:  Uncaught TypeError: fwrite(): Argument #1 ($stream) must be of type resource, null given in /usr/local/www/weberp/includes/footer.php:21\nStack trace:\n#0 /usr/local/www/weberp/includes/footer.php(21): fwrite()\n#1 /usr/local/www/weberp/WWW_Users.php(842): include('...')\n#2 {main}\n  thrown in /usr/local/www/weberp/includes/footer.php on line 21, referer: https://weberp.dalescott.net/WWW_Users.php?&SelectedUser=glennhughes&delete=1

The code is the head of the master branch from https://github.com/webERP-team/webERP. I had performed a git pull prior to attempting to delete the old user, but the only update was to doc/CHANGELOG (Tim's update indicating the link from the dashboard to the manual had been corrected). I'm using PHP v8.0.18, MariaDb 10.5.15 and Apache 2.4.53.  

Unfortunately I cannot say when I was last able to delete a user, but it was likely before I upgraded from PHP 7 to PHP8 at Christmas (thereabouts).

Can anyone shed some light on this? Could this be a PHP v8 problem that was unknown until now? Should I be using the weberp_version5 branch now? 

Thanks,
Dale


PHP Version

Code:
dale@whizzer:/usr/local/www/weberp % php --version
PHP 8.0.18 (cli) (built: Apr 16 2022 01:20:15) ( NTS )
Copyright (c) The PHP Group
Zend Engine v4.0.18, Copyright (c) Zend Technologies
dale@whizzer:/usr/local/www/weberp % php -m
[PHP Modules]
bcmath
bz2
Core
ctype
curl
date
dom
exif
fileinfo
filter
gd
gettext
gmp
hash
iconv
imagick
intl
json
libxml
mbstring
mysqli
mysqlnd
openssl
pcre
PDO
pdo_mysql
posix
Reflection
session
SimpleXML
soap
SPL
standard
tokenizer
xml
xmlreader
xmlwriter
zip
zlib

[Zend Modules]

dale@whizzer:/usr/local/www/weberp %


MariaDb Version

Code:
dale@whizzer:/usr/local/www/weberp % pkg info | grep -i maria
mariadb105-client-10.5.15_3    Multithreaded SQL database (client)
mariadb105-server-10.5.15_3    Multithreaded SQL database (server)


Apache Version


Code:
dale@whizzer:/usr/local/www/weberp % pkg info | grep -i apache
apache24-2.4.53_1              Version 2.4.x of Apache web server


RE: Failure on PHP v8 appears to prevent deleting user - TurboPT - 05-06-2022

Thanks for the report, Dale, will take a look as soon as I get a chance. May likely be PHP8 related.

RE: Failure on PHP v8 appears to prevent deleting user - dalescott - 05-06-2022

Thanks @TurboPT. Let me know if you need more information or want me to do any testing.

RE: Failure on PHP v8 appears to prevent deleting user - TurboPT - 05-08-2022

Does not look to be PHP 8 related.

What do you show for the first 10 lines of footer.php? ... it looks like a fix that I added a few years ago might be lost.

Also, at Setup => System Parameters, what do you show set to: Log Severity Level ?
Setting this to None, as a temporary basis, should avoid the fwrite based on conditions that check the levels.

RE: Failure on PHP v8 appears to prevent deleting user - dalescott - 05-10-2022

Hi TuroboPT, I set Log Severity Level to "None" (it was originally set to "All") and a warning message appeared at the top of the page when attempting to delete the user ("WARNING Report : Cannot delete user as entries already exist in the audit trail"), and there was no PHP Fatal error in the Apache log file.

I then changed the log severity level back to "All" and confirmed the warning message did not appear (presumably the page was not re-rendered at all), and the PHP Fatal error appeared again in the Apache log file.

Could this issue result in other errors? Will it be limited in scope to only operations that fail expectedly due to business logic (such as in this case, when the delete is not permitted because the user has entries in the audit trail)?

I checked the contents of my includes/footer.php and see there are significant differences between the master branch and the "after_4.15.1_bug_fixes_only" branch (and that the default branch is the "after_4.15.1_bug_fixes_only" branch).

I wanted to follow development in my demo database by using the "master" branch, but is this unreasonable and I should use "after_4.15.1_bug_fixes_only" instead? If you recommend I use the "after_4.15.1_bug_fixes_only" branch, is it safe now to switch branches? I.e. will there be database issues if I switch branches?

Best regards,
Dale

My includes/footer.php (head of "master" branch):


Code:
dale@whizzer:/usr/local/www/weberp % head -n 12 ./includes/footer.php
<?php
echo '<div id="mask">
                <div id="dialog"></div>
        </div>';

if (isset($Messages) and count($Messages) > 0) {
        foreach ($Messages as $Message) {
                switch ($Message[1]) {
                        case 'error':
                                $Class = 'error';
                                $Message[2] = $Message[2] ? $Message[2] : _('ERROR') . ' ' . _('Report');
                                if (isset($_SESSION['LogSeverity']) and $_SESSION['LogSeverity'] > 3) {
dale@whizzer:/usr/local/www/weberp %


RE: Failure on PHP v8 appears to prevent deleting user - TurboPT - 05-10-2022

Know that everything in the after_4.15.1_bug_fixes_only branch has been merged into master with the 4.15.2 release, so all those changes from the bug_fixes_only branch are in master as well. Unfortunately, the repo's default is set to the bug_fixes_only branch, and with the new GitHub authentication (though I say new, it's been about 2 years since GitHub made the change), I've not been able to login to set the default back to master and delete the bug_fixes_only branch. The new GitHub device authentication code goes to another email account that I do not own.

The change needed to avoid the fwrite error is: (see the code comment, or lines 2-4 below)

PHP Code:
if (isset($Messages) and count($Messages) > 0) {
    if (isset($_SESSION['LogSeverity']) and $_SESSION['LogSeverity'] > 0) { // add these 3 lines
        $LogFile = fopen($_SESSION['LogPath'] . '/weberp.log', 'a');
    }

    foreach ($Messages as $Message) { 

So, if you could please add those 3 lines between the first if and the foreach, save, and recheck with the severity set to All to see if the fatal error goes away?
I'm thinking that there might be another unrelated error, but we'll see how the test goes.

The database changes are very minor (there's only 3 short statements, one of which is the version update), and you can see what those are here.

Hope all that helps.

RE: Failure on PHP v8 appears to prevent deleting user - dalescott - 05-11-2022

Hi TuroboPT, unfortunately still no warning message when attempting to delete user having audit trail entries with log severity level set to "All", and still have an error in the Apache httpd log file. However, the error has changed from "Argument #1 ($stream) must be of type resource, null given..." to "... must be of type resource, bool given..."

Edited includes/footer.php as requested (using tabs as original file uses tabs):


Code:
dale@whizzer:/usr/local/www/weberp % head -n 20 includes/footer.php
<?php
echo '<div id="mask">
                <div id="dialog"></div>
        </div>';

if (isset($Messages) and count($Messages) > 0) {

        if (isset($_SESSION['LogSeverity']) and $_SESSION['LogSeverity'] > 0) { // open log file if needed
                $LogFile = fopen($_SESSION['LogPath'] . '/weberp.log', 'a');
        }

        foreach ($Messages as $Message) {
                switch ($Message[1]) {
                        case 'error':
                                $Class = 'error';
                                $Message[2] = $Message[2] ? $Message[2] : _('ERROR') . ' ' . _('Report');
                                if (isset($_SESSION['LogSeverity']) and $_SESSION['LogSeverity'] > 3) {
                                        fwrite($LogFile, date('Y-m-d h-m-s') . ',' . $Type . ',' . $_SESSION['UserID'] . ',' . trim($Msg, ',') . "\n");
                                }
                        break;
dale@whizzer:/usr/local/www/weberp %

Error message in Apache log file:

Code:
dale@whizzer:/usr/local/www/weberp % tail -n 1 /var/log/httpd-error.log
[Tue May 10 14:25:41.638036 2022] [php:error] [pid 51945] [client 162.223.103.50:19623] PHP Fatal error:  Uncaught TypeError: fwrite(): Argument #1 ($stream) must be of type resource, bool given in /usr/local/www/weberp/includes/footer.php:26\nStack trace:\n#0 /usr/local/www/weberp/includes/footer.php(26): fwrite()\n#1 /usr/local/www/weberp/WWW_Users.php(842): include('...')\n#2 {main}\n  thrown in /usr/local/www/weberp/includes/footer.php on line 26, referer: https://weberp.dalescott.net/WWW_Users.php
dale@whizzer:/usr/local/www/weberp %


RE: PHP error when attempting to delete user - TurboPT - 05-11-2022

Ok, thanks for the update AND for giving that a try.

I'll look into that this weekend, sounds like a little deeper look is definitely needed.

I find it odd that the error would only be with delete user? ... because that footer is used with most pages.

=====

I had one other thought that might help me check... What is set, if anything, to Setup => System Parameters => Path to log files ?

RE: PHP error when attempting to delete user - dalescott - 05-12-2022

(05-11-2022, 10:47 AM)TurboPT Wrote: I had one other thought that might help me check... What is set, if anything, to Setup => System Parameters => Path to log files ?

Eureka! Yes, footer.php fails because the log file cannot be written to because the path specified in [Setup => System Parameters => Path to log files ] does not exist.

I set the path to a directory the Apache user has write permission to and now all is ok. My apologies, I should have been able to sort this on my own.

Do you want to keep the edit to footer.php? I can submit a pull request if this is an improvement, otherwise I will revert my local code.

Also, how should I interpret the log file? Does the following simply indicate that user dalescott attempted two actions at the indicated times? (presumably the first was to change the log file path, and the second was the attempted delete). 

Code:
dale@whizzer:~ % cat /usr/local/www/weberp_log/weberp.log
2022-05-11 09-05-08,,dalescott,
2022-05-11 09-05-36,,dalescott,
dale@whizzer:~ %


RE: PHP error without warning when logging is enabled - SOLVED - TurboPT - 05-12-2022

Thanks for the update! (no apology needed, config can be tricky sometimes if all the moving parts are not known)

Keep the local change, for now, since it's working (at least writing to the log, but looks like info is missing), but I'll commit that minor change to restore since it looks like there is more to cover.
However, you can revert if you want, but I'd set the Log Severity Level back to None to avoid the fwrite errors.

Interpreting the log file SHOULD have:

date, type (warn, success, etc.), user, message

... based on your example output, it looks like I need to update that handling in the footer too, as it appears to be missing the type and the message parts, which is why I'll cover the commit.

I will commit to master. (sometime this weekend)
Did you decide to switch to this branch? Won't matter much to download the updated footer from master if still on the bug_fixes_only branch.

Thanks for reporting this find, the only report on this matter as far as I know. You'll be credited for reporting the issue in the change log.