This allows subclasses and extensions time to modify the list of options and their configuration without having to override the entire Field method.
A more flexible way to implement silverstripe#3311
BUG Fix incompatibility in Member_GroupList
Fix regressions in merges from 3.1
BUG Fix Security failing on test classes
BUG Fix postgresql compatibility
Clarify sql encoding of table names
1. Add missing _super calls.
2. Make UI widget destroys more consistent to avoid exceptions.
Selectable would throw an exception in the GridField.js if destroy
called from onunmatch - at that stage jQuery UI would have had called
the destroy already. Add a guard, and change to onremove, which triggers
before the element is removed from DOM.
3. DOM traversal fails after the element is removed from DOM.
Onunmatch triggers after the removal of the element from the DOM, which
makes DOM traversal fail. Use onremove instead, which triggers while the
element is still in DOM.
Database abstraction broken up into controller, connector, query builder, and schema manager, each independently configurable via YAML / Injector
Creation of new DBQueryGenerator for database specific generation of SQL
Support for parameterised queries, move of code base to use these over escaped conditions
Refactor of SQLQuery into separate query classes for each of INSERT UPDATE DELETE and SELECT
Support for PDO
Installation process upgraded to use new ORM
SS_DatabaseException created to handle database errors, maintaining details of raw sql and parameter details for user code designed interested in that data.
Renamed DB static methods to conform correctly to naming conventions (e.g. DB::getConn -> DB::get_conn)
3.2 upgrade docs
Performance Optimisation and simplification of code to use more concise API
API Ability for database adapters to register extensions to ConfigureFromEnv.php
Specific case: LeftAndMain::$session_keepalive_ping = true cannot be
set to false in config.yml for some cases because the value is ignored
when merge_array_low_into_high() is processing the config arrays.
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?
