Upload Bugs and an Enhancement

[406man]

My gallery is set up so that it only accepts images up to a certain size in pixel dimensions and file size. If an image is bigger it should be rejected. Uploads have to be approved by an administrator who is emailed when an image is uploaded. I've found a number of bugs in the upload process with the gallery set up this way. Same behaviour with 1.6.21 and 1.6.22.

I've included details of these bugs and also an enhancement because it would be really helpful to see them included in a future release of CPG so I don't have to change the code myself in future.
------------------
Upload Bug #1
When an image is uploaded using the single image loader, if it's too large the image is added to the users's album in /albums/userpics/100xx but not deleted when it is found to be too large.

The file is deleted in /include/picmgmt.inc.php by the command @unlink($uploaded_pic). Unfortunately the variable $uploaded_pic is undefined at this point and there's no checking the status of the command so the error is not reported.I fixed it by defining $uploaded_pic as a global in two places:
- in uniload.php
    add code just after:  define('H5U_LOG','h5upload');
    new code:     global $uploaded_pic;

- in /include/picmgmt.inc.php
    Replace:  global $lang_errors, $lang_db_input_php;
    with:     global $lang_errors, $lang_db_input_php, $uploaded_pic;
--------------
Upload bug #2.
When an upload in the single uploader fails the error message appears as just text on a white screen whereas it should have been included in a standard Coppermine error screen.
See screenshot too-big-error.png

In the code, when the upload fails, uniload.php calls the error_out routine which outputs the error message shown. I fixed it by redirecting back to upload.php with a fatal error code and suitable error message. This also involved editing picmgmt.inc.php to pass back an error code of 2 in this case. It's a messy solution but it works.

Attached: bug2-code.txt
--------------------
Upload bug #3.
When using the HTML 5 uploader, if the config option is set to notify admins by email, an email is not sent if all uploads are successful. The email only gets sent if one fails to be uploaded because of, for example, an image being too big.

I've tried to find out why this is happening. I put a debugger call in \plugins\upload_h5a\upload.js where function H5up_done is called. This works as expected.
In the debugger I stepped into various js calls.
Stepped into: $.post('notifyupload.php'........
Stepped into: \js\jquery-1.12.4.js   
At this point I got lost. I'm unable to proceed due to lack of skill and experience.
I know that notifyupload is not being called because the PHP debugger shows control going straight to editpics.php

For now I'm getting email notification from a hack that I added to uniload.php but the downside is getting an email for each image.
---------------------------
Enhancement #1
An enhancement to the upload. When I get an email to say that a user has uploaded a picture for approval I really want to know the album where they've uploaded it because different albums have different deadline dates. In some cases I may need to action the approval quickly, other times not. So I enhanced the part of uniload.php that sends the email to include the category and album names. I've included code fragments to show this. I won't claim it's great code but it works.
Attached: enhancement-1.txt

[ron4mac]

Thank you for your feedback and sleuthing out these issues. We'll look into them before the next release (1.6.23).
You should be aware that at our Github Repository you can create Issues for problems that you may find.
Your help is appreciated.

[ron4mac]

I was unable to replicate the issue you are having with no admin approval emails when there are no upload errors.
I could, however, see the possibility existing for some systems/browsers.
Could you please use the attached versions of upload.js and upload.min.js to see whether it may correct the issue for you?
(be sure to clear cache)