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..?

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.

Ah, yes indeed. It's just that I like simplifying the database as much as possible, like removing extra tables...

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.

Are you positive about that?After all, an XML file can also contain function declarations...

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.

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 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.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.

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.

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.

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.

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.

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. 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 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.

A full bbc parser in JS..? But how is it different than using Ajax to parse said bbc?

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).

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...

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.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 ;))

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.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.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

Although now I understand your point about leaving BBCode support in the database.

I really love the ability of defining stuff like this in the plugin-info.xml. 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 complexstuff you can still achieve that with mods.xml or hooks.

Still working on this, we are now producing notices if a bbcode can't get applied. I don't know exactly why we just skip the bbcode in the moment (so if a bbcode has an invalid type or anything the plugin still gets activated, even if it won't work how it should) but yeah. Now we at least know why our bbcode didn't show up in the database (and therefore doesn't work). The Notices aren't very nice and hardcoded in english, but i guess they are still more helpful then nothing.

I'm still workin on the process functions. I don't like how they work in the moment. bbc_process_any_tag() functions get called with 4 arguments. The first one is $tag which simply holds basic information about the tag in an associative array. For exmaple tag, len etc. All the stuff which is defined in the bbcode table (or hardcoded in the Subs-BBC file). The second tag is $data which holds different things depending on the type. For the type 'parsed' it holds anything between the opening and the closing tag. For unparsed_content it's the same. But for example for the type 'unparsed_commas' and some tag like this [md=test,a,3] we get an array containing ['test', 'a', '3']. What's weird is that there is also a fourth variable defined named $params which should hold this type of information in my opionion (it didn't get passed to the function in wedge, but in smf so i simply added it again).Or for 'unparsed_equals_content' we get an array with two elements. The first one is the content, the second one the equals parameter. I want to make this more general. Benefits would be, that we don't have different variable content for different types. We maybe could do the old validate functions more general so that we can decide on the different bbctype of the tag how we behave. This would result in less and more intuitive/clean code.

EDIT: New syntax will be bbc_foo_bar(&$tag, &$content, &$disabled, &$params). If the type does not support paramaters, params will be null. If the type is closed, $content will be an empty string. I'm not sure how i will do the content stuff, because depending on the type you can modify the content by modifying $content or $tag['content']. Maybe always doing it over $tag['content'] is the more clean approach.

EDIT2: Outlined all the process functions to only have one function for all same tags. Less (duplex) code and more clean.

EDIT3: One problem more. It's possible to have those [tag=abc,def] params, and to have [ŧag alt="xyz" foo="bar"]. Maybe even both. I want to have that all in $params, have to think of a good way to do that.

EDIT4: All [tag=foo,bar] params will be inside $params['indexed'], all [tag foo=bar bar=foo] will be in $params['associative']. It should be possible to have both. It's currently not used anywhere, but I'm sure this is a thing someone could need at someday. I even think of doing something with it just because it's a nice thing :D

I'm quite happy now with the changes, at least with the currently implemented parse_bbc() function. We should totally refactor or maybe better rewrite that function at one day. I will go through the changes again and maybe change some small stuff. But in total this is how i would do it. @Nao i hope you find a spare minute to go through the changes?Things about which im not sure:- the notices in ManagePlugins.php- it's totally possible that some bbcodes won't work as expected, even if i tested the most common ones.- we should maybe kick out some unimportant bbcodes, like this ftp tag...PR: https://github.com/Wedge/wedge/pull/54

I will continue this monologue ^^First, there are still bugs on this implementation, i'm fixingthem as soon as find them and as soon as i find time tofix them. Maybe I will update my site to use this branch thisweek and see how well it works.Also I figured out that it's quite easy to have backwards compatibilityfor the process/validate-func to old wedge versions, just because theold version would ignore the process part, and the "new" ones validate-func.For sure all the adjustments to give you more control about the bbcodes wouldnot work on old versions, so you also couldn't use all bbctypes.

Besides that I also have to revert some things I said in this topic.When I said "I think php is dying" I maybe was verywrong. I actually lost track on what's going on in the php world andthere is still a lot going on. Played around with tools like phpunit, composerand php_codeSniffer. Nice tools, maybe hard to apply to wedge and notreally useful because it would need refactoring a lot of code (and changingthe workflow). But for other projects (and maybe bigger plugins) this is definetlyworth a look.

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.

Yes. It's not really a bug, it's "as expected" given what the code does, it's up to me (or another dev) to simply add more code to simply remove any extra newlines that come after. I think what I/we should do is, when we determine the point at which the split needs to be done, select anything before and after that point that's either a space, a tab or a newline (basically an \s), and delete it (there's a function to select a zone of text, then we can delete it.)

Quote

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.

Yeah, it's not like we can magically strip Wedge down to 2000 lines of code, but for maintainability it's always best to simplify complex code where possible.

Quote

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')

Yes that's what I mean, and yes I remember adding support for that, I'm pretty sure at least... ^^Or maybe it was in skin.xml... Hmm.

Quote

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.

Same with lestrades.com ;)This avatar problem is really annoying, though.

Quote

I already thought about the problem of external content. It's actually only images which make problems.

There's an option to retrieve external avatars locally but meh...

Quote

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.

Unrealistic.^^In these situations, it's acceptable to have the green icon disappear. It's not exactly the Grail of SSL-enabled websites. It's just good to have on non-user-generated-content pages. So my main concern is with that frigging avatar showing up on every page. Then again, it's just for members!

Oh, speaking about security... I noticed one of your commits has a comment that explains you don't know about the noopener security problem, but that you'll leave it in. Well, first of all you could have just asked me, since I added that feature last month... Second of all, I'd understand that you document that in the git log, but... Why in the file comments, man?? Why...? :-/

Quote

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'm kewl with SSL. One of the things I enjoy about Lestrade's is that I get to touch areas that I never had the opportunity to deal with before. SSL and Nginx are interesting. (Not ENJOYABLE interesting, but interesting nonetheless.)

Quote

I don't know sm.org, guess you mean the smf homepage?

Yes, simplemachines.org.

Quote

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.

That's absolutely right. I don't know why I didn't just remove them myself all these years ago.Even the "Ordered list" thing to me is something that takes space for nothing... I'll keep it, but MEH. FTP and email, yeah, they can go.

Quote

Do you mean that people can reply to a post? A bit like how comments work on youtube?

Hmm yeah, but it's not the best example... ^^Threading has always been a stable of sites like slashdot or reddit. Or the Disqus comment system, for instance.Wedge does threading internally-- it just doesn't show it.

Quote

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.

Yes.But honestly, I don't see any 'smart' way of doing it, besides showing it threaded by 'default', and flat when viewing 'New' posts (e.g. the New icon.)

Quote

But I think this amateurs thing is a bit of legacy of smf and many open source projects.

I'd say SMF always wanted to see itself as a professional bunch. Which is why they're so freaking slow in adding new features... They tend to look severely at people who add new features without polling the team at least 27 times and sending 42 test suites.Seriously, what I added to SMF back in 2010 in the few months I worked as developer was more than everyone else together did for the following years... (I haven't checked in recent years, but I doubt they changed much either.)I'm not boasting, I'm just saying that they don't have the same way of doing things. Which is why SMF is so much behind. Even Pete couldn't save it with his SMF 3 project. (I think that was abandoned too...?)

Quote

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.

Yeah, so, there are two ways of handling PHP and Nginx, AFAIK:- Nginx as reverse proxy and Apache behind. Nginx redirects all php requests to Apache, which itself calls PHP through FCGI or mod_php, whatever. This way, htaccess is taken into account.- Nginx as both reverse proxy (or not) and server with PHP support (FastCGI or PHP-FPM). Nginx redirects all php requests to the CGI process. htaccess isn't support. And PHP isn't faster either.Which is why most servers adopt the former solution, of course.

Quote

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.

Oh and I just removed a thing for IE6/7... ;)This is becoming less and less of a problem. IE8-11 and Edge still have some market shares, but 6-7 are comparatively negligible.If I had more time, I'd completely remove support for both of those. You have no idea how much simpler the codebase would be in all CSS handling areas... ^^

Quote

I thought wedge already implemented something like this.

Not really, no.I suppose it's feasable, though, with the caching system in Wedge (while in SMF it would be completely impossible, I think even Elk couldn't do it, without resorting to hacks.) Just generate the JS file 'automatically' from the data available in files and the database.

Quote

Ajax means a lot of traffic if you send over the complete post.

Yeah... Not that much, really. ^^

Quote

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?

The latter for now. Let's not get ahead of ourselves... ;)Real-time chat can always be added through a plugin.

Quote

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.

Yes.I just never saw any real traction for thoughts. I'm pretty much the only one to use them. And no one asked for a refresh, so... Here you go. There's a refresh for notifications is all.

Quote

Actually I really like the thoughts system, it get's used quite a lot on our forum.

LT has been online for a week and no one used it, not even once. I ended up disabling it... My lone message was just too lonely. ^^

Quote

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.

Yeah I don't understand the appeal of CS:GO related stuff.. ^^ I prefer regular good old single-player games. LT is mostly about retrading duplicate game keys you acquire when you're a regular customers of bundle sites like humblebundle.com, indiegala.com, bundlestars.com and groupees.com (basically the top 4 bundle websites). And they often re-bundle games offered by other sites months prior. So you ALWAYS end up with duplicate keys. I only recently opened an account for my kid, where I can now redeem many of these duplicates... But before that, since I don't like waste, I used barter.vg to retrade my keys for other games.

Quote

But you definetly have to change the skin, the current one doesn't fit at all ^^ Maybe the first dark skin for wedge? :D

Well, err... I think it's very fitting..?!I tried to stay close to barter.vg in spirit.

Yes. It's not really a bug, it's "as expected" given what the code does, it's up to me (or another dev) to simply add more code to simply remove any extra newlines that come after. I think what I/we should do is, when we determine the point at which the split needs to be done, select anything before and after that point that's either a space, a tab or a newline (basically an \s), and delete it (there's a function to select a zone of text, then we can delete it.)

Yes that's what I mean, and yes I remember adding support for that, I'm pretty sure at least... ^^Or maybe it was in skin.xml... Hmm.

Not sure about skin.xml but mods.xml works very well. But who cares, in my opinion there should be no php code in plugin-info.xml. It's already a bit of a hassle to take care of the right identation in mods.xml. I like it when the cached file in /gz/ looks clean ^^

Unrealistic.^^In these situations, it's acceptable to have the green icon disappear. It's not exactly the Grail of SSL-enabled websites. It's just good to have on non-user-generated-content pages. So my main concern is with that frigging avatar showing up on every page. Then again, it's just for members!

Maybe just disable non ssl content. Sure it will take some (maybe even some more :lol:) years, but with http/2 there will be no non-ssl websites anymore.

Oh, speaking about security... I noticed one of your commits has a comment that explains you don't know about the noopener security problem, but that you'll leave it in. Well, first of all you could have just asked me, since I added that feature last month... Second of all, I'd understand that you document that in the git log, but... Why in the file comments, man?? Why...? :-/

Actually I thought this is some old SMF stuff. But hey, can you explain me what's about this noopener? :whistle:

I'm kewl with SSL. One of the things I enjoy about Lestrade's is that I get to touch areas that I never had the opportunity to deal with before. SSL and Nginx are interesting. (Not ENJOYABLE interesting, but interesting nonetheless.)

We are using nginx with ssl since I don't know, 2 years? Once you configured it, it works and works. Split your "config logic" into snippets and include them to reduce duplicated config stuff. Otherwise you will find yourself in nginx config hell ^^ Cleaned up a config just today, it's so much nicer with snippets ^^

That's absolutely right. I don't know why I didn't just remove them myself all these years ago.Even the "Ordered list" thing to me is something that takes space for nothing... I'll keep it, but MEH. FTP and email, yeah, they can go.

Hmm yeah, but it's not the best example... ^^Threading has always been a stable of sites like slashdot or reddit. Or the Disqus comment system, for instance.Wedge does threading internally-- it just doesn't show it.

I'd say SMF always wanted to see itself as a professional bunch. Which is why they're so freaking slow in adding new features... They tend to look severely at people who add new features without polling the team at least 27 times and sending 42 test suites.Seriously, what I added to SMF back in 2010 in the few months I worked as developer was more than everyone else together did for the following years... (I haven't checked in recent years, but I doubt they changed much either.)I'm not boasting, I'm just saying that they don't have the same way of doing things. Which is why SMF is so much behind. Even Pete couldn't save it with his SMF 3 project. (I think that was abandoned too...?)

Couldn't use any SMF Forum nowadays, it's just lacking usabilty everywhere. Forking it was the best thing to do.

Yeah, so, there are two ways of handling PHP and Nginx, AFAIK:- Nginx as reverse proxy and Apache behind. Nginx redirects all php requests to Apache, which itself calls PHP through FCGI or mod_php, whatever. This way, htaccess is taken into account.- Nginx as both reverse proxy (or not) and server with PHP support (FastCGI or PHP-FPM). Nginx redirects all php requests to the CGI process. htaccess isn't support. And PHP isn't faster either.Which is why most servers adopt the former solution, of course.

I don't know if it makes sense to use nginx as a reverse proxy with apache behind. I guess you lose all the performance benefits from nginx. The thing with .htaccess is that it isn't "high performance". I guess you can do all those rewrite rules for pretty urls also with nginx. At least estricting the access to the various files isn't that hard with nginx. Just put "include_conf /etc/nginx/snippets/wedge.conf" wherever you serve a wedge forum. In case you need this.

Not really, no.I suppose it's feasable, though, with the caching system in Wedge (while in SMF it would be completely impossible, I think even Elk couldn't do it, without resorting to hacks.) Just generate the JS file 'automatically' from the data available in files and the database.

The current parse_bbc is too complicated to port it to js. Sure you could do it, but I don't think it would be fast. If i find some time I want to give it a try to write one from scratch. I think those different bbc types make the whole thing quite complicated, I guess it could be easier if you just have flags like "allow_indexed_params", "allow_assoc_params", "parse_content" etc. No need for types. Besides that, any "process" logic would need to get ported to js too, or some callback stuff needs to be implemented. I don't know if it would be worth it. WYSISWYG is fine for simple stuff, but as soon as you have more complex stuff like tables it's a pain. Also for plugin content, or spoilers or anything. How do you want to edit a spoiler in the WYS..WG editor without implementing a special logic?I would strip it out and implement a nice preview. Maybe with two tabs, one for editing, one for preview. Like the github editor.

Yes.I just never saw any real traction for thoughts. I'm pretty much the only one to use them. And no one asked for a refresh, so... Here you go. There's a refresh for notifications is all.

I think most people don't know how to use it. It looks like a chat, but isn't one. So putting a "hello" in there is not really useful. It's more for small side discussions which aren't worth a thread or any information which could interest some people. At least that's how it gets used on my site. But it took a long time for people to understand it and yeah it developed like that.

Yeah I don't understand the appeal of CS:GO related stuff.. ^^ I prefer regular good old single-player games. LT is mostly about retrading duplicate game keys you acquire when you're a regular customers of bundle sites like humblebundle.com, indiegala.com, bundlestars.com and groupees.com (basically the top 4 bundle websites). And they often re-bundle games offered by other sites months prior. So you ALWAYS end up with duplicate keys. I only recently opened an account for my kid, where I can now redeem many of these duplicates... But before that, since I don't like waste, I used barter.vg to retrade my keys for other games.

I like the idea, i guess there are many who have unplayed steam games. I have to tell my brother about lestrade ^^

Well, err... I think it's very fitting..?!I tried to stay close to barter.vg in spirit.

It's simple, but i wouldn't agree that it shares the same spirt asbarter.vg. Barter is just the minimum, letstrades looks more thanthe minimum, but i don't know, i miss a dark theme which would fitto the look of steam. But I'm maybe a bit picky about that and don't know the audience for sucha service good enough to know what they want and need. Still, the technicalpart is definelty more important. It has to work, look can get adjusted later.Nothing's more annoying as a good looking, but bad working piece of technique :D

So created a new PR only for the "hardcoding bbcode again" stuff.Everything should work without any database changes (we onlyload bbcodes from plugins out of the database to don't breakthings).Besides that language variables are now hardcoded for thedefault bbcodes, so no need to parse all bbcodes anymore, onlyfor the ones from the database. Didn't measure it, but this should bea bit faster. Before we had to do a ton of regexes and loops...

I'm currently very busy adding a large feature to Lestrade's (see over there, it's being discussed), so I really don't have the time for this I'm afraid.Did you check that all your spaces are there, around dots? Like, 'Hello'.$world; should be 'Hello' . $world; for instance. (I'm only saying because that's the thing I noticed in your previous pull request.)

Wysiwyg: feel free to make a poll on wedge.org about overall use (not use by forum admins but by their communities...), for now I don't see much of a reason to remove it entirely, maybe add an option to disable it... I don't know.

Did you check that all your spaces are there, around dots? Like, 'Hello'.$world; should be 'Hello' . $world; for instance. (I'm only saying because that's the thing I noticed in your previous pull request.)

Wysiwyg: feel free to make a poll on wedge.org about overall use (not use by forum admins but by their communities...), for now I don't see much of a reason to remove it entirely, maybe add an option to disable it... I don't know.

Maybe we just have to fix the Wysiwyg thing. I don't know, will look into it. At end of march i have my last exam, in the mid of april I'm some days in paris but besides that i will hopefully find some free time.