Wedge

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.Bug.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.

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.

(2 files, 1KB)

Revision: 49
Author: arantor
Date: 21 September 2012 03:04:27
Message:
! [Topic Solved] Debugged quick moderation, it does actually function. Permissions have not been tested. (plugin-info.xml, TopicSolved-QuickMod.php)
----
Modified : /topic_solved/plugin-info.xml
Modified : /topic_solved/src/TopicSolved-QuickMod.php

It's running here... But there's other ways to get involved, like participating in any of the many discussions about how things should work.

(19 files - includes folders apparently, 49KB)

Revision: 48
Author: arantor
Date: 19 September 2012 14:31:25
Message:
! [Topic Solved] Initial checkin. Quick mod doesn't work at the present time but I'm fed up of it right now.
----
Added : /topic_solved
Added : /topic_solved/img
Added : /topic_solved/img/cross-button.png
Added : /topic_solved/img/tick-button.png
Added : /topic_solved/img/tick.png
Added : /topic_solved/img/tick_big.png
Added : /topic_solved/lang
Added : /topic_solved/lang/TopicSolved-Admin.english.php
Added : /topic_solved/lang/TopicSolved-Display.english.php
Added : /topic_solved/lang/TopicSolved-MessageIndex.english.php
Added : /topic_solved/plugin-info.xml
Added : /topic_solved/readme
Added : /topic_solved/readme/readme.english.txt
Added : /topic_solved/src
Added : /topic_solved/src/TopicSolved-Action.php
Added : /topic_solved/src/TopicSolved-Display.php
Added : /topic_solved/src/TopicSolved-MessageIndex.php
Added : /topic_solved/src/TopicSolved-Permissions.php
Added : /topic_solved/src/TopicSolved-QuickMod.php

(The readme is pretty much just a placeholder too, will likely extend that at some time)

(4 files, 9KB)

Revision: 1695
Author: arantor
Date: 19 September 2012 03:47:02
Message:
! Added permissions management directly from the plugin files. (plugin-info.rng, ManagePermissions.php, ManagePlugins.php, Reports.php)
----
Modified : /trunk/Sources/ManagePermissions.php
Modified : /trunk/Sources/ManagePlugins.php
Modified : /trunk/Sources/Reports.php
Modified : /trunk/other/plugin-info.rng

I mentioned yesterday that I would have to look at this, and well, here we are.

This is, interestingly, absolutely required in the long term, so I might as well do it now.

Problem 1: unless permissions are declared in the plugin-info.xml file, there's no way for the system to automate cleanup when removing a plugin. This would be more of a problem if it weren't for problem 2.

Problem 2: even if you declare permissions in your plugin's settings page (using the permissions option or similar), there is a possibility that the main manage-permissions code can remove them again because they're not part of the main permissions code as well.

Consequently, we actually have to declare permissions and add them to the main permissions area, even if you keep all the settings in the plugins area like I've been doing. It sucks, but given the rest of the architecture that's actually the best way to go forward.

What it does mean is that you do need to actively declare your permissions, regardless of anything else. And if you really want to do complex stuff, you can still use the hooks that are there, but you must ALWAYS declare permissions in the plugin-info.xml file.

Even if you're doing byzantine stuff like declaring permissions guests can't have, which isn't in the plugin-info.xml file but only accessible via the hook to keep the structure lean, you still have to put the bulk of permissions stuff in plugin-info.xml.

Here's what the structure will look like - simplest case, like I've added for topic solved.


Anyone who's added SMF permissions should recognise all the components of that ;) In case people haven't... let me break it down.

<newperms> is the overall container. If that block isn't found, there's no permission processing to do. If it is, there should be a filename entry, which should cover the language file which contains all the strings for that plugin's permissions.

<permissionlist> is the container for all the permissions. There is another container I'll get onto in a moment.

<permission> declares a new permission. Type is membergroup or board, for whichever it is, name is the core permission name. ownany declares whether it is an own/any permission or not, and if it isn't, the name will be the actual name for allowedTo() tests. Otherwise it'll be the permission + _own and _any, just like in SMF.

classic indicates which group it will be added to in Classic View, simple for Simple View, just like in SMF. I may yet rip this stuff out, don't know yet.

If you need to add a whole new group of permissions, you can do so by also adding the groups container.

For example, if I had wanted to make a new section for Topic Solved entirely, I could have done so with:


All the $txt requirements (i.e. what all these should be named) is entirely unchanged from what it is in SMF.

This looks cumbersome but it actually is no more than you'd have written making permissions in SMF (and this is simpler in practice, you just declare it and it works)

You know me by now, I do not give that much credence in how other things do it. I care about how I think it should be done in Wedge. You're conflating two separate use cases under one umbrella, which as I already alluded to is not how it should be. Let's clear that up right now.

Use case 1: Translators
In the *short term*, translators have to copy files and edit them directly. Putting the bulk of stuff in the database makes it harder for them to translate, unless we build a complete translation interface directly into Wedge, which is a very large waste of time by making something that ends up with every user when only a fraction of a percent of users will use it.

In the *long term* we end up with something like sm.org has, a translation facility. It's a facility that tracks all the languages, all the changes and allows for building translation packages, much like SMF's language packs. This doesn't require any file editing, it's all a web based interface.

User friendliness is not really a concern in these cases because of the very small number of people that will have to deal with these things.


User case 2: Users wanting to customise their setup
This is the only scenario I give a damn about in the core package itself, because this would be useful to potentially any site owner who wants to customise their site. There is already a foundation of one of these in SMF and Wedge (see Admin > Languages, you can select a language then edit its files there)

I want to be able to give people the ability to edit the language files directly from the ACP, without them having to go into code or manually edit files, or to have to open the permissions up. Doing so as suggested would allow people to edit things from the ACP, without any of these other issues - and it could be made to be more friendly than what is presented available right now. I mean, it would be huge if people even knew it was there...That's even less user friendly, in fact, and I'm well aware that other systems do this and it is one reason I've avoided them.

I gotta do other things with the permissions stuff anyway, and last night I wrote up how I want to extend the permissions code from plugin-info.xml files, so I can probably fix this along the way.