Wedge

No no I just made a mistake in my code, and didn't test because I don't have custom fields here.

I'll fix that ASAP but a bit busy irl right now.

[Commit revision 3ff1484]
Author: Nao
Date: Sat, 23 Aug 2014 00:45:58 +0200
Stats: 5 files changed; +29 (insertions), -29 (deletions)

• Sort of reverted the responsive menus I implemented earlier this year. Instead of moving menus to the sidebar automatically, which was a neat trick, I went for usability and left them where they are, instead developing all sub-menus below their parents, rather than on their side. Scrolling on mobile devices isn't an issue. The CSS bandwidth use remains approximately the same. (script.js, index.css, sections.css)
• Just for the record... This change is made possible by the fact that I moved all menu entries below the 'Home' menu item. I know that many of you wondered why I did this in the first place, well, that was for that. I just didn't take the time to finish this back then.
• Okaaaay, here's hoping I won't break anything by hiding #wedge overflows... Doing this is a media query is pretty much the only way to ensure it 'works' on mobile devices and doesn't annoy the rest of us. (sections.css, Wilderless/extra.css, Wireless/extra.css)

I don't suppose it'd help.
Seriously though, txcas -- I posted a suggestion right before your message. Why didn't you give me feedback on this..?

[Commit revision 50d5d14]
Author: Nao
Date: Thu, 21 Aug 2014 00:42:06 +0200
Stats: 3 files changed; +16 (insertions), -6 (deletions)

• Added privacy icons to profile edit pages, in addition to the profile homepage. I'm sincerely hoping custom fields will work, but these ones are completely untested. (Profile.php, Profile-Modify.php, Profile.template.php)
• Removed a few DB fields being loaded and never used. (Profile-Modify.php)

[Commit revision 1ab0d0d]
Author: Nao
Date: Mon, 18 Aug 2014 12:48:19 +0200
Stats: 1 file changed; +2 (insertions), -1 (deletion)

• Fixed wrong margins in Wuthering's responsive mode. (Wuthering/extra.css)

---

[Commit revision 92b02a5]
Author: Nao
Date: Mon, 18 Aug 2014 15:55:32 +0200
Stats: 1 file changed; +1 (insertion), -1 (deletion)

• More padding problems, this time on the homepage. (Wuthering/extra.css)

---

[Commit revision 6a38e88]
Author: Nao
Date: Mon, 18 Aug 2014 23:25:31 +0200
Stats: 1 file changed; +6 (insertions), -3 (deletions)

• Fixed clickable privacy icons on other people's profile pages. (You still couldn't have modified their privacy settings, but still...) (Security.php)

Anyone else?

I'm not much of a hook guy, didn't write many plugins either, so I'd rather trust people to add whatever hooks they need. If you think you have a use case, then go ahead.
BTW, hooks need to be added to ManagePlugins.php as well... I don't know why, there's certainly a good reason.

So... Hopefully I'll get some feedback on this. If not, at least writing my thoughts helps me sort them out a little.

Currently, Wedge does privacy[1] by storing data in different places. Profile privacy is stored in the profile owner's member data field (which is the perfect place for it, unless you start wanting to access this data from a place where ALL profile fields are requested, thankfully there aren't many), and topic privacy is stored in a field in the topics table, which is pretty much the opposite way of doing it: it's made with, in the mind, the idea that places that query multiple topics will want to access it, but nothing more, that is, you lose flexibility in favor of speed because you can't store multiple groups or lists or member IDs or whatever in it.

Now, a *privacy table* is something I left aside for as long as I could, because it forces me to:
(1) do a table join pretty much everywhere (okay, I can do a subselect from within {query_see_topic}[2], but I don't know if it'll hurt overall performance),
(2) insert a 'dummy' entry for each and every topic, including existing ones (which can be done through the upgrade script), meaning there'll be lots of useless data, i.e. id_group = 0 on the large majority of entries, possibly causing the same kind of performance problems that SMF has been having on large boards with the 'approved' bit. Meh...

But there are also other advantages:
(1) it can easily be extended by plugins (so that they can have their own privacy settings without the need for a new privacy table),
(2) speed could be better than any other solution, provided we cook up the 'perfect' system, and I'm afraid I alone can't build a proper efficient table,
(3) multiple privacy entries for everyone and everything,
(4) and it's cleaner.

So, I'm looking into preparing for that, and asking for feedback, suggestions, and alternatives I might have not thought about.

This is the preliminary, simplified privacy table structure I'm currently looking into.

wedge_privacy {
  int: privacy_type (could be profile, topic, media album, etc.)
  int: id_context (could be a topic ID, or a profile area like 'age', turned into a number...)
  int: id_member (member ID of the owner -- useful for profiles)
  int: id_target_member (member ID of someone who's given specific access to this, otherwise empty)
  signed int: id_group (could be: 0 for everyone, 1 for members, 99 for just the author, 100+ for a contact list ID, -1 and below for a membergroup)
  anything else..?
}

Maybe I should split privacy tables into two: one for topics, and one for all the rest... That way, the topic table wouldn't hurt performance for other privacy items.
Or, I could skip the whole 'have to have an entry for each topic', and add a flag to the topic table, saying whether it's a public topic (no privacy entry), or a topic referred to in the privacy table. I can't have it directly refer to a privacy table entry, as that would prevent me from adding multiple groups or lists for the topic.

Or if it's too complicated for you, just feel free to chip in regarding how you'd like me to deal with privacy on a user's point of view. For instance, do you like the idea that you can have multiple lists per privacy item (something I didn't even consider when I first built the feature, because I figured one could simply build a new list out of people you want to include from other lists, but then it can get crowded quick...), or individual member IDs per item (a feature that's actually already in Aeva Media, so I'll have to rewrite/force it into the new privacy system, but at least it's something you'll be familiar with).

In fact, I noticed this week (because I was looking into privacy settings for posting pictures of my kid) that Facebook (recently?) added a 'Custom' privacy setting which is really, really not all that obvious to the eye, but that pretty much allows you to do everything I'm planning to have... It doesn't have "Members" though (i.e. the ability to determine whether unlogged guests can see something), but it has "Friends of friends", which is something I'm not sure I want to have in Wedge... Well, you know, things like that, I'm all for your feedback, guys!

1.	And the simple fact that it's the ONLY forum system to do it AFAIK is quite upsetting! Although it's also one of these 'killer' features in the killer app that is Wedge, so it's both upsetting and reassuring for me. :lol:
2.	Thus something like SELECT id_topic FROM wedge_topics AS t WHERE ... AND (SELECT ... FROM wedge_privacy AS wp WHERE t.id_topic = wp.id_topic AND wp.privacy_type = PRIVACY_TYPE_TOPIC AND ((wp.id_target_member = {int:me} OR wp.id_group IN {array_int:my_lists_and_groups})... That looks VERY bad to me!