* Fix for v4: Admin returns "Too many pages" for subpages below top level
Simple logic error during porting to new version it appears
* V4: LeftAndMain::getSiteTreeFor() returning space & New line in link
The "Too many pages" "View as list" link had a return &
tab characters in it
* V4: LeftAndMain::getSiteTreeFor() fixes link for list view
"Too many pages" link pointed to `?view=list` which is
just normal hierarchy. Value had been updated to "listview"
in #8c87ea6b
Silently failing only the first command with error code 0 through a single ampersand
is hardly intuitive. Our general line is that either you have linting and
enforce it (via build failures), or you might as well not bother since
it'll deteriorate quickly.
The $record argument should NOT be used for object construction, since it bypasses setters.
While the original PHPDoc hints at this (“internal systems”), it doesn’t make it clear enough.
Sometimes a manipulation can’t be carried out, either because the backend isn’t available,
or because there isn’t enough PHP memory available. In these cases, $backend->getImageResource()
will be set to NULL. This should be picked up by manipulateImage(), to avoid passing an invalid
backend into the $callback provided.
The specific case this solves is calling Image->FitMax() on large images:
$resizedImage = $originalImage->FitMax(<width>, <height>)
This will have $resizedImage==$originalImage if the image is smaller than the targeted dimensions,
but with this fix $resizedImage==NULL if the image is too large to be resized.
Which gives custom code the ability to determine which of the two should be used,
for example choosing not to pass the original large image URL to the client
since it wouldn’t be considered a “thumbnail” size.
This has been discussed previously, and was assumed to be handled by PHP automatically:
https://github.com/silverstripe/silverstripe-framework/issues/2739#issuecomment-32603005
It’s unclear if its a regression in SS4.
Tested with PHP 5.6.29, by setting xdebug breakpoints
and inspecting memory_get_usage() before and after GDBackend->manipulateImage().
Even a single 7MB JPEG straight from my DSLR (6000x300) can chomp bring the system from 30MB to >128MB memory use.
That’s in addition to the 7MB of PHP memory required for the $content variable.
Note that the image manipulations likely happen on the raw bitmap, which is much larger than the 7MB compressed JPEG.
Checked ImagickBackend, which doesn’t have this issue (and only uses about half the memory for the same set of images).
