Loads default TinyMCE config instead of empty one

[davejtoews]

Description

v4.13.30 introduced a bug where a custom TinyMCE config would start from an empty config rather than the default config.

Manual testing steps

Define an extended valid elements value for a custom TinyMCE config in _config.php.

TinyMCEConfig::get('CustomConfi')
    ->setOptions(['extended_valid_elements' => 'small']);

Add a custom field using this config in Page.php

        private static $db = [
            'RichTextField' => 'HTMLText'
        ];

        public function getCMSFields()
        {
            $fields = parent::getCMSFields();
            $fields->addFieldToTab('Root.Main', HTMLEditorField::create('RichTextField', 'RichTextField', $this->RichTextField, 'CustomConfig'));
            return $fields;
        }

Open a TinyMCE editor in the CMS and enter paragraph breaks, links, h3 tags, and, via the source code option a <small> tag.

Prior to this fix all except the small tag will be stripped on save. After this fix, all the markup will save as expected.

Issues

• [Bug] TinyMCEConfig breaks when using option extended_valid_elements on a custom Config. #11141

Pull request checklist

• The target branch is correct
• All commits are relevant to the purpose of the PR (e.g. no debug statements, unrelated refactoring, or arbitrary linting)
• The commit messages follow our [commit message guidelines]
• The PR follows our contribution guidelines
• Code changes follow our coding conventions
• This change is covered with tests (or tests aren't necessary for this change)
• Any relevant User Help/Developer documentation is updated; for impactful changes, information is added to the changelog for the intended release
• CI is green

Additional Comments

• I do not know the reason for the change in 4.13.30, I suspect it was to prevent loading the "active" config, which presumably may or may not be the default. If loading the default was not the desired outcome, this PR may conflict with the reasoning behind that change. However, for my purposes, 4.13.30 was a breaking change.
• The change in 4.13.30 was also applied in 5.x. It may be necessary to cherry-pick the change there as well, though I have not tested in 5.x.

[davejtoews]

Hmm... after reviewing the CI failures I'm not sure this is the correct solution, but... I'm now confused about what's going on here.

By default the table option is available in the TinyMCE frontend, however the test here assumes table will not be present in valid_elements. Where is the source of truth for valid elements?

[davejtoews]

I think the test needs to be re-written here. A custom TinyMCE config w/ no changes applied to it will output a Table tool on the frontend, but table is not being included in the valid elements list of the test, and is in fact being specifically tested as an invalid element.

Happy to include a test rewrite in a PR, but still unclear to me how to find the definitive list of default elements. Surely the test itself should not be the source of this list?

[GuySartorelli]

Closing in favour of #11201