I think phpcs's indentation logic was wrong in the previous version. Rearrange some code to make it less likely that a future phpcs fix will cause the code to break.
Upgrade Bootstrap from V3 to V5. The current version is very much out of date. Migration wasn't particularly straightforward - I have rejected doing it in the past for that reason. I let AI help me this time around, and, although we went down many blind alleys, we eventually met with success. The upgrade leads to a couple of improvements:
- There is now a toggle for light/dark mode.
- The dropdown lists now have scrollbars when needed. This means that we can re-consolidate some categories which were previously split up because the dropdown was unusable. This PR leaves the categories unchanged, but it is something I can consider in future.
Bootstrap V5 no longer requires jQuery, so it is dropped.
FontAwesome is still on an old version. Newer versions use much larger files, mainly because of many new icons, none of which we use. So there is a cost to upgrading, and I don't see a compensating advantage. In fact, I have reduced its css file to one which includes only the icons we are using. And, since more modern versions distribute only the woff2 version of the font, I am removing the alternatives; I'm willing to add them back on request.
This change does not affect the PhpSpreadsheet code in any way, nor does it affect running samples from the command line - just running samples in a browser.
The samples have become unwieldy when running them from a browser. In particular, the drop-down lists are fixed size with no scrolling, and many of them are now just too large. I have moved all the Calculation samples up a level, and broken several categories (Basic, Chart, DateTime, Engineering, Financial, and Reader) into several pieces.
Convert-Online (now found in the Engineering category) had a number of different problems which are now resolved. It is the only member with any significant code change.
Fix#3739. User is seeing an intermittent notice when running samples using a web browser. The notice is comming from ob_clean, complaining that there is no buffer to delete. I frankly do not understand what the ob_clean is supposed to be paired with, nor why I cannot duplicate this result. Possibly, a better solution would be to eliminate the ob_clean; but using ob_get_length beforehand to see if there is anything to clean up seems safer, and I can't think of a downside.
The code in question is never executed when a sample is run from the command line. Consequently, no formal unit test is possible. The user reporting the problem was asked to test the change, and confirmed that the problem went away; no new problem arose on my system.
This introduce a helper class that should be used to log things,
avoiding a lot of boilerplate code.
Also all output are made in /tmp folder instead of beside the script
itself. This is because there is a high chance that the folder containing
the script is not writtable by webserver. So using the /tmp folder
makes it more likely to works in a variety of setup.
oleibman
Owen Leibman
Adrien Crivelli