Settings form does not show existing value of normalize_post_dates

Yes, that was experimental code for 📌 Support config for fetcher and parser plugins Needs review . Thank you for finding it.

I haven't written a test yet, but that's partly because this ended up being more complicated than anyone might have expected. By default there are two plugin forms being submitted: first the parser and then the processor. The way that the config forms were submitted caused the processor to overwrite what the parser was doing with the original configuration. I'm not sure how it was getting the original configuration instead of the config that was just set by the parser, but I'm not planning to backtrace it right now. The entire plugin system needs an overhaul anyway.

Instead I'm fixing the problem by changing how the configuration is set. Previously the plugin loaded the entire configuration, set new values on it, and then saved. Now I'm making the plugins set only the values they control on a new, empty array. Only those values in the array get saved on the configuration. That way the plugins aren't potentially affecting settings they have nothing to do with. I want to run this through the tests to make certain everything else (mostly the processor) still works.

Huh. That's weird. The test failed properly on my local environment.

The test namespace was wrong.

The last submitted patch, 6: 3392062-6-test-only.patch, failed testing. View results →

I considered making a test for ensuring that the processor settings subform elements work properly, but that's already covered by AggregatorAdminTest::testSettingsPage(). I may want to move those assertions someday.

Automatically closed - issue fixed for 2 weeks with no activity.