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
6961
Features / Re: Privacy options
« on December 2nd, 2011, 12:24 AM »
Added a poll, and I encourage everyone to vote...
Very quiet here this evening...... :P
Posted: December 1st, 2011, 07:49 PM
Very quiet here this evening...... :P
6962
FAQs / [FAQ] Re: What is Wedge?
« on December 1st, 2011, 07:54 PM »
I've proven recently that a series of strpos calls could actually be faster than even a well crafted regex. The regex is still available for comparison in a comment.
That reminds me. Pete, could you deal with adding the prepare code to thoughts? It shouldn't be too annoying as they're only treated in Ajax.php. Or just remind me when I'm on my pc.
Added it myself...
Just one thing to note.
Before wedit::preparsecode, used in various places around Wedge, there's always an htmlspecialchars() call.
Well, while I'm wary of this kind of thing being done (because maybe it should be done inside preparsecode itself if we're going to make life easier for modders...), I did notice an intriguing detail: sometimes it's called without arguments, and sometimes it's called with ENT_QUOTES.
I have a feeling this is something that is due to different devs doing the code at different points in time, and maybe we should harmonize everything. Shouldn't we...? I'd suggest removing all ENT_QUOTES and maybe even push for ENT_NOQUOTES... Because I can't think of a reason to protect parsed BBC against quotes.
Also -- maybe add the double_encode param while we're at it?
That reminds me. Pete, could you deal with adding the prepare code to thoughts? It shouldn't be too annoying as they're only treated in Ajax.php. Or just remind me when I'm on my pc.
Posted: December 1st, 2011, 06:16 PM
Added it myself...
Just one thing to note.
Before wedit::preparsecode, used in various places around Wedge, there's always an htmlspecialchars() call.
Well, while I'm wary of this kind of thing being done (because maybe it should be done inside preparsecode itself if we're going to make life easier for modders...), I did notice an intriguing detail: sometimes it's called without arguments, and sometimes it's called with ENT_QUOTES.
I have a feeling this is something that is due to different devs doing the code at different points in time, and maybe we should harmonize everything. Shouldn't we...? I'd suggest removing all ENT_QUOTES and maybe even push for ENT_NOQUOTES... Because I can't think of a reason to protect parsed BBC against quotes.
Also -- maybe add the double_encode param while we're at it?
6963
Features / Re: Privacy options
« on December 1st, 2011, 01:25 PM »I'd love to see the results of EXPLAINs on those queries.
I should have copied the explains but they were nothing special -- just had the number of processed rows over 30k in the first two queries, and at 500+ in the last.
It's a tough call. How much is too much?Quote But if we start thinking this way, then we might as well drop the concept of topic privacy entirely...?
Basically, if you tell bloggers that they have to create a new blog for their private friends, they may say "okay", or they might just turn away and leave. I don't know, I just implemented stuff that people asked of me back in the day... And it seemed quite logical to do it.
The only issue with topic privacy, to me, is not really about performance, but mostly about not ever forgetting to add query_see_topic in every single topic query I'll have. That was a PITA, but I'm ready to do it again... (Especially since I now have the diff for that... And I've already decided that I'll mark every {db_prefix}topics as {db_prefix}topics_done or something so that once everything from the diff is implemented, I can simply look for {db_prefix} to find any remaining offenders...)
I thought 5.5 was actually a bastardisation of the 6.x branch anyway.
SOAP is... evil, and I'm not just saying that as a smelly hippie code hacker :P But if it's involving WSDL... WSDL is a language that indicates what services exist at a given URL, and what inputs are expected and what outputs will be given. It's sort of like XML-RPC but more convoluted IMO. (Yes, I've done SOAP work. It's not that exciting, but it should be manageable. It really depends whether you're doing it all by hand in PHP or using something like the Zend_Soap components.)
I don't know, if you're up for it and if you think you can help, would you be willing to help her by e-mail...? We already spent two evenings on the little fucker... (The first one was devoted to installing a virtual host on her PC, which didn't work until I realized the error code was 403 and I'd actually forgotten to add +Indexes to the httpd conf file... Oops. But she was like, "wow", when I fixed it. I liked that. :P)
*nods* And given that LJ is really not working out so well at the moment (it's not been the same since it was sold off a bit back), maybe we should be pushing that harder.
Yup, but we can still try and optimise as best possible for those cases.
BTW, did you ever check out the SQL queries for the thought system? I'm always afraid of forgetting something in them... Most of the stuff is in Ajax.php where I nearly committed something that would have allowed anyone to modify anyone else's thoughts just by editing their HTML source... Oops. That was scary.
6964
Features / Re: Privacy options
« on December 1st, 2011, 10:10 AM »
Okay, I tested all of these:
SELECT * FROM _messages AS m WHERE id_msg IN (SELECT n.id_msg FROM _messages AS n WHERE n.id_msg < 100000);
SELECT * FROM _messages AS m WHERE (SELECT 1=1 FROM _messages AS n WHERE m.id_msg = n.id_msg AND n.id_msg < 100000);
SELECT * FROM _messages AS m INNER JOIN _messages AS n ON n.id_msg = m.id_msg AND n.id_msg < 100000;
They all returned 685 entries on Noisen, so that's the exact same request being done. NOTE, though, that because both tables are the same, MySQL may be applying specific optimizations that wouldn't take place if using two different tables. You may want to rewrite the queries with two different tables and tell me your results.
The first query does a full table scan and returns in X milliseconds. The second query does the exact same full table scan, and returns in X milliseconds (sometimes a tad more but they're all very variable). Finally, the last query does an index search, and returns in X*2 milliseconds. It's also the most 'stable' of all queries, but it's stable in that it's always slower than even the slowest return time for the first two queries...
As a reminder, the messages table on noisen has 30k+ entries. I could do a test on Cynarhum.com (220k+ entries), but I suspect I'll get similar results overall...
Talk about clusterfuck!Quote from Arantor on December 1st, 2011, 12:26 AM Well, LJ has it, Blogger has it, etc... (At least the 'mature' flag.) What I don't like is that they always ask you to confirm your age, even if you're logged in. Meh. There's a news blog on LJ about Kaamelott, which I read from time to time, it has no 'mature' content at all (it's just an Arthurian legend show after all...), but I still have to confirm my age every time.Quote But if we start thinking this way, then we might as well drop the concept of topic privacy entirely...?Quote Nope, not backported. From what I gather in the link you posted, subqueries are implemented in 5.x in a way that they can't use an index, and it works in 6.x not because they fixed that bug, but because they rewrote their subquery code.Quote I didn't, until we dropped support for MySQL 4.0... And, turns out, I always hated doing inner joins...Quote My girlfriend suggested I use DISTINCT for these no later than last night. Funny ;) (Even funnier that our work fields sometime intersect...)
I'm currently helping her set up a SOAP client in PHP for a WSDL app at Oracle. Another clusterfuck, BTW... We have no idea what functions we're supposed to call (and AFAIK there's no way to request a list of available methods once the custom object is created), how we're supposed to identify, etc... Thank you Oracle for zero documentation. Plus it doesn't help that neither her or I have any prior experience with SOAP... :-/
I don't know why I'm mentioning that... Maybe there's a SOAP specialist around here :PQuote Well, that's already what I'm doing at Noisen and I know that some of my most faithful users have been using it... I can quote at least one blog that is reserved to the Friends list of a member.Quote Ah yes, you just reminded me why I'm looking up to them... LJ is the only blogging platform that actually encourages communication between blog authors, rather than having parallel blogs with their own comment authors and such. It's like LJ is a huge forum with boards set up as blogs, just like on Noisen. Back when I created Noisen (2007-2008), LJ was the only similar example, and I actually used them as an example of *why* it would eventually work. Noisen was pretty much supposed to be the 'French LJ'... Too bad it never really got momentum. I'm not very good at advertising my work. I prefer development work.Quote Well, if topic privacy is disabled, we're just not going to empty out the query_see_topic variable, so it won't be any slower...?Quote On bigger boards, at least.
Because that's the thing here... When we work with normal-sized boards, there's no such thing as a slow query. Start adding bot posters or scraping or simply have a hugely successful site, and you get your first performance issues.Quote Done...
SELECT * FROM _messages AS m WHERE id_msg IN (SELECT n.id_msg FROM _messages AS n WHERE n.id_msg < 100000);
SELECT * FROM _messages AS m WHERE (SELECT 1=1 FROM _messages AS n WHERE m.id_msg = n.id_msg AND n.id_msg < 100000);
SELECT * FROM _messages AS m INNER JOIN _messages AS n ON n.id_msg = m.id_msg AND n.id_msg < 100000;
They all returned 685 entries on Noisen, so that's the exact same request being done. NOTE, though, that because both tables are the same, MySQL may be applying specific optimizations that wouldn't take place if using two different tables. You may want to rewrite the queries with two different tables and tell me your results.
The first query does a full table scan and returns in X milliseconds. The second query does the exact same full table scan, and returns in X milliseconds (sometimes a tad more but they're all very variable). Finally, the last query does an index search, and returns in X*2 milliseconds. It's also the most 'stable' of all queries, but it's stable in that it's always slower than even the slowest return time for the first two queries...
As a reminder, the messages table on noisen has 30k+ entries. I could do a test on Cynarhum.com (220k+ entries), but I suspect I'll get similar results overall...
Talk about clusterfuck!
This seems like it's potentially *very* complicated and something I'm not entirely sure I want to get into, to be honest.
This sounds to me like overthinking for SCIENCE!
But the bug report was 3 *years* ago. I have no idea whether that's since been backported to 5.5 or 5.6 or 5.WTF any more. I think we need to try it sometime.
I believe it can be made to work like that but I'm not sure, I don't think in subselects very often.
It sort of depends, really. There are times it will, times it won't. It also depends on whether DISTINCT is present or not, which would solve the multi-row return case regardless of joins or in clauses.
I'm currently helping her set up a SOAP client in PHP for a WSDL app at Oracle. Another clusterfuck, BTW... We have no idea what functions we're supposed to call (and AFAIK there's no way to request a list of available methods once the custom object is created), how we're supposed to identify, etc... Thank you Oracle for zero documentation. Plus it doesn't help that neither her or I have any prior experience with SOAP... :-/
I don't know why I'm mentioning that... Maybe there's a SOAP specialist around here :P
Hmmm. Part of me thinks that's a wonderful idea,Quote The ability to create a blog for your professional friends... And another for your drinking buddies. (Same goes for topics, although less important.)
They're the only popular hosted blog platform I know of that still functions with a community aspect to it.
In the end, even as long as there is one line of code for it, it is going to be slower than SMF.
We can mitigate it (and given other things will be altered, it may even out in the end) but it must make a difference.
Because that's the thing here... When we work with normal-sized boards, there's no such thing as a slow query. Start adding bot posters or scraping or simply have a hugely successful site, and you get your first performance issues.
If anyone is reading this -- please tell us whether you think that it would be nice to be able to create contact lists (i.e. friends, family, work...) and whether you'd use the feature to fine-tune your topic/board privacy settings, or you just wouldn't bother yourself?
(New topic, perhaps?)
6965
Features / Re: Privacy options
« on December 1st, 2011, 12:06 AM »Personally I'd rather have 0 = everyone, 1 = me, 2 = members (since 0 -> nothing to limit, 1 -> I'm the only 1) but I'm not particularly fussed.Quote So we need to establish a list of privacy IDs and their corresponding meaning...
I'm starting with the basics:
1- everyone
2- members
3- just me (author & admins)
Other possible privacy values..?
"18 years old or older"
"13 years old or older"
Etc...
I'd say it's possibly better than having a 'mature' flag on posts.
The table structure seems straightforward enough to me.
As for when to do it, it should be done from the importer.
Oh hell yes. FIND_IN_SET is bad for a reason. Like the fact you cannot under any circumstances make a usable index on it.Quote Slower than its equivalent subselect with a secondary table?
You're right that it will cause a table scan, but only if the subquery is used IN () directly (this is not something I've done very often) but it's interesting to note that 3 years ago it was flagged as being solved in MySQL 6 as per http://bugs.mysql.com/bug.php?id=18826
Is this just in an IN () situation?
I mean, could it work with something like SELECT t.id_member WHERE (SELECT TRUE FROM wedge_other AS o WHERE t.id_member = o.id_other).....? (Just off the top of my head.)
But you need to be careful. INNER JOIN may be faster but you then have to process the results of a result-table that now has multiple rows, potentially many many rows you didn't want in the first place.
Anyway -- query_see_topic does an inner join, and it's fucking ugly because it makes inserting the query_see_topic variable more compatibled than, say, query_see_board. Having it use an IN() would make it much more elegant.
It's one of the reasons the board index query is fucked up, because it inner-joins the moderators table to the list of boards, so if you have 100 boards, each with 2 moderators, you get 200 rows back of which most of it is duplicated.
If the list's owner is stored in the table of contacts, why does it even need to be in the members table at all? Index the owner and you're golden.
Personally I just don't see the point. I can't think that many people are going to create topics that are visible to only a subset of a subset of friends.
If anyone is reading this -- please tell us whether you think that it would be nice to be able to create contact lists (i.e. friends, family, work...) and whether you'd use the feature to fine-tune your topic/board privacy settings, or you just wouldn't bother yourself?
Then again, I know it happens on LiveJournal which does make it a viable target for us (blogging context), I guess.
Consequently it must slow things down compared to a base SMF install,
6966
Off-topic / Re: Doctor Who
« on November 30th, 2011, 10:00 PM »
It didn't work for me but that's okay.
6968
Features / Re: Privacy options
« on November 30th, 2011, 04:15 PM »Not so important for Thoughts, but it is important for topic privacy.
I'm starting with the basics:
1- everyone
2- members
3- just me (author & admins)
This is what will be in the code for now.
I'm turning oThought's privacy array into an object so we can easily manipulate item position within the select box.
Dunno if 'everyone' should be set to zero, though...
It was, yes, which is why I didn't really get into it. Facebook is now sort of asynchronous, Google is asynchronous by design and creates multiple lists for you to be asynchronous with. But I think that might be a bit too complex for what's needed in Wedge.
Here's what I've come up with for now... Do tell me if it seems reasonable.
#
# Table structure for table `contact_lists`
#
CREATE TABLE {$db_prefix}contact_lists (
id_list mediumint(8) NOT NULL DEFAULT 0,
id_owner mediumint(8) NOT NULL DEFAULT 0,
PRIMARY KEY (id_list),
KEY member (id_owner)
) AUTO_INCREMENT=10 ENGINE=MyISAM;
#
# Table structure for table `contacts`
#
CREATE TABLE {$db_prefix}contacts (
id_member mediumint(8) NOT NULL DEFAULT 0,
id_list mediumint(8) NOT NULL DEFAULT 0,
is_synchronous tinyint(1) unsigned NOT NULL DEFAULT 0,
position tinyint(4) NOT NULL DEFAULT 0,
updated int(11) NOT NULL DEFAULT 0,
hidden tinyint(1) unsigned NOT NULL DEFAULT 0,
PRIMARY KEY (id_member, id_list)
) ENGINE=MyISAM;is_synchronous could be a boolean set to true if we find out that the target member also has you in their list(s). It's currently used in your contact lists, where they're separated by sync status. Also, 'position' is the position inside the list, which you can manually modify. 'updated' is the last updated date for the contact list -- although we could have both a created and updated field... Or none at all. 'hidden', as I mentioned before, prevents anyone (but the list owner) to see the name show up in the contact list.
Now we'll need to update the Import tool to actually convert buddy lists to contact lists (and automatically create a default list for every user that has at least one buddy.) I don't know if it's best to do it from the importer tool, or from within Wedge if the table is empty etc... I'd say the importer.
Thorsten, are you reading this? :P
If buddy_list is a single list of comma-separated users, it's queryable without having to do an extra query. It'll be slow, but it'll be doable.
The problem with subselects, is that they often (always??) require a table scan to complete, even if done on the proper index...
This is something that doesn't happen with INNER JOINs.
If it's *anything* else, we'll have to query it independently, decode it (I'm assuming unserialize), then build a query based on that. It's going to suck in performance terms.
It's still multiple lists to manage, and I just don't think that's entirely necessary. On a social network like Facebook or Google, where you're inherently sharing information that may be suitable for some but not all people, it's important to have that granularity. On a forum, it just isn't necessary.
I don't know about that. I think contact lists would have more pros and cons. And no one is forced to create multiple lists... It's just good to have them.
Heck... Either lists (id >= 10) or 'all contacts' is easily doable in a subselect. We either select id_members who are associated to our stored id_list (>= 10), or id_members who are associated with the id_member owner of the list. In which case it'd be best to store the list owner's id in the contacts table as well, to save time. Or just do a find_in_set on their buddy_list of course... But buddy lists are limited in size, unlike the contacts table.
Don't inner join. I get where you're going but inner join is a bad place to be. All of the queries (or at least, all the *important* queries that rely on topic visibility; there are many but the important ones like topic display for example) rely on having only one result returned, and inner join will generate multiple rows in the result.
Also, as I said above, from my experience, subselects don't use indexes. If you could help here, because you're the mysql specialist out of us both, it'd be nice to be able to use subselects, if only because it'd make life a hell of a lot easier when using {query_see_topic} in the code I'll eventually import from the Noisen diff...
It's hurting but you probably wouldn't notice it until you got to really huge boards with many many many topics.
Then again, it may never happen at all.
The only performance bottleneck I've been told so far, is the random list of items in the media homepage. That's because it retrieves all entries, randomizes them, and returns the first few. I still have an entry in my to-do-list to add a pseudo-randomizer variable in each item...
You know you're going to end up designing your own in the end...Quote I'm not making advances when it comes to the select box, BTW... I'm still unsure where to start from!
I should be getting ready to analyze the code for each plugin, and determine whether I can 'merge' at least two of them to get the 'best of both worlds' (or more.)
The last selectbox I suggested has issues in my iPod, as I already said. The keyboard problem is gone for now (now it automatically disappears a second after clicking...), but for instance, if you have a multi-select box, every time you click something in Chosen, the list closes and you have to reopen it... A 'regular' selectbox object will actually stay opened to let me select other options. Regular wins when it comes to accessibility...
6969
Features / Re: Privacy options
« on November 30th, 2011, 11:13 AM »No, I had a specific reason for 'just me + moderators'. There's a poor-man's helpdesk, there's for discussing reasons for bans etc, discussing 'application forms' on clan type sites. The list goes on, and it's much easier for us to implement it there in the core than it would ever be to bolt it on later.
Definitely not SMF.Quote - I'd like to have some user opinions on contact lists. Who do you think does it best? Noisen.com (if you ever used it)? Facebook? Google+? SMF?
It was kind of rhetorical. Noisen has asynchronous contacts, plus the ability to hide selective contacts from viewers. That one will be in Wedge too, once I get to implementing contact lists...
Because it wouldn't just be an extra table hit. If you want to store anything other than a simple number, you have to either implode it and store it inline, or you have to store it in another table, which means that's *two* extra tables vs what we have now, not one.
Although I'm not sure we'll be using that field much in the future... But IIRC there are reasons to leave it in.
If you start setting privacy settings on everything in your profile for instance, it'll be a disaster if you have to set multiple contact lists in each. I think it's much smarter to encourage people to put their 'safe' friends into a special list, and give that list all permissions, and deny the rest to anyone else -- guests, members and contacts that aren't in the safe list.
And believe me, the notion of putting an imploded field in the topics table is a no-no, seeing how it would make the entire topics table an order of magnitude slower because right now there are no variable-size fields in it, which is a very, very good thing.
I'm thinking of a structure like this:
wedge_members
...
contacts (1,2,3,4,5)
wedge_contact_lists AUTO_INCREMENT 10
id_member (id_owner?)
id_list
name[1]
description (?)
wedge_contacts
id_member
id_list
(possibly store the list's id_owner as well, not mandatory)
So when we check for a topic's privacy validity, we just retrieve its privacy setting, if <10 (for instance) it's a special setting like 'guests' or 'members' or 'just me' or 'just me + mods' or anything else we can think of, if >=10 it's a contact list, so we INNER JOIN wedge_contacts AS c ON t.privacy = c.id_list AND c.id_member = {int:myself}, or something like that...
Well, that's the basic idea.
If it's kept as a simple number, it's possible to solve a touch more efficiently, because what you can then do is figure out who the users are who have the current user as a friend, and turn it into (where topic starter = me OR (privacy = friends AND topic starter IN (list of people who friended me)).
Does that make sense...?
The one thing to realise about topic privacy, and this is quite important: it is going to suck compared to board privacy. It's unavoidable, because there's no way to do it in a way that adds extra conditions that can be evaluated without ORs (except in the just me or everyone cases) - ORs are bad for performance because they're an extra branch and often virtually a sub-query in their own right.
I'm not making advances when it comes to the select box, BTW... I'm still unsure where to start from!
| 1. | If a generic list like Friends, Family etc, store {friends}, {family} and use $txt[trim($name, '{}')] or whatever at display time. |
6970
Features / Re: Privacy options
« on November 30th, 2011, 12:49 AM »
- No, it's something else.
- The keyboard sometimes gets hidden automatically. It's still not very practical. Yet, it looks good, needless to say... But I'm sure we can do better. Heck, actually I'm thinking a lot about going for the 'Wedge menu' style, like John suggested... Plus, I just know myself, I'll probably just rewrite the whole thing from scratch... Maybe using ideas and samples from other libraries.
- Okay for moderators, you've convinced me they should be kept out. Still, I think it's best to leave that option aside -- just have 'Just Me'.
- I'd like to have some user opinions on contact lists. Who do you think does it best? Noisen.com (if you ever used it)? Facebook? Google+? SMF?
- Additionally, how would contact granularity hurt performance more than a general 'My Contacts' choice...? Considering we'll be hitting an extra table in every case?
- The keyboard sometimes gets hidden automatically. It's still not very practical. Yet, it looks good, needless to say... But I'm sure we can do better. Heck, actually I'm thinking a lot about going for the 'Wedge menu' style, like John suggested... Plus, I just know myself, I'll probably just rewrite the whole thing from scratch... Maybe using ideas and samples from other libraries.
- Okay for moderators, you've convinced me they should be kept out. Still, I think it's best to leave that option aside -- just have 'Just Me'.
- I'd like to have some user opinions on contact lists. Who do you think does it best? Noisen.com (if you ever used it)? Facebook? Google+? SMF?
- Additionally, how would contact granularity hurt performance more than a general 'My Contacts' choice...? Considering we'll be hitting an extra table in every case?
6971
Off-topic / Re: Aeva Media in Spanish
« on November 29th, 2011, 10:41 PM »
I'm sorry, I never watched the translation packages for AeMe.
Afaik if you can access the download album over there, that'd be where the latest versions are.
Afaik if you can access the download album over there, that'd be where the latest versions are.
6972
Features / Re: New revs
« on November 29th, 2011, 03:00 PM »
rev 1182
(4 files, 11kb)
+ Finally added the thought list to the welcome page. Fully working, hopefully... (Welcome.php, Welcome.template.php, index.member.css)
* Cleaned up profile area's thoughts page, if only because it's a bit complicated to fit edit/new links into that area... Will deal with that later for all Facebook-wannabe sites, although it's not a priority. I've spent wait too long on this feature, time to focus on other things... (Profile.template.php)
(4 files, 11kb)
+ Finally added the thought list to the welcome page. Fully working, hopefully... (Welcome.php, Welcome.template.php, index.member.css)
* Cleaned up profile area's thoughts page, if only because it's a bit complicated to fit edit/new links into that area... Will deal with that later for all Facebook-wannabe sites, although it's not a priority. I've spent wait too long on this feature, time to focus on other things... (Profile.template.php)
6973
Features / Re: New revs
« on November 29th, 2011, 02:36 PM »
rev 1181
(3 files, 3kb)
* Hide new/edit/delete buttons when interacting with a thought. (script.js, index.member.css)
! Various fixes to the sidebar thought editor. And yeah, they're totally obscure... (Ajax.php, script.js, index.member.css)
(3 files, 3kb)
* Hide new/edit/delete buttons when interacting with a thought. (script.js, index.member.css)
! Various fixes to the sidebar thought editor. And yeah, they're totally obscure... (Ajax.php, script.js, index.member.css)
6974
Features / Re: Privacy options
« on November 29th, 2011, 11:04 AM »Chosen is slick, really slick. It even works great on iPad.
Unfortunately, I tested it on my iPod and it has issues:
- there are graphic glitches inside the input boxes. Minor, but visible.
- because there's always a combo box, Safari will enlarge the page and focus on the input box. And because of that, you get the keyboard and you suddenly can't see the list of items at all... Good luck browsing it!
I'm not sure what the options on Noisen are.
Come to think of it... I doubt anyone even noticed the feature itself.
Go to any non-blog board index.
Find a topic started by you. Just below the title, there's a faint icon of a key visible at the left. Click it. There you go...
Now, click 'Groupes Spécifiques' (I'm sorry that it was never localized to English...), which means 'Custom Groups', and a new popup shows up to its right, where you can fine-tune your selection.
I think it's a pretty neat way of selecting privacy... And because I'm not going to keep 'groups' in the list anyway, I was thinking I could instead show a list of checkboxes for friends -- either a complete list of friends, or simply 'friend types', something I will probably add in the future (close friends, family, co-workers, etc.) I'm just not sure whether it'll be something that doesn't hurt performance, really.
Normal topic privacy setup would imply:
* topic starter only can see it
* topic starter and their contacts can see it
* topic starter and moderators
* anyone who can access the board
This should cover all the main cases. I don't think list of groups is needed, and I think that if it's down to the above, a simple number could deal with it.
- if we add a new option in the future and it should be placed before 'Just Me' in the list (because 'Just Me' is really the deepest level you could have), the select box would have <option>1</option><option>3</option><option>2</option>, to simplify. I'm not a big fan... Although, who cares :P
- friend granularity would be hard, or even impossible, with a simple number. Unless we give friend groups a unique ID for everyone (like, I'm new to this site, and the first friend group I'll create will have id #2356 because there are already 2000+ other contact lists), and we start these IDs above 3 or 4 (used for default, logged in members, and all friends.)
Maybe we could also have 'by default' a general contact list for everyone, created when they first make a friend, and then they can add their contacts to other contact lists (with their own contact list ID), mutually exclusive or not... hmm... It would probably make a lot of sense, and would certainly help with sql queries.
6975
Features / Re: New revs
« on November 29th, 2011, 10:48 AM »
rev 1180
(3 files, 1kb) (I remember the good old days when TortoiseSVN would report 3KB for the same amount of changes... It doesn't look as impressive now, but at least it's more honest :P)
! Profile link deletions and color replacements were broken when user had no cookie set yet. Thanks Pete for the report. (Subs-Template.php)
* Replaced the div tag for smileys with a shorter i tag, which is semantically a bit better, and will still validate when shown in inline text. Plus, well, it's shorter. (Class-Editor.php, Subs-BBC.php,
! The <ins> tag is rendered by browsers as underline, so it should be turned to a 'u' BBCode at conversion time. (Class-Editor.php)
(3 files, 1kb) (I remember the good old days when TortoiseSVN would report 3KB for the same amount of changes... It doesn't look as impressive now, but at least it's more honest :P)
! Profile link deletions and color replacements were broken when user had no cookie set yet. Thanks Pete for the report. (Subs-Template.php)
* Replaced the div tag for smileys with a shorter i tag, which is semantically a bit better, and will still validate when shown in inline text. Plus, well, it's shorter. (Class-Editor.php, Subs-BBC.php,
! The <ins> tag is rendered by browsers as underline, so it should be turned to a 'u' BBCode at conversion time. (Class-Editor.php)