- Remaining Developer Guides and Upgrading
- SilverStripe in a namespace or api has not been change
- To keep PRs easier no formatting was changed
Update merge conflics with two files
Update Silverstripe Ltd, Silverstripe Cloud and Silverstripe CMS
Silverstripe CMS Ltd > Silverstripe Ltd
Silverstripe CMS Platform > Silverstripe Cloud
Silverstripe CMS Framework > Silverstripe CMS
Resolve merge conflict
Remove Framework from Silverstripe CMS Framework
- 3 files
Change SilverStripe CMS to Silverstripe CMS
I am not quiet sure if this is needed but if you want to only add the custom action to the GridField action menu than you need to add the extra classes otherwise it would add it to the action menu and to the gridfield.
I found these errors while going through this tutorial,
missing ```use use SilverStripe\Forms\GridField\GridField;```
interface GridField_ActionMenuItem required parameters on getTitle() and getGroup()
incorrect if statement on getExtraData() - $field is not defined
Update guidance on form template location. They don't necessarily have to be placed in /app/templates and will work in the theme directory too. The current text also seems to suggest that they can be placed in the core directory - something which I don't believe should be advised,
- Stronger wording around "use composer"
- Consistent domain and email address naming
- Removed example for publishing non-composer modules (those shouldn't be encouraged)
- Removed instructions for installing modules from archives
[ci skip]
* WIP GridField action menu work, the gist of the idea is using a new gridfield component
* Add delete action to actions menu
* Actions are added automatically to action menu (allows for extension)
* Add test and minor changes
* Add docs and minor changes
* Refactor ActionMenuItem into distinct types, general ActionMenu cleanup
* Add icons and fix title
* Pass columnName, so it can be used by components
* Update test to open and find action menu buttons
* Add section in changelog upgrade section for GridField_ActionMenu
They're broken since you can't access PHP files in the vendor dir any more,
and they're not easily fixed by creating a new rpc.php file in the webroot.
There's something around TinyMCE missing a base_uri.
Regardless, browsers have great built-in spellcheck these days,
so server-side spellchecking is more of an edge case that we don't have to cater for in core.
