Discuss requests for comments/changes posted in the Issue Tracker for the development of phpBB's style.
Forum rules Please do not post support questions regarding installing, updating, or upgrading phpBB or modifying styles of released phpBB versions. If you need support for phpBB please visit the Support Forums on phpbb.com.
If you have questions regarding creating styles please post in Styles Support & Discussion to receive proper guidance from our staff and community.
hello. This is not the correct place to post this. All feature requests need to be posted to the ideas section of .com https://www.phpbb.com/community/ideas/.
This forum is for development discussion of the new style for the software.
However, I will say this seems like a very useless feature IMHO not sure why you would ever need this? just replace the block of code
Aren't there before post and after post events? You can just use those to render a div around the posts with the needed class if you're looking to alter the color or do something else to post rows.
hanakin wrote: Thu Dec 20, 2018 4:45 pm
hello. This is not the correct place to post this. All feature requests need to be posted to the ideas section of .com https://www.phpbb.com/community/ideas/.
This forum is for development discussion of the new style for the software.
Sorry!
hanakin wrote: Thu Dec 20, 2018 4:45 pm
However, I will say this seems like a very useless feature IMHO not sure why you would ever need this? just replace the block of code
I try to avoid overriding template files as long as possible because core template updates are painful.
DavidIQ wrote: Thu Dec 20, 2018 4:48 pm
Aren't there before post and after post events? You can just use those to render a div around the posts with the needed class if you're looking to alter the color or do something else to post rows.
There are some problems:
1. If I add <div> and another extension adds <section> the closing tags would be in the wrong order.
2. It would cause unnecessary markup. 4 extensions using this feature would mean there are 3 unnecessary divs. Traversing DOM with jquery would be more complicated and perhaps not compatible with other extensions.
I mean some of those same points are also relevant to your proposed solution. If you add a class it's possible another extension adds their own class and overrides whatever you're doing in your class and another extension adds a class that overrides that and yet another clears it all and adds a page element. Basically those same arguments can be said about any style or PHP event an extension can leverage.
Also in this case your solution is only useful for one edge case which, as you can imagine, would not be a good investment of a developer's time. You're welcome to create a ticket in the tracker with the details and send a pull request for it on GitHub though.
DavidIQ wrote: Thu Dec 20, 2018 5:23 pm
I mean some of those same points are also relevant to your proposed solution. If you add a class it's possible another extension adds their own class and overrides whatever you're doing in your class and another extension adds a class that overrides that and yet another clears it all and adds a page element. Basically those same arguments can be said about any style or PHP event an extension can leverage.
Also in this case your solution is only useful for one edge case which, as you can imagine, would not be a good investment of a developer's time. You're welcome to create a ticket in the tracker with the details and send a pull request for it on GitHub though.
Of course, the classname would be in a format vendorname_extensionname_classname.
That won't stop another class from overriding style properties which is what I'm referring to. For instance a background color in your class can be overridden by another class regardless of what you call yours.
Either way this is only an issue with prosilver due poor selector scope. It will not be an issue going forward in the next theme. Due to individual components
DavidIQ wrote: Thu Dec 20, 2018 6:48 pm
That won't stop another class from overriding style properties which is what I'm referring to. For instance a background color in your class can be overridden by another class regardless of what you call yours.
The point of the modification is not to change backgrounds but to make some things possible that currently are not and overall, make the extension developers life a bit easier.
<body> tag has BODY_CLASS template variable. If it's so evil shouldn't it be removed ASAP?
Who said anything about it being bad? I simply said that there are already solutions for whatever it is that you're wanting to do that don't require someone to add additional code to the core to handle this which may not even see the light of day until the next major version (still quite a few months away). The existing solution has drawbacks just as the proposed solution has drawbacks. The difference is that one exists while the other one doesn't.