Wedge

The issue in this bug is that if a page errors for any reason, any attachments made are saved after the initial submission and the details stored in session, but it's not specific - they're just generically in session, because browsers with multiple tabs just weren't around at the time, and as such it was never really so much of a problem.

Whatever fix SMF has, they've separated it out by board, which is workable but still susceptible to two topics in the same board exhibiting the same behaviour.

Possible solutions:
* only accept attachments AJAXively (e.g. to Media and return a media bbcode for it)
* when submitting, create a token for those attachments, and return that token with the form, such that the token has to be returned to get the attachments submitted. (All the other protections about orphaned attachments in session would need to be adapted but this is not a huge task)

In the profile and in the admin areas, the top level menu items are explicitly not clickable, and many, many times I've clicked them by accident and got nowhere >_<

Not sure yet how best to deal with it, though, especially since admin and profile use them in such different ways, but I'm sure we can do something with them.

OK, so I'm fixing up the calendar at last, and there's the grisly assortment of mismatches of variables and things out of scope where they were before in the original code and I forgot to preserve it.

But, interestingly, I got this to happen.

The top template, as you might recognise, is the fatal error template. The theory is that it should normally override everything and anything. But it's called with a simple wetem::load, and as it happens in this case, another wetem::load has already been issued before we get to the actual fatal_lang_error call.

I'm inclined to think that the fatal error should override and remove anything in the default layer rather than the current prepending behaviour.

Thoughts (Nao especially)?

Having now integrated the admin panel stuff for simple cases, I'm inclined to think I should add something similar for the main menu - much as it's already possible to add actions without any hooks being called. The idea isn't to remove those hooks but to take out the most common use cases from being required (to lower the barrier to entry for basic stuff, without compromising more powerful stuff should it be needed)

Main menu tabs are a bit more complex than actions, because they need to cover things like permissions, so here's what I'm thinking. There would be a single cache of all the items, which is a nicely serialized array.

The XML would look like:


This would create a new menu item, which would be highlighted on action=myplugin (due to the name), would use $txt['my_plugin'] as its caption (loaded from the plugin's MyPlugin.language.php file, and cached!), would have myicon.png as its icon, would only be visible if the user had some_perm permission, and when clicked would go to the given URL. Same deal for sub items.

As far as the caching goes, all that information would be cached, as well as - and this is the important part - when we created the cache and added an item, we'd also make sure to load all the different installed languages' files, to grab the entry/ies that we needed, and we'd cache them all in the menu. Since it's done at enable-plugin time, it should be relatively cheap to do.

The only problem I can imagine with that setup is that we might end up overflowing the serialize field if there's a lot of languages and a lot of menu entries added. Maybe this is a candidate for json_encode instead.

Also note we would definitely need to change the menu styling code as discussed before to create a single base class for each of the menu icons, such that each icon held to the same styling as far as padding etc. goes (and then this only has to worry about adding the icon itself, rather than having to worry about trying to add all the extra style code like padding)

Thoughts? (This one's primarily for plugin authors, though I'd appreciate your comments, Nao)

2 hours work, and I'm almost done (one random quirky bug and I need to test it on a real server that can email but otherwise I'm done)

Another one for the list :)

I probably could make it a little nicer in places, but I wanted to get the core functionality done.

It occurs to me that we could do something quite interesting with this - how about, if the same post gets reported more than (say) 3 times, it automatically get moderated causing it to require something more serious to be done with it?

It would of course be admin configurable ;)

Thoughts?

Had a random idea about this today. The plugin info file already lists all the $settings variables that a plugin uses (so that it can set defaults and clean up properly later) but I've been thinking about the interface side of things.

Right now, if a plugin wants to add a settings page, even a simple one, it's going to have to create a file, use at least two hooks[1] and create a stub file that is almost entirely identical from plugin to plugin. Heck, when I start a plugin now that uses a simple settings page, I just copy everything from an earlier one.

So, here's what I'm thinking. Everything that you would normally have to set up for a settings page ($config_vars etc.) can be streamlined. Of course, more complex plugins (of the likes of WedgeDesk) would still do their own thing, but the smaller stuff could be simplified.

For example, I have a stub plugin that will grow into a big scary share-topics-with-services monster, dubbed Flitter because it was originally just Facebook + Twitter. Right now, it's very straightforward however, with its settings page being:


Then you have a function which binds to the admin menu, and the rest of the boilerplate in this function that's used for saving and calling the relevant templates and stuff. It gets set up as action=admin;area=flitter and uses 'Flitter' as the title (which is the plugin's title anyway)

I'm thinking we could handle this in the plugin-info.xml file directly instead.


Assuming the plugin author uses this, it should be able to handle the menu item, the settings themselves, making them searchable and auto-linking it in the plugins area (minimising the need for using the <acp-url> element though not obsoleting it)

The area= part specifies what admin area it should be, the icon is the icon for the dropdown menu, the bigicon is the big icon to use, <load-language> identifies what language file(s) should be loaded when running the page, so that the relevant strings can be loaded. Everything else just correlates to the above.

Personally, I think it's less effort for the plugin developer generally, it's less they have to deal with - you don't expressly have to deal with hooks when doing this and you're still doing less work than you would doing it manually.

Thoughts?

1.	Three if you want to make it searchable as well, yup, even that isn't automated.