Wedge
Public area => The Pub => Plugins => Topic started by: Arantor on September 6th, 2012, 05:24 AM
-
I've not been feeling 100%, but anyway, I wanted to kick off with a plugin tonight, just to get back into some semblance of a coding life.
So I figured I'd make a start on something that we might use here and that others might want to use. Colours are configurable from the admin panel, too, because I'm nice like that, and that way it's also preserved across installs of the plugin.
(Still early, this is about as far as I've got... without file edits.)
-
Quick second preview before I go to bed. It's ugly, but you get the idea where this is going :)
-
I do now ^_^
-
:cool:
Very useful indeed.
List of unresolved topics coming eventually?
-
Looks nice and presumably "something that we
might will definitely use here" :)
-
It looks great, nice work! :)
-
That's cool!
-
Did I mention no template changes? :D
-
Just going to leave this one here... (in case it's not clear, the dropdown in quick moderation can be extended now without too much kerfuffle)
Also, to answer Spoogs' question, yes, there will somewhere be a list of unsolved topics for the boards in question. But I still need to make other changes to Wedge to support some of the functionality I want, so it's further down the list.
Just to clarify, I need to do some more work to make quick moderation extensible, at the processing stage, and I need to support some sane way of extending configuration to support a list of boards.
Basically, while yes, ultimately, it will need to be possible to provide options in the manage-boards area for plugins, for something like this I'm really averse to storing it in the boards table for all the effort for that one column. What I might as well do - and what I can well imagine would be useful for other plugin authors - is to have a simple selection in the standard configuration pages, to quickly select which boards are applicable and which ones aren't.
There's already a 'permissions' type for that sort of thing, and I don't see that declaring board types is any more of a problem, in that respect. That way plugin authors can do it real quick and easy.
-
Just going to leave this one here... (in case it's not clear, the dropdown in quick moderation can be extended now without too much kerfuffle)
Also, to answer Spoogs' question, yes, there will somewhere be a list of unsolved topics for the boards in question. But I still need to make other changes to Wedge to support some of the functionality I want, so it's further down the list.
-
It wasn't finished based on the complexity IIRC
Figured as much ;) it was something you really wanted to get into the one you and Nas made under SD
-
I have a couple of forums where that would really be nice.
-
Having now rewritten the behemoth that was quick moderation, I figured I'd dive into the rest of this plugin.
Also, note that there is no actual configuration code required for that configuration page. All that is is a small block in the plugin-info.xml file.
<settings-page area="topicsolved" icon="$pluginurl/img/tick.png" bigicon="$pluginurl/img/tick-big.png">
<language file="lang/TopicSolved-Admin" />
<text name="topicsolved_bg1" />
<text name="topicsolved_bg2" />
<text name="topicsolved_fg" />
<boards name="topicsolved_boards" />
</settings-page>
Yes, really. Wedge plugins will be super easy to get going.
-
Totally unrelated, but maybe we should use the HTML inputs of the 'color' type for actual color requests...? Instead of HTML code...
Or implement our own, something like showing a small inline-block next to the box, and fill its background-color on 'change' and 'blur' events.
-
I have been thinking about that, actually, though if I did it, I'd go into having a full colour selector. The HTML5 color input is only supported in some browsers, meaning I'd need to do something else instead.
I haven't found one in jQuery that I like the look of though, and don't know exactly how I'd like it to look either...
-
It looks amazing, nice work! :) I like that it just takes a few lines to create a decent settings page, which is really cool. ;D
-
I haven't found one in jQuery that I like the look of though, and don't know exactly how I'd like it to look either...
Okay, may have found a bug somewhere, *or* I incorrectly set something up, but it shouldn't be doing this...
Warning: getimagesize(/my_root/wedge/Themes/default/images/admin/http://wedge.org/.../topic_solved/img/tick.png) [function.getimagesize]: failed to open stream: No such file or directory in /my_root/wedge/Sources/Class-CSS.php on line 619
This is caused by the admin menu's call to the @dynamic CSS icon generator, which in turn expects the 'icon' entry of admin menus to be a relative URL, rather than absolute...
And it seems that your plugin system provides an absolute URL to the tick.png file. It should either calculate the relative position for it, or we should update the admin code to deal with absolute URLs... What do you prefer..?
-
Always looking for plugins eh? Be a man, write everything yourself!
Okay, may have found a bug somewhere, *or* I incorrectly set something up, but it shouldn't be doing this...
And it seems that your plugin system provides an absolute URL to the tick.png file. It should either calculate the relative position for it, or we should update the admin code to deal with absolute URLs... What do you prefer..?
There's also the other matter: making it easy to use. The current structure is easy enough to follow for modders. If you want @dynamic to mess around with it and do something else, that's absolutely fine, but please please please do not force modders to have to do something more byzantine and awkward to put an icon in to the admin menu. (I'm still not happy with how plugins have to jump through hoops like adding a whole line of CSS including positioning to add a simple main menu icon.)
The rest of the code is straightforward on this point: if the icon looks like a URL, treat it as a URL, if it doesn't look like a URL, fetch it from the admin folder of the theme's images.
Also, remember that a plugin CANNOT know for certain what folder it will be installed in, relative to Plugins/, which is the whole point of having the context variables. If you want to make it relative, do it OUTSIDE of the plugin, e.g. in the @dynamic code.
-
I don't actually like JavaScript that much if I'm honest, but as I said, if I knew how I'd like it to look, I could probably make my own.
The plugin provides absolute URLs for everything, and the code was designed with that in mind and has been that way since I wrote the guts of the plugin manager a year ago. The problem with relative URLs is that it assumes the structure doesn't change, just as some mods assumed that Sources would always be at $boardurl/Sources, which it isn't. I know at least a dozen sites that do that, and I can well imagine they would want to do the same with plugins.
It's no biggie, but absolute URLs can be a pain when doing getimagesize() on them, so doing, in Wess, a "width(absolute_url)px" call might fail if the server doesn't allow for these... :-/
Other than that, yeah, it makes more sense to test for absolute URLs inside the dynamic function, but the above is the reason why I wanted to explore something else before, ah ah...
-
Just a quick note ...
(http://wedge.org/pub/plugins/7557/something-i-started-working-on/do/dlattach/?attach=3944;image)
Shouldn't those two be labeled row colours instead of column colours?
-
No, the message index has differently coloured columns, not differently coloured rows - just like Curve...