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 - CerealGuy
Bug reports / [Security] Re: BBCode in SQL Database
« on February 13th, 04:51 PM »
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
Bug reports / [Security] Re: BBCode in SQL Database
« on February 13th, 03:52 PM »
Quote from Nao on February 12th, 09:54 PM
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
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.
Quote from Nao on February 12th, 09:54 PM
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.
Quote from Nao on February 12th, 09:54 PM
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.
Quote from Nao on February 12th, 09:54 PM
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.
Quote from Nao on February 12th, 09:54 PM
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.
- 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.
Quote from Nao on February 12th, 09:54 PM
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, of course, but I stopped going there years ago.
I don't know, 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.
Quote from Nao on February 12th, 09:54 PM
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.
Quote from Nao on February 12th, 09:54 PM
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
Quote from Nao on February 12th, 09:54 PM
Nginx is the php server too? Did you convert your htaccess to use Nginx too?
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.
Quote from Nao on February 12th, 09:54 PM
I don't know. I'm not used to using a nuclear bomb to break a window.
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.
Quote from Nao on February 12th, 09:54 PM
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.
Quote from Nao on February 12th, 09:54 PM
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).
Quote from Nao on February 12th, 09:54 PM
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.
Quote from Nao on February 12th, 09:54 PM
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
Quote from Nao on February 12th, 09:58 PM
A markdown parser? Nice... :)
I'm sure it could be useful.
I'm sure this could be useful. For example reusing the 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
Code: [Select]
Quote from Nao on February 12th, 09:58 PM
I don't think you have to use the CDATA block around such short code, though!
I tried it without, but simplexml complained about that. Plugin couldn't get loaded and so on.
On mods.xml it works quite well, but not for plugins-info.xml.
Quote from Nao on February 12th, 09:58 PM
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 complex
stuff you can still achieve that with mods.xml or hooks.
Quote from Nao on February 12th, 09:58 PM
'unparsed'? ;)
With 'unparsed' i'm not able to use bbcodes inside [md] tags anymore, which I like.
Bug reports / [Security] Re: BBCode in SQL Database
« on February 12th, 07:16 PM »
A little progess which is worth to mention in my opinion. We can now use the process function on all bbc types :cool:
and i wrote a small plugin to show you what this can now do. (Don't use the plugin in production environments, markdown-extra is evil ;))

It's just hacked together, but still works quite well. Besides this autolink stuff wedge does (inserting random http://tags on everything which looks like a url to something) :D
Bug reports / [Security] Re: BBCode in SQL Database
« on February 12th, 02:58 PM »
Umm... actually I'm more or less done with my changes. Problem is now, that the validate_func stuff never got called for some bbc types. And for some other it's not even implemented. Maybe this made sense at some time, but now it doesn't anymore. Have to see how SMF does this.

New syntax for bbcode in plugin-info.xml:
Code: [Select]
    <bbcode tag="md" type="unparsed_commas" block-level="no">
      <process file="src/BBC-Markdown" function="bbc_process_markdown" />

Oh and Elkarte rewrote the complete BBC parser.
I will see what they did, maybe we can reuse some of their work? Because the SMF thing is really ugly and unmaintable. You can fix it but you will never be happy with it  :lol:.
Bug reports / [Security] Re: BBCode in SQL Database
« on February 12th, 10:21 AM »
Quote from Nao on February 11th, 11:02 PM
Yeah, as long as it's not in a Load.php or Subs.php file that gets loaded even if no BBCode parsing takes place.
(Gee, I just remembered about the Shift+Enter feature in Wedge to cut off quoted posts... How cool. Why am I not using it more?!)
Nope, everything is in Subs-BBC.php. This Shift-Enter thing is nice, you should tell more people about that :D
Quote from Nao on February 11th, 11:02 PM
Oh yeah, hooks, good idea... Maybe with hooks, there's really no need to use the database at all..?
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. Wouldn't be possible without loading bbcodes from database. Still I would add hooks, just to let people easily do more advanced stuff like modifiying existing bbcodes.
Quote from Nao on February 11th, 11:02 PM
If I'd seen that post earlier, I could have offered to do it for you, I still have a wide knowledge of what everything does.
(And I'm saying that just after discovering/remembering that SMF/Wedge use a set_error_handler() function to show errors, when I was implementing my own for a debug session lol...)
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
EDIT: The SMF Sources are helpful:
Quote from Nao on February 11th, 11:02 PM
You don't need a VPS to use Let's Encrypt. In fact it's starting to become a generic feature in many shared hosting environments. IIRC you don't even need a unique IP to use a SSL certificate.
My hosting is a VPS, BTW, not shared hosting. My only shared hosting is for, and even then I'm considering moving my site somewhere else because it's getting really expensive for a SINGLE mostly static site with barely any visitors... Hmmm. But my current hosting being PHP7 only, it would take days to convert cynagames to use it, since it's running an old SMF 1.1!
When we're already talking about SSL, what about ssl for
Quote from Nao on February 11th, 11:02 PM
Well, if it were just up to me, I'd remove it entirely, I never use WYSIWYG. And I'm pretty sure 95% of all SMF/Wedge users don't, either.
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.
Quote from Nao on February 11th, 11:02 PM
Interesting. I don't know if it's a feature people would use, though.
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
Quote from Nao on February 11th, 11:02 PM
You probably haven't tried them all ;)
Maybe XenForo 2 is better, I don't know...
I know ElkArte has its fans, too. (Plus its authors are eminently respectable, so that helps!)
I'm not a big fan of their design though. I don't like Wedge's either, but Wilde is very tweakable and close to something both usable and good-looking.
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
Quote from Nao on February 11th, 11:02 PM
Because I spent so much time optimizing it... ;)
Then again, with modern browsers, modern servers and modern web software, it doesn't feel like much of a difference anymore.
Quite well optimized :cool:
Quote from Nao on February 11th, 11:02 PM
I must be the only one, then... ;)
Or generally people who use weird setups like Nginx + Apache.
nginx + latest php + mariadb. Works like a charm.
Quote from Nao on February 11th, 11:02 PM
With PHP7 increasing performance ten-fold, I don't think it's dying anytime soon...
It will exist for a long time, too many projects which rely on php are still heavily used.
Quote from Nao on February 11th, 11:02 PM
Quote from CerealGuy on February 9th, 01:06 PM
I'm not sure about that, but for example websockets aren't
  supported yet in php.
