It produces invalid HTML since the "for" attribute doesn't
map to any HTML input field. Each individual checkbox or radio button
input element has its own <label for>
- Based on new (last) translation download from getlocalization.com
- Removed untranslated strings. Getlocalization started including those at some point
which is highly annoying, unnecessary and breaks the new transfix system,
since it'll mark all of the english strings as actual translations
- Avoid dots in entities. It confuses the Transifex YML parser
- Removed some locales unknown to Transifex which didn't have any translations anyway
- Removed "lolcat" locale, uses custom notation (en@lolcal)
which SilverStripe's i18n system can't handle
(needs mapping from SS naming to Zend naming)
- Renamed "Te Reo/Maori" locale from "mi_NZ" to "mi" (Transifex/CLDR notation)
- Namespaced all entities used in templates (deprecated usage)
- Converted dots to underscores where template filenames are used for namespaces,
since Transifex YML parsing handles them as separate YML keys otherwise
- Removed whitespace in entity names, SilverStripe i18n can't handle it
- Only allow selection of locales registered through i18n::$all_locales to avoid
issues with unknown locales in Zend's CLDR database
The generic email template encapsulates the "body" content in a paragraph mark. This is undesirable as it can lead to invalid HTML. Rather than using a paragraph, it is better to have a div encapsulating the content.
The underlying reason for this is that $Body is usually HTML and this can included block elements (div, p, etc...) that are not allowed within paragraphs (p).
It is important that the HTML is valid, because it will reduce the likelihood for it being marked as spam, because it is less likely to show up strange formatting and for use of tools like emogrifier.
This is the companion setting to canUpload, letting you control whether existing files from the asset store can be referenced. It's particularly useful when using UploadField on the front-end.
Although editing meta-data or deleting permanently would require File editing/deleting permissions, merely linking to a record does not. This change is important for allowing front-end use of UploadField; or, more importantly, use of UploadFile by people without CMS rights.
The field carries the configuration, and some non-upload functionality
like "attach files" still relies on the fileupload jQuery plugin
being initialized.
Conflicts:
templates/UploadField.ss
The field carries the configuration, and some non-upload functionality
like "attach files" still relies on the fileupload jQuery plugin
being initialized.
Add extra preview-mode selector to the CMS actions so we can show
something when the preview is closed (and with it all options are not
visible).
Thanks @mateusz, @clarkepaul and @robert-h-curry for contributing.
