A follow-on activity to PR #5061. That PR added scrollbars to the dropdown lists when samples were run in a browser. Earlier changes had broken up a number of categories into multiple entries because the dropdown lists were too long and wound up truncated. With the scrollbars, it makes sense to re-consolidate many of those lists, such as ComplexNumbers, which are all essentially the same test as each other. Some break-ups are retained (e.g. Basic/1/2/3/4/5) because they differ substantially from sample to sample; that's kind of an arbitrary decision, but it will have to do for now. I also renamed some of the members so that like members sort together when listing the directory (e.g. all pivot table samples now start with `pvt`). The sample code is mostly unchanged; only the directory and/or member names are changed.
The download samples were moved to their own new directory, and now represent a complete set of all the write formats that we permit. Studying their code, an improvement for `Helper\Downloader` became evident. It had been used merely to copy an existing file to be downloaded. However, by changing the first parameter of `download` to be either the name of the file directory (the existing usage) *or* a `Writer` object poised to issue `save`, you can use it to download your spreadsheet without having to worry about the headers which the browser requires. It then becomes generally useful beyond being used in samples:
```php
$writer = new WriterType($spreadsheet);
$downloader = new Downloader($writer, 'suggestedFileName.xlsx');
$downloader->download();
```
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.
With setPreCalculateFormulas(false) the formula text was written as the
value of the cell (office:string-value and text:p), and LibreOffice showed
it as the result. The cell now has table:formula alone, as the Xlsx Writer
writes <f> without <v>, so the application that opens the file calculates
it. A hyperlink of the cell is still written.
Ods Reader applied a style only to a cell with content or with a cell
after it, so such a formula cell at the end of its row lost its style;
a cell with a formula now keeps it.
When an IF sits in the condition of another IF, BranchPruner only
looked at the immediately enclosing IF to decide which branch the
condition tokens depend on. If that enclosing IF was itself still in
its condition, nothing was recorded, so the link to an outer IF whose
branch is being pruned was lost. Those tokens were then evaluated and
left on the stack while the rest of the branch was pruned, and the
calculation ended with "internal error".
Walk up the stack of enclosing IFs to the closest one whose then or
else branch contains the nested IF instead.
Fixes#3790Fixes#3755
These have made it to the nightly Php8.6 for Windows, though it hasn't yet affected that release on Github Ubuntu.
- A string like `xyz` has historically been treated as if it were `<p>xyz</p>` by `Dom->loadHtml()`. No more - recent changes cause it to be dropped altogether, treating it as an empty string.
- `Dom->loadHtml()` seems to have stopped issuing warning messages altogether, so there is no longer any clue that anything untoward has happened.
- There seem to have been some changes regarding how line endings are generated.
- There are doubtless other differences that I haven't stumbled upon yet.
Documentation on these changes is available at https://gitlab.gnome.org/GNOME/libxml2/-/work_items/211
Php says there's nothing they can do about this. Their recommendation is to move to the new Dom\HTMLDocument class. Which is a fine idea, except that we still need to support Php 8.2 and 8.3, and the new class wasn't introduced until Php 8.4. So this PR kludges up our code a bit to use the existing code for libxml releases before the one where these problems were discovered, and the new class for later releases. I think, or at least hope, that this is safe - I don't think the problematic libxml release will be applied to anything earlier than Php8.6.
dependabot[bot]
oleibman
^^
Dmytro Kulyk
HawkForge
Progi1984