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
6331
The Pub / Re: Trying something a bit new
« on February 24th, 2012, 06:23 PM »
Okay...

- A concept for you to play with: dynamic replacement of HTML code. In skin.xml:

<replace for="ie6,ie7">
  <from><aside id="sidebar"></from>
  <to><table id="sidebar" class="top"><td></to>
</replace>

It's just an example, because it'd be impossible to find the closing div, and thus to do a full replacement -- I think. Unless we do some recursive regex matching... I dunno. Without it, that would allow adding extra divs, but only if you could also match the next div opener to add a closer before it.

- removing tabs on a typical page will save about 100 bytes after gzipping. It's not something to be ignored, but it's not that much compared to a typical (small) page size of 5KB gzipped. About 2% worth...
6332
Other software / Re: Finally, they've made an announcement
« on February 24th, 2012, 06:17 PM »
I've just got a 'meh' to say, personally... Nothing to add until they release something. And mod sessions? What the hell? Are they so worried that SMF is insecure or what?

And what's MVCS, BTW? More pseudo-"dev talk" crap from actual business reps, like "Agile programming"?
6333
The Pub / Re: Trying something a bit new
« on February 24th, 2012, 05:30 PM »
Okay, I hope you won't mind too much but I've fixed some things that needed fixing in the skeletons, so it's possible that you'll need to fix them too in Wintage... At worst, you'll just need to copy some of the stuff from the Wine/skin.xml file.
Quote from Arantor on February 24th, 2012, 04:12 PM
For the info centre, InfoCenter.template.php. Under the <we:title> is a div with an explicit 8px height.
Ah, yes... I think I added that one as a quick hack to make it 'work' because the padding wasn't very good for this particular occurrence.
Even if Wedge is miles ahead of SMF when it comes to theming, templating and CSS, it still inherits a few of its oversized CSS so sometimes I'm just too lazy to look into what's breaking padding etc... :-/
Quote
Now put a single border around those items, with a 1px padding between the border and the content, and leave the content such that you can still put borders on the content that butt up against the 1px padding+border (e.g. the someotherstuff div has a gradient but a 1px darker border on it)
I see. Feel free to add a wrapper or remove anything... But technically speaking, it might also break other design possibilities. (For instance, breaking up a large div into several horizontal divs certainly makes it impossible to put a gradient on the first div and expect it to continue flawlessly in the following ones. Unless you set the parent div's position to relative and the children to absolute, and set a large height for the first child... Uh.)
Quote
i.e. replicating the Core layout.
I was more of a Babylon guy, myself, BTW :)
The first Noisen theme (back when it was running SMF 1.1) was based on Babylon. I still like it a lot.
Quote
Certainly late, but interesting idea. Personally, though, I'd rather strip the indentation instead of outputting it - simply because it should save a bit of bandwidth, no?
Well, it certainly would be feasable... Could even have an admin setting to determine whether you want 'correct' indenting (i.e. based on skeleton tabs), or bandwidth/CPU-saving indenting (i.e. nothing done), or bandwidth-saving indenting (i.e. removing all indents at run time, including the hard-coded ones.)
Although yeah, it's really indenazi territory at this stage... ;)
6334
Features / Re: New revs
« on February 24th, 2012, 05:21 PM »
rev 1382
(7 files, 8kb)

* Moved sidebar to the right in Wuthering. It basically shows that if you don't reproduce the custom macros from its parents, an inherited skin will use the default macros (and skeleton, and code overrides). It may be argued that they should inherit them silently just like CSS files, but right now I'm not sure about that. (Wuthering/index.css)

* Which brings me to... Warm explicitly requiring the sidebar macro rewrite from its parent (Wine). (Warm/skin.xml)

* And, while I'm at it, Weaving wasn't using the proper skeleton settings, with the sidebar block being incorrectly positioned in the HTML. I'm not even sure why it worked... Everybody keep this quiet all right? (index.template.php, skin.xml)

* Button bevel is now a 300x42 PNG instead of 200x42, as I found at least one oversized button (Moderation Filters page, French version) that was over 200px in width. It adds about 6 or 7 bytes to the final gzipped file. Can live with that for now... (images/theme/bevel.png)

