Step by step Composer installation instructions, including a composer.json example.
In addition:
- Removed self-page reference to an introduction
- Removed reference to PEAR installation instructions due to end of life
- Removed reference to Ruby as doesn't add value
- Shortened testing via Web Browser section (as covered in Composer installation instructions)
These should be avoided because they undermine the process of
peer review and merging in github, we should strive to have
zero open pull requests, as opposed to treating it as a stage
for work in progress. Intermediary code review can happen in github forks instead.
Also remove some checklist items which were based on the Trac bugtracker,
e.g. its not longer possible to assign yourself to issues because
of github's limited permission abilities.
Provides an interface for classes to implement their own flush()
functionality. This function gets called early in a request on
all implementations of Flushable when flush=1|all is requested in the
URL.
This fix came out of an issue where Requirements combined files were not
being cleaned up after dev/build?flush=1, due to the fact that flush
would only occur when you called it while on a page that used those
combined files, but not in any other contexts. This will now call flush
on any implementors of Flushable regardless of the context of where
flush was called.
getTempParentFolder() in framewor/core/TempPath.php checks for silverstripe-cache directory in webroot first, failing that it falls back on the sys_get_temp_dir() folder.
also, getTempFolder() is no longer in framework/core/Core.php since #b075fa29c59f970bea31bbe8be1bd6560a8778b6, it is now located in framework/core/TempPath.php
There's no way to make things like [api:DataObject->beforeUpdateCMSFields()] work, is there?
I removed those kind of api tags (the links yielded a 404 page), and corrected a few other link-rendering issues.
Changed Fragment links to Anchor links, however it's is slighty confusing what the right name for the thing is.
According to w3.org: "Some URIs refer to a location within a resource. This kind of URI ends with "#" followed by an anchor identifier (called the fragment identifier)." - http://www.w3.org/TR/html401/intro/intro.html#fragment-uri
After doing some research in the most common used name for the #some-link identifier I came to the conclusion that most of the time (about 70% on StackOverflow/BlogArticles/Interwebz) Anchor-link was the term used to describe the identifier. Imho, Anchor is the prefered term for the identifier.
Is it acceptable to change fragment to anchor, since it seems more used?