There are libraries like Ratchet. But websockets are more of a JS thing, aren't they..?
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
Quote from Nao on February 11th, 11:02 PM
Quote from CerealGuy on February 9th, 01:06 PM
Which could be a nice thing to have,
  also for wedge. Especially for notifications. Wedge is maybe
  the last and best php Forum Software.
Well, for notifications I agree websockets are a good idea, but Wedge's implementation is already good enough-- it loads as little data as possible and pauses itself when needed. I could add some code to send the notifications through Chrome's own notification system, though.
Already thought about that notification system, maybe would be a nice thing, especially with a better PM System :P
Quote from Nao on February 11th, 11:02 PM
Whenever I see code I don't understand, I'll just use git blame on the file, and find out what commit added it, and the related commit notes. That's often how I figure out something was improperly added.
That's a good idea!
Quote from Nao on February 11th, 11:02 PM
Quote from CerealGuy on February 9th, 01:06 PM
- No documentation, no helper/"framework like" functions to make life
  easier for plugin developers.
Well, I never wanted to document the whole thing, I hate writing docs... Pete was supposed to do it, then someone else, been there done that... :-/
Maybe something like js-doc for php would already be enough with generated html docs. Many functions and classes are documented inside the code.
Quote from Nao on February 11th, 11:02 PM
Agreed. Can't help much here.
Same can be said for SMF, though. Didn't stop it from being successful and having tons of mods. (Most of them being shit, though. Not all mods were of Aeva Media quality :P)
I think this we can solve quite easily if we give wedge "framework like" functions. Every now and then someone needs a function like this in a plugin, we can simply add it to special core/app/file. Problem is of course that we have to document them somewhere, or at least in the code :D
Quote from Nao on February 11th, 11:02 PM
Quote from CerealGuy on February 9th, 01:06 PM
Leave the bbcode in, but just don't advertise it. Let's just say it was just a good excuse to make use of sbox.js's advanced features!
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.
Quote from Nao on February 11th, 11:02 PM
Quote from CerealGuy on February 9th, 01:06 PM
Yeah, you know what, I actually considered that for my new site, and was wondering if I should just replace it with a pseudo-chat system between 2 users... Something similar to Facebook, really.
Could be a path to explore.
Only problem is: how exactly do you 'import' the old PMs into that system... ;)
Also, it would probably encourage people to post more 'PMs', thus more entries in the PM base, thus slower to use... (?)
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.
Quote from Nao on February 11th, 11:04 PM
Did you simply turn it back into something similar to SMF's version?
Because it'd be best, I suppose, for plugin authors to 'understand' the thing...
It's actually quite similiar to the SMF approach. I think the only difference was that wedge loaded it's bbcodes from db, smf has them hardcoded. We will now do both :D
Quote from Nao on February 11th, 11:04 PM
preprocess for pre-validation
postprocess for validation
Or just 'process' if you want to keep it simple.
Thanks, process should hit the nail.
Bug reports / [Security] Re: BBCode in SQL Database
« on February 11th, 06:43 PM »
So loading bbcodes from file works, language parsing works, additional loading bbcodes from sql works too.
The bbcodes as an array take 602 lines.

