Validate feed importer configuration: check for invalid bundle and invalid language

I can confirm that when importing an importer using admin/structure/feeds/import, there is no alert about a non-existing content type and that on the mapping page some of the targets say "missing". In my case, the created importer is not completely "blank". All the "settings" (basic settings, fetcher settings, etc.) are still there. It's just the mapping that can be qualified as "blank". I agree a warning message would be nice here.

We should do some validation.

Checking the content type would be a good start. I don't think we should validate that all of the fields exist, since the missing mapping is fine.

Here is a first step at this.

• Two methods are added to FeedsConfigurable:
  • getConfigAllowedValues():
    This allows Feeds plugins to set the allowed values per config key. This is handy for the processor's bundle setting and - when #2529538: Generic entity language support. is done - for the processor's language setting.
  • validateConfig():
    This allows Feeds plugins to validate the config. Plugins implementing this method should return an array of error messages.
• FeedsProcessor implements getConfigAllowedValues() to set allowed values for the bundle setting.
• FeedsImporter implements validateConfig() to execute the same method on the fetcher, parser and processor that it contains.
• The configuration is validated on every feeds_ui_edit_page() call, thus on every importer config page.
• The configuration is validated when importing an importer.
• The config form for FeedsProcessor is modified to always show the current bundle setting, even if that points to a non-existing bundle. When the current set bundle does not exists, the option label is prefixed with "Unknown bundle".

Caveats, further improvements

• When a setting is validated on allowed values, the error message refers to the config key instead of the config label. The config key is not translatable.
• There might be some overlap between the methods validateConfig() and configFormValidate().
• The check for plugin availibity now happens only when importing an importer. Because it is part of validation, maybe it should be moved to validateConfig().
• Automated tests.

Suggestions and feedback are welcome!

Some of the test failures were caused by a bug in the test "FeedsUIUserInterfaceTestCase". I've fixed that in #2574789: Wrong processor settings set in FeedsUIUserInterfaceTestCase::testImporterImport().

Another bug in the patch from #4 was that all importers you were trying to import became invalid, because form_error() was called regardless if there were errors or not. This is fixed in the attached patch. Caveats noted in #4 still apply.

This patch does the following in addition of the previous patch:

1. The method FeedsConfigurable::getConfigAllowedValues() is removed because the error message for an invalid config option would refer to the untranslatable config key instead of config label.
2. The check for plugin availability is moved to FeedsImporter::validateConfig().
3. Validation is added for the processor's language setting.
4. Automated tests are added that check if warnings are displayed on the importer configuration pages in case of invalid configuration, and when importing an importer. The following cases have been covered for both the UI and importing an importer:
   • Invalid plugin.
   • Invalid bundle.
   • Invalid processor language.

All caveats reported in #4 are handled with the patch except the following (minor) one:

There might be some overlap between the methods validateConfig() and configFormValidate().

Oops, accidently showed an error message of an unavailable plugin when the plugin class was *not* an instance of FeedsMissingPlugin. Should be the opposite, of course!

I hope that this will make it into the Feeds 7.x-2.0-beta4 release.

Reroll.

Noticed an issue with validating the selected language on the importer: every language was reported as invalid, even LANGUAGE_NONE! This issue is new though, it did not occur before the changes from #2788125: FeedsProcessor not respecting bundle i18n language settings.
Changed language validation to use the new languageOptions() method, introduced into that same issue.

Other then that, I think this is ready.

Oops, noted a small mistake in last patch. Should have been catched by the tests though.

Reroll.

Committed #16.