Update to Change Log

Inline documentation updates

It's a shared formula: the formula itself is only actually stored for one cell (e.g. R2). Cells R3, R4, R5, R1500 etc don't store the formula itself, they simply store a pointer saying that they should use the formula that was read from R2 after adjusting it for the current row.

Normally cell R2 would have the f`` attribute set to indicate that it contained a formula. Even though it's outside the filter range, the Reader still sees that ftag and looks to see if the formula itself is defined as **shared**. If so, it stores that formula in the Shared Formula Table, even though it doesn't load the Cell. Then, when it reads a cellR1500that is inside the filter range, and cellR1500says to use the formula fromR2`, it can look for that formula in the Shared Formula Table.

In this file, the f attribute wasn't set for Cell R2, so the Reader was simply ignoring it, and the formula wasn't being added to the Shared Formula Table. When cell R1500 says to use the shared formula for R2, that formula isn't in the Shared Formula Table, so it returns an empty formula.

The code change that I've made and merged into the master branch ready for the next release means that the Reader doesn't only look to see if the f attribute is set when the cell is outside the filter range, but also looks further to see if the cell actually contains a formula that is defined as shared, so that it will now get added to the Shared Formula Table.

When loading a file and accessing cells outside a filter range, we still check for shared formulae that may need to be used inside the filter range; so we test for the cell's f attribute. However, in some cases this attribute isn't set and we need to check for the presence of an f child element with a shared attribute

Scouting improvement: move the Shared Formula data to an object in an instance array, rather than using a simple nested array. This should be better for memory usage; and when we can apply readonly to object properties, then we can make the properties readonly public, eliminate the getters in the SharedFormula class

ChangeLog

Merge branch 'master' into Issue-3473_Shared-Formula-Chunked-Read-no-attribute-set

Merge pull request #3474 from PHPOffice/Issue-3473_Shared-Formula-Chunked-Read-no-attribute-set

Shared Formulae outside the filter range when reading with a filter are not always being identified

This is:

• [X] a bugfix
• [ ] a new feature
• [ ] refactoring
• [ ] additional unit tests

Checklist:

• [ ] Changes are covered by unit tests
  • [ ] Changes are covered by existing unit tests
  • [ ] New unit tests have been added
• [X] Code style is respected
• [X] Commit message explains why the change is made (see https://github.com/erlang/otp/wiki/Writing-good-commit-messages)
• [ ] CHANGELOG.md contains a short summary of the change and a link to the pull request if applicable
• [ ] Documentation is updated as necessary

Why this change is needed?

Issue #3473

When loading a file and accessing cells outside a filter range, we still check for shared formulae that may need to be used inside the filter range; so we test for the cell's f attribute; and if it is a shared formula then it's saved in the Shared Formula table so that it can be used when we encounter a cell inside the filter range that does use it.

However, in some cases (like this one) no f attribute was set and we need to check for the presence of an f child element with a shared attribute to indicate a Shared Formula that needs saving in the Shared Formula table.

Catch Up Change Log (#3475)

Some changes missing since release 28.

Merge branch 'master' into Issue-3473_Shared-Formula-Chunked-Read-no-attribute-set

Scouting improvement: move the Shared Formula data to an object in an instance array, rather than using a simple nested array. This should be better for memory usage; and when we can apply readonly to object properties, then we can make the properties readonly public, eliminate the getters in the SharedFormula class

ChangeLog

This is:

• [X] a bugfix
• [ ] a new feature
• [ ] refactoring
• [ ] additional unit tests

Checklist:

• [ ] Changes are covered by unit tests
  • [ ] Changes are covered by existing unit tests
  • [ ] New unit tests have been added
• [X] Code style is respected
• [X] Commit message explains why the change is made (see https://github.com/erlang/otp/wiki/Writing-good-commit-messages)
• [ ] CHANGELOG.md contains a short summary of the change and a link to the pull request if applicable
• [ ] Documentation is updated as necessary

Why this change is needed?

Issue #3473

When loading a file and accessing cells outside a filter range, we still check for shared formulae that may need to be used inside the filter range; so we test for the cell's f attribute; and if it is a shared formula then it's saved in the Shared Formula table so that it can be used when we encounter a cell inside the filter range that does use it.

However, in some cases (like this one) no f attribute was set and we need to check for the presence of an f child element with a shared attribute to indicate a Shared Formula that needs saving in the Shared Formula table.

For some reason in this file, the formula attribute f isn't set for the cells outside the filter range that contain the shared formula definition, so it isn't being read.

Correct: this is not a bug;

Formulas must have access to all the cells that they need to calculate their value correctly: It's the responsibility of you as an end-user developer to ensure that is the case.

There should be no problems with cells containing line breaks, it's just a normal character.

But your sample file loads without any issues:

$ php testing/readerTest.php
File LineBreaks.xlsx Identified as Xlsx
Loading File LineBreaks.xlsx using Xlsx Reader

Call time to load spreadsheet file was 0.0360 seconds
Max Row: 1000, Max Column: Z
Max Data Row: 3, Max Data Column: U
 Current memory usage: 8192 KB
    Peak memory usage: 8192 KB

…e size of the test suite grows

Initial tests locally suggest that paratest is slower (1:41 compared with 1:09), but uses a lot less memory (74MB compared with 227MB) Also need to see how it will handle the coverage report with pcov, and sending that to scrutinizer

This is:

• [ ] a bugfix
• [ ] a new feature
• [ ] refactoring
• [ ] additional unit tests

Checklist:

• [ ] Changes are covered by unit tests
  • [ ] Changes are covered by existing unit tests
  • [ ] New unit tests have been added
• [ ] Code style is respected
• [ ] Commit message explains why the change is made (see https://github.com/erlang/otp/wiki/Writing-good-commit-messages)
• [ ] CHANGELOG.md contains a short summary of the change and a link to the pull request if applicable
• [ ] Documentation is updated as necessary

Why this change is needed?

Provide an explanation of why this change is needed, with links to any Issues (if appropriate). If this is a bugfix or a new feature, and there are no existing Issues, then please also create an issue that will make it easier to track progress with this PR.

More tweaking of arguments passed to the parallel test runner; specifically now to handle memory problems with code coverage

Some tweaking of arguments passed to the parallel test runner

On my local, I'm now getting times that are faster than basic phpunit, while still only using 35% of the memory; but a very odd Fail

…e size of the test suite grows

Initial tests locally suggest that paratest is slower (1:41 compared with 1:09), but uses a lot less memory (74MB compared with 227MB) Also need to see how it will handle the coverage report with pcov, and sending that to scrutinizer

This is:

• [ ] a bugfix
• [ ] a new feature
• [ ] refactoring
• [ ] additional unit tests

Checklist:

• [ ] Changes are covered by unit tests
  • [ ] Changes are covered by existing unit tests
  • [ ] New unit tests have been added
• [ ] Code style is respected
• [ ] Commit message explains why the change is made (see https://github.com/erlang/otp/wiki/Writing-good-commit-messages)
• [ ] CHANGELOG.md contains a short summary of the change and a link to the pull request if applicable
• [ ] Documentation is updated as necessary

Why this change is needed?

Provide an explanation of why this change is needed, with links to any Issues (if appropriate). If this is a bugfix or a new feature, and there are no existing Issues, then please also create an issue that will make it easier to track progress with this PR.

…e size of the test suite grows

Initial tests locally suggest that paratest is slower (1:41 compared with 1:09), but uses a lot less memory (74MB compared with 227MB) Also need to see how it will handle the coverage report with pcov, and sending that to scrutinizer

This is:

• [ ] a bugfix
• [ ] a new feature
• [ ] refactoring
• [ ] additional unit tests

Checklist:

• [ ] Changes are covered by unit tests
  • [ ] Changes are covered by existing unit tests
  • [ ] New unit tests have been added
• [ ] Code style is respected
• [ ] Commit message explains why the change is made (see https://github.com/erlang/otp/wiki/Writing-good-commit-messages)
• [ ] CHANGELOG.md contains a short summary of the change and a link to the pull request if applicable
• [ ] Documentation is updated as necessary

Why this change is needed?

Provide an explanation of why this change is needed, with links to any Issues (if appropriate). If this is a bugfix or a new feature, and there are no existing Issues, then please also create an issue that will make it easier to track progress with this PR.

This is:

- [X] a bug report
- [ ] a feature request
- [ ] **not** a usage question (ask them on https://stackoverflow.com/questions/tagged/phpspreadsheet or https://gitter.im/PHPOffice/PhpSpreadsheet)

What is the expected behavior?

The Excel EOMONTH() and EDATE() functions should always return a float with the date, but with the time truncated to 0.

e.g.

EOMONTH(22269.75, 3) should result in float 22371.0 EDATE(22269.75, 2) should result in float 22331.0

What is the current behavior?

If the dateValue argument to EOMONTH() includes a time, then the result also includes that time.

EOMONTH(22269.75, 3) results in float 22371.75 EDATE(22269.75, 2) results in float 22331.75

What are the steps to reproduce?

Please provide a Minimal, Complete, and Verifiable example of code that exhibits the issue without relying on an external Excel file or a web server:

<?php

require __DIR__ . '/vendor/autoload.php';

use PhpOffice\PhpSpreadsheet\Calculation\DateTimeExcel\Month;

$dateValue = 22269.75;
$adjustment = 3;
$result = Month::lastDay($dateValue, $adjustment);
var_dump($result); // Should be (float) 22371.0 but is (float) 22371.75

$dateValue = 22269.75;
$adjustment = 2;
$result = Month::adjust($dateValue, $adjustment);
var_dump($result); // Should be (float) 22331.0 but is (float) 22331.75

If this is an issue with reading a specific spreadsheet file, then it may be appropriate to provide a sample file that demonstrates the problem; but please keep it as small as possible, and sanitize any confidential information before uploading.

What features do you think are causing the issue

• [ ] Reader
• [ ] Writer
• [ ] Styles
• [ ] Data Validations
• [X] Formula Calculations
• [ ] Charts
• [ ] AutoFilter
• [ ] Form Elements

Does an issue affect all spreadsheet file formats? If not, which formats are affected?

N/A

Which versions of PhpSpreadsheet and PHP are affected?

All

Fix for Issue 3439 - Getting a style for a CellAddress instance fails if the worksheet is set in the CellAddress instance

Merge pull request #3469 from PHPOffice/Issue-3439_GetStyle-with-CellAddress-object-including-Worksheet

Fix for Issue 3439 - Getting a style for a CellAddress instance fails…

… if the worksheet is set in the CellAddress instance

This is:

• [X] a bugfix
• [ ] a new feature
• [ ] refactoring
• [ ] additional unit tests

Checklist:

• [X] Changes are covered by unit tests
  • [X] Changes are covered by existing unit tests
  • [X] New unit tests have been added
• [X] Code style is respected
• [X] Commit message explains why the change is made (see https://github.com/erlang/otp/wiki/Writing-good-commit-messages)
• [X] CHANGELOG.md contains a short summary of the change and a link to the pull request if applicable
• [ ] Documentation is updated as necessary

Why this change is needed?

Bugfix for Issue #3439 - Getting a style for a CellAddress instance fails if the worksheet is set in the CellAddress instance

Fix for Issue 3439 - Getting a style for a CellAddress instance fails if the worksheet is set in the CellAddress instance

Thanks for the diagnostic work with this issue. You were right about the change to applyFromArray(), though it was slightly more complicated with Named Ranges

Fix for Issue 3439 - Getting a style for a CellAddress instance fails if the worksheet is set in the CellAddress instance

… if the worksheet is set in the CellAddress instance

This is:

• [X] a bugfix
• [ ] a new feature
• [ ] refactoring
• [ ] additional unit tests

Checklist:

• [X] Changes are covered by unit tests
  • [X] Changes are covered by existing unit tests
  • [X] New unit tests have been added
• [X] Code style is respected
• [X] Commit message explains why the change is made (see https://github.com/erlang/otp/wiki/Writing-good-commit-messages)
• [X] CHANGELOG.md contains a short summary of the change and a link to the pull request if applicable
• [ ] Documentation is updated as necessary

Why this change is needed?

Bugfix for Issue #3439 - Getting a style for a CellAddress instance fails if the worksheet is set in the CellAddress instance