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
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.
This is related to how Zend_Date returns year for YYYY & yyyy format. Detailed explanation is here http://framework.zend.com/issues/browse/ZF-5297
Sample code (adapted the Datetimefield setValue() method) to highlight the problem:
include 'framework/thirdparty/Zend/Date.php';
$userValueObj = new Zend_Date(null, null, 'en_US');
$userValueObj->setTimezone('GMT');
$userValueObj->setDate('2012-01-01', 'YYYY-MM-dd');
$userValueObj->setTime('00:00:00', 'HH:mm:ss');
echo $userValueObj->get('YYYY-MM-dd HH:mm:ss', 'en_US'), "\n"; // returns 2011-01-01 00:00:00
echo $userValueObj->get('yyyy-MM-dd HH:mm:ss', 'en_US'), "\n"; // returns 2012-01-01 00:00:00
This reverts commit 14b997eea3.
Its just not practical to use the Config API as it stands,
the add_extension() wrapper does more than just a Config->update().
Most use cases can be covered via YML, but any conditional
additions (e.g. in unit tests) can still benefit from the
add_extensions() shorthand.
