View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 3361 | Composr | core_themeing | public | 2017-11-20 00:12 | 2021-02-24 04:19 |
| Reporter | Chris Graham | Assigned To | Chris Graham | ||
| Priority | normal | Severity | feature | ||
| Status | resolved | Resolution | fixed | ||
| Summary | 3361: Improving CSS and JavaScript maintenance | ||||
| Description | Move out colours from global.css: 1) Move colours to new _colors.css file. This reduces the need to override global.css. 2) Add a Tempcode INCLUDE directive to include the default theme's own _colors.css. This is so any newly-defined colours come through automatically. 3) At top of global.css change comment to say colours are in _colors.css file 4) Search for code that references global.css and in some cases change to _colors.css 5) Search for code that references 'global' and in some cases change to '_colors' 6) Check that now the Theme Wizard ends up only creating a single CSS file, _colors.css Move out hybrid responsive design initiation code from global.css: 1) Move responsive modes stuff (in hybrid responsive branch) to new _responsive.css file. This reduces the need to override global.css. Allow easier tacking onto the end of any existing CSS file: 1) For each of our CSS files add a Tempcode INCLUDE to the _<file>__extensions CSS file on the bottom. The intention here is a themer can just decide to add CSS code by adding as an extension, removing the need for an actual override. Add a comment by the include explaining this. 2) Add all these _<file>__extensions files. 3) Document clearly in the tut_themes tutorial that this is the best way to override styles. That CSS lets you override stuff that's redefined later in the file. 4) Remove the theme wizard inclusion-style method (not needed anymore) 5) In <file>__extensions.css files support regexp substitutions, regexp deletions, white-space safe substitutions, white-space safe deletions. This would be done by new Tempcode symbols. Document all this too, being clear to explain these only work in CSS (and JavaScript) files. 6) Also support CSS-aware deletion symbols. {$DELETE_CSS_SELECTOR,selector}. {$DELETE_CSS_PROPERTY,selector,property}. Ditto about documentation. Allow easier tacking onto the end of any existing CSS file: 1) Rename custom_global.js to _global__extensions.js, for consistency any clarity with how CSS will now be done 2) Add extension files for all the other default bundled .js files. 3) Document in tut_themes, just how we did for CSS. More changes for JavaScript: 1) Rename the upper case JavaScript templates to lower case, and put underscores in front, and update our documented coding standard about this. Again, for consistency. Misc: 1) Add all the new files to the appropriate addon_registry hooks. 2) Add an automated test to ensure all the __extension.css/__extension.js files exist, so we don't forget to maintain this in the future. 3) ...Document as a coding standard too. 4) New themes being installed would be displayed (via an automatic algorithm) as being upgrader safe or not. Ones that only use extension CSS/JS files, theme images, and no full template overrides would be considered safe. A warning would explain that unsafe ones may be fine if maintained, but otherwise will become incompatible at some point. | ||||
| Tags | Roadmap: v11 | ||||
| Attach Tags | |||||
| Time estimation (hours) | 16 | ||||
| Sponsorship open | |||||
| child of | 3362 | Resolved | Chris Graham | Themeing improvements in v11 (idea staging issue) |
|
|
I think it would be cool to allow any number of extensions to automatically be merged into a file. Do it via some kind of file naming pattern, e.g. cns_special_cpf__extension__foobar.ini would be extending cns_special_cpf for the foobar addon. As this happens at compilation page (template compilation or lang file compilation), there wouldn't be much overhead. Possibly for .php overrides too, but I do worry more about performance there. |
|
|
This is now implemented. I've done things a bit differently... Instead of _colours.css and _responsive.css, there is just _base.css. No need for two. This is loaded via PHP logic, rather than INCLUDEs. Cleaner, as it is needed by any CSS file. There are, however, some _*_colours.css files that are done via includes, for addon-specific colours. The whole system of extensions is changed significantly. We are trying to solve two problems: 1) Allow overrides to minimally specify their changes, to make upgrading easier 2) Allowing multiple addons to override the same files, to avoid conflict The extension system would have involved a lot of extra files and complexity and impacted performance. So instead for (1), I've improved the INCLUDE directive a lot. It can do the same kinds of substitutions discussed here for the extension files. It's nice to extend our existing functionality rather than create something new. To solve (2), I've created a new system called 'contentious hooks'. These may alter PHP code files, .ini files, and templates. It's nice because the hooks directory needs only scanning once, rather than looking for extension files for each individual file being loaded. All in all, this is simpler and cleaner, and works great. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2017-11-20 00:12 | Chris Graham | New Issue | |
| 2017-11-20 00:16 | Chris Graham | Relationship added | child of 3362 |
| 2019-06-27 18:12 | Chris Graham | Tag Attached: Roadmap: v11 | |
| 2019-12-13 16:38 | Chris Graham | Note Added: 0006228 | |
| 2019-12-13 16:39 | Chris Graham | Note Edited: 0006228 | |
| 2020-03-07 21:21 | Chris Graham | Assigned To | => Chris Graham |
| 2020-03-07 21:21 | Chris Graham | Status | Not Assigned => Assigned |
| 2021-02-24 04:19 | Chris Graham | Status | Assigned => Resolved |
| 2021-02-24 04:19 | Chris Graham | Resolution | open => fixed |
| 2021-02-24 04:19 | Chris Graham | Note Added: 0006965 |