* Indenazi. (Admin.template.php)
6335
The Pub / Re: Trying something a bit new
« on February 24th, 2012, 04:03 PM »
Quote from Arantor on February 24th, 2012, 03:29 PM
It is experimental, though, so it's ugly coding for now, but I did manage at one point to do a "#id reset extends something" which I thought was pretty neat :D
I felt the same, made the same for Wine when rewriting inheritance, but I had to get rid of it and it broke my heart. Good that you could add it, so it'll give an example to future skinners :)
Quote
But it is also interesting to note where there is styling stuff hardcoded - the gap between the catbg and the titlebg bars in the screenshot is not controlled by the theme - but by a hardcoded div in the template.
Really...? Is that something in Wedge you mean? Where?
You can rewrite title headers with a mixin, although I think they really need some kind of rewrite... (Perhaps just removing the default ones from the index template, because it's really not the same format as in skin files.)
Quote
Interestingly, it's not possible to truly replicate SMF's Core layout without changing templates, because there's no way I could find to wrap both the upper sections (the blue gradient area, the title area) with the navigation menu inside a single element, to get a border around both at once, because they're contained in two separate divs and the only parent is #wedge which contains the entire page.
Everything is doable in CSS... :niark:
Just that sometimes it's not worth it.
Posted: February 24th, 2012, 03:59 PM

Speaking about the skin system...
I was thinking about something a bit funny and idiotic. And very certainly too late in the process.
Having all template blocks behave as if they had no indenting at all, and then indenting them when outputting them, by using the number of tabs by which the block name is indented in the skeleton.
The code is already ready for that, since there's an 'indent' param in skeletons, I just thought it'd be neat to do it automatically based on the skeleton...
Of course, the only (and major!) issue is that it would require going through all existing templates and removing their base indenting.
6336
The Pub / Re: Trying something a bit new
« on February 24th, 2012, 03:13 PM »
Good!
6337
The Pub / Re: Trying something a bit new
« on February 24th, 2012, 11:46 AM »
Color changes can sometimes be done with a single variable change.

$main_bg = hue(rgb(235,235,255), 20%)

to...

$main_bg = #fcfafc

Save and upload.
Totally different results :)
You can set $main_bg in custom.css too, this ensures Wedge updates don't erase it.
Has other vars like $window_bg2 etc.
6338
The Pub / Re: Trying something a bit new
« on February 24th, 2012, 10:54 AM »
CSS only. No pngs for colors. Wedge is magic ;)
6339
The Pub / Re: Trying something a bit new
« on February 24th, 2012, 08:19 AM »
Lol. After all this time, it'll be fun to try and run Wedge with such a skin. Is it inherited or main?
We should try finding existing W words before relying on new terms but it's not important.
Maybe I should give guests the ability to change skins too. Via a URL var I guess?
6340
Off-topic / Re: New here!
« on February 24th, 2012, 08:13 AM »
A spammer I guess. I'll remove his account later.
6341
Features / Re: Privacy options
« on February 23rd, 2012, 08:25 PM »
Looks like you didn't compile the list I asked you to do... I know, I know, it's annoying for you too :P
Quote from Arantor on February 23rd, 2012, 06:45 PM
If it requires a FAQ rule, it's already broken :lol: OK, then, put it in and we can see if it's necessary or not (it's not like we can't remove it in a later version if needed)... making such a setting be taken care of is as simple as updating Load.php to check for !empty($settings['postmod_rules']) || !empty($settings['postmod_override']) or whatever you want to call it.
.....................
.......I don't really want to change your stuff :^^;:
Wouldn't feel comfortable doing so.
I can only suggest what I feel would be best.
Quote
We could certainly have a link to the moderation filters area from there. I don't like the idea of just configuring an option directly from the menu though.
I don't think I said that...?
Oh, possible re-ordering of the menus: (I'm translating from French to English from memory)
Features & Settings > Settings, Pretty URLs, Anti-spam
Moderation > Settings (currently 'Moderation' in 'Security & Moderation'), Moderation filters, and maybe a link to add a filter directly?

That would save us an extra entry... No?
Quote
There is, of sorts, an approval queue, yes. It's a table with a single column, id_msg. We don't track topics, only the messages themselves.
Hmm, I'm looking into it...
Topics have unapproved posts.
Boards have unapproved topics and unapproved posts.
I can't find any global setting with unapproved posts, contrary to what I thought... :-/
Only an unapprovedMembers variable.
It would seem to me that unapprovedTopics and unapprovedPosts variables would be good things to have, if only to make the queries faster.

Basically, I thought that we had unapproved_posts somewhere, so it was easy thinking: because a topic is a post, if there are no unapproved posts, then there are no unapproved topics, thus we can skip the test entirely.
Quote
Hmm, there's actually nowhere in the system to be able to activate or deactivate a filter. I guess one can be added, though.
On your time and your own terms, of course.
Quote
Quote
Then I think it should be 'acknowledged' at the very least, for instance in the rule settings, instead of 'Posting in...', have something like 'Creating new topic in...' or 'Sending new post in...'?
I guess. It's an extra string, but that's no biggie, of course.
That would be swell.
(And no, I don't particularly like to give you more work to do... I'm busy on my own things, too :P)
Quote
They're pretty nice, just I'd never thought of them before. On the subject of toggles, note that slideToggle and toggle do behave differently as far as forcing a state goes (slideToggle(false) does not do the same overall thing toggle(false) does)
Sure, and this just reminds me that maybe I should have done something else instead of simplifying your JS code to use toggle(boolean)... :^^;:
Quote
Yes. Query conditions are evaluated much as they are in PHP, from left to right with AND/OR working much the same way. One thing... the order that fields are used in conditions is normally supposed to be the same order that the components of a primary/other key are supposed to be, but it's probable they fixed that limitation some time ago.
Always good to know!
Quote
Ugh. My understanding was that if postmod isn't active, the checks shouldn't be performed. Anything contrary to that is a bug, especially since disabling postmod forced everything to be approved anyway. (It's not like us where clearing the rules leaves things unapproved!)
So... Shall we change these to use postmod_active all the time?
Heck... Maybe we could have a {query_see_message} as well. Why not? It'd be simpler -- just the 'approved' test. Although sometimes the tables have a different alias from 'm'...
Quote
Oh yes. And it's not directly solvable just by doing that either, e.g. cases of XSS injection attempts get foiled here.
Why XSS? If we're careful to replace 039 with a quoted single quote right before insertion, it shouldn't be a problem...?
Quote
I'm on the fence about that. Private messages are not private in reality, they are merely personal. Though the core doesn't allow the admin to access it, it also doesn't do anything to prevent it (e.g. obfuscation of the data)
Yes, and thoughts and topics, when set to a privacy of 'author', are not meant to be published. And thus, should be treated the same way as PMs, in my opinion. Unlike an unapproved post, which requires an admin to read them before they're available to everyone.

I mean, admins can't access anyone else's drafts either, can they...?
Quote
Sure it would still be run, but the table it's joining to would be similarly small, so you'd just get an empty column coming back. If the table's small enough to be in memory it's going to be fast.
But how could it be faster than a subselect that, first, doesn't always get executed (yeah, we could apply the same stuff to the left join, but it'd be quite tiresome), and second, uses the same secondary table so should effectively be as fast as the join...?
Quote
To be fair, though, those posts take less mental effort to do. They're also, typically, a *lot* shorter than my posts here. Besides, we're at the stage now where I'm doing a little bit of positive marketing without having to deal with "Post here and... and I'll fucking spank you"
I'm just surprised nobody mentioned that particular forum in here...
(Oh, and one thing you shouldn't mention to me is Kevin Smith. I stopped watching Comic Book Men #1 after 10 minutes, it was felt so... unnatural, scripted and just generally not funny and uninteresting. All of that in only 10 minutes, when you usually pack all of your good stuff into the first few minutes to catch the viewer's attention. I had high hopes. :-/
Quote
Quote
Of course, I *suppose* you thought of that because of Wedge.org's current implementation -- you're thinking that it'd be simpler to just give 'View thought replies' permissions to Friends, and 'View thoughts' permissions to everyone else... Right?
Correct. That's how it is here and that seemed perfectly workable to me ;)
Well, I don't know... I'd like external opinions, once again. Personally I think it's something that can be emulated by putting a privacy of 'groups' and an ID matching our membergroups, too. I'd like everyone to be able to determine whether their answers will be private or public, etc...

Oh, my. I just realized a thought privacy setting that SHOULD be mandatory in Wedge. "Me and the recipient", or something. Just like a mini-PM... And replying to such a thought would automatically set it as private, too.
Hmm, maybe it could be set within the 'author' privacy setting. i.e. if you reply another thought but set it to 'author', what good is it...? If it's just to say "Die, die sucker!", it's not very smart...
Quote
The thing is, privacy controls are wonderful - but they're also complex, no matter how you do them, unless your interface is totally geared to it - which is why G+ got it quite right,
I don't know about G+'s privacy features, I never actually used the thing (in spite of my account over there.)
I just know that Facebook's privacy settings are more extensive now than they used to be...
Quote
If I don't care whether people can see it, I'll post it as a thought. If I do care who can see it, I'll post it in the relevant board.
To each their own ;)
6342
Features / Re: New revs
« on February 23rd, 2012, 06:43 PM »
(Forgot a few files...)

rev 1381
(5 files, 2kb)

* Because I'm a maniac, and JavaScript can't be faster than CSS to hide something... Adding 'hide' classes to the various elements in the moderation filter wizard. (ManageModeration.template.php)

* Translation and typo fixes. (ManagePaid.french.php, ManageSettings.french.php)

! Fixed thought form buttons in IE7 and IE8. Can't make it work in IE6 for now. Screw it. (index.ie7.css, index.ie8.css)
6343
Features / Re: New revs
« on February 23rd, 2012, 06:40 PM »
rev 1380
(2 files, 1kb)

* Just recording privacy and tags fields for template/later use... (Display.php)

! SMF bug: loadBoard should now properly send back an error if you're trying to directly access an unapproved topic that you can't read. (Load.php)

- $context['user']['is_mod'] is set as an alias twice, without any reason. Actually three times, but the third time I'm not sure is useless. (Load.php)
6344
Features / Re: Privacy options
« on February 23rd, 2012, 06:19 PM »
:edit: Okay, that was a long post... Could you go through it and, while you're reading, compile a list of everything we're discussing in it, and what needs to be done, what needs to be further discussed, etc...? Because I'm feeling lost. And the more I talk about something, the less time I have to work on it ;)
Quote from Arantor on February 23rd, 2012, 05:29 PM
The only way to do it is to create a new rule.
And it's going to cause many people to ask about it... Then we'll make a FAQ rule, that people won't read... Then you'll give up and add a master setting :P
There's already a moderation entry in the main admin settings menu, so we could have the master moderation setting there, something like "Enable Post Approval and Moderation Rules", maybe something shorter, and depending on that setting, we show the moderation filters menu or not... (Although it's likely that you'll want to have it very much in everyone's sight for starters, if only because it's a powerful new Wedge feature...) (Well, that could be a good opportunity to set post moderation by default.)

One possibility I just thought of, to make post mod faster... We keep a list of unapproved posts, right? I remember seeing that setting in the code I dabbled with this morning. Well, how about we simply add, in query_see_topic, a PHP check to see if there are any unapproved posts... If anything's found, add the t.approved code as needed. Otherwise, skip it!
Quote
Though, I guess we could add a tickbox, but I think it's going to be incongruous and out of place (which is why I deliberately didn't go down that road, and tied it into the rules logic as it currently is)
Your logic itself is sound and very commendable. I'm more worried about our users' logic. And mine :P
Quote
As for disabling a filter without deleting it - why would you? Either it's not working for you and needs editing, or it is working and should be left alone.
I don't know -- just say you wanna test whether the filter is actually useful, so you disable it for a while, and if spam comes back or whatever, you re-enable it.
Or if a pre-moderated area is quite slow and you're going on vacation and want people to be able to post freely to it -- you disable it, until you come back and re-enable it without having to worry about re-entering a list of filters or whatever.
Quote
Yup, because you might decide to change the scope of the rule, e.g. you set it to new topics by accident but want to switch it to all posts.
Then I think it should be 'acknowledged' at the very least, for instance in the rule settings, instead of 'Posting in...', have something like 'Creating new topic in...' or 'Sending new post in...'?
Quote
As for 'posting in these boards', I couldn't think of a better way to phrase it. I suppose past tense is more correct, but the idea is to convey the notion that if the post is made in one of the boards you're picking (or not, depending on situation), that the rule will apply.
Your way of phrasing it is correct, it's just harder to understand on first use. It might be better with the suggestions I wrote above.
Quote
slideDown/slideUp didn't occur to me at all when building it, but I agree (having seen it used in the paid subs area too)
Yeah, I like them a lot eheh. I try and use them anywhere I can.
One of the annoying things with these JS toggles though (it's valid for both slide and immediate toggles), is that if you go back to a page (Back button) where you'd changed an opened div, usually the default opened setting will be reestablished and the default selection will stay the same (or the other way around), meaning you have to click once or twice to reset it the way you wanted. Anyway... It's just a minor tidbit, and something I never found a solution for.
Quote
SELECT ... WHERE stuff is always going to outperform SELECT ... WHERE stuff AND m.approved... unless (and only unless) the stuff in the first place excludes everything anyway. If there are any rows found by the stuff clauses, they will have to be evaluated by m.approved.
And if it only finds a few entries, it doesn't matter that m.approved is slow ;)
I noticed earlier today while making my commit, that I'd at some put put a query_see_topic at the beginning of a query instead of the end. Oops! I immediately moved it to the end, specifically because I figured it would be evaluated last and thus would be much less expensive. So I was right, right?
Quote
And... hang on... it is testing for m.approved only when postmod is active.
Yes, in many queries. But not all... Look at Recent.php, for instance. There are more like that. I left them as is because I figured we should discuss it first. (Believe me, I did most of the hard work this morning with t.approved stuff... Was a bit messy and I believe I managed to make it behave, but m.approved, oh man, don't tell me I'm going to spend my day on this so I'll just discuss it :P)
Quote
Can do if you like... it doesn't help that the rules are non typical because of the whole entity 039 thing,
Oh, my... That again? Oh, I try not to touch these with a 10-foot pole... It gave me nightmares so many times before. I'm so tempted to modify the import tool so that it converts all of these 39 and 039 entities to single quotes on the fly, but then I know I'll also have to review the entire Wedge codebase to try and make sure it doesn't keep sending these to the database... :^^;: (Heck, maybe we could hook into the wesql code to check for 'body parts' and replace 039 on the fly...)
Quote
I discovered this on sm.org in their showcase board when I was a Friend. I'd see topics in the message index I wasn't supposed to but because they weren't approved I couldn't actually see the topics themselves. loadBoard should deal with that AFAIK.
So it's the opposite of what I thought, right...? I thought that people wouldn't be able to see the topics in the topic list, but would be able to access them by ID...
Quote
Some will want to show multiple badges too - e.g. if you have multiple groups. It's not an easy thing to solve.
That's what I'm saying... An admin setting would be good for that. Even the SMF codebase refers in a comment to how there are several schools of thought on this...
It may be just a detail, but if it can save us from people asking for a plugin for this... And I don't even know if it'd be doable as a plugin anyway ;)
Quote
Quote
Hmm yes, that's the way it should be. I think I meant moderate_forum per se, though. Does giving moderate_forum permission to someone, also give them implicitly (or explicitly through code I couldn't find), the issue_warning permission...?
Not that I'm aware of. issue_warning is a regular permission in the permissions area.
Ah, bugger...
Then again, I'd tend to go to someone's membergroup and check permissions accordingly. But it's always unclear what moderate_forum does. Plus, SMF/Wedge tends to... be a bit lazy about it, and sometimes it adds allowedTo('moderate_forum') for something, where in other situations it won't...
Quote
In the same way that YaBB was Yet Another Bulletin Board, perhaps Wedge 1.0 should be codenamed YaSBS - Yet another SMF bug squished :P
More like YaPoS to me. Don't ask me what that stands for. :niark:
Quote
A subselect should be faster than a FIND_IN_SET, I believe.
If not, then there's no point in using extra tables and such... Imagine a whole world running on FIND_IN_SET... Lol, what a mess :lol:
Quote
Quote
Well, I suppose we could add something in loadBoard... Check $topic, and if it's filled, add a query_see_topic?
Yup, sounds like a plan - it would nail down a lot of edge cases that rely on that behaviour.
Okay, doing that right now.
Okay, done.
Interestingly, it was already done this way... I just had to add the AND {query_see_topic} to the INNER JOIN. Problem solved. Hopefully!
Quote
A table would be better but you still have to get the query running nicely, though having the option of subqueries should help.
It isn't exactly fantastic to add two tables (I suppose -- one for topics and one for thoughts), but it would probably be best if anything. Plus, allows for fantastic fine-tuning of topic privacy... I mean, if you can actually enter specific member names... Everyone will be over the moon! Another good reason to switch to Wedge :P

