Patch #43206
closed
Remove deprecated icon-* classes from stylesheets
0%
Files
Related issues
Updated by Marius BĂLTEANU 2 months ago
- Subject changed from Removes deprecated icon-* classes to Remove deprecated icon-* classes from stylesheets
Updated by Marius BĂLTEANU about 1 month ago
- Category set to Code cleanup/refactoring
- Status changed from New to Resolved
- Assignee set to Marius BĂLTEANU
Updated by Marius BĂLTEANU about 1 month ago
- Status changed from Resolved to Closed
Updated by Go MAEDA about 1 month ago
- Related to Defect #43337: Missing icons for scroll buttons in the project menu added
Updated by Go MAEDA 23 days ago
- File redmine_issue_templates-before@2x.png redmine_issue_templates-before@2x.png added
- File redmine_issue_templates-after@2x.png redmine_issue_templates-after@2x.png added
- File administration-before@2x.png administration-before@2x.png added
- File administration-after@2x.png administration-after@2x.png added
- Status changed from Closed to Reopened
This removal is correct for core, but many third-party plugins still use raster icons. As a result, their icons no longer render correctly since r24029.
Plugins probably use raster icons for various reasons. One is that they need to remain compatible with Redmine 5.1 and earlier. Another is that the author has not yet found the time to migrate to SVG icons.
To preserve compatibility with existing plugins, could you consider reverting r24029?
Before r24029 (redmine_issue_templates plugin):
After:
Before r24029 (Administration page with two plugins installed):
After:
Updated by Marius BĂLTEANU 21 days ago
It is expected to cause this issue with some plugins that are not updating their icons, this is why I didn't removed the classes when I introduced the icons in Redmine 6.0.0 and I waited for next major version (7.0.0).
I prefer to not keep this complexity in the core just because we break some plugins, but I'm open to provide a easier way for plugins to keep the compatibility. Maybe one option is to move all the rules to an icons-legacy.css file and let the plugins include the file based on their needs? Any other suggestion is welcomed.
Updated by Go MAEDA 20 days ago
Marius BĂLTEANU wrote in #note-6:
Maybe one option is to move all the rules to an icons-legacy.css file and let the plugins include the file based on their needs?
That is a good idea.
For plugin developers, a more descriptive name such as legacy-icons-compat.css would make its purpose clearer.
Updated by Go MAEDA 15 days ago
- Related to Defect #43422: File format custom fields use legacy download icon instead of SVG icon added
Updated by Go MAEDA 15 days ago
- File 0001-Add-legacy-icons-compat.css-legacy-icons-compatibili.patch 0001-Add-legacy-icons-compat.css-legacy-icons-compatibili.patch added
Marius BĂLTEANU wrote in #note-6:
I prefer to not keep this complexity in the core just because we break some plugins, but I'm open to provide a easier way for plugins to keep the compatibility. Maybe one option is to move all the rules to an icons-legacy.css file and let the plugins include the file based on their needs? Any other suggestion is welcomed.
The attached patch adds legacy-icons-compat.css that provides styles for legacy icons. A plugin developer or user can restore the appearance of legacy icons just by importing legacy-icons-compat.css in the plugins stylesheet:
@import url('/legacy-icons-compat.css');
Updated by Marius BĂLTEANU 14 days ago
- Status changed from Reopened to Closed
Thanks for taking care of this, I've committed the patch. I still recommend to invest the effort in moving the icons to the new svg icons.