This should be mostly doable, having the new config handling classes (T275989: Rework MediaUploader config handling).
Probably the main issue here will be campaign config validation which should be rewritten to not rely on merging the campaign config with the global config prior to validation.
Some loose notes:
- CampaignContent will use a setServices public method for unit testing, due to the lack of a better alternative.
- CampaignContentHandler can use ObjectFactory: T243560: Use ObjectFactory to construct ContentHandlers
- DB code should be moved out to something like CampaignStore. This can also expose a custom SelectQueryBuilder, if there is a need for it.
- Constructing future Campaign or CampaignRecord (?) objects worries me a bit. Currently UploadWizardCampaign when constructed will retrieve the config from CampaignContent which is then validated. This content validation is okay for things like loading the campaign for use in the uploader, but is absolutely not okay when called repeatedly on Special:Campaigns or in ApiQueryAllCampaigns. I see two possible solutions, for now I'd go with the first one:
- Store the entire campaign config in the campaign DB table, as serialized JSON. This will help reduce the number of queries to the DB. We probably also would have to store some indication of whether the campaign is valid or not.
- Or decouple CampaignRecord from CampaignContent entirely and force callers interested in the full content to construct the WikiPage themselves and then handle the content. This would need some changes to the DB table and the API, which would have the option to retrieve the full campaign config marked as expensive or something like that. Seems a bit more complicated.