Oh, and reminds me of something... Maybe, MAYBE we should allow for topic privacy to be respected even by admins... I mean, somehow, it's exactly like private messages, or PMs sent to multiple recipients (in the case of "contact-list-based topic privacy").
Quote
Quote
Because topic privacy is unlikely to be used on a majority of topics, it would keep the table quite small. Maybe we could even get rid of any privacy fields in the topic table, and just do a LEFT JOIN but I don't think it's very practical to do, just a silly idea.
Doing the left join would probably be faster actually.
You think...? Because it would be run even if topic privacy is set to default... (Of course, it wouldn't return anything.)
Well, technically it couldn't be a left (or inner) join I think -- if it doesn't find anything, does it mean it's a public topic, or it's private but you can't access it...?
Quote
A healthy dose of computer addiction ;)
And I'm not even getting started on this forum I found through googling for 'wedge fork' a couple of days ago, 'anotheradminforum', where I was surprised to find you and a bunch of our members discussing Wedge and other things... And nobody even cared to tell me :P Of course, you *had* to post nearly 3000 posts over there in the last 4-5 months, which is more than your post output on wedge.org... And I thought you'd gone quieter over the end of the last year :P
Quote
Quote
But I'm not sure it's any good. I mean, why would I would people to be able to view something or not? I want authors to be able to determine that themselves... They're the ones who should know whether they want a thought to be public or private.
Consider it here. Who sets the rules about thoughts here? It's done based on whether you're a Friend or not... isn't that really the same thing as what I'm talking about?
Not really...?

