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
1
Bug reports / Re: Couple things to look into...
« on March 20th, 04:44 PM »
Quote from Nao on March 20th, 04:28 PM
[Commit revision 7fdc0bd]
Author: Nao
Date: Mon, 20 Mar 2017 16:28:03 +0100
Stats: 2 files changed; +6 (insertions), -6 (deletions)

[cli=f]This is a follow-up to rev c92eb3fb73b94a545029e73a830540e5779dfd5c from October 2013. I'd changed the Mark Topic as Unread system to better accomodate for infinite scrolling, but it also broke 'regular' use of the feature by resetting the read post counter to the beginning of the page, instead of the last unread post. I've tweaked the files to always reset to the last unread post, unless (1) you're on a read page (in which case it will mark the LAST post in THAT page as unread), (2) you're in infinite scrolling mode and you just viewed a new page (here it'll simply mark the penultimate read page's last post as unread.) This sounds complicated, but it works better for me. Until, of course, someone tells me it's broken... (Display.php, Subs-Boards.php)[/cli][/q]
Did this solve the unread thing?
3
Development blog / Re: The obligatory Christmas update.
« on March 19th, 04:03 PM »
Quote from Nao on March 19th, 12:40 PM
I just realized this was my last post on the blog... :^^;:
Oh, and that comment system looks so cool.

I'm guessing I need to make a strong statement about Wedge still being alive.
Thanks to CerealGuy for never giving up and pestering me into coming back :)
Also thanks to Lestrades.com for giving me a good reason to get back to work!
Wedge was the first bigger codebase I worked with and later contributed to. In that
time (and it still goes on) I learned a lot. Not only the benefits of open source and how
much fun it can be to work on project, but also It's the first time that code i wrote and ideas
I have, really get used in projects which aren't my own :lol:.
Thanks for making this possible.
 I hope we can obtain this friendly working condition in the future.
I wish you best luck and success with your LT project  :cool:
4
How about using that <PROT> magic thing we added once for Aeva Media? So everyone using a https connection will get https://wedge.org, everyone else plain http.

But still I don't see any real benefit on using https over plain http on the credit page. What maybe would make sense is that you get forced to use ssl as soon as you try to login. And always get redirected to the ssl url if you are logged in and don't use ssl. Plugin stuff?
5
Bug reports / Re: Couple things to look into...
« on March 19th, 03:25 PM »
Quote from Nao on March 19th, 11:41 AM
Actually that's because the cli tag didn't have a plugin ID and you're only loading those.
This might be a problem if someone built a mod (rather than a plugin) that still added stuff to the database, but it's unlikely of course.

(This still isn't working yet, ahah.)

 :edit: Was due to the fact that the list tag didn't have 'cli' in its allowed children.
This where part will get removed as soon as the default bbcodes got removed from the database. So only a temporary thing.
6
Bug reports / Re: Couple things to look into...
« on March 18th, 08:20 PM »
Will definetly look into the login thing, unread topics also but less priority.
There are some things which bug me about login (besides sha256):
- no js counter for failed logins, i find myself quite often on the "you have to wait before you can try to login again" error page.
- after x failed logins this error page should first show up, for me it shows up after the first try
- no redirect of $_POST content, i often loose posts because my session timed out. Don't know if this should get solved on login or in editor. Have to think about that.
- notification on x failed logins for the user would be cool, maybe plugin stuff.
7
The Pub / Re: PHP 5.4?
« on March 18th, 08:06 PM »
I guess we can safely increase it to 5.6 even if we should recommend php7 just because it's noticeable faster. Sure, the thing with php versions is always the slow upgrade of webspace providers but do we have to care about them? Do we have the manpower to support old/outdated php versions? Does it even make sense?
8
Bug reports / [Security] Re: BBCode in SQL Database
« on March 14th, 01:56 PM »
Quote from Nao on March 13th, 10:33 PM
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.
Don't worry, look into it if you find some spare time for it.
Quote from Nao on March 13th, 10:33 PM
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.)
I tried to adapt that, so it should be like that. But maybe not every time :whistle:. Yesterday I started looking into php_codeSniffer and started developing a coding standard for wedge. One rule is "one space around string concatenating operators" ^^. 
Still WIP, but works already quite well. Comes in very nice if you have a linter integrated in your editor.
https://github.com/C3realGuy/wedge/tree/dev_coding_standard
https://github.com/C3realGuy/Wedge-Coding-Standard
Quote from Nao on March 13th, 10:33 PM
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.
Quote from Nao on March 13th, 10:33 PM
The rest: okay, I still haven't read your mammoth post..... :sob:
Don't worry, there's no deadline :D
9
Bug reports / [Security] Re: BBCode in SQL Database
« on March 10th, 07:59 PM »
So created a new PR only for the "hardcoding bbcode again" stuff.
Everything should work without any database changes (we only
load bbcodes from plugins out of the database to don't break
things).
Besides that language variables are now hardcoded for the
default bbcodes, so no need to parse all bbcodes anymore, only
for the ones from the database. Didn't measure it, but this should be
a bit faster. Before we had to do a ton of regexes and loops...

