The current guides have a few areas where they recommend an approach that is more complex than what most people take.
- Rebase straight onto upsteam/msaster
- Force push a rebased branch
I also fixed the conflict resolution help to be relevant to rebase commands, and kept the push instruction out of the rebase instruction.
I don't know what that release candidate branch stuff is, but:
* I've never seen any of the core team do it
* I think it's overkill for most patches
* I think it's being too prescriptive: if contributors want to do that, that's cool, but it doesn't affect the core team.
* It makes our contributing guidelines more complex than they need to be.
The guidelines for contributing code were scattered across a section of contributing.md and collaboration-on-git.md. I've updated this to have separate contributing/code.md page with all the content in a single cohesive page. We also have contributing/documentation.md, contributing/issues.md and contributing/translation.md.
Delayed show because TinyMCE calls hide() via
setTimeout on removing an element,
which is called in quick succession with adding a new editor
after ajax loading new markup
See e0378ceb77
and https://github.com/silverstripe/sapphire/pull/847
Avoids breaking execution if PHPUnit is not installed,
since classes in framework/dev/ extend PHPUnit,
and get autoloaded when we inspect the ancestry and implementors
of every class defined on the filesystem.
Not an ideal, since it removes i18n support for dev classes,
but in practice this only impacts a single entity definition.
Everytime TinyMCE is saved, it adds characters immediately
after anchors, e.g. <a name="test"></a> - this fix stops
TinyMCE from adding those extraneous after the anchors.
Using late static binding makes it possible to override SS_Log to create
logs which are separate to the main Silverstripe log but still use the
built in functionality.
Add test for SS_Log subclassing.
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.