My concept:

Admin: does nothing
Author: determines who can view their thoughts
User: views thoughts based on author's decision

Your concept:

Admin: determines who can view thoughts and replies
Author: determines who can view their thoughts... Well, APART from the people prevented from doing so by the admin
User: views thoughts based on author's and admin's decision

A penny for your thought. I believe in freedom of speech -- and thought. Admins could possibly disable the thought system (which I'm wary of -- considering I haven't even begun to implement this in the first place... not because of laziness but because of freedom), but I'm not sure there's a point in letting them determine that only a single membergroup can access thoughts.

Of course, I *suppose* you thought of that because of Wedge.org's current implementation -- you're thinking that it'd be simpler to just give 'View thought replies' permissions to Friends, and 'View thoughts' permissions to everyone else... Right?
6345
Features / Re: Privacy options
« on February 23rd, 2012, 05:32 PM »
Quote from Arantor on February 23rd, 2012, 10:50 AM
Maybe that suggests a rethink of how the moderator badge is applied is in order. Perhaps, even, have it in addition to (rather than instead of) the standard badge?
I don't know. It screams "admin setting" to me, because some admins will want two badges, others will want to show moderator badges, and others like me will want to show regular badges if available... :-/
What do you think?
Quote
They won't, it's a standard permission. But specifically it is a general permission, not a board one, so board level moderators never get the chance to have it in the first place (because that's the quirk of group 3 - it never has general permissions)
Hmm yes, that's the way it should be. I think I meant moderate_forum per se, though. Does giving moderate_forum permission to someone, also give them implicitly (or explicitly through code I couldn't find), the issue_warning permission...?
Quote
So yes, it's a bug - they have the power to see the warn button but not to actually use it.
Yay, a SMF bug :P
Quote
Sure it is, but as group 3 is special in other ways you can expressly do things with it that you can't with a bare allowedTo() check.
I'm giving up trying to understand what that group is meant to do/be... :^^;:
Quote
The only issue I have is with the FIND_IN_SET - but there's no way around it.
There's a way about it, it's using the contact table :P Which we'll do, as it's already in the DB...
Quote
Quote
After all, it's not like adding query_see_topic will break anything. It can be done gradually
I'm not used to features that can be added gradually :P
Well, turns out it was a quick implementation, eh...? Although, you know how I am, I'm still going to check every single occurrence of query_see_topic in the Noisen code and make sure they're in our code, and if not, that it was really not needed at all.
Too bad that the very first occurrence was in Display.php... Which spawned a discussion of its own ;)
Quote
Quote
I wouldn't be able to determine what's best, between "mirror from profile..", "mirror profile", "alias of profile..." or whatever makes sense.
I'll think about it, got a lot of personal stuff going on today :(
If anything, a help icon would be best. To take time and explain...
Quote
Point is: some queries that look like they need query_see_topic actually don't, because loadBoard should take care of them, or at least if loadBoard takes care of them, other places don't have to as much.
Oh, so THAT was what you were referring to... :lol:
Sorry, hadn't read this post yet, it was in a tab waiting for a proper reply ;)
Well, I suppose we could add something in loadBoard... Check $topic, and if it's filled, add a query_see_topic?
Quote
Quote
I just said that if we have to store an extra integer for the contact list ID, then we might as well enable Wedge to store a group ID in that same place...
*nods* But that's only really true for holding a single value - the minute you start trying to hold a relationship in there it's going to go to hell.
Hmm... A relationship, you mean a comma separated list?
Hey, how about we keep a table with proper relationships...?
{db_prefix}topic_privacy
id_privacy = unique ID
id_topic = topic ID
privacy = privacy type?
privacy_id = ID of group or contact or member, depending what's in the privacy type