The bbcode entries can get deleted in the next big database upgrade.
https://github.com/Wedge/wedge/pull/58

Not included in this PR is the merging of the different "dup" validate functions.
Shouldn't be a big problem, depends if @Nao wants that already in this PR or not.

BTW: Let us really rip out this WYS..G stuff, since i enabled it for testing, it annoys me each time i write a post here on wedge :D
10
Archived fixes / [CSS] Re: Login looking bad on small screens
« on February 24th, 11:26 AM »
Will do one but could take a while and it's not really high priority. Exams are :D
11
Archived fixes / [CSS] Re: Login looking bad on small screens
« on February 23rd, 12:08 PM »
Now I remember, I set it to 450px because that was a good
point where it should get split into different lines. 600px is
in my opinion too high, between 450px and 600px it still
looks fine if it's in the same line. But that's just cosmetics.
All your other changes work as expected  :cool:


Example: It's on 540px, definetly enough space to still have it
in one line.






12
Bug reports / [Security] Re: BBCode in SQL Database
« on February 21st, 02:13 PM »
Quote from Nao on February 21st, 12:24 PM
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.)
Would make this keyoard shortcut perfect.
Quote from Nao on February 21st, 12:24 PM
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 ^^
Quote from Nao on February 21st, 12:24 PM
Same with lestrades.com ;)
This avatar problem is really annoying, though.
Quote from Nao on February 21st, 12:24 PM
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.
Quote from Nao on February 21st, 12:24 PM
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:
Quote from Nao on February 21st, 12:24 PM
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 ^^
Quote from Nao on February 21st, 12:24 PM
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.
:cool:
Quote from Nao on February 21st, 12:24 PM
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 from Nao on February 21st, 12:24 PM
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.)
Hmm I really like the Idea, especially for blogs this could be nice.
Quote from Nao on February 21st, 12:24 PM
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.
Quote from Nao on February 21st, 12:24 PM
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.
Code: (/etc/nginx/snippets/wedge.conf) [Select]
location ^~ /gz/ {
   deny all;

   location ~ "^/gz/js/.*\.js$"  {
      allow all;
   }
   location ~ "^/gz/css/.*\.css$" {
      allow all;
   }
}

location ^~ /assets/ {
   deny all;

   location ~ "\.(gif|png|wav|ttf|jpg|jpeg)$" {
      allow all;
   }
}

location ^~ /attachements/ {
   deny all;

   location ~ "\.(ext|ext_thumb)$" {
      allow all;
   }
}

location ^~ /core/ {
   deny all;

   location ~ "^/core/skins/.*\.(png|jpg|jpeg|gif)$" {
      allow all;
   }
}

location ^~ /plugins/ {
   deny all;

   location ~ "\.(png|jpg|jpeg|gif|ttf|wav)$" {
      allow all;
   }
}

location ^~ /install/ {
   deny all;
}

location ~ "^/(Settings.*\.php|README\.md|DCO\.txt|changelog\.txt|contributors\.txt|license\.txt)$" {
   deny all;
}
Quote from Nao on February 21st, 12:24 PM
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... ^^
I don't want to know, that would result in nightmares...
Quote from Nao on February 21st, 12:24 PM
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.
Quote from Nao on February 21st, 12:24 PM
Yeah... Not that much, really. ^^
^^
Quote from Nao on February 21st, 12:24 PM
The latter for now. Let's not get ahead of ourselves... ;)
Real-time chat can always be added through a plugin.
Maybe a good idea to do it first "static" with as less js as possible. Makes things easier and the nice features can still be added later.
Quote from Nao on February 21st, 12:24 PM
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.
Quote from Nao on February 21st, 12:24 PM
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. ^^
:lol: We currently have 5740 Thoughts, give it some time until people understand how to use it. Or make it a shoutbox :D
Quote from Nao on February 21st, 12:24 PM
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 ^^
Quote from Nao on February 21st, 12:24 PM
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 as
barter.vg. Barter is just the minimum, letstrades looks more than
the minimum, but i don't know, i miss a dark theme which would fit
to the look of steam.
But I'm maybe a bit picky about that and don't know the audience for such
a service good enough to know what they want and need. Still, the technical
part 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
13
Bug reports / [Security] Re: BBCode in SQL Database
« on February 20th, 07:08 PM »
I will continue this monologue ^^
First, there are still bugs on this implementation, i'm fixing
them as soon as find them and as soon as i find time to
fix them. Maybe I will update my site to use this branch this
week and see how well it works.
Also I figured out that it's quite easy to have backwards compatibility
for the process/validate-func to old wedge versions, just because the
old 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 would
not 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 very
wrong. I actually lost track on what's going on in the php world and
there is still a lot going on. Played around with tools like phpunit, composer
and php_codeSniffer. Nice tools, maybe hard to apply to wedge and not
really useful because it would need refactoring a lot of code (and changing
the workflow). But for other projects (and maybe bigger plugins) this is definetly
worth a look.
14
Bug reports / [Security] Re: BBCode in SQL Database
« on February 16th, 10:03 PM »
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
15
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