clearTable is mainly used for clearing data between tests. In this case,
there are very few or zero records, and DELETE FROM is quicker than
TRUNCATE, which works by deleting and recreating the table.
This materially speeds up test execution, at least on MySQL.
Cherry-pick of SS3 ae9ab22a8f
clearTable is mainly used for clearing data between tests. In this case,
there are very few or zero records, and DELETE FROM is quicker than
TRUNCATE, which works by deleting and recreating the table.
This materially speeds up test execution, at least on MySQL.
Implemented in SS3 at 815da76b056a716c8831d22bbf93528912cbcb28
This prevents the map-to-ArrayData conversion from changing object
state and making the result of toArray() non-deterministic.
Fixes#2636. Other solutions were suggested on that ticket, but there is
no way of putting special code in for a SSViewer-specific iterator, and
having object state pre-emptively converted to ArrayData would
be an SS5-level change.
If a session already exists, and Session::start() isn’t called until
after a large enough block of content is output, then headers_sent()
will be false. The previous code prevented the session from being
started in this case. That might makes sense for the creation of a new
session, but it prevent legitimate access to an existing session.
This mostly manifested when running debugging tools such as showqueries,
which may output content before the session is started.
it's not very likely to happen (it did in my case :-) ) but if the value is an array, sprintf will fail (because raw2att accepts array, but sprintf doesn't). i suggest to json encode any array data to ensure it's safely included in the html. Or we should throw proper exceptions to make sure invalid values do not result in a php error.
* NEW: Add Hierarchy::prepopulate_numchildren_cache()
API: Hierarchy::stageChildren() customisations must be applied to the base class and not include record-specific behaviour.
Adds the ability to prepopulate the cache for Hierarchy::numChildren()
in a batch.
Note that this optimisation means that stageChildren() is not called on
each record in order to calculate numChildren(). This means that the
structure of the stageChildren() query must be the same for all records
and the behaviour cannot be customised only for a subclass of the base
data class. For example, apply your customisations to SiteTree and not
a subclass.
This is an useful part of optimising the query count on tree generation.
See https://github.com/silverstripe/silverstripe-framework/issues/8379
* NEW: Add Hierarchy::prepopulateTreeDataCache()
This provides a more extensible way of preopulating caches for optimised
tree generation.
Fixes https://github.com/silverstripe/silverstripe-framework/issues/8391
Two functions interact with the LoginAttempt object which when used in conjunction with BasicAuth result in significant performance degradation over time, as the LoginAttempts Table fills.
This fix adds an index to the lookup column EmailHashed and removes the Email filter part of getByEmail() so it can use the index resulting in a much faster query.
For more information see https://github.com/silverstripe/silverstripe-framework/issues/8389
This variant of showqueries will include a backtrace after each query.
This is extremely verbose but can be helpful when diagnosing where
queries have come from.
This is something that I have frequently added as a local hack on my
environment, I figured that exposing it as a formal feature would be
useful.
This allows React form builders (or other such view layer builders in a
headless environment) to obtain the details that would otherwise only be
rendered in a PHP side template. Some of the details are critical for
rendering correctly, and are necessary to be passed through -
particularly when moving toward replacing the Entwine initiator for
TinyMCE with a React component in `silverstripe/admin`.
I new interface method has been added to the abstract class for HTML
editor configs in order to facilitate this. It is not itself abstract as
this would break backwards compatiblity with any existing custom config
(aside from the TinyMCE one which we're editing here), which is most
certainly not what we want.
GridField doesn't have a valid readonly state if it's value is set to an Object
without `forTemplate()`. The default behaviour is to render a ReadonlyField,
but given GridField is a complex type this isn't suitable.
This bugfix provides a transformation method to render only components that are
whitelisted to provide a readonly state.
@see #3357 - https://github.com/silverstripe/silverstripe-framework/issues/3357
If no body is defined, the email is rendered according to a template. Clearing requirements prevent unnecessary styles/scripts to be included in the html (and that needs to be processed/stripped down the line).
Print view uses the SilverStripe templating to render values which means that
values are safely escaped by default. This can be tested by chaing `$CellString`
to `$CellString.RAW` in the GridField_print.ss template to see this escaping
being disabled.
This pull request removes double escaping of HTML in strings.
This fixes a bug where the installer redirects to home/ ('home' as the domain) as the url as opposed to localhost/home.
To reproduce:
* Use chrome (untested in other browsers)
* composer create project silverstripe/installer
* Run through the installer
Expected:
* Silverstripe installs and it takes you to the success page
Actual:
* SilverStripe installs and takes you to a different domain (ie. 'http://home')
The problem seems to be, any URL starting with `//` (two slashes) is normalised by the browser to an absolute URL by removing both slashes meaning `//home` becomes just `home` (as in http://home)
Fixes regression from 3.x, where sessions where lazy started as required:
Either because an existing session identifier was sent through with the request,
or because new session data needed to be persisted as part of the request execution.
Without this lazy starting, *every* request will get a session,
which makes all those responses uncacheable by HTTP layers.
Note that 4.x also changed the $data vs. $changedData payloads:
In 3.x, they both contained key/value pairs.
In 4.x, $data contains key/value, while $changedData contains key/boolean to declare isChanged.
While this reduces duplication in the class, it also surfaced a bug which was latent in 3.x:
When an existing session is lazily resumed via start(), $data is set back to an empty array.
In 3.x, any changed data before this point was *also* retained in $changedData,
ensuring it gets merged into existing $_SESSION data.
In 4.x, this clears out data - hence the need for a more complex merge logic.
Since isset($this->data) is no longer an accurate indicator of a started session,
we introduce a separate $this->started flag.
Note that I've chosen not to make lazy an opt-in (e.g. via start($request, $lazy=false)).
We already have a distinction between lazy starting via init(), and force starting via start().
Fixes regression from 3.x, where sessions where lazy started as required:
Either because an existing session identifier was sent through with the request,
or because new session data needed to be persisted as part of the request execution.
Without this lazy starting, *every* request will get a session,
which makes all those responses uncacheable by HTTP layers.
Note that 4.x also changed the $data vs. $changedData payloads:
In 3.x, they both contained key/value pairs.
In 4.x, $data contains key/value, while $changedData contains key/boolean to declare isChanged.
While this reduces duplication in the class, it also surfaced a bug which was latent in 3.x:
When an existing session is lazily resumed via start(), $data is set back to an empty array.
In 3.x, any changed data before this point was *also* retained in $changedData,
ensuring it gets merged into existing $_SESSION data.
In 4.x, this clears out data - hence the need for a more complex merge logic.
Since isset($this->data) is no longer an accurate indicator of a started session,
we introduce a separate $this->started flag.
Note that I've chosen not to make lazy an opt-in (e.g. via start($request, $lazy=false)).
We already have a distinction between lazy starting via init(), and force starting via start().
When selecting a column, it doesn't make sense to have it distinct.
As an alternative, the API could be changed to give the end user the option
(eg `->column($field, $distinct = false)`)
However if we did that, we would need to make sure we do something
similar with `SilverStripe\ORM\UnsavedRelationList` to ensure consistency.
* Add gridfield restore action, enable view button in action menu
* Abstract restore action and create test
* Use more appropriate canRestoreToDraft and isArchived, move translations
* Use Hierarchy to determine if a record should be restored to root
* Move restore action to versioned
