Wedge

Admin will have the choice (just need to write that), ultimately there are three consequences of changing the agreement, all of which is admin choice:

1. Change it, don't force users to reagree (thus only new users need to, e.g. a non-consequential edit, e.g. spelling, formatting fixes)
2. Change it, force users to reagree but only if they want to post
3. Change it, force users to reagree and don't let them do anything else

...but I just had a wicked idea. And this is like da bomb because it solves an awful lot of headaches very quickly.

For most plugins, they'll have their language files and keep them to themselves like good little plugins. But some plugins are not so well behaved because they'll need to load language files in other contexts. Probably the biggest example is menu items.

Now, I want to have a menu editor function in the core - some day - but the biggest problem is handling language items and doubly so for plugins. How can we have them around and loaded, and still do it efficiently?

And it occurred to me... no, I don't mean reinstating that shitfest Modifications.language.php, that shit can remain dead and buried. No, what I had in mind was far more elegant.

Menu items are needed every page, right? That means, essentially, wherever loadLanguage('index') is called, the menu items are needed. So why not have some facility whereby a plugin's language strings can be injected into the database? Obviously I wouldn't be expecting language files to do their own DB inserts, but I'd probably have a facility in the plugin-info.xml that says to load a given language and append it to an existing set of entries. That way if a plugin wants to add a new menu item, it just has to add its language file correctly, the plugin manager kicks it into the DB, recaches etc. and then it's available without having to load an extra file.

Then the menu editor just becomes some juggling of arrays and cache items, plus any other plugin that wants language strings 'everywhere' can just append them where it needs them if that makes sense.

If it doesn't, just prod me in the morning and I'll see if it still makes sense :D

Maybe. Maybe not. There's no signature, there's an avatar and some other things - these are not things usually added by a would-be spammer.

u mad, bro? :lol:

Yup. There's just too many boards to put into the popup. Hence you'd defer that to a full page.

My concern was actually activating it on mobile. Can you access it on mobile? iOS may prove awkward there ;)

My other objection is a usability one: having stuff hidden away on hover is not entirely usable unless there's a hint to it in some form, like we found with the thoughts menu.I suppose whatever calls it just needs to not invoke the board listing code...That's what I originally implemented as a basic start.Wait.

How many users know that the linktree does that?

textarea takes linebreaks as linebreaks, and the unpreparser converts brs to linebreaks too. There should be no linebreaks in the file.Nah, doesn't bother me. Don't really notice. Mostly related to the exciting and fun custom draggable thing we inherited.If it has a current version, it's different from master ;)Yes, it's the wrong thing to do. Each link is supposed to be one level of hierarchy, not repurposing a link that is already present.English should still be loaded first though... in all cases, even email templates.

Just to clarify, the latest SVN has a popup, which looks like the attached.

I haven't tested on mobile but I can imagine this could cause trouble (since tapping the textbox should give the textbox focus).

I have to admit, I'm not sold on the on-hover aspect from a usability point of view, it's not clear that you have to do it to bring up more complex behaviour, but I could see the advantage if more options were available inline, like XenForo does (though they do it based on focus of the textbox IIRC)

I think I will need to experiment with the search dropdown though, even with this addition.