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 - Arantor
5251
Features / Re: Fixing mismatched BBCode
« on December 8th, 2011, 12:39 AM »
Oh, I think that's pretty awesome :)
5252
Features / Re: Fixing mismatched BBCode
« on December 7th, 2011, 10:59 PM »
Works for me :)

Purely academically, is the goal for fixing mismatched tags so that it can be removed from the bbc parser? (If so, we probably *should* also route imported posts through this code too)
5253
Features / Re: Fixing mismatched BBCode
« on December 7th, 2011, 10:23 PM »
No, it can't. But it can set a global variable to be acted upon.

In any case there's more stuff that doesn't go through Post2 than just Aeva comments. Quick modify for one.
5254
Off-topic / Making a note for the future
« on December 7th, 2011, 08:02 PM »
Leaving this here as a note for the future: if I or someone else makes a paid work and people ask about it for free, provide this link: http://shouldiworkforfree.com/

It seems to answer all the difficult questions.
5255
Features / Re: Fixing mismatched BBCode
« on December 7th, 2011, 07:54 PM »
Shouldn't things like that be in preparsecode anyway?
5256
Features / Re: Extending the postbit/poster info
« on December 7th, 2011, 04:54 PM »
This can be done with minimal change to anything outside the Display code (for now) and also has no impact on the postbit in PMs, if done how I think it could be done. Of course, PMs would likely be updated to include similar code, then lMC itself could be overhauled in the future - but that's not something that has to happen immediately.
5257
Features / Re: Extending the postbit/poster info
« on December 7th, 2011, 04:03 PM »
Faster than what? Building a separate array instead of calling memberContext? I wasn't planning on doing that just yet, more just leaving lMD and lMC alone and just yanking out the details needed into an array to be used by the template. It would actually be marginally slower than the current solution, with the exception that it's actually much more flexible and wouldn't require any extra hooks to be set up.

Though that would pave the way for overhauling lMD and lMC in the future, of course. I really should sit down one of these days and figure out if all the stuff in lMC is ever used generally or just in the profile area (and if there's stuff only used in the profile, perhaps it should be broken out and put into the profile area)
5258
Features / Re: Privacy options
« on December 7th, 2011, 03:15 PM »
Quote
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...?)
The idea of hiding a membergroup is simply to prevent it showing up in the group key and/or the group listing, nothing more.

On the other hand, if it were turned into a global ignore feature to hide users who are a pain in the arse... that's something else entirely.
Quote
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...
It's not, parts of it are GPL, the rest is ambiguous. Plus, it's not the prettiest mod ever written.
Quote
I'm not sure about rewriting all of the membergroup-related queries to use an extra table though...
Of course, it would also get us rid of these annoying find_in_set calls...
Boards already does this anyway without FIND_IN_SET. There aren't *that* many other places where group membership is validated with that, are there?
Quote
I'd personally rather use the slower, but more 'natural' one. (Maybe it'll become a bigger issue if we ever have some successful installs.)
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...
Could always have {query_see_topic_join} and {query_see_topic_where} or similar. To answer your point, yes, {query_see_board} and its friends all rely on boards AS b being joined, just as SD/WD's {query_see_ticket} requires helpdesk_tickets AS hdt being joined.

Unless it's made into a subquery, it's impossible to avoid forcing a table join with alias.
5259
Features / Re: Extending the postbit/poster info
« on December 7th, 2011, 10:06 AM »
OK, new idea.

Inside prepareDisplayContext, the poster's details are pulled from memberContext. What if, instead of that, we did something smarter?

We already have a list of the people who have posted in a topic. Why not build - in memberContext or somewhere else - an array of the stuff we're going to display for them?

Instead of just throwing a reference to the relevant user's memberContext, we create an array for that user (to be referenced in the return from pDC) which has the list of items to be displayed, and in the order to display them.

