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 - Nao
6931
Features / Re: Fixing mismatched BBCode
« on December 7th, 2011, 09:03 PM »
Preparsecode can't refuse a post and send back a list of errors afaik...
6932
Features / Re: Fixing mismatched BBCode
« on December 7th, 2011, 07:46 PM »Here's the code, for those interested. It seems to work, at least on my test cases. Maybe you can figure out a faster/shorter way to do it ;)
PRO: well, it'll make things a bit faster...?
CON: if adding code tags inside anything that does NOT go through Post2 (e.g. an AeMe comment, etc.), it won't work...
Obviously, for anything that does NOT do proper error checking on post contents, it's going to be harder to manage... It's not like we can easily plug these situations into Post2...
6933
Features / Re: New revs
« on December 7th, 2011, 07:40 PM »
rev 1187
(4 files, 3kb)
! Mismatched tag code wouldn't work when openers had parameters. (Post2.php)
* Rewrote mismatched tag logic to generate an error in, for instance, a situation where you'll have matching openers and closers but in the wrong order. (Post.php, Post2.php, Errors.language.php)
(4 files, 3kb)
! Mismatched tag code wouldn't work when openers had parameters. (Post2.php)
* Rewrote mismatched tag logic to generate an error in, for instance, a situation where you'll have matching openers and closers but in the wrong order. (Post.php, Post2.php, Errors.language.php)
6934
Features / Re: Extending the postbit/poster info
« on December 7th, 2011, 05:55 PM »6935
Features / Re: New revs
« on December 7th, 2011, 05:54 PM »
rev 1186
(12 files, 14kb)
+ Added a new routine to the post code that will check for extra or missing tags and send an error instead of trying to fix, generally badly. The error message also indicates the number of expected and found tags. (Post.php, Post2.php, Errors.language.php)
! The Post() function's error handling code was pretty messed up to begin with. Rewrote it to use the same system as in Post2(), as well as avoid rebuilding the error list in case an error was found in Post2(). (Post.php)
- Why exactly does SMF/Wedge still show a hidden error box when there are no errors to show in the first place...? That's silly. (Post.template.php, sections.css)
! SMF bug (doesn't matter here, but just so they know if they're reading our changelogs...): $context['post_errors'] is set in Post(), instead of $context['post_error']. Fixing this will break Post2() error handling though... (Post.php)
* Harmonized other occurrences of $context['post_errors'] to $context['post_error']. Well, technically post_errors is better suited, but there are far more to fix if we start going that way... I have a life, too. (Profile-Actions.php, Profile.php, Report.php, Profile.template.php, SendTopic.template.php)
@ Note: I have yet to cache the BBC list for the mismatched tag check code. Actually, I'm not even sure it's worth caching it... It's a tiny table and the code is only run when posting a message... What do you think?
(12 files, 14kb)
+ Added a new routine to the post code that will check for extra or missing tags and send an error instead of trying to fix, generally badly. The error message also indicates the number of expected and found tags. (Post.php, Post2.php, Errors.language.php)
! The Post() function's error handling code was pretty messed up to begin with. Rewrote it to use the same system as in Post2(), as well as avoid rebuilding the error list in case an error was found in Post2(). (Post.php)
- Why exactly does SMF/Wedge still show a hidden error box when there are no errors to show in the first place...? That's silly. (Post.template.php, sections.css)
! SMF bug (doesn't matter here, but just so they know if they're reading our changelogs...): $context['post_errors'] is set in Post(), instead of $context['post_error']. Fixing this will break Post2() error handling though... (Post.php)
* Harmonized other occurrences of $context['post_errors'] to $context['post_error']. Well, technically post_errors is better suited, but there are far more to fix if we start going that way... I have a life, too. (Profile-Actions.php, Profile.php, Report.php, Profile.template.php, SendTopic.template.php)
@ Note: I have yet to cache the BBC list for the mismatched tag check code. Actually, I'm not even sure it's worth caching it... It's a tiny table and the code is only run when posting a message... What do you think?
6936
Features / Re: Extending the postbit/poster info
« on December 7th, 2011, 04:50 PM »
I think I'll let you think about it because I haven't touched the Display code much these last few months and I feel totally unable to help here... :-/
6937
Features / Re: Extending the postbit/poster info
« on December 7th, 2011, 03:54 PM »
Do you think it's gonna be noticeably faster?
6938
Features / Re: Privacy options
« on December 7th, 2011, 03:10 PM »Whoever wants to argue that one will also have to convince me of it. It's just not a good idea IMO.Quote I guess I can still be convinced to use membergroups, but I'll need someone to debate with me
Also, any extra feature added to contact lists could be used as well in regular membergroups: 'hidden' state (rather than hide the entire membergroup from view, why not hide just one person from view...?)
I didn't really consider this whole aspect because I'd given up on it at Noisen, but I didn't as well consider why I removed it from noisen -- primarily the UI issues, which I couldn't bother to deal with. Noisen's friend lists use the UltimateProfile code to manage friends, and this is something I'm going to rewrite anyway -- it's not like UP is BSD or whatever, AFAIK...
That said, I'm inclined to go with one row per association rather than denormalise the data and stuff it in a text. It's cleaner, easier to maintain, less likely to get screwed up (cf the comments in Load.php about loading the user's groups and 'history shows that these can go bad')
Of course, it would also get us rid of these annoying find_in_set calls...
I've thought about it and I just don't know. I can see benefits both ways of doing it - doing it before the WHERE will probably make it faster, but doing it after the WHERE only makes it easier to maintain and makes it easier for modders to apply it properly in their own things later on.
Either way, adding in {query_see_topic} "forces" us to always declare topics AS t, because the extra code will definitely use the alias. But IIRC it's the same with query_see_board anyway...
I'll just add that query_see_topic can be moved before or after the WHERE whenever we want -- it's not that big a deal because it's called at most 60-70 times in our code so it can be redone manually...
6939
Features / Re: Privacy options
« on December 7th, 2011, 09:47 AM »
@Pete> I'm still unsure whether our query_see_topic should be before WHERE (i.e. use an inner join just like at noisen), or after it (i.e. use a subquery). Did you think about it..?Quote from AngelinaBelle on December 6th, 2011, 09:34 PM Well, as I said, Noisen did it very well. It wasn't scary at all, actually... In terms of security, there's nothing new compared to SMF. I don't think it took me more than a couple of days to implement the feature back then... That being said, it's not something I'm planning to implement in Wedge, because contact lists will be better suited IMHO. But they WILL probably be slower, that's for a fact. I guess I can still be convinced to use membergroups, but I'll need someone to debate with me ;)
The main reasons for not using membergroups are (1) the fact that the UI is complex, although it could be solved by writing an alternative UI for non-admins (I couldn't care less at the time...), (2) if you're someone 'popular' in a certain community and lots of people put you into their follow/contact lists, you'll end up with dozens of membergroup ownerships in your member account. If a forum is extremely popular, you could end up with your group field being overfilled (its size is 64KB at best IIRC). This could be solved by having a new table where members and membergroup relationships are stored. This isn't something I've explored so far... Maybe Pete has an opinion on this...?Quote No plans for now...
It will be feature-locked when it goes beta, I suppose. (And even then, we'll still be flexible about adding stuff that make sense.)
We used to have schedules and everything... Back when our relationship with SMF was bad at best. We wanted to release something in mid-2011 but because SMF eventually went gold around that time, it pretty much freed us of any restraints. Even when the main Noisen features are finally integrated, I'll still be wanting to finetune the overall design of Wedge because I'm not entirely happy with it. An important milestone will be when I install Wedge on this very website. This could be done today because the thought system is now ready to use (something Pete was adamant should be kept on Wedge.org), but thoughts led me to rethinking the privacy system, which in turn led me to rethink the select box stuff... Etc, etc. It's probably never going to end, but what matters is that Wedge is constantly evolving and not staying in its corner without any updates etc.
It will be complicated.
And scary, because you need to allow "everyone" to use stuff that was meant for only admin.
Easy enough to make the user moderator of the user's membergroups. New to make them able to create usergroups.
The main reasons for not using membergroups are (1) the fact that the UI is complex, although it could be solved by writing an alternative UI for non-admins (I couldn't care less at the time...), (2) if you're someone 'popular' in a certain community and lots of people put you into their follow/contact lists, you'll end up with dozens of membergroup ownerships in your member account. If a forum is extremely popular, you could end up with your group field being overfilled (its size is 64KB at best IIRC). This could be solved by having a new table where members and membergroup relationships are stored. This isn't something I've explored so far... Maybe Pete has an opinion on this...?
When do you feature-lock this puppy?
It will be feature-locked when it goes beta, I suppose. (And even then, we'll still be flexible about adding stuff that make sense.)
We used to have schedules and everything... Back when our relationship with SMF was bad at best. We wanted to release something in mid-2011 but because SMF eventually went gold around that time, it pretty much freed us of any restraints. Even when the main Noisen features are finally integrated, I'll still be wanting to finetune the overall design of Wedge because I'm not entirely happy with it. An important milestone will be when I install Wedge on this very website. This could be done today because the thought system is now ready to use (something Pete was adamant should be kept on Wedge.org), but thoughts led me to rethinking the privacy system, which in turn led me to rethink the select box stuff... Etc, etc. It's probably never going to end, but what matters is that Wedge is constantly evolving and not staying in its corner without any updates etc.
6940
Features / Re: Fixing mismatched BBCode
« on December 6th, 2011, 10:58 PM »Oh, I see what you're getting at, misread it at first.
Also, Post2 is not the only place content updates are done (quick edit for example)
6941
Features / Re: Fixing mismatched BBCode
« on December 6th, 2011, 10:48 PM »
Look at Post2 -- if errors are found, we're ALWAYS redirected to Post().
The messages array is filled in Post2, and ALWAYS reset in Post().
Conclusion: the messages array is filled for no reason in Post2() when it should be done in Post().
That's why I'm upset -- coz I'm gonna have to move my code to Post() tomorrow... -_-
The messages array is filled in Post2, and ALWAYS reset in Post().
Conclusion: the messages array is filled for no reason in Post2() when it should be done in Post().
That's why I'm upset -- coz I'm gonna have to move my code to Post() tomorrow... -_-
6942
Features / Re: Fixing mismatched BBCode
« on December 6th, 2011, 10:33 PM »
Woohoo, this is messy...
Okay, I've finished implementing the checks. It works flawlessly :) Just needs to be optimized... Like, adding a cache for tags.
Unfortunately, Wedge/SMF isn't cooperating. In the sense that it doesn't allow posts to show more than one error of the same type... I'd *love* to know the logic behind that!
Here's what it does:
- Post2 generates an error. Later on, it will fill in $context['post_error']['messages'] with the errors, and $context['post_error'] with the error types.
- Then it calls Post() in Post to regenerate the original form.
- Post(), in turn, EMPTIES $context['post_error']['messages'][1] and attempts to regenerate it based on the error types...
Which means that not only do we lose any additional errors of the same type (it only generates only error message for each type), but we also lose any customizations done in Post2... That's ridiculous.
Now, logic dictates that I 'simply' get rid of the current Post() code and instead use the same code as in Post2. But the code is really shitty in Post()... I mean, there's only one possible error set BEFORE we re-parse 'post_error'. The only other reason to re-parse it, is because Wedge has detected we're previewing or editing a post, i.e. maybe we're coming from Post2... Look at the way the 'no_name' error is handled. In Post2, it's a string added to the list of errors. Then it's handled within the error parser. Then we go back to Post(), where this isn't done until we reach the error parser. At this point, the loop is actually doing the guest tests AGAIN, and adding 'no_name' directly to the list of parsed errors (instead of errors to parse), and... Oh well, it's hard to explain.
Suffice to say, it's really, really really fucked up. I'm so annoying, I'm actually going to let it go for tonight. And I really have no idea how to best handle all of this...
Pete? Any suggestions?
Okay, I've finished implementing the checks. It works flawlessly :) Just needs to be optimized... Like, adding a cache for tags.
Unfortunately, Wedge/SMF isn't cooperating. In the sense that it doesn't allow posts to show more than one error of the same type... I'd *love* to know the logic behind that!
Here's what it does:
- Post2 generates an error. Later on, it will fill in $context['post_error']['messages'] with the errors, and $context['post_error'] with the error types.
- Then it calls Post() in Post to regenerate the original form.
- Post(), in turn, EMPTIES $context['post_error']['messages'][1] and attempts to regenerate it based on the error types...
Which means that not only do we lose any additional errors of the same type (it only generates only error message for each type), but we also lose any customizations done in Post2... That's ridiculous.
Now, logic dictates that I 'simply' get rid of the current Post() code and instead use the same code as in Post2. But the code is really shitty in Post()... I mean, there's only one possible error set BEFORE we re-parse 'post_error'. The only other reason to re-parse it, is because Wedge has detected we're previewing or editing a post, i.e. maybe we're coming from Post2... Look at the way the 'no_name' error is handled. In Post2, it's a string added to the list of errors. Then it's handled within the error parser. Then we go back to Post(), where this isn't done until we reach the error parser. At this point, the loop is actually doing the guest tests AGAIN, and adding 'no_name' directly to the list of parsed errors (instead of errors to parse), and... Oh well, it's hard to explain.
Suffice to say, it's really, really really fucked up. I'm so annoying, I'm actually going to let it go for tonight. And I really have no idea how to best handle all of this...
Pete? Any suggestions?
| 1. | Actually, it starts by emptying $context['post_errors'] (note the plural) which is never used, meaning it's actually a typo... |
6943
Features / Re: Fixing mismatched BBCode
« on December 6th, 2011, 07:11 PM »
Actually, that's a very good suggestion you know...?
I probably wouldn't 'look' for the exact position of the offender, if only because that would mean writing a UI for it (:P) when I can just use SMF's post error box, but it's definitely something of a good idea: we could go through the list of bbcodes that expect a closer tag, and make sure they're there. If not, post an error message asking the user to fix it...
I guess for long posts it's going to be a pain to fix, but OTOH it's only going to be better because if a quote tag is broken and you don't fix it, you're upsetting all of your users. Better one person than everyone...! ;)
:edit: Go through all bbcodes except for those of the 'closed' type... Simple!
I probably wouldn't 'look' for the exact position of the offender, if only because that would mean writing a UI for it (:P) when I can just use SMF's post error box, but it's definitely something of a good idea: we could go through the list of bbcodes that expect a closer tag, and make sure they're there. If not, post an error message asking the user to fix it...
I guess for long posts it's going to be a pain to fix, but OTOH it's only going to be better because if a quote tag is broken and you don't fix it, you're upsetting all of your users. Better one person than everyone...! ;)
:edit: Go through all bbcodes except for those of the 'closed' type... Simple!
6944
Features / Re: Privacy options
« on December 6th, 2011, 07:08 PM »
Yes, contact list are pretty much like membergroups in SMF...
In fact, Noisen.com offers (or used to offer -- I think I disable it) the ability for users to create their own custom membergroups, for which they'd then be able to give proper privacy settings. It did work, but I felt uncomfortable giving users access to the admin area, even if just for that particular membergroup page, plus it was a bit confusing to end users anyway.
That's why I want to go between the two opposites - and use a technique that's closer to what Facebook and Google+ have.
I don't know if I'll go all the way Ajax to manage your lists, but I can sure give it a try...
Anyway, the poll's results are now clearly pointing towards a contact list solution, and I'll deal with that later this week. I just don't know if I'll do it before or after the selectbox rewrite...
In fact, Noisen.com offers (or used to offer -- I think I disable it) the ability for users to create their own custom membergroups, for which they'd then be able to give proper privacy settings. It did work, but I felt uncomfortable giving users access to the admin area, even if just for that particular membergroup page, plus it was a bit confusing to end users anyway.
That's why I want to go between the two opposites - and use a technique that's closer to what Facebook and Google+ have.
I don't know if I'll go all the way Ajax to manage your lists, but I can sure give it a try...
Anyway, the poll's results are now clearly pointing towards a contact list solution, and I'll deal with that later this week. I just don't know if I'll do it before or after the selectbox rewrite...
6945
Features / Re: Fixing mismatched BBCode
« on December 6th, 2011, 12:21 PM »AND.... Interestingly, the same code can be reused for proper quote de-nesting :)
Which makes me think... I've often seen cases of people (including me, TBH) surrounding quotes with two closers instead of an opener and a closer. I'm trying to figure out a way to fix these automatically, but honestly it's hard to tell... :-/