Test for url image used file_get_contents on file which we have read successfully for years. Today it started returning error 403. Disable tests while I study whether there is a suitable replacement.
* Validate Mime Type for Images
* Extend Change to Xlsx Reader
* Attach Drawing to Sheet Only If Valid
* Suppress Some Theoretical Warning Messages
* Minor Tweak
Changes to Php8.4 floating point calculations caused failures in unit tests for ROUNDDOWN, ROUNDUP, and AMORDEGRC. These were addressed in a kludgey manner by PR #3897. Then someone reported a problem (not specifically related to Php8.4) with TRUNC. That was fixed by PR #4115, in which I applied the method used by TRUNC to ROUNDDOWN and ROUNDUP as well. The method used to fix these was to cast a floating point value to string and then cast it back to float again. It's a bit surprising that this works, but it seems effective for all our test cases, and is less kludgey than what had been done earlier. Missing from that PR was a similar change for AMORDEGRC. This PR applies that change to AMORDEGRC, which again passes the unit test suite for all releases of Php.
As described in issue #4161, Php seems to be prepared to break the fgetcsv function in release 9, marking the existing usage deprecated in 8.4. This gives us a long-term problem. This PR provides a short-term solution.
* Validate POST Input in Sample 45
Errors will result if inputs are not numeric.
* Update 45_Quadratic_equation_solver.php
---------
Co-authored-by: Owen Leibman <owenleibman@fico.com>
PR #4132 was needed for release 2.2.2 because of a problem with Excel 2016 introduced with 2.2.0. This is a minor tweak to that change - a little simpler, and possibly beneficial if the spreadsheet uses split screens.
Fix#1402, another in our "better late than never" series. Stalebot closed it in May 2020, and I have reopened it. @ljcag submitted the issue, and PR #1403 to resolve it, also marked stale. That change is more complicated than this one. Since there were no tests in that PR, and since this PR solves the original problem (test added), I will stick with this version, but will continue to study 1403 before merging.
This is also another in the "Excel doesn't believe in complete documentation" series. (See issue #3802 for a similar example.) Nothing that I have seen in the documentation suggests that a number will not match a numeric string, but that seems clearly to be the case. Despite the lack of complete documentation, PhpSpreadsheet implemented VLOOKUP with that in mind. Unfortunately, it did so by using `is_numeric` on its comparands, and so treats numeric strings as if they were numbers. This PR replaces those tests with `is_int() || is_float()`. The earlier PR used `is_string()` instead as a proxy for "not numeric" but that required other changes.
When String Value Binder converts a numeric value to text, the resulting spreadsheet will be full of little green triangles to indicate to the end user that something might be wrong. It is unlikely that a spreadsheet created in this manner needs that visual clutter. This PR adds a property and setter (I can't really think of a good use case for a getter) to suppress it. Suppression should arguably be the default, but, for now, I will avoid any BC problems by leaving non-suppression as the default.
This supersedes PR #607 by @christian-forgacs, who deserves all the credit for reporting the problem and devising the solution. The PR went stale in 2018, and it is just easier to resubmit a clean version rather than clean up the old one. Among the suggestions in the PR was that you should try to create a spreadsheet from scratch to demonstrate the problem rather than supply one. However, my attempts to match the failing spreadsheet do not have a problem when they are read. So, a supplied spreadsheet it is.
Fix#1570. No sample spreadsheet was supplied with that issue, but I am almost certain that this is another example of the same problem. I am removing the stale label from that issue; it will be closed properly when this PR is merged.
Suggested by PR #1321 from @rtek, which was marked stale in March 2020. If the xml for a cell does not specify a type, PhpSpreadsheet has been using string; however, Excel uses numeric. PhpSpreadsheet will be changed to do the same as Excel. In theory, this is a BC break; in practice, it is doubtful that anyone will be adversely affected. No changes in the existing unit tests were required. The new test from rtek does demonstrate the change in behavior; however, the new behavior is certainly what a user would expect to happen. Unlike the original PR, this one is restricted to Xlsx Reader; I do not believe that any logic change is needed for Writer. (N.B. - changing Writer to use class constants rather than literals is a good idea, but, with no other logic change in this version, it seems risky - I may do that as separate PR.)
oleibman
dependabot[bot]
Marc Bennewitz