Only problem i have is thinking of a good name for the sql fields and the array field.
Currently the functions are called 'validate' functions, which is in my opinion not describing it well, because you can also modify the content and do more advanced stuff as only validating. Any ideas for a better name? @Nao

EDIT: No need to do anything for ManagePosts, works already how it should.
Bug reports / [Security] Re: BBCode in SQL Database
« on February 9th, 04:42 PM »
Back to topic,
hardcoding the bbcodes array is around 550 lines at least :^^;:
Of course faster than loading it everytime over sql, but still not nice.
Any ideas? :hmm:
Bug reports / [Security] Re: BBCode in SQL Database
« on February 9th, 01:06 PM »
Quote from Nao on February 9th, 11:26 AM
Quote from CerealGuy on February 7th, 11:58 AM
Yup, totally aggree with your points. On the other hand, adding bbcodes via plugins is quite a handy thing. So i won't say the idea is bad, just the way it's done in the moment is not the best.
Maybe do... BOTH?!
- Have the main BBCode in a source file,
- Give plugins the ability to add or replace BBCode,
- Only, plugins can't add code in the database, rather a function name. IIRC plugin files are always loaded so it's easy enough to just put the code in a plugin file and it should get executed.

Or, if it's too much to handle, just do points 2 and 3, because it still means putting the code to be executed into a source file, goddammit.
Yeah, that's probably the most realistic solution..?!
- First thing I want to do is moving all "validate_funcs" to
  Subs-BBC (nearly done with that).
- Next thing is refactoring those functions, making more
  clear what they do (figured out that the do nothing which
  you should describe with the term "validate", most of them
  trim or beautify the content.) and  understanding why the
  hell there are often the same tag twice with nearly the same
  "validate_func". I'm sure it would be enough to have one of
  those function for each tag (which needs this stuff).
- If this is done I want to look if it's possible to "hardcode" all those
  default bbc tags in a nice function. Something like loadBBCodes(),
  which returns all default bbc tags plus loads all others from sql.
  Have to see how the disable tag stuff is done. Want to add a
  hook here too, so plugins really have all the power over bbcodes
  without the need of modifying the bbc parse code or doing some
  regex stuff on top of it.

It's a bit to do, won't get bored the next days. The Problem is not
the coding, it's understanding what goes on in Subs-BBC :lol:
Quote from Nao on February 9th, 11:26 AM
Well, I've moved and at the same time. was flawless, but is running a heavily customized SMF 2.0 RC, with none of the code fixes to make it run on PHP 7. However, that server can ONLY run one version of PHP (because the admin doesn't want to bother, and it's okay), so I had to manually convert SMF code to PHP 7 *and* my custom code as well, of course... Took at least a day.
If I move my site again, I'll make sure it has PHP 5 as an option. I'd rather use PHP 5 for Noisen, even though it's now working correctly in PHP 7.
Sorry if it was confusing. Wedge was fine.
I'm having Wedge problems with my other new site though, ahah. But again-- server problem. Another server, other problems: this time it's file permissions. The difference is, the admin has been AWOL for 2 months now. Not great...
Didn't play with a pure webspace in years, and i know why :D You just have more control, more power and of course more responsibility. But stuff like let's encrypt (free ssl certificates in case you don't know them), full control about software which is running and the configuration will always let me choose an vps/kvm/whatever over a webspace.
Quote from Nao on February 9th, 11:26 AM
PS: It feels good to see wedge back under active developement:D
Yeah, me too. And thank you for being the only developer who still believes in it.:)