{db_prefix}topics
privacy = privacy type?

The topic table could check for privacy type, and if != 'default', do a subselect on wedge_topic_privacy using its own topic ID, trying to determine whether we belong to the privacy_id list.

Because topic privacy is unlikely to be used on a majority of topics, it would keep the table quite small. Maybe we could even get rid of any privacy fields in the topic table, and just do a LEFT JOIN but I don't think it's very practical to do, just a silly idea.
Quote
The problem comes in when you query a table with such records, and actually retrieve the text/blob. In those situations, if you do any ordering, it triggers a filesort rather than an in-memory table.
Hmm, so it's definitely a no-no...
Posted: February 23rd, 2012, 05:29 PM

I really, REALLY want to know what you drink or eat to be able to answer things so quickly and so thoroughly.
I just can't keep up :P
Quote from Arantor on February 23rd, 2012, 10:50 AM
Yup. But in the case of thoughts at least, depending on permissions checks (which are basically free in DB terms), you can exclude things on a more granular nature, rather than on a permissions flag. Consider, if you do 'permission to view thoughts' and 'permission to view replies', the former obviates any need to query at all,
But I'm not sure it's any good. I mean, why would I would people to be able to view something or not? I want authors to be able to determine that themselves... They're the ones who should know whether they want a thought to be public or private.
Call it a dream or folly, but I want people to be able to think freely! :P :P
Quote
Oh... I just realised I'm a doofus (based on your earlier post), because I mistakenly thought it was the current user's friend list which is already loaded and available, rather than the topic starter's (which can't be done without some kind of lookup)
I think I lost you here :P Too many things being discussed...