Loving Foundry, we're rolling it out across our very heavily testing Symfony 5.4 codebase with plans to completely replace Alice fixtures.

I ran into an issue when upgrading from 1.29.0 to 1.30.3.

PR #423 appears to have broken Foundry when creating objects which are not Doctrine entities. We're using Foundry to create both Entities and DTO's in the same test and now we're receiving the following exception:

Doctrine\Persistence\Mapping\MappingException : The class 'App\Integration\FooApiResponse' was not found in the chain configured namespaces ...
vendor/doctrine/persistence/src/Persistence/Mapping/MappingException.php:26
vendor/doctrine/persistence/src/Persistence/Mapping/Driver/MappingDriverChain.php:89
vendor/doctrine/doctrine-bundle/Mapping/MappingDriver.php:42
vendor/doctrine/orm/lib/Doctrine/ORM/Mapping/ClassMetadataFactory.php:132
vendor/doctrine/doctrine-bundle/Mapping/ClassMetadataFactory.php:18
vendor/doctrine/persistence/src/Persistence/Mapping/AbstractClassMetadataFactory.php:343
vendor/doctrine/persistence/src/Persistence/Mapping/AbstractClassMetadataFactory.php:207
vendor/doctrine/orm/lib/Doctrine/ORM/EntityManager.php:318
vendor/zenstruck/foundry/src/Factory.php:375
vendor/zenstruck/foundry/src/Factory.php:111
src/Factories/VendorFactory.php:101
tests/Functional/Api/VendorUpdaterTest.php:60

Stepping in with Xdebug I can identify the simplification in Factory::normalizeAttribute() which fetches the object manager for class. It appears that Doctrine is returning the default object manager when the given class is not a configured entity, and then calling ->getClassMetadata() for a non-entity throws an exception. See: https://github.com/zenstruck/foundry/pull/423/files#diff-f1158fbec0bb446d87dbd5346fba683c58ccec1a98b1787511ec7786585e8c31R376

Whereas previously, $this->ownedRelationshipField($name, $value); returned null on line 360 and $this->isPersisting() returned false on line 369.

I think the $objectManager instanceof EntityManagerInterface check on line 376 was intended to catch this. I'm unsure if there's a better way to ask Doctrine if a gives class is a configured entity.

Start gnome keyring

Reinstall archlabs

Reinstalling sigbus with new archlabs

Add pritunl

Nice work! This seems to correctly propagate the ref error back to the caller. I wonder if this counts as a BC break since it is different behavior to both pre-1.26.0 and post-1.26.0?

What sort of other tests do you think are necessary? Your current tests seem to cover everything way of getting a #REF! error that I know of. Maybe some other ExcelErrors should be tested as well?