Although I never felt back about leaving it -- I just considered it finished. What I'm doing is maintenance work, plus extra minor features from time to time because, well, it's fun?
My game development plans were set aside due to the state of the market. Purely from a business point of view, there just isn't enough visibility for a new game, and for now I don't want to rely on my 'Kyodai' brand name to attain more recognition. So I just focus on selling that old game and building that game trading site. (Which for now is just a game trade matching site. Supposed to be unveiled today, except the site isn't working due to aforementioned permissions ahah.)
Wedge is quite finished. It's totally usable, I only tweak stuff which I don't like how it behaves. For example the WYSIWG Editor. It's fully working, but awful :D Will be the next thing i want to look at. And some features I see around other forum softwares which i like. For example mark quotes. So you mark a part of post and you can only quote this part. Really like this idea, have to see how i can implement that. Maybe stuff for a plugin.

Besides that, i said it already in parts here and there, wedge is in my opinion the only good forum software around.
It's nearly perfect with balancing out pure html/css functions and extra js. It has many js stuff which makes it feel modern and dynamic without making it unusable on browsers without js. I mean solutions like nodebb they won't work in a browser without js. Those "in browser apps" are cool for sure, but not for a forum software (in my opinion). They are slow, make problems with search engines, are unusable with noscript. But forums should be accessable by as many people as possible and shouldn't make problems.
The next thing is mobile/responsive design. A lot of forum softwares aren't able to this. Xenforo just looks really really bad on a smartphone. They didn't understand this *less thing which wedge does. Less padding and style elements is more on a mobile screen. You wan't to use as much of the screen as possible to show content without confusing the user. Xenforo also didn't do this js thing well. It's just bloated with js even if it's more of traditional "non ajax" solution compared to nodebb. I hate it to surf on any xenforo forum. Only thing which is maybe worse is an old vbulletin forum. I just always fear to lose my account's email and password to some hackers :D
Wedge feels lightweight, it loads super fast on the browser. It looks modern, has a special touch to it which you will recognize. And it has a lot of really good ideas implemented. Besides that, it's super stable. I think we use wedge on our forum since 3 years. Never had a serious problem with the forum software. Not even a small one.

But still there are problems with wedge.
- PHP is just not modern anymore. In fact, it's a bit dying.
  I'm not sure about that, but for example websockets aren't
  supported yet in php. Which could be a nice thing to have,
  also for wedge. Especially for notifications. Wedge is maybe
  the last and best php Forum Software.
- Besides the PHP thing, the codebase is old and unmaintained.
  No unit tests, no coding style standards. You also don't want to
  touch that code, risks are too high to break a thing and don't even
  notice it. Not a big of a problem, there aren't too many who use wedge
  anyway :D 
- No documentation, no helper/"framework like" functions to make life
  easier for plugin developers. As a plugin developer you write so many
  functions again, which are maybe already implemented in the wedge
  core and you just could reuse. But you don't know of them and never will.
- In general you can make wedge do everything you want, but it's often not
  a nice way. It's more like forging it with a flamethrower.
- Some standard functions are just not as good as they should. For example
  the editor. Color chaning is bad, you can't asign a choosen color to another
  marked text without first changing it's color to something else and than to
  the color you want. Makes no fun.
  Or Private Messages. It's this old private messaging system you know from
  Bulletin Boards. It's just old and feels bad to use. It's a bit like emails and this
  is already bad. In fact i would always prefer to write you a message on any
  instant messanger instead of using wedge.

Wow this is more of an essay and totally off topic. But who cares.
Archived fixes / [CSS] Re: Login looking bad on small screens
« on February 9th, 12:57 PM »
Looks fine on all my devices. The only thing to tweak is when it should change. 600px seems to be a bit high in my opinion, alread on 550px it looks ways better. But this is something we can always change.
Archived fixes / [CSS] Re: Login looking bad on small screens
« on February 9th, 11:14 AM »
Looks fine on my galaxy s3, will try later on other devices :cool:
Bug reports / [Security] Re: BBCode in SQL Database
« on February 7th, 11:58 AM »
Yup, totally aggree with your points. On the other hand, adding bbcodes via plugins is quite a handy thing. So i won't say the idea is bad, just the way it's done in the moment is not the best. Also this validate thing i really don't like. The name suspects a very limited function, even if it's not. Have to think of something for this.
I will give it a try and see what i can do. I'm ill in the moment (EB Virus is quite a nasty one) so I have some time.

Quote from Nao on February 7th, 12:58 AM
PS: I just have no time to look into this right now. I'm pretty busy with the new site. Plus I may be moving servers again in the future-- this one is so blazing fast, I love it, but there are so many configuration issues, it gives me nightmares... -_-
What kind of a server are you using that the configuration issues give you nightmares :hmm:

PS: It feels good to see wedge back under active developement :D
Bug reports / [Security] Re: BBCode in SQL Database
« on February 6th, 11:23 PM »
Bumping this, because this one bugs me a bit. I think this a security problem, even if it's low priority.
Why? Because if someone hijacked a database where a wedge instance is running on, he doesn't need too much more
to also undertake the php execution level. Which basically means he has many more possibilities to harm you.
Injecting some bad code into a often used bbcode validation, maybe changing the type of it and accessing a post where this bbcode gets translated into html (and bad code) is all what needs to be done.

It wouldn't be hard to make this ways less evil. We just need to get rid of those php code in the database and load it from a file. So adding three fields: validation_plugin, validation_file, validation_func would be all we need besides some code moving and a bit of adjusting.
Just to mention it again, php code in a database is not even handy. If there's an exception you won't know on which bbcode (in the moment), to debug it you have to update your database, to fix it you need to roll out a database update. This just makes no real sense in my opinion. And if you want to hook in with a plugin, you have to do hacky stuff (see my hidemod post on this topic).

Quote from Nao on January 30th, 02:27 PM
Hmmmmm... That might actually explain it! I was thinking of exclusive locks but couldn't figure out why this would only happen with ViewRemote.
I'll give it a look.

:edit: I don't know... The first thing that gets called is copy(). Meaning the file SHOULD exist, in its entirety, by the time a second AJAX request is triggered. Of course it could still be unsuccessfully copied or something.
I don't know how copy() is exactly working. It's possible that the function first creates the file and then streams to it. Would make sense because you can use copy with network resources. So maybe it would already be an improvement if apply_plugin_mods does it manually. I think the file gets written on the fclose call to the disk, but i'm not sure about that.
Another option would be to set LOCK_EX with flock() until the file is completely written and minified, and then test on other requests if it can safely be acccessed with LOCK_SH. However, i don't know if those fopen + flock calls are imperformant? Also it's not possible to pass an file resource to require_once()..
Problem is, that it's a pain in the ass to test this thing. Don't know how to provocate this race condition.
If we are able to create a test for this, it shouldn't be too hard to fix.
I can reproduce it if gz/app/ViewRemote.php is an empty file. Maybe this happens if file gets renewed and in the same moment you  try to access it? So file is still empty or something and you try to load the file?

What makes me wonder is that this only happens to ViewRemote. Never saw a similiar error with any other required files...

EDIT: I have a theory:
When we go to admin panel, we fire two ajax requests against ?action=viewremote
?action=viewremote;filename=current-version.js and

If ViewRemote isn't cached, wedge will try to create it very likely on the current-version.js request. But in the same time we will ask again for viewremote, maybe the file is already created, but not completed. So the first thread (current-version.js) is creating the file, but not finished. In the same time the second thread (latest-news.js) is trying to loadSource('ViewRemote'), loadSource checks if file exists (it exists) and then requires it. But it's empty or not done yet. So second thread will result in an error. So this could be kind of a race condition.
Plugins / [Plugin] Re: HideMod
« on January 22nd, 12:05 PM »
Quote from CerealGuy on February 8th, 2014, 02:36 PM
Im using the display_post_done hook to replace the hide(-reply) stuff and check if user is allowed to do so. But perhaps the bbcode stuff in plugin-info.xml is bether?
Quite an old one, but I finally found a solution for this and wanna share it with you.
The Problem with my first approach was that i used regexes to figure out where my
bbc tags for hide & hide-reply where. So I didn't drop in the normal bbc parsing wedge
does and did it just after everything was already parsed. This is a thing which definetly
can be done, but it has many downsides. For example you have to handle every "special"
cases the wedge bbc parser handles already again. Like bbc tags inside a code tag etc.
And you have to make sure that your regex really works in every case :lol:
All in all it would be better to just inject it somehow in the normal bbc parsing process.
And it's possible, even when you want to do more complex stuff like in this plugin.
The key to glory is the validate-func which allows us to inject php code in the normal bbc
parsing process. Because the most bbc tags only add some html before or after and don't
care about who's viewing this post (we do, because we want to determine if the current user
is allowed to watch the content in the hide tag or not).
I guess the purpose of the validate-func was to validate anything related to the tag in more
complex use cases. Eg. validating complex urls or stuff like that. But we can also modify the
part of the message containing the bbc tag, and that's what we want to do.
All you need to do is adding a php file to your plugin with a function which gets called by the
validate-func eval block. And you need to add the bbcodes to your plugin-info.xml:
Code: [Select]
    <bbcode tag="hide" type="unparsed_content" block-level="no">
      <content>HIDDEN CONTENT: Like to see</content>
      <validate-func>loadPluginSource('CerealGuy:HideModv2', 'src/Hide'); validate_hide_bbc($tag, $data, $disabled);</validate-func>
    <bbcode tag="hide-reply" type="unparsed_content" block-level="no">
      <content>HIDDEN CONTENT: Reply to see</content>
      <validate-func>loadPluginSource('CerealGuy:HideModv2', 'src/Hide'); validate_hide_reply_bbc($tag, $data, $disabled);</validate-func>
As you see, i call plugin function named "validate_hide_bcc" (or "validate_hide_reply_bbc") with three arguments.
If you catch them in your function header as referenced variables, you are free to modify all values of them. Play around with them, you will understand what's where easily.
Sounds straight forward, but there was still a hurdle to clear. The Problem was that I didn't know of which type my bbc tags have to be. With some types just nothing happend, with some others it got parsed at some times and sometimes not. Don't ask me why, i didn't understand the differences and purposes of those types. Maybe someone knows this stuff @Nao? :whistle:.
Anyways finally i found the right one, "unparsed_content".
This was a small background report about stuff which took me quite some time to figure out. Maybe it helps somebody.

Tl;dr: If you want to do more complex stuff with bbc tags, add them via plugin-info.xml and use the validate-func to inject your own code. Setting the type of your custom bbc tags to "unparsed_content" did work for me best, other types didn't work out that good.