Developers may want to amend a gridfield (either by modifying its
components or amending the list) after it has been transformed to be
readonly.
One such modification may be replacing the GridFieldViewButton
with something else - because components are instantiated with the "new"
keyword this would be the only way to do that.
GridField has onBeforeRender in its Field method, but that hardly ever gets called.
This commit adds the onBeforeRenderHolder extension hook that is normally available via FormField::FieldHolder().
If the content is invalid for whatever reason e.g. when instantiating
a DBText field to get a summary of text through
`DBField::create_field('Text', $content)->Summary(10)`, preg_split returns
false and the rest of the code expects an array.
This tweak ensures an array is always returned even when preg_split fails.
This new opt-in setting will let grid field detail forms redirect to the
“Correct” URL of a GridField if it’s not found in the current list.
This works by:
* Looking for the item in the database
* If it exists, check for a CMSEditLink() method that returns a value
* If so, redirect to that
This is useful if you have a number of grid fields that each show a
partial list of records, and it’s possible for the user to make changes
such the item no longer appears in the list, but does appear in another
list.
It’s an opt-in feature as I think all changes like this should be
opt-in, based on previous experiences improving GridField and in turn
breaking SecurityAdmin and slowing versioned-data-browsing down. ;-)
The functioning of dot-syntax in form fields mean that .s are more
likely to appear in names. This breaks javascript behaviour in HTML IDs
and I believe is an invalid character for them.
Wrap doesn't actually wrap in the tidy extension.
This causes tests to be flakey, for example some of `FormTest` fails
if you happen to have `ext-tidy` installed (which is the default on most systems).
This happened to me on PHP 7.4.19 with tidy 5.6.0 (OSX Homebrew).
Note that the tests aren't failing in Travis right now.
You'd expect `wrap => 0` to be honoured. It's documented as an integer
in the tidy docs: https://api.html-tidy.org/tidy/quickref_5.6.0.html#wrap.
Even tracked this down to the PHP source which appears to be doing the right thing:
https://github.com/php/php-src/blob/master/ext/tidy/tidy.c#L300
There's a bug from 2018 against PHP 7.2.8 which was closed as "not a bug" without comment:
https://bugs.php.net/bug.php?id=76683
You can see the behaviour in action in the following test.
```
<?php
$html = '<p>a really long string which should not be wrapped</p>';
echo "## With tidy extension" . PHP_EOL;
$tidy = new tidy();
$tidy->parseString(
$html,
[
'output-xhtml' => true,
'numeric-entities' => true,
'wrap' => 0,
],
'utf8'
);
$tidy->cleanRepair();
echo $tidy . PHP_EOL;
echo "## With tidy cli" . PHP_EOL;
$cmd = sprintf("echo " . escapeshellarg($html) . " | tidy --force-output 1 -n -q -utf8 -asxhtml -w 0 2> /dev/null");
echo shell_exec($cmd);
```
Long story short, setting it to 99999 fixes the issue.
