- Moved thumnbail loading out of repo into ImageResizer.
- Updated gallery and editor image handling to show errors where
possible to indicate memory issues for resizing/thumbs.
- Updated gallery to load image data in a per-image basis via edit form
for more resiliant thumb/data fetching. Data was previously provided
via gallery listing, which could be affected by failing generation
of other images.
- Updated image manager double click handling to be more pleasant and
not flash away the edit form.
- Updated editor handlers to use main URL when thumbs fail to load.
Added since we can't always be sure of future image usage, and in many
cases we don't generate ahead-of-time.
Also:
- Simplified image handling on certain models.
- Updated various string handling operations to use newer functions.
- Added some level of app out-of-memory handling so we can show a proper
error message upon OOM events.
- Added endpoint and image-manager button/action for regenerating
thumbnails for an image so they can be re-created upon failure.
During review of #4560.
- Simplified command to share as much log as possible across different
run options.
- Extracted out user handling to share with MFA command.
- Added specific handling for disabled avatar fetching.
- Added mention of avatar endpoint, to make it clear where these avatars
are coming from (Protect against user expectation of LDAP avatar sync).
- Simplified a range of the testing.
- Tweaked wording and code formatting.
Added support for mulit-line endpoint descriptions via blank
intermediate lines in php controller method docblocks.
Also tweaks endpoint header design for better flexing and alignment.
Within the flow of HttpFetchException, the actual exception from curl is preserved and logged. Make HttpFetchException a pretty exception for when it is shown to users.
- Updated UI with image form dropdown containing delete and replace
image actions.
- Adds new endpoint and service/repo handling for replacing existing
image.
- Includes tests to cover.
Added test to cover.
Did attempt a 64k limit, but values over 2k significantly increase
chance of other issues since this URL may be used in redirect headers.
Would rather catch issues in-app.
For #4044
This allows download of attachments that are larger than current memory
limits, since we're not loading the entire file into memory any more.
For inline file responses, we take a 1kb portion of the file to sniff
before to check mime before we proceed.