The markup is already a series of li with classes, e.g. li.membergroup, we just create that in the array as the key, with the li contents as the array contents, then we can just render it consistently, and plugins can reorder it or insert things where they like with array_insert, provided that it's accessible via a hook (which there's no reason why it wouldn't be, hell, I see no reason why this wouldn't be done before the main post-getting query is done, so it would be done before display_main is called)

How does that sound?
5260
Features / Re: Privacy options
« on December 7th, 2011, 09:56 AM »
Quote
I guess I can still be convinced to use membergroups, but I'll need someone to debate with me
Whoever wants to argue that one will also have to convince me of it. It's just not a good idea IMO.
Quote
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...?
64KB is a lot of space, and it allows for a lot to occur. That said, there's no real reason why it couldn't be made a mediumtext as opposed to a text; everything I've seen indicates there isn't any real problem in doing that, in the same way that text values aren't stored in the rowspace itself but in a separate area, so too with mediumtext, the only difference is that mediumtext offers 3 bytes per row not 2 (but while theoretically 16MB is wonderful, you actually hit other limits before hitting that one, 1MB is the largest safe insertion value on most systems)

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')
Quote
This could be done today because the thought system is now ready to use (something Pete was adamant should be kept on Wedge.org)
Primarily because we use it so much. I post vastly more on there than I do on either Twitter or Facebook, for example.
Quote
@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..?
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.
5261
Features / Re: Fixing mismatched BBCode
« on December 6th, 2011, 11:19 PM »
Well, either it should set them and Post should use them, or only Post should be setting them.

Most of the point of Post2 doing anything like that is simply so that there will be something to force it back to Post, but if you're going to rip it out, make sure that there is some way not only to feed back to Post when there's a problem but that it can be extended by plugins too.
5262
Features / Re: Fixing mismatched BBCode
« on December 6th, 2011, 10:55 PM »
Oh, I see what you're getting at, misread it at first.

What I was saying is that IIRC there are circumstances where we end up at the post page, not at a creation step, and without having gone to Post2.

Also, Post2 is not the only place content updates are done (quick edit for example)
5263
Features / Re: Fixing mismatched BBCode
« on December 6th, 2011, 10:38 PM »
Well, the logic behind it is that you should only ever be receiving one instance of any given type of error. I can imagine any circumstance where - normally - you'd need multiple instances of the same message. Wouldn't you just format an otherwise generic message to include all the problem cases?

Remember that the post code - in that context - can be called from both Post2 and directly, and quite possibly other places that don't occur to me right now.

I'm not arguing that it's fucked up, but I'm not sure it's as fucked up as it might be.
5264
Features / Re: Privacy options
« on December 6th, 2011, 09:39 PM »
This wouldn't use the admin member group management area but be custom. It doesn't take long to whip up such things once we know what we're trying to build.

There's no way it would create a full member permissions profile, as that would massively overcomplicate something that doesn't need that level of depth. Permissions are inherently much simpler.

As far as implementing privacy goes, Nao already did a fair amount of the hard work before in Noisen.
5265
Features / Re: Privacy options
« on December 6th, 2011, 05:20 PM »
Quote
This will be tricky, combining all those A's, D's, and X's properly for people who are in multiple groups, where they might have A, D, and X permission on the same pouvoir.
Actually, you'd be surprised at how straightforward it really becomes. Gather all the groups a user is in, and gather all the A/D/X values for all those groups. Ignore any D values, so you build a list of the A values that there are, and then eliminate any Xs from the list. It's really not a massive amount of code in the long run.

The real problem isn't even figuring out ADX permutations, the trick is to make it parsable in a fashion that means it can trivially be dropped in (or at least, insertable easily) into some of the existing queries and to do so without killing performance. The real hurt is going to come on things like unread and the message index where you have to evaluate a lot of topics at once, and even the stuff I did in SimpleDesk (which is verging on scary-complex, because that's author+staff, which is a trivially definable group and isn't set per topic but per board) isn't as complex as this is.