Wedge

I don't know how to handle them yet.

Doing it how SMF does it, though, is a no-go, because their editor accepts the smiley but on conversion, converts it to a generic img tag. This has other consequences, not just the obvious one about taking more processor time to process, like users who have different smiley sets to the forum default.

Because they're already HTML.

Posts with bbcode likely cannot translate back and forth cleanly. E.g. Footnotes cannot be converted to/from HTML in any meaningful fashion.

Well, I could have it remember the port and username (as SMF can do) and you just type in the password.

Revision: 1059
Author: arantor
Date: 16:34:18, 05 October 2011
Message:
! Don't include 'desc' type entries in the admin search, they're often not that relevant. (Admin.php)
! Move 'do admins have to approve account deletions' to the Members > Options area. (ManageMemberOptions.php, ManageSettings.php)
! Move 'require users to revalidate email on change' to Registration and split the registration options into two panes. (ManageRegistration.php, ManageSettings.php, ManageSettings language file)
! Remove the now-empty Security and Moderation > General page (Admin.php, ManageSettings.php, Admin language file)
----
Modified : /trunk/Sources/Admin.php
Modified : /trunk/Sources/ManageMemberOptions.php
Modified : /trunk/Sources/ManageRegistration.php
Modified : /trunk/Sources/ManageSettings.php
Modified : /trunk/Themes/default/languages/Admin.english.php
Modified : /trunk/Themes/default/languages/Admin.french.php
Modified : /trunk/Themes/default/languages/ManageSettings.english.php

I just decided, when it comes to Wedge and support, I'm going to be mean. Hate me if you want!

Here's what I'm going to do. Whenever anyone asks me where a setting is, I'm going to tell them to:Seriously, I'm going to do that - and make sure I have a bookmarklet or similar for it - simply because I want to emphasise that there is, in fact, a search facility for the admin panel...

:niark:

I'm curious to know what people think of this, because I have the feeling that I'm going to be seen as snobby for the approach I'm about to implement - if only because I value putting security and not-breaking-things above convenience.

We all know that file permissions on Unixish type systems can be problematic, and none more so than leaving things at 777, because on shared servers it's a pain, and on systems with suExec in place, it will actually cause system failure.

Now, because of my design structure, moving as much as possible outside of the standard tree, there's only a single place that requires permissions to be set in such a way as to allow for file changes (for the vast bulk of the time, and for the time file edits are actually needed, well, the same framework will be able to change them)

Here's the thing: I'm not planning on doing what SMF does, which is allow you to make all the folders and files writeable from Admin > Packages > File Permissions. I consider that quite dangerous, and have done for some time.

What I'm planning is that if the files are already writeable, for whatever reason, it'll just do what it has to do. (That means if you're crazy, or brave, or have suitable configuration, you can just get on with it. It also means that if you do change it, you're doing it manually, and all bets are off, we can't support you particularly effectively if you break it.)

When things aren't writeable, it'll prompt you for FTP (and hopefully, the option for SFTP details instead if possible) details, make the necessary changes, and here's the clever bit: it'll put them back again.

That means you're exposed to elevated permissions for a short period of time, rather than generically, and it should mean that even if files/folders are made 666/777 for writing purposes, that change is undone afterwards so things don't die in the suExec case.

The caveat is that you'll have to enter your FTP(/SFTP) details every time you add a plugin (or anything else), but frankly that seems preferable to me than making it possible to 'brick' it on a very typical setup and have to fix it through FTP afterwards.


Is that an acceptable compromise for users, or would it be better to allow the current state of play? (Remember: if your configuration allows the PHP script to alter files naturally, e.g. on some Windows configurations, or everything's uploaded as the Apache user, or everything's at 666/777 anyway, you won't be prompted - but it's then on your own head anyway.)

OK, back over this topic.

WYSIWYG has a place. Me personally, I'd never use it, I find the entire idea so imprecise it's unreal (and please don't tell me time's an issue, I make quite literally hundreds of forum posts some days.)

And SMF does have a WYSIWYG editor. Now, if SMF's editor were replaced with another editor, that'd be a different story entirely, because it would have the security issues as mentioned but also the improved functionality of a WYSIWYG editor that wasn't retarded.

Here's an interesting point: we actually discussed a bit back about ditching bbcode and using purely WYSIWYG instead. That's almost more practical than you'd imagine in a lot of ways, it would save a great deal of trouble in terms of processing for a lot of posts, the only real objection I raised wasn't even the implementation of security, or the increased bandwidth use - no, the only objection I raised was in fact concerning usability.

One of the perks of bbcode is that you can introduce quick codes for all kinds of things. Representing a spoiler, or a footnote, in HTML is frustrating if done in a WYSIWYG fashion. However, most users that use WYSIWYG will not use these features.

So, perhaps, there's room for an alternative. For posts made with the WYSIWYG editor, save them with a flag to indicate they came from WYSIWYG. For all other posts, flag them as using bbcode, and render appropriately from the database.[1]

You'd have to be careful about switching between the two, since you would want to do that from time to time, but no more so than is currently being used.

1.	Security's not a concern in any practical fashion. If access is granted to be able to manually override this parameter, it's also going to be able to manipulate the raw data anyway so that raw HTML could be injected, negating the pre-parser sanitisation rules that are currently in place.