Nope, everything is in Subs-BBC.php. This Shift-Enter thing is nice, you should tell more people about that :D
I know right... Well, when I introduced it, it was pretty popular in Wedge. I was even a bit scared that the feature would end up in SMF... Yeah, I guess I overestimated them. :P
One of the downsides with the auto-splitter, is that if there's a newline after the point where you're splitting, Wedge won't notice it, and will insert an opening quote tag, then that newline, then the original text. It looks ugly. I've gotten used to just editing those out, but honestly it'd be best to add some code at the beginning of splitQuote() to look for space/newline characters immediately before and after the split point, select them together, and remove them, then adjust the starting position. THEN it'd be the perfect splitter. Or maybe you have a simpler idea..?
There wouldn't be a need for it, but I would keep the database stuff. I like it that you can add bbcodes over plugin-info.xml.
Ah, yes indeed. It's just that I like simplifying the database as much as possible, like removing extra tables...
Are you positive about that?
After all, an XML file can also contain function declarations...
If you still know what's the difference between the 'unparsed_equals', 'unparsed_commas', 'unparsed_commas_content', 'unparsed_equals_content', 'parsed_equals' bbc types this would be very helpful :D
Well, I could explain it, but I won't bother, as the SMF documentation (I think?) did it well... But Pete removed it in his commit to move BBCode to the database (December 3, 2010 -- quite soon after we started work on Wedge.)
(edit: removed block, since you've already seen it.)
Unparsed content just means that the contents won't be parsed by parse_bbc(), like in... Well, the code tag?
IIRC, one of the things I added to the system is the ability to have multiple (optional) parameters.
Oh gee, looks like you found it by yourself. Sorry for wasting your time (and mine!) ;)
Well it's supported already, it's just not the 'default'.
The reason why it's not default is that Wedge uses http-based avatars, which means browsers showing an HTTPS page will consider it 'insecure' because there's an HTTP-based image embedded in the HTML.
The solution, of course, is to 'simply' fix all local avatar links to the correct protocol, but Wedge stores the URL in multiple places, so that's a bit annoying, unless we change it directly in the database, but that means if you switch back to HTTP (e.g. expired certificate), you're likely to get empty images (expired cert + image link = no image at all, because the browser won't trust it until it's approved manually, and since it won't show a popup for a simple image, you're screwed.)
Also, doesn't help with external avatars. There's no way to know if they're compatible with HTTPS.
And I'm pretty sure HTTPS fans would want that address bar icon to be green, not gray...
Yup, remove it and only let the preview thing there. Maybe split the editor in two tabs, one for modifying and one for preview. Like the github editor.
Yeah, I wouldn't know about removing it... But it's certainly worth posting a poll. Only, on this site, we wouldn't be getting many answers... Probably likelier to get proper answers at sm.org, of course, but I stopped going there years ago.
I will give it a try, people who quote a lot will use it. I just like quotes for off topic or threads with many questions/answers. Like this one :D
But you're talking about preventing people to quote parts of your message, no?
Maybe there's a misunderstanding.
Were you instead talking about a multi-quote feature? Like the one that's been in Invision Power Board literally since forever..?
That would also imply that topics ARE flat. My own 'implementation' of the thing is the soft-merging of posts, so that multiple answers don't take more space, and yet if you click Quote on a post, your reply is automatically threaded below that post, even if it doesn't show on the default flat skins.
ElkArte looks like a good SMF fork. But I prefer the look and feel of wedge. They seem to have a nice codebase. Tests and stuff :D
Yeah, I'd tend to say Elk is made by hardened professionals, and Wedge by enlightened amateurs.
The fact that they've been at work on it for the last 5 years is impressive, too. When they started, I doubted they'd 'last' for 5 years. In the end I worked fulltime on Wedge for 5 years, and they did too.
Personally though, I'd hate being restricted by test suites when it comes to adding new features. These aren't even a guarantee your feature will work in every situation. I prefer to rely on beta testers.
Nginx is the php server too? Did you convert your htaccess to use Nginx too?
They are, but as soon as we use JS, we could use all the JS features, even the new fancy ones. For a chat system for example :D
I don't know. I'm not used to using a nuclear bomb to break a window.
Maybe something like js-doc for php would already be enough with generated html docs. Many functions and classes are documented inside the code.
Yeah. There's 'something' called phpdoc, I think.
Actually, that was the idea behind the comment refactoring that Pete did for a while. He wanted to use a tool to later automatize the extraction of function descriptions. I wasn't comfortable with that tool, so I just left him to his devices, unfortunately he never finished it. But he did a good job at what he did. (Basically, he commented most of what matters...)
Maybe this would be an idea. For real WYSIWYG wedge would need a full bbc parser in js... Or a basic bbc parser which lets the server render the html if it's a more complex bbcode.
A full bbc parser in JS..? But how is it different than using Ajax to parse said bbc?
I don't really have an idea, but definetly something more like a chat, even if it's pseudo and without ajax features.
But would be a neat thing. Maybe we can just reuse the database structure.
Yeah, I looked into it, and:
- there are a few columns that'd be useless, like the subject one. Not a big problem.
- PMs don't have a recipient ID assigned to them, instead it's done through an extra table that can hold multiple people as recipients. While it's a good idea to make it more flexible, it also makes it harder to sort PMs by conversation. How do we 'recognize' that a specific conversation should be treated separately? Maybe by having some sort of id_conversation toggle, I don't know. It's a possibility, just makes it harder. Then again, a multi-user chat message, aka a chat room, sounds good to me...
This is definitely the next refactoring work I'll be doing, as soon as I'm done with the new site (Lestrade's
, if you're curious! Although, if you dont have a Steam account, it'll be quite useless to you ;)