Problem/Motivation
This is the real motivation for
#3230827: Test fixes for 2.x โ
:)
The current situation is that the CSS is only written to disk when the config form is saved. This means that you can't use this module from an existing configuration, nor deploy changes to it via configuration import. (Or, you can - but it requires an additional save click in the admin form each time.)
My first approach was to preserve the built CSS to disk and pick up on that via config event listeners, but this turned out to be unreliable for some reason, and didn't seem worth the effort when we can build and output the CSS effectively as required.
So, MR!3 does that - it injects additional CSS inline into the node edit form, which delivers the same outcome and better supports config api operation.
Steps to reproduce
- Deploy changes to the module via `drush config:import`
- Observe that changes are not displayed to admin until admin form is also saved
- Note that files stored to sites/default/files/css *might* be cleaned up unexpectedly, breaking this module's behaviour until Save gets clicked again
Proposed resolution
- Generate CSS from stored config when called from form alter
Remaining tasks
- Review
- Merge
Happy to write test coverage for behaviour, but we need to turn tests on for the module and get existing tests passing (
#3230827: Test fixes for 2.x โ
) and coding standards fixed first.
User interface changes
API changes
Data model changes