At this stage, the test just checks line-length and line-endings, but previous commits have ensured that framework actually passes those tests. We can add more tests as we actually correct the code to pass those tests, and grow the test suite, as we had for unit tests.
The entire framework repo (with the exception of system-generated files) has been amended to respect the 120c line-length limit. This is in preparation for the enforcement of this rule with PHP_CodeSniffer.
This is partly a fix to #7574, although quite different from the work Ingo did on Content-length. The text/json mime type occasionally gets a charset suffixed to it by the webserver, which broke everything.
A follow-on fix from this would be to get the PHP code to supply charsets more consistently, so that webservers don't have to make things up.
Additionally, the 2nd interpretation - which treats the response as text/html - should probably only happen if the response is text/html, and throw a more helpful error otherwise.
If you're logged in as a specific user in a group who has view/edit
permissions of a page that has a parent page which doesn't have
permissions, you can't expand the tree node to get access to that
nested page.
This fixes LeftAndMain.Tree.js to allow expanding if there are
immediate children tree nodes that are not disabled. Also fixes
styling so that only immediate children nodes are greyed out.
Fixes this ticket: http://open.silverstripe.org/ticket/7913
This is a fix for ticket #7670. Some hosting situations don't
allow write access to the system temp path. tiny_mce_gzip.php is currently
using sys_get_temp_dir() by default, and not using a local silverstripe-cache
folder that may exist in the SilverStripe project.
This change moves the getTempFolder() function into a common file, and
includes that in core/Core.php, as well as thirdparty/tinymce/tiny_mce_gzip.php
so both locations share the same code to work out the temp path.
In the case of errors arising during setUp or setUpOnce a unit test will fail to run any individual tests. However, this situation was incorrectly being reported as a test pass (as no tests were run, thus no tests had errors). E.g. the output of a test run that raised an error during setUp would be "0 tests run: 0 passes, 0 failures, and 0 incomplete" with a green background.
To rectify this the following fixes were made:
- Non-cleanly ended tests and test suites are now automatically ended at the end of the test run, as well as at the beginning of subsequent test/suites. This should make catching of errors a lot more robust.
- Errors raised during setup are now no longer lost to the mist of time. The test suite itself will record any error status which was generated outside the scope of any individual tests.
- An additional "errors" count is added to the output at the end of test running. For example, in the case where setup failed and no tests could be run the error would be written to the browser (along with stacktrace) with a message similar to "0 tests run: 0 passes, 0 failures, and 0 incomplete with 1 errors". The intent of this is to separate the concepts of failed/succeeded/incomplete tests from any errors which may have arisen. I.e. no tests "failed" due to the error, but the test run itself is highlighted as an error (red background on the output).
This problem has been a severe cause of issue when testing code that interacts with the database, as any database error during setup would refuse to be shown.