Wedge
Public area => The Pub => Bug reports => Topic started by: Arantor on March 28th, 2013, 11:08 PM
-
I know I've reported the first before but this is to remind me to dig into it.
A call of add_plugin_css_file('Arantor:PiePolls', 'piepolls', true); will grab $plugindir/piepolls.css which is fine. (I seem to remember the last parameter being reversed, i.e. the default being to include the CSS file in the header, rather than having to explicitly indicate such)
The problem is that it generates:
<link rel="stylesheet" href="/wedge/css/pie_polls-chrome26-windows6.1-member-m1-b7-c2-admin-local-global-replace-505778.css.gz">
Now I know why this happens, add_plugin_css_file wasn't kept in step with add_css_file, but I'm not sure I want to touch add_plugin_css_file to bring it in line with add_css_file (since there's a *lot* of code for that by the looks of things)
Secondly, plugins can't use inline block. I'm sure I've brought this up before, but it just doesn't work. My file contains:
#pie_legend
div
margin-bottom: 4px
div
font-size: smaller
.pie mixes .inline-block
width, height: 16px
border-radius: 8px
The definition of inline-block is simply not pulled in because the plugin loader never pulls in anything other than the plugin. I'm aware this has always been the case - but until inline-block was a virtual class, it was never a problem. When inline-block was made a virtual class, I mentioned it then, and I mentioned it again about two-columns not being extensible in a plugin (since I wanted to make a three-columns class based on two-columns just with the width changed) but that's also not possible either.
Virtual classes and mixins are great but if plugins can't use them, I need to figure out something else entirely for them.
-
Hmm, yeah... It's complicated.
As you know, I never looked much into add_plugin_css stuff, and was hoping for you to catch up, ah ah.
I've thought about it a bit, and decided that suffixes aren't needed in plugins, for the most part.
- local, global: there are no sub-skins in plugins... No need for that.
- admin, mod: I don't see much of a need for these...
- m1, again, it's mainly for testing...
Basically, I'm only keeping: guest/member, OS, browser, and language. These are entries that I'm always saving.
The workaround would be to either merge both functions and have a param to specify it's a plugin, or rewrite the function to match its sibling's functionality, or just drop file suffixes altogether, and rely only on @if stuff, and use the opportunity to rewrite both functions.
Regarding mixins: it's never worked... Neither did extends!
Remember, they're in a common.css file, and up till now you had to explicitly add it to your add_css_file list. The same went for plugin files... Since rev 2000 or so, add_css_file automatically loads common.css, so I guess add_plugin_css_file SHOULD do it as well... Again, it's a case of "I didn't even remember that function existed..."
-
Maybe merge functions, but keep add_plugin_css_file() as a shortcut of sorts?
-
Basically, I'm only keeping: guest/member, OS, browser, and language. These are entries that I'm always saving.
That makes sense to me.The workaround would be to either merge both functions and have a param to specify it's a plugin
Hmm, I think I'd rather not. The biggest issue with that is add_css_file only handles relative paths, whereas they're only going to get absolute paths from plugins. If that means add_plugin_css_file just ends up as a wrapper for add_css_file, that's fine but the distinction needs to be kept because add_plugin_css_file does other stuff around getting the correct path.Regarding mixins: it's never worked... Neither did extends!
No, it never worked - but all the time inline-block was a regular class, it didn't matter too much ;)so I guess add_plugin_css_file SHOULD do it as well...
Probably, yes.Maybe merge functions, but keep add_plugin_css_file() as a shortcut of sorts?
Under the hood, perhaps, but all it really needs is add_css_file being able to handle absolute as opposed to relative paths and then just have add_plugin_css_file be a straight wrapper.
-
Guys, what should I do about this topic..?
-
Guys, what should I do about this topic..?
Maybe get @live627 or @Dragooon to take a look.
-
Hmm, apparently the pokes weren't enough. :^^;:
Guess I can leave this unfixed for now.
-
Hmm, apparently the pokes weren't enough. :^^;:
I tried lol
-
Im not sure if i understood the topic correctly, but in the moment im trying to do some jquery.tab() stuff with jquery-ui etc. I tried to add the sample css files via add_plugin_css_file but it throws errors
8: Undefined index: selector
Filter einschalten: Nur Fehler von dieser Datei anzeigen Datei: /home/killtwba/www.killthebit.w2.ms5.eu/wedge/gz/app/Class-CSS.php
Zeile: 1077
I already deleted {,},; but is it perhaps not enough for the wedge minimization?!
Perhaps a fallback function for normal css files would be nice, something like an fopen add_css wrapper or some stuff.
-
Typical error that happens when you have indentation problems in your CSS files. Make sure you're using tabs consistently.