The Postgres implementation was always faulty,
but the database exception was swallowed until
See https://github.com/silverstripe/silverstripe-framework/pull/9456.
Now that the the exception is only swallowed the first time,
the second recurrence will cause failing test execution.
This is a bit of an awkward fix, but the indirection "through" DataObject doesn't allow for anything else without changing public API surface.
The logic goes from TempDatabase to DBSchemaManager, then through the closure into DataObject->requireTable(),
then back into DBSchemaManager->requireTable(). And updateschema() is subclassed in SQLite3, making it difficult to add more arguments.
VACUUM is described as:
> VACUUM reclaims storage occupied by dead tuples. In normal PostgreSQL operation, tuples that are deleted or obsoleted by an update are not physically removed from their table; they remain present until a VACUUM is done. Therefore it's necessary to do VACUUM periodically, especially on frequently-updated tables.
https://www.postgresql.org/docs/9.1/sql-vacuum.html
Since test databases are short-lived, there's no reason to delete dead tuples, they'll be garbage collected when either the transaction is rolled back, or the database is destroyed after the test run.
The query might still work depending on where these chars are placed,
but it seems weird to only remove *some* of the valid chars here.
See https://dev.mysql.com/doc/refman/5.6/en/fulltext-boolean.html
Note that the query runs both the actual boolean query with chars,
and then a separate relevance search without them.
This came up in https://github.com/silverstripe/silverstripe-cms/issues/1452, and wasn't fully addressed.
Either we allow boolean mode and all the constraints this brings around special character usage,
or we filter out those special characters, which makes boolean mode pointless.
You can't just pass arbitrary user input in a power-user function like this.
See https://dev.mysql.com/doc/refman/5.6/en/fulltext-boolean.html
Context: This used to work for some examples like "foo>*" under MyISAM,
presumably because it had a more lenient parser. InnoDB rightfully complains about this now.
MyISAM used to be the only one to support it, now InnoDB has caught up.
Unless an engine is set specifically in create_table_options,
this will auto-convert existing MyISAM tables to InnoDb.
Fixes#9242
Member::logInAs doesn't exist as a static function.
Additionally, `logInAs` does exist as a function in SapphireTest.php, so, should this be updated to also use `Member::actAs` for consistency?
* Add wildcard URL parameter matches for url_handlers
* Extra tests for wildcard parameters
* Add a PHP warning if more params appear after wildcard param
The accessibility attribute `role="listbox"` requires its immediate children to be set as `role="option"`, currently they don't have this option and accessibility tests are failing.
Silverstripe Forms allow malicious HTML or JavaScript to be inserted
through non-scalar FormField attributes, which allows performing XSS (Cross-Site Scripting)
on some forms built with user input (Request data). This can lead to phishing attempts
to obtain a user's credentials or other sensitive user input.
There is no known attack vector for extracting user-session information or credentials automatically,
it required a user to fall for the phishing attempt.
XSS can also be used to modify the presentation of content in malicious ways.