Describe the bug The documentation says to use TextField, TextAreaFieldorCodeEditorField` field to display a Doctrine json type.

However, using either TextField or TextAreaField fails with

RuntimeException: The value can't be converted into a string, so it cannot be represented by a TextField or a TextareaField.

And using CodeEditorField fails with:

Array to string conversion

This could be worked around by using ->formatValue(fn ($value) => json_encode($value)) however, the TextConfigurator does not actually use the formatted value callable, and code_editor.html.twig does not use it for the DETAIL view.

To Reproduce EasyAdmin 4.6.1

1. Create a doctrine entity with a json field
2. Create a CrudController
3. Try to use the json field in a view

My apologies, it seems my previous comment was riddled with typos. I was working through multiple cases in Excel and seem to have messed up my explanation. I certainly did not mean to use ranges that cross rows/columns.

Here are my examples again, explained correctly with my Excel files attached :sweat_smile:

1. In cell A1 write formula =SUM(B1:E1) -> this returns 0 as expected
2. Create Sheet2
3. In cell A2 of Sheet1 write formula =SUM(Sheet2!A1:D1) -> this returns 0 as expected
4. Delete columns B:E in Sheet1 -> A1 now displays #REF!
5. Delete Sheet2 -> A2 now displays #REF!

Excel file showing steps 1-3: ref-error-step1-3.xlsx Excel file showing steps 4-5: ref-error-step4-5.xlsx

For reference, I'm using Office Professional Plus 2016 on Windows 10.

Regardless, I think we're largely agreed that PHPSpreadsheet should return #REF! when calculating these formulas. This is also just discussing reading Excel files, not writing them after deleting columns/sheets. I'm unsure if PHPSpreadsheet copies Excel and changes the formula to #REF! as well.

I think it also needs some further tests to see what Excel returns when passed a '#REF!' error value as part of a SUM() argument set, not just as the range.

I've tested with Excel a few different things.

1. Delete parts of a range included in a SUM() -> =SUM(B1:E1) and delete columns C and D. The formula is updated to SUM(B1:C1)
2. Manually enter =SUM(B1:#REF!) (I can't figure out a way for excel to make this formula on it's own) -> This returns #REF!
3. Delete cells called out specifically in a SUM() -> SUM(B1,C1,D1) and delete column C. The formula is updated to SUM(B1,#REF!,C1)

Thanks for the response @oleibman, I had not realised that this was connected to #2870/#2902. It also, looks like #2902 was released in 1.24.0 but this issue is not present until 1.26.0, so maybe it's not connected?

I agree that propagating #REF! is the right action here because an exception is probably not ideal and neither is returning 0 for an invalid formula. Additionally, propagating #REF! is what excel does in this situation:

I had also not realised that providing #REF! as a string was a contrived example, as that appears to be what excel does when you delete the cells it's referencing, for example:

• SUM(A2:H1) is replaced with SUM(#REF!) when deleting columns F-H
• SUM(Sheet2!A1:Sheet2!H1) is replaced with SUM(#REF!B1:#REF!B4) when deleting Sheet2

However, having just tested both of the above cases using the script I posted above, I can confirm that PHPSpreadsheet returns 0 for both of them in 1.24.0 and 1.28.0.

I still believe this is incorrect since Excel will return #REF! for both these cases so maybe this is not a regression?

PS.

I can confirm that the literal string #REF! is written to the Excel file on save by extracting the .xslsx, so it's probably a case that needs to be handled?

In cell A1 I entered SUM(A2:H1) and then deleted the columns. I then created Sheet2 and in cell A2 entered SUM(Sheet2!A1:Sheet2!H1) and then deleted Sheet2.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<worksheet xmlns="http://schemas.openxmlformats.org/spreadsheetml/2006/main"
           xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006" mc:Ignorable="x14ac xr xr2 xr3"
           xmlns:x14ac="http://schemas.microsoft.com/office/spreadsheetml/2009/9/ac"
           xmlns:xr="http://schemas.microsoft.com/office/spreadsheetml/2014/revision"
           xr:uid="{9C764240-3645-4F55-8702-5DB1513E66B0}">
    <dimension ref="A1:A2"/>
    <sheetViews>
        <sheetView tabSelected="1" workbookViewId="0">
            <selection activeCell="A3" sqref="A3"/>
        </sheetView>
    </sheetViews>
    <sheetFormatPr defaultRowHeight="15" x14ac:dyDescent="0.25"/>
    <sheetData>
        <row r="1" spans="1:1" x14ac:dyDescent="0.25">
            <c r="A1" t="e">
                <f>SUM(#REF!)</f>
                <v>#REF!</v>
            </c>
        </row>
        <row r="2" spans="1:1" x14ac:dyDescent="0.25">
            <c r="A2" t="e">
                <f>SUM(#REF!)</f>
                <v>#REF!</v>
            </c>
        </row>
    </sheetData>
    <pageMargins left="0.7" right="0.7" top="0.75" bottom="0.75" header="0.3" footer="0.3"/>
</worksheet>

This is:

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

What is the expected behavior?

Prior to version 1.26.0 calculating the value of a formula that contains a reference error (eg. =SUM(B1:#REF!)) would result in a

[PhpOffice\PhpSpreadsheet\Calculation\Exception]               
  Worksheet!B4 -> Cell coordinate can not be zero-length string

What is the current behavior?

From 1.26.0 until now (1.28.0) the result is 0 instead of an exception.

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';

$spreadsheet = new Spreadsheet();
$worksheet = $spreadsheet->getActiveSheet();

$worksheet->setCellValue('B4', '=SUM(B1:#REF!)');

\var_dump($worksheet->getCell('B4')->getCalculatedValue());

What features do you think are causing the issue

Seems to have been introduced here: https://github.com/PHPOffice/PhpSpreadsheet/commit/153a3a6af688387bd544a5a4dabbac8833e13589 with a change to extratSheetTitle.

• [ ] 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?

I have tested with .xlsx, don't see why it wouldn't affect all other formats.

Which versions of PhpSpreadsheet and PHP are affected?

PHP 8.1.16 PHPSpreadsheet 1.26.0+ (until at least 1.28.0)

A workaround for this is to use the optional chaining operator on every method call in the chain:

https://psalm.dev/r/203fa897fc

Duplicate of #6057?

Duplicate of #6057?

The published NPM package contains no files when installed:

This appears to be because the package.json includes a files directive:

"files": [
    "dist"
  ]

Bug present in 1.5.1, but not 1.5.0

Apologies @benschwarz, it's been a crazy start to the year. I tried to fix this a few times and finally realised the issues is due to 2FA tokens on npmjs.com. I've published v1.5.2 with a granular access token and it appears to have worked correctly this time.

v1.5.2