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..?
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...
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...
The tricky part would be the one for images. One approach would be to let wedge check if the content is the same over ssl as with a plain connection.
Example:
- image over http, but we want https
- get img over http and try to get the image over https. If it's the same, we can just make it to https (or allow both)
- if it's not the same, we can simply make a url out of it and remove the image tag or we can create a thumbnail and link it to the original resource or we can just download the picture and link it to the original resource.
- another approach would be to just make it https. If it can't get viewed, it can't get viewed. People will get that and use image hosters where ssl is supported.
But we should definetly improve the ssl support of wedge, even if it works quite well on my site (with only ssl). SSL and encryption in general isn't a topic with which only criminals have to care about, it affects all internet users nowadays.
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.
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.
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?
Ahah.
I don't know. I'm not used to using a nuclear bomb to break a window.
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...)
A full bbc parser in JS..? But how is it different than using Ajax to parse said bbc?
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...
Actually I really like the thoughts system, it get's used quite a lot on our forum.
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 ;))
But you definetly have to change the skin, the current one doesn't fit at all ^^ Maybe the first dark skin for wedge? :D
A markdown parser? Nice... :)
I'm sure it could be useful.
I also thought of making it possible to use markdown without any special bbcode at all. So you could write your posts in normal markdown syntax plus you have the ability to use bbcodes to do more advanced stuff. Currently you can already use bbcodes inside
[md][/md]
I don't think you have to use the CDATA block around such short code, though!
On mods.xml it works quite well, but not for plugins-info.xml.
Although now I understand your point about leaving BBCode support in the database.
It gives your plugin a good structure which is easily to understand
even for other devs or non-devs. And if you need to do more complex
stuff you can still achieve that with mods.xml or hooks.
'unparsed'? ;)