Regression in 4.x i18n rewrite. Can’t test this since ThemeResourceLoader hardcodes constants like THEME_DIR,
so its impossible to mock in different directory structures. Ideally this would use an application object with access
to environment variables, but that’s too much of a refactor to validate this simple fix.
API Substitute Zend_Locale with Locale / NumberFormatter
API Substitute Zend_Date with IntlDateFormatter
API Added DBTIme::Nice12, FormatFromSettings
API Added Short() method to DBDate / DBTime / DBDatetime
API Add Date::getTimestamp()
API Added setSubmittedValue api for FormField
API Add second arg to base FormField::setValue()
API Major refactor of i18n into component data parts
API Implement Resettable interface to reset objects between tests
ENHANCEMENT Changed DBField::create_field return type to `static` to support better type hinting
ENHANCEMENT i18nTextCollector supports __CLASS__
API Implement enhanced pluralisation
Remove Zend_Translate and all Zend dependencies from i18n
Deprecated $context from i18n::_t()
Warn on missing default string for i18n::_t()
* API Replace existing Email and Mailer classes with SwiftMailer powered email system
* DOCS New Email docs
* Initial feedback from Damian
* Making Mailer an interface
* Templates relocated
* Round of feedback
* More robust approach to plain parts
* Revert changes to TestMailer
File names are generally valid without an extension (although they might be disallowed by upload constraints),
so the filter should deal gracefully with them (“myfile” should return “myfile”, not “myfile.”)
* Introduced in 0cf477d36
* Should use the "template_main" static to decide which model to use for rendering this page
* Assuming SiteTree means any requirements added in Page and assumed to work everywhere will not
This small refactoring makes TestMailer better suited as a base class
for the behat-extension’s implementation, which means that we don’t
need to coordinate cross-module commits in dhensby’ SwiftMailer work.
See https://github.com/silverstripe/silverstripe-framework/pull/6466
Enhancement add accessibility info to page number
Enhancement new font icons added, improve trash icon and increase icon size of close
Enhancement improve title of gridfield search trigger
Enhancement add title to button to open gridfield search and improve gridfield search styles
API Shortcode fails if no parent
API JQuery-UI classes removed
Enhancement centre actions tabs within dropup in more-actions
Enhancement fix IE input height issue and fix for safari of icons in buttons with hidden text (e.g. pagination)
Enhancement only show external link on hover
Enhancement remove float from buttons as already aligned inline
Enhancement Align buttons in toolbar more consistently
API remove ui overrides
API ss-ui-button no longer exists so styles where not seen, removed nesting
Enhancement Tidy up permission icons to new icon library
WIP The modal is a short term workaround until the UI is all react based but we wanted to do some cleanup prior to 4 release
API Remove ssui.button
Enhancement Update buttons to new flat bootstrap style
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).
