-
-
Notifications
You must be signed in to change notification settings - Fork 1.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Bug]: Rows with Drawings broken since v3.1.47 #4134
Comments
I somehow accidentally closed this issue despite it not being fixed. I have no idea how/why I did that! |
This bug report has been automatically closed because it has not had recent activity. If this is still an active bug, please comment to reopen. Thank you for your contributions. |
I’m experiencing the same issue. I’m using maatwebsite/excel version 3.1.58 with Laravel 11 and PHP 8.3. After updating from older versions of both Laravel and this package, my Excel exports now have collection rows starting at A1, which places them above the headers and sometimes even overwrites them, just like in your screenshots. I'm also using drawings. I think I tried everything to fix this, without success. Have you found a solution to this problem @aaronhuisinga? Thanks |
@cristiangervasi I did find something that works for me and have been rolling with it since this issue was closed. I'm just using a fairly simple composer patch to load my file that has the breaking change reverted. I exclude the package composer.json
patches/Sheet.php
|
@aaronhuisinga This solution is perfect, thank you! |
Why not create a PR so we can actually see what is happening? |
Is the bug applicable and reproducable to the latest version of the package and hasn't it been reported before?
What version of Laravel Excel are you using?
3.1.55
What version of Laravel are you using?
11.x
What version of PHP are you using?
8.3.0
Describe your issue
A bug was introduced in #3873 that broke how drawing behave and results in incorrect exports. I left a comment on it when it was merged originally but I think it was lost in the flow of things and still hasn't been resolved. We had been locked at v3.1.46 until we needed to update to Laravel 11 which required a newer version of this package. We discovered then that this bug still exists.
What this did pre-change was add an image to cell A1, leave the rest of the first row blank, and add footers in row 2. After that, student data was printed.
With the drawing being inserted at the end, it appears to break things pretty badly. I don't think we're doing anything we aren't supposed to be in our export logic, and so it seems to me this is an unintended change.
How can the issue be reproduced?
What should be the expected behaviour?
Pre v3.1.47, the drawing properly sits above the rest of the spreadsheet data.
The text was updated successfully, but these errors were encountered: