Wedge

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

There is, in the depths of the permissions code a function to set which permissions should not ever be shown to guests.

But it does not honour own/any properly - so even when an _any permission is listed to be denied to guests, it still shows up in the admin panel, for example view_ip_address_any is in the deny-to-guests list but still shows in the guests permissions area.

I cannot confirm whether this is an SMF bug or not, all the cases in SMF itself only ever extend _own permissions to be denied to guests (because they can't have an _own)

But it needs fixing.

(Also, permissions + hooking are sort of borked, I really need to extend it in the plugin-info.xml file to fix other issues related to it but that's something else entirely.)

See, there's a problem right there - there is absolutely no need to store all the standard stuff in the DB - people do not modify everything.

I was gobsmacked when I looked through the installer for XenForo and noted hundreds of KBs of stuff dumped into the DB, IMO unnecessarily. I understand why, but that doesn't mean I have to like it.

Doing it this way does give the compromise of ease of access, the security upside and whatnot.

Well, I know other systems dump everything into the DB, but I'd rather avoid that if possible.

You all know my feelings on editing files, and currently the language editor does just that - even for plugins (eek), and right now it's broken. So it needs an overhaul.

So here's what I was thinking. How about, we store the changed strings in the database and load them when necessary? That sounds awful, but let me temper it with this which only occurred to me today.

We know what files contain what strings, and we know what file is being edited at any one time. So if we keep a record of what strings have been modified in the DB versus the original files, we can add a check to loadLanguage to say 'look, we've asked for <language file x>, has there been any changes to that file?' then load any changes to it after the fact, as it were.

All we then need is a DB table containing language, file, optional plugin ID, and the new string and we're golden. Plus if a given file hasn't been updated, no harm, no foul (and no extra query)

This way we get to allow language strings to be edited (cleanly), without any file edits (which is also a security improvement). I'd also move the registration agreement into the language files too and have them all supported in one clean place.

Thoughts?

I changed the line referenced in the original topic, i.e. the reported bug.

Also, I thought it should be moved seeing how the only bug mentioned was fixed...

The other changes were necessary for quick moderation...

It's not about not liking Batman,[1] it's just that what has been seen, cannot be unseen. ;)

I like them all.

1.	BECAUSE I'M BATMAN.