Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Messages - Arantor
3346
Features / Re: New WYSIWYG editor..?
« on May 24th, 2012, 03:25 PM »
We have had this debate before.
There are good reasons to use BBC and not raw HTML, security being the foremost. Yes, I know there are libraries that can help with this but given how many vulnerabilities have been in WordPress due to improper sanitisation, I'm at least wary of doing so.
The second good reason is functionality. Although Nao gave the example of quote, probably a better example of how it's not practical is footnotes. I'd love for someone to tell me how to meaningfully handle footnotes in basic HTML - because it isn't designed for that. BBC can do so.
In fact, if you ever looked at the 'plain HTML' in WordPress, there is a wonderful kludge they've had to implement. There is no tag that meaningfully handles 'more', so they bastardised an HTML comment to make it work - if you look at the source in a WP page that has the more tag, you'll see a variation on:
Code: [Select]
There is a third reason. I've been using computers for years, I remember first coming across WYSIWYG text processors when they were a new thing.[1] And ever since then, I've spent more time screwing around with formatting than I ever did actually writing content, and that holds true even now.
Most of the useful meaningful HTML has meaningful BBC too, but the same doesn't work the other way around. On top of footnotes and quotes, there's also media codes for embedding items, spoilers and it's much easier to create new short codes.
Point of interest, did you know that WordPress can actually support 'short codes' which is actually the same thing as bbcode if you look at it? The way I see, it's actually harder to justify WYSIWYG support than it is to justify going WYSIWYG only, even though we had some strong arguments on it.
Note also that copy/pasting raw content is actually also a bad idea for general forums as it can screw the layout up if not heavily processed, and if you're doing that, you might as well use BBC and be done with it.
There are good reasons to use BBC and not raw HTML, security being the foremost. Yes, I know there are libraries that can help with this but given how many vulnerabilities have been in WordPress due to improper sanitisation, I'm at least wary of doing so.
The second good reason is functionality. Although Nao gave the example of quote, probably a better example of how it's not practical is footnotes. I'd love for someone to tell me how to meaningfully handle footnotes in basic HTML - because it isn't designed for that. BBC can do so.
In fact, if you ever looked at the 'plain HTML' in WordPress, there is a wonderful kludge they've had to implement. There is no tag that meaningfully handles 'more', so they bastardised an HTML comment to make it work - if you look at the source in a WP page that has the more tag, you'll see a variation on:
<!-- more -->There is a third reason. I've been using computers for years, I remember first coming across WYSIWYG text processors when they were a new thing.[1] And ever since then, I've spent more time screwing around with formatting than I ever did actually writing content, and that holds true even now.
Most of the useful meaningful HTML has meaningful BBC too, but the same doesn't work the other way around. On top of footnotes and quotes, there's also media codes for embedding items, spoilers and it's much easier to create new short codes.
Point of interest, did you know that WordPress can actually support 'short codes' which is actually the same thing as bbcode if you look at it? The way I see, it's actually harder to justify WYSIWYG support than it is to justify going WYSIWYG only, even though we had some strong arguments on it.
Note also that copy/pasting raw content is actually also a bad idea for general forums as it can screw the layout up if not heavily processed, and if you're doing that, you might as well use BBC and be done with it.
| 1. | I'm old enough to remember word processors using dot commands for formatting with only basic bold/italics/underline actually being shown on-screen |
3347
Features / Re: Rewriting the skin file parser...
« on May 24th, 2012, 11:31 AM »
mana.css is absolutely fine, and I love the idea of board and category CSS - not quite so keen on m1.css, but I'm sure it'll have use.
I really like the idea of using the replace.css and I can see the benefits of it simplifying add vs replace skins. Would it be faster to drop add/replace skin types and rely on the keyword?
I really like the idea of using the replace.css and I can see the benefits of it simplifying add vs replace skins. Would it be faster to drop add/replace skin types and rely on the keyword?
3348
Off-topic / Re: Same user data in multiple databases.
« on May 23rd, 2012, 10:56 PM »
You might want to read the discussion at sm.org about doing it, that covers most of the issues with doing it.
3349
Features / Re: Rewriting the skin file parser...
« on May 23rd, 2012, 10:27 PM »3350
Off-topic / Re: Same user data in multiple databases.
« on May 23rd, 2012, 10:25 PM »
Just as in SMF, this is incredibly difficult to pull off because of how intermixed data is.
For example, you can't just share the member table because part of that is a link to avatars (which are stored in the attachments table) and also to membergroups (directly in the table, linking to the membergroups table) so you have to split the table up.
It's doable but it isn't going to work too well.
For example, you can't just share the member table because part of that is a link to avatars (which are stored in the attachments table) and also to membergroups (directly in the table, linking to the membergroups table) so you have to split the table up.
It's doable but it isn't going to work too well.
3351
Other software / Re: May I ask a dumb SMF question?
« on May 23rd, 2012, 07:54 PM »
Codeine is like that, heh.
SMF can usually be beaten into submission, it just isn't usually as obvious as perhaps it might be - and this is certainly the case here.
SMF can usually be beaten into submission, it just isn't usually as obvious as perhaps it might be - and this is certainly the case here.
3352
Features / Re: Rewriting the skin file parser...
« on May 23rd, 2012, 07:54 PM »
I guess no-one used Wireless in that time?
3353
Features / Re: New WYSIWYG editor..?
« on May 23rd, 2012, 07:53 PM »
Funny, I was thinking a lot about it.
The biggest battle is not using their user interface and retaining the current code, and I still think we'll have to deal with the HTML-BBC transition that we already have.
It could also be made smaller by using jQuery (since they're not)
The biggest battle is not using their user interface and retaining the current code, and I still think we'll have to deal with the HTML-BBC transition that we already have.
It could also be made smaller by using jQuery (since they're not)
3354
Other software / Re: May I ask a dumb SMF question?
« on May 23rd, 2012, 06:02 PM »
First up, in answer to the title, yes, you can ask a dumb SMF question. We're not really set up to be an SMF support forum, but for something like this we can answer fairly easily.
Well, sort of. There's no good way to do this in SMF but a pair of less optimal methods.
The easiest method is to go into the permissions, turn on post-count based permissions (Admin > Members > Permissions > Settings), then go into the permissions themselves. Set it up so 'Regular Members' do not have the ability to start new topics (but leave all their other permissions alone) then set it up so all the higher post count groups can start new topics.
(The second easiest method is to turn on deny permissions and just deny start-new-topic to the lowest post count group, but that makes other things more complicated.)
Well, sort of. There's no good way to do this in SMF but a pair of less optimal methods.
The easiest method is to go into the permissions, turn on post-count based permissions (Admin > Members > Permissions > Settings), then go into the permissions themselves. Set it up so 'Regular Members' do not have the ability to start new topics (but leave all their other permissions alone) then set it up so all the higher post count groups can start new topics.
(The second easiest method is to turn on deny permissions and just deny start-new-topic to the lowest post count group, but that makes other things more complicated.)
3356
The Pub / Re: Some admin options required
« on May 22nd, 2012, 04:09 AM »
True, you typically won't, but the option's there.
Also note to self: the jumpto calls the core board index code, it would be possible to hook in already through the board index code though I would be inclined to add a flag when coming from the jump-to to indicate that's the case. Or, failing that, a separate hook for jump-to on its own (but I'd still probably include the flag so that if you hijack something into the board index, it won't show up in the jump-to if you don't want it to)
Also note to self: the jumpto calls the core board index code, it would be possible to hook in already through the board index code though I would be inclined to add a flag when coming from the jump-to to indicate that's the case. Or, failing that, a separate hook for jump-to on its own (but I'd still probably include the flag so that if you hijack something into the board index, it won't show up in the jump-to if you don't want it to)
3357
The Pub / Re: Some admin options required
« on May 22nd, 2012, 04:02 AM »
Just to add... the browser has feeds built in but there are a bunch of feeds that the browser may not pick up, like per-topic feeds which IIRC are not indicated by the header.
3358
The Pub / Re: RSS feeds (Was: Some admin options required)
« on May 22nd, 2012, 03:38 AM »
Disabling feeds outright has been an option in SMF for years, and we inherited it. If it's enabled, there's little point disabling it per board (though I've been thinking about hiding it for non-guest boards)
:edit: I split this because I did not want this derailing the specific questions posed, though it is an important point in its own right.
:edit: I split this because I did not want this derailing the specific questions posed, though it is an important point in its own right.
3359
The Pub / Re: Some admin options required
« on May 22nd, 2012, 02:59 AM »
Well, the system does not currently prevent you from doing just that, you're perfectly able to like your own post if you want.
Likes ARE on a per-post basis already, I'm only asking about giving admins the choice to make it per-topic.
As far as the 'thanking' goes, that's not going to be in the core, and that part is not negotiable, having anything over and above the likes will be plugin-material.
Likes ARE on a per-post basis already, I'm only asking about giving admins the choice to make it per-topic.
As far as the 'thanking' goes, that's not going to be in the core, and that part is not negotiable, having anything over and above the likes will be plugin-material.
3360
The Pub / Some admin options required
« on May 22nd, 2012, 01:21 AM »
OK, there's a few things that need discussion since I'm not sure how best to cope with it. Some of it is just a to-do list, some of it needs discussion.
1. Thoughts
There are no configurable permissions for it at present, nor is there any way to disable it. Required permissions: add thought, edit (own/any) thoughts, delete (own/any) thoughts, reply to (own/any) thoughts.
2. Likes
There are no permissions for likes, nor any ability to disable it. I'm thinking that we also want options for whether likes are enabled or disabled, whether people can like their own posts or not and whether likes are only for the first post (i.e. liking the topic) or not.
3. Feeds
There's no way to have feeds active but disable the feed block in the sidebar. Do we need an option for that somewhere?
4. Quick access
There's no option to disable that. I'm thinking it might be a useful option. Also, might be nice to offer a hook for extending it so that plugins can add other areas to it.
1. Thoughts
There are no configurable permissions for it at present, nor is there any way to disable it. Required permissions: add thought, edit (own/any) thoughts, delete (own/any) thoughts, reply to (own/any) thoughts.
2. Likes
There are no permissions for likes, nor any ability to disable it. I'm thinking that we also want options for whether likes are enabled or disabled, whether people can like their own posts or not and whether likes are only for the first post (i.e. liking the topic) or not.
3. Feeds
There's no way to have feeds active but disable the feed block in the sidebar. Do we need an option for that somewhere?
4. Quick access
There's no option to disable that. I'm thinking it might be a useful option. Also, might be nice to offer a hook for extending it so that plugins can add other areas to it.