View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0002971 | Composr | core_themeing | public | 2016-12-07 00:09 | 2017-11-19 22:20 |
| Reporter | Chris Graham | Assigned To | Chris Graham | ||
| Severity | Feature-request | ||||
| Status | closed | Resolution | fixed | ||
| Product Version | |||||
| Fixed in Version | |||||
| Summary | 0002971: Theme tooling improvements | ||||
| Description | I've been thinking a lot how to make theme upgrading easier. This has been a long-running difficult-to-solve issue, but I believe we now have a number of ideas that can together solve it. Principles: - Most users will not do theme changes beyond Theme Wizard. These Theme Wizard themes must update close-to-perfectly across versions - If files are overridden then compo.sr site must show clear table of all changes, put everything very clearly in front of the webmasters eyes so diff tools aren't needed - Automatic change appliers are complex and unreliable, so continue to avoid for now. Improved tooling can massively reduce the problem as a stable and manageable solution. - Tools should be built into Composr, our unit testing workflow, or our compo.sr code - and meet our minimum standard - they shouldn't be in scrappy non-bundled addons Tools to add... Edit an existing theme's seed; must be smart enough to only change images and CSS colours that matched the previous seed More theme management test links (take code from theme_debug page) For each CSS have a validation link (for local validator and W3C validator) For each screen preview have an HTML validation link (for local validator and W3C validator) Unit tests to add... Find unused CSS classes for any installed theme, with defined exceptions (take code from css_check page) Find missing theme images for any installed theme, with defined exceptions (take code from theme_debug page) Find unused theme images for any installed theme, with defined exceptions (take code from theme_debug page) For each custom theme does a validation on its CSS, and the screen of each template it has - not just the default theme On compo.sr... Auto-generated page on compo.sr that shows table of all theme files changed in each version with diff/images Upgrader can link to this page with a list of all files included in custom themes, so it can be filtered and tagged by theme also show changes you've made via sending in the files with .editfrom files (if they exist) also provide feature to download tar so you can do a 3-way diff also provide link to DiffMerge also search tutorials for mention of DiffMerge and update to mention new tool Work out latest compatible version using .editfrom Provide above link in theme management too Provide button to mark-selected-files-consistent with latest version (recreates .editfrom from default theme) [shows only the files not consistent yet, or a "no entries" error] And also from all upgrade release note posts Theme images... Ability to regenerate any selected theme images from default theme file Ability to generate any missing theme images using theme wizard (take from fix_partial_themewizard_css page) Implement as a cleanup tool and also automatically call from upgrader Ability for theme wizard to generate to a streamed zip file so that you may easily get files from a reference theme without adding crap to your live site CSS... Move colours to new _colors.css file Make the Theme Wizard add some special code to _colours.css that dynamically does a Theme Wizarding using the theme seed before the colours are defined in the file. This will have the effect of allowing any new-defined colours in the default theme retroactively copying through Move responsive modes stuff (in hybrid responsive branch) to new _responsive.css file For each CSS file add an include to the <file>__extensions CSS file on the bottom At top of global.css change comment to say colours are in _colors.css file And also mention that every CSS file by default includes a <file>__extensions.css file And include a comment at the top recommending to add changes to the <file>__extensions file, even if the changes are to undo our own rules Search for code that references global.css and in some cases change to _colors.css Search for code that references 'global' and in some cases change to '_colors' Add all new CSS files to addon registry hooks Remove the theme wizard inclusion-style method (not needed anymore) ...and make sure it is not documented Test that now the Theme Wizard ends up only creating a single CSS file, _colors.css (Existing principle, not a change) CSS rules can be re-defined, so safe In <file>__extensions.css files support regexp substitutions, regexp deletions, white-space safe substitutions, white-space safe deletions JavaScript templates... (Existing principle, not a change) Any new code can go in new files or the custom file (Existing principle, not a change) JS functions can be re-defined, so safe In the custom file support regexp substitutions, regexp deletions, white-space safe substitutions, white-space safe deletions Delete theme_debug addon | ||||
| Tags | Type: Usability (major) | ||||
| Time estimation (hours) | 16 | ||||
| Sponsorship open | |||||
| related to | 0003049 | non-assigned | Major upgrade reimagining (including hypervisor, and default theme improvements) |
|
|
Thinking that instead of <file>__extensions for CSS, we should have a standard that any template may have a <file>__pre and <file>__post template to automatically prepend and append to it. This would be useful for quite a lot and would not add any load because it would happen only at compilation. |
|
|
For CSS it would be good to have substitutions that have a CSS awareness. E.g. {$CSS_REMOVE,.re_body,color} To strip the 'color' property from the default '.re_body' class without needing to write regexps or do a full CSS file override. |
|
|
We may want to make the diff page we have on our site also handle templates, and have filtering options to filter by file. Maybe multi-select lists of what files to include. I suppose we could make it work with every single file in the distribution, why not. |
|
|
Closing this. SOME of this was implemented a while back. Otherwise I am opening up new issues, splitting it all up for clarity. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2016-12-07 00:09 | Chris Graham | New Issue | |
| 2016-12-08 12:48 | Chris Graham | Tag Attached: Type: Usability | |
| 2016-12-08 12:50 | Chris Graham | Tag Renamed | Type: Usability => Type: Usability (major) |
| 2016-12-23 17:07 | Chris Graham | Note Added: 0004656 | |
| 2016-12-23 17:13 | Chris Graham | Note Added: 0004657 | |
| 2017-01-04 22:10 | Chris Graham | Note Added: 0004669 | |
| 2017-01-31 11:49 | Chris Graham | Relationship added | related to 0003049 |
| 2017-11-19 22:20 | Chris Graham | Note Added: 0005220 | |
| 2017-11-19 22:20 | Chris Graham | Status | non-assigned => closed |
| 2017-11-19 22:20 | Chris Graham | Assigned To | => Chris Graham |
| 2017-11-19 22:20 | Chris Graham | Resolution | open => fixed |
