View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
2156 | Convertr | Build tools | public | 2016-01-30 15:18 | 2022-11-20 22:12 |
Reporter | Chris Graham | Assigned To | Guest | ||
Priority | normal | Severity | feature | ||
Status | new | Resolution | open | ||
Summary | 2156: Identification of what a theme file was built from | ||||
Description | When we make a theme in Composr, we have .editfrom files for each individual overridden file. This is a copy of the full file an override is from, allowing easy diffing even if the original file is changed in a newer version. We do not explicitly store the version. We do need to know the version though. I suggest we start maintaining data/theme_signatures/<checksum>.json files that let us recognise what version a .editfrom file comes from. e.g. data/theme_signatures/54fgretg4g.json: {file: 'global.css', version: '10.1.1'} Most files wouldn't change between releases. However, we can just bump forward the signature file to the latest version it is equivalent to. E.g. if 10.1.2 global.css is the same as the 10.0.1 global.css, the build tools would simply replace as: data/theme_signatures/54fgretg4g.json: {file: 'global.css', version: '10.1.2'} (it can do this naively, it just replaces everything it finds a current checksum for). We can use md5 for the checksums, but we must strip all whitespace before running md5, as this may get borked outside our control (we don't remove the whitespace from the actual files of course). | ||||
Tags | No tags attached. | ||||
Attach Tags | |||||
Sponsorship open | |||||
|
Actually it may be better to do this in a single JSON file, otherwise we'll end up with thousands of tiny files. |
Date Modified | Username | Field | Change |
---|---|---|---|
2022-11-20 22:12 | Chris Graham | Assigned To | user4145 => |
2022-11-20 22:12 | Chris Graham | Status | Assigned => Not Assigned |