This feature is actually quite a good `workaround` for the missing 'partly quote a message thing by marking a parts of a post' i want to implement.
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
I think i get your point, there's a newline in between the quote tag and the next part of the post. It's more like a bug isn't it? Even if it's not very problematic, but still annoying.
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..?
Actually my implementation is quite powerful as you have 3 collumns for the process stuff. I prefer it that way because it gives you the maximum of control over this feature. But I agree, as soon as something's not really needed, we should strip it out. For example you could also reuse bbc validation functions from the core. It's not something which will get used very often, but i like to have the possibility. I don't like it to have a feature like this which is very restricted. It should let people do as much as possible.
Ah, yes indeed. It's just that I like simplifying the database as much as possible, like removing extra tables...
It's not a limitation of xml, for sure you can have php code in your xml file (if that's what you mean by 'xml file can also contain function declarations') but if you want to parse bbc, you have to go through all plugin-info.xml files and get the things you need for bbc parsing. Don't think that this is any better than loading the preprocessed bbcodes from the database. By preprocessed I mean checking if the bbcode is correct can get applied.
Are you positive about that?
After all, an XML file can also contain function declarations...
Yup that's the big problem with the mixed content stuff and https. On our site we completely switched to https, no plain http anymore. I already thought about the problem of external content. It's actually only images which make problems. Because of Aeva we could quite easily check if the content (videos/media) can be safely (without mixed content) get displayed. We know the providers and we can know if they support ssl or not.
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.
- 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.
I don't know sm.org, guess you mean the smf homepage? The editor itself isn't bad in my opinion, but many things don't work very well. For example inserting urls or images is just a pain in the ass with those weird js alert boxes. You can't click them away and it just doesn't make fun. Besides that, no need for email and ftp buttons anymore. Also we should make this thing easy to extend with own buttons. I want to have a button for markdown/hide bbc. Have to look into that as soon as I'm done with the bbc parsing stuff.
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.
Do you mean that people can reply to a post? A bit like how comments work on youtube? The problem with this is that it get's confusing very fast. I saw it on another forum where you could switch between the "thread display modes". But I didn't really like it. It has to be implemented very well and smart.
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.
This is a very well fitting answer, i really liked the 'enlightened amateurs' even if i can't say to much about anyone else besides myself. But I think this amateurs thing is a bit of legacy of smf and many open source projects. It's fine as long as it doesn't get too complex or security critical. But I'm sure we are hard working to improve our 'amateurs' title :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.
php-cgi is the php server. Nginx just redirects all 'php' requests to php-cgi. I'm not too sure about the htacess stuff, have to look at it.
Nginx is the php server too? Did you convert your htaccess to use Nginx too?
We also don't need to. Most of those features aren't something we need for wedge. Would also break compatibility to old browsers which is one of the things wedge cares about.
I don't know. I'm not used to using a nuclear bomb to break a window.
I will look into that, in general the idea isn't too bad, worked with some javadoc and jsdoc things but they often have a very strict syntax which was not very nice for callbacks. Maybe they are better for php.
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...)
I thought wedge already implemented something like this. Ajax means a lot of traffic if you send over the complete post. Everything else gets complicated (like only sending what changes). I don't know how wedge does it currently, besides the preview thing (this is totally fine to send the complete message, but for 'real time wysiswyg' editing it's not the best solution?! Github also has a markdown parser in js which makes it quite handy to edit stuff in the browser).
A full bbc parser in JS..? But how is it different than using Ajax to parse said bbc?
Definetly something which would make wedge a lot nicer. The thing is, do we want a real time chat or a messaging system with a chat like feeling? It's a bit the same with thoughts. For sure you get notified if someone replies to your thought, but they don't get refreshed automatically. It's a bit the difference between a shoutbox and those thoughts.
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.
I have a steam account, somewhere... played a bit dota 2 and cs:go when they got freshly ported to linux. But not really into gaming anymore. But for sure i will have a look into your project. My brother is really into gaming and steam, definetly a market. Those weapon skins and stuff, it's just crazy how much money you can spend on that.
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
I'm sure this could be useful. For example reusing the README.md of your plugin. This already works quite well.
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
I tried it without, but simplexml complained about that. Plugin couldn't get loaded and so on.
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.
I really love the ability of defining stuff like this in the plugin-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.
With 'unparsed' i'm not able to use bbcodes inside [md] tags anymore, which I like.