[2.0] Backend sections created by additional plugins
Posted: Thu May 15, 2014 10:49 am
So I have a day off and decided to start testing and adapting those plugins in additonal_plugins which create their own sections in the backend to 2.0. I kind of ran into an issue there which needs discussion.
The way we do layout in the 2.0 backend now, there are not many “generic classes” to use for layout purposes. In hindsight, that might not have been my wisest idea, although it is way better for making individual adjustments as well as writing a different backend theme without touching the markup.
The issue with this is that at least some of the additional_plugins which generate their own backend section would need layout styles as well. (I'm guessing it's more like “most of them” than “some”, but I have only tested one so far.) The question is how to best handle this.
The options I currently see are:
1. Include these styles in templates/2k11/admin/style.css, which will blow up that file significantly. Technically, this is bad because a lot of users won't even use most of the additonal plugins, yet the backend theme stylesheet would still include styles for them.
2. Rewrite templates/2k11/admin/style.css to provide and use generic layout classes which backend sections generated by additional plugins can use. I assume this would slow down the RC phase quite a bit since it could be a lot of work.
3. Have plugins which generate a backend section emit individual CSS (just like they do in the frontend). I don't think this is feasible since this CSS obviously would not work well with possible future backend themes, so it would need to be overwritten there.
4. Just ignore it. That would mean the backend sections generated by additional plugins would be styled according to their markup (adapted for 2.0) and the generic styles which already exist in templates/2k11/admin/style.css, but they would not get individual layout. I don't think this is a solution, but it might be a temporary option to not slow down backend development.
If anyone sees another option, please add to the list. Based on this list, I think the only viable options are 1 and 2, 1 being the obvious preference because it would not slow down developement (much). I also think the impact on style.css (in option 1) would be acceptable.
YL
The way we do layout in the 2.0 backend now, there are not many “generic classes” to use for layout purposes. In hindsight, that might not have been my wisest idea, although it is way better for making individual adjustments as well as writing a different backend theme without touching the markup.
The issue with this is that at least some of the additional_plugins which generate their own backend section would need layout styles as well. (I'm guessing it's more like “most of them” than “some”, but I have only tested one so far.) The question is how to best handle this.
The options I currently see are:
1. Include these styles in templates/2k11/admin/style.css, which will blow up that file significantly. Technically, this is bad because a lot of users won't even use most of the additonal plugins, yet the backend theme stylesheet would still include styles for them.
2. Rewrite templates/2k11/admin/style.css to provide and use generic layout classes which backend sections generated by additional plugins can use. I assume this would slow down the RC phase quite a bit since it could be a lot of work.
3. Have plugins which generate a backend section emit individual CSS (just like they do in the frontend). I don't think this is feasible since this CSS obviously would not work well with possible future backend themes, so it would need to be overwritten there.
4. Just ignore it. That would mean the backend sections generated by additional plugins would be styled according to their markup (adapted for 2.0) and the generic styles which already exist in templates/2k11/admin/style.css, but they would not get individual layout. I don't think this is a solution, but it might be a temporary option to not slow down backend development.
If anyone sees another option, please add to the list. Based on this list, I think the only viable options are 1 and 2, 1 being the obvious preference because it would not slow down developement (much). I also think the impact on style.css (in option 1) would be acceptable.
YL