#11323 closed defect (bug) (worksforme)
Scaling attempt in Media produces error
| Reported by: | dpaule | Owned by: | |
|---|---|---|---|
| Priority: | normal | Milestone: | |
| Component: | Media | Version: | 2.9 |
| Severity: | normal | Keywords: | reporter-feedback has-patch |
| Cc: | Focuses: |
Description
"Error while saving the scaled image. Please reload the page and try again."
I've changed permissions, though no joy.
Change History (13)
#1
in reply to: ↑ description
@
17 years ago
#2
@
17 years ago
- Keywords reporter-feedback added; Error scaled image saving removed
Have you tried other images, or is it only one image that is failing?
#3
@
17 years ago
- Milestone 2.9 → Unassigned
Every time? Can anyone else reproduce? We need more info.
#4
@
16 years ago
- Milestone Unassigned
- Resolution → worksforme
- Status new → closed
Re-open with steps to reproduce.
This ticket was mentioned in PR #12009 on WordPress/wordpress-develop by @adamsilverstein.
2 months ago
#5
- Keywords has-patch added
## What
Bumps the bundled Gutenberg build to 0e198c7ac7ca634e73ded9220ce048c0302174dd (current tip of the wp/next branch) and updates the regenerated build artifacts.
## Why
The client-side HEIC canvas-fallback work in #11323 needs the matching Gutenberg JS (the upload/media client-side conversion path) bundled into core. This separates the bundled-Gutenberg bump from the core PHP changes in #11323 so each can be reviewed and committed independently.
wp/next is used rather than Gutenberg trunk because trunk currently requires React 19 while core ships React 18; 0e198c7 is React-18 compatible and carries the HEIC client-side code.
## Notes
- The 114 changed files under
src/wp-includes/{blocks,assets,build,images}are regenerated Gutenberg build output, produced bynpm run gutenberg:download. package.json'sgutenberg.shafield is the only hand edit;package-lock.jsonis unaffected (the SHA lives in a custom field, not the npm dependency tree).
Related: HEIC canvas fallback (#11323).
@adamsilverstein commented on PR #12009:
2 months ago
#6
I noticed an experiments folder in build/pages and a route folder 'experiments-home' - do those belong in core?
It would be good to land https://github.com/WordPress/gutenberg/pull/76715 - short of that, should those folders be excluded from the core commit.
@westonruter commented on PR #12009:
2 months ago
#7
I'm not sure how to review such PRs. I'd appreciate pointers!
@adamsilverstein commented on PR #12009:
2 months ago
#8
I'm not sure how to review such PRs. I'd appreciate pointers!
we probably need someone with deep Gutenberg familiarity to review. I only changed the Gutenberg SHA - every other change was generated.
@westonruter commented on PR #12009:
2 months ago
#9
@adamsilverstein So you bumped the hash in a57e63d7200157887c1e75b7eefbb940599434e1 and then for f1ff566fdcb42a1a1422018cd484dc05e3373e79 you just ran npm run build and committed the result?
@adamsilverstein commented on PR #12009:
2 months ago
#10
@adamsilverstein[[Image(chrome-extension://hgomfjikakokcbkjlfgodhklifiplmpg/images/wp-logo.png)]] So you bumped the hash in a57e63d and then for f1ff566 you just ran
npm run buildand committed the result?
I also ran npm run gutenberg:download && npm run gutenberg:copy . I'm not super familiar with the build system and haven't looked too carefully yet, but those don't seem to get run (and I don't see the changes) with npm run build or even npm run build:gutenberg. Previously I assumed all we had to do was update the SHA (which i've done in the past with some backport PRs without running the extra commands).
Some of the files/paths are added, I guess we need to review those carefully to see what should really be added:
I'm guerssing at least src/wp-includes/build/pages/experiments/ and src/wp-includes/build/routes/experiments-home/ can be excluded.
@wildworks commented on PR #12009:
6 weeks ago
#11
The current Gutenberg ref points to Gutenberg version 23.4. How about updating the commit hash to the latest one from Gutenberg trunk again? The newer the commit hash, the closer the core state will be to what is expected in Beta1.
@desrosj commented on PR #12009:
6 weeks ago
#12
The current Gutenberg ref points to Gutenberg version 23.4. How about updating the commit hash to the latest one from Gutenberg trunk again? The newer the commit hash, the closer the core state will be to what is expected in Beta1.
Since the current plan is to sync changes during weeks opposite each plugin release, let's leave it as 23.4 right now to see how that cadence works.
@wildworks commented on PR #12009:
6 weeks ago
#13
If possible, I would appreciate it if we could update the Gutenberg ref again before the Beta1 release.
This is because CI errors occurred in #11559. #11559 attempts to change the WP_Icons_Registry::register method from protected to public. However, in Gutenberg 23.4, this method is overridden as protected in a child class, which causes a fatal error due to narrowing the class visibility. In the latest version of Gutenberg, this method is public, but this is not yet included in 23.4. To resolve this fatal error, we must update to the latest Gutenberg ref.
![(please configure the [header_logo] section in trac.ini)](/chrome/site/your_project_logo.png)
Replying to dpaule:
BTW - only happens when reducing image. Also, my version: 2.9-beta-2