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.

I installed it and created a survey. This was a few years ago. (My client, who I was researching a solution for, decided to go with a different application.) I haven't explored LimeSurvey any further since then.

Spreadsheet? LibreOffice Calc can publish to HTML.

And this: https://github.com/illuminate/database/commit/34ae98bd9d942cbf93ff32627b0d4f093b092ba4

The change is in the Github from two years ago: https://github.com/illuminate/database/commit/5dc6c29463ef5245f6e4d91501a7d8aac9d30df1

The $query from $this->getQuery() does not have a valid - as of PHP 7.2 - property. Prior to PHP 7.2, the result of count() with an invalid parameter would have been misleading (a 0 or 1). Suggest verifying if this package has been updated to work with PHP 7.2.

"I repeat the same process by going to his sponsor and his sponsor..." Unlimited looping needs a calculated release. In your table, user2's sponsor is user2. (Typo?) This could create an inescapable loop. I like the query above, but the sponsor tree needs a sort so that the LIMIT 1 will be the closest ancestor.

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!