This prevents it from failing for proxied values
like BlogEntryForm, where the field name doesn't exist,
and rather gets processed and saved into a different field.
Since that used to be the default shortcode notation
for our core "insert media" functionality, its important
to have this fixed and keep supporting "legacy" content
created with 3.0.
example configuration wuldn't allow to install silverstripe, as
install.php does exist as a regular file (and that was ignored in the
old version of the documentation)
Similarily, the last rule in the htaccess snippet that should allow the
access to the tinymce php files were never applied, as a previously
listed regex did match and denied access. Even if it would have taken
effect: as those files do exist on disk, they would have been handed out
as-is and not been interpreted by php.
Also the statement regarding accidental/exploitable execution of
arbitrary php was misleading (and to some degree even wrong) in the old
context.
squashed commit as per pr#1791
Makes setups which are completely driven by that file a bit easier
to automate, particularly if the same codebase is deployed
multiple times (e.g. to a staging and live instance)
Makes setups which are completely driven by that file a bit easier
to automate, particularly if the same codebase is deployed
multiple times (e.g. to a staging and live instance)
API: CompositeDBField::setValue() may be passed an object as its second argument, in addition to array.
These changes provide a 15% - 20% performance improvement, and as such justify an small API change in the 3.0 branch. It will likely affect anyone who has created their own composite fields, which is fortunately not all that common.
Caused the UploadField rows to show "[Object object]" because
it tried to pass through a PHP object to JS without string casting
(the return used to be a string).
DO NOT MERGE: to be reviewed. Only i18n & Deprecation classes use
->getModules() as far as I can see. Given that the method still simply
returns an array of modulename => modulepath, I don't think it's really
an API change
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.
The parser could sometimes generate invalid code if the
source-file-comments were enabled, this moves the comments outside the
html-tag to circumvent these problems, update test as well.
