bsmither

This is very interesting information and I am grateful for the time you've taken to explain the situation. Thank you!

Another experiment with a 8GiB file has these results: PHP did not time out. Even though max_execution_time is set to 60 seconds, it took 66 seconds for the entire process to finish (this function and and a few milliseconds of additional work elsewhere). The web server did time out waiting for PHP. Using NGINX where the default request timeout is 60 seconds, the result was a 504 Gateway Time-out. PHP's current memory allocation jumped from 3MiB to 12MiB at the point where md5_file() executed. Watching the drive activity light on the server box showed continuous activity for approximately 65 seconds. Followed by a brief blip for housekeeping. So, I can surmise that PHP's md5_file() reads the file in chunks - perhaps 8-9MiB per chunk - but unknown if the file fits completely in memory, then that is what will happen.

PHP 7.4.2 is given 256M as memory_limit. I am giving a 370MB file to md5_file(). I get a hash with no errors. Is PHP loading the entire file into memory, all at once, to process it? If so, is there then a practical limit to the size of the file without eventually causing an out-of-memory situation?

I wouldn't know what to look for when searching PHP's bug tracking system. That's why I asked here - maybe there is someone here who is far, far more into understanding the innards of PHP who could definitely say the extra line endings is a bug, and whether or not it is even directly associated with print_r(), or if the extra line endings were coded into the PHP source elsewhere and its appearance in print_r() is a knock-on effect.

After switching from PHP 5.3 on Windows Server 2003 to PHP 7.4.3 on Linux Mint 19.3 (Tricia Cinnamon), I find that the output of print_r() has changed. If we look at the documentation (https://www.php.net/manual/en/function.print-r.php), the provided example output is as it was on my earlier machine: <pre> Array ( [a] => apple [b] => banana [c] => Array ( [0] => x [1] => y [2] => z ) ) </pre> However, on the second machine, the output is: <pre> Array ( [a] => apple [b] => banana [c] => Array ( [0] => x [1] => y [2] => z ) <blank line> ) </pre> Note the unexpected new line after each recursed array's closing parenthesis. The new line is not present after the outermost array closing parenthesis. Also to note, there is a newer version of XDebug installed. My question is: Is this a bug? (Follow-on question: if possible to determine at which version the output changed, what version would that be?) This difference is causing existing code to not be able to correctly parse that output.

You probably have an error in these statements: $to = "info@mydomain,com, mysecondaryemail@gmail.com"; $subject = 'Naming Form via Website'; $email_from = 'info@mydomain,com'; Check the spelling of the email addresses.

If you are concerned about getting an array of objects instead of an array of associative arrays, use: json_decode($json, true) Realize you will end up with null elements in the output objects if parsing a string having three or more delimiters where any two or more are consecutive.

I suggested: <a href="?action=edit&file=bludit%2Fstart%2Ephp">bludit/start.php</a> and this is what is being attempted: <a href="?action=EDIT<?php echo $file; ?>"><?php echo $file; ?></a> which gives you: ?action=EDIT./bludit/bl-kernel/boot/rules/70.posts.php The &file= is missing, unless it is included as part of $file. Since the leading dot-slash seems to be common for every item in the report, my suggestion did not include that, and also suggested that the data to populate the HTML link be urlencode()'d. Having a collection of checkboxes with the same name sometimes gets you an array, but sometimes gets you a scalar. To make sure we get an array of selected files to delete - one or more than one - we add brackets to the name. <input type="checkbox" name="DELETE[]" value=<?php echo $file; ?>> <!-- do not forget to use quotes for the value attribute --> If the form is POSTed, PHP gives you $_POST['DELETE'] as an array of selected checkbox values.

We can try: <a href="?action=edit&file=bludit%2Fstart%2Ephp">bludit/start.php</a> When including the list in the output, you might want to urlencode() the querystrings. Surround all those links with <form> tags, add a <input type="check", name="delete" value="bludit%2Fstart%2Ephp"> next to each link, add a submit button and there you are!

Not a recommendation, but another way to skin the cat: function check($a, (int)$z) { $return = is_array($a) && (count($a)==$z); // so far so good if($return) foreach($a as $k => $v) $return = $return && (is_int($k)); // first non-integer key fails the whole thing // can also use a while loop to iterate the array and stop at first false return $return; } I think your test arrays will always be non-associative as you are using a short syntax listing only values. Also, there is the possibility that the integer indices will not be zero and one.

In addition to the blank line before the opening code delimiter (<?php) in config.inc.php, another situation that may trip up new coders is that general-purpose text editors may place what is known as the "byte-order-mark" (BOM) at the start of the file. This BOM is not visible unless looking at the file in HEX mode. PHP will also send this byte sequence out, causing the same "headers already sent" message. Please be sure to use a programmer's text editor, and save files without the BOM.

I would think this would be a javascript/ajax powered solution. Maybe ColorBox or ThickBox.

In create.php, I do not find where $submit (line 42) has had anything assigned to it. Presumably, it is $_POST['submit']. And you are not enclosing the last two else blocks within braces. I would recommend you do that regardless of any shortcut you may have seen elsewhere.

Maybe just a smidgen more involved: <i class="image" rel="index|hash"></i> Have javascript (jQuery) collect up all the $(".image") objects, associate the rel attribute into a json array, ajax that to a PHP script, that will get the index and compare the pre-computed hash in a server-based filemanager setup, then return a base64 encoded binary response of actual image data, whereby the inner contents of the relevant <i> tag is filled with the image data using the "data:image/png;base64" format. ...I think.

Please verify the name of the variable you have assign $_REQUEST['name'] to, versus the name of the variable in the query.