Wedge

I really, really don't have time these days, so can anyone (okay, CerealGuy) look into these potential issues?

- DoLogin() in Subs-Login accesses we::$user['ip'] (previously $user_info['ip']). I couldn't find any reference to we::$user being set during the login process, leading me to believe maybe we should use $user_settings everywhere across that short function. Can you find one reference to it..?

- On LT I've been marking topics as unread and noticed the number of unread counts was higher than before I reached said topic. I specifically rewrote the unread system to make sure it would keep track of it. Can you look into it and determine if I screwed up something..? :edit: Just tried on your last post on the BBC topic, and voilà, 9 unread posts... I definitely screwed something up then, because I'm positive that it used to work.

Thanks!

I just noticed that CerealGuy, who's been one of our (if not the) most involved contributor so far in 2015, and a damn fine guy to begin with, was never more than a 'regular' member, not even having access to our older private boards or testing grounds.

Thus, I'm making him a Friend, a Tester as well as a well deserved Global Moderator position.

Congrats ;) Hope you find some reward in that!

Test

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!

I just installed a fresh copy of Wedge on a sub-folder of wedge.org and then a sub-folder of cynagames.com (which is hosted at my old host), and... Well, I'm not getting the same speeds. The OVH (cynagames) version is much more responsive. It gives me the same parsing times (less than 0.1s per page), but I actually get pages fast.

So, quite obviously -- my current hosting isn't as good as I was hoping it would be. Well, honestly I wasn't really hoping -- because if it was half as good as I wanted, it would mean that *Wedge* itself is slower than SMF. Which isn't the case.
Unfortunately, I also realized that Wedge is slower than SMF 1.x, but there's a good reason for that -- SMF 2.0, while it added many nice features, is also very bloated: the size of all CSS and JavaScript files was multiplied by 4 or 5, or something like that. All I've been doing in Wedge was to try and make it faster and shorter. Because it relies on jQuery, it's never going to be able to catch up, but at some point I'll just have to be satisfied that it's (nearly) as fast as feature-light SMF 1.1 installs.

Anyway-- I was wondering if any of you guys were willing to share your web hosting space (preferably something very solid, with daily backups and so on!), because I don't know if there's any point in advertising Wedge when all people can see is that it's very slow for them -- before they actually even try to install it.

So, today I did a quick audit of my web pages, and noticed that PageSpeed Insights had AGAIN changed their algorithm... Okay.

As you may know, Wedge is the champion of web optimization, I spent enough time on making sure it was, and in earlier versions of PSI I was hover over 95% while the SMF-based competition was between 60 and 70%. All scores were lowered by a fair margin when analyzing an actual topic page, though.

Now it seems that with the new algorithm, and with page 1 of a random topic, SMF is at 53%/59% (Speed/User experience), ElkArte is at 68%/97%, and Wedge is at 78%/97%. Yes, BARELY better than ElkArte... Anyway.

Both Elk and Wedge have the same 'blocking' error: CSS blockers in the head, which end up delaying the page render phase. Okay, uh...
Seriously.
CSS files are supposed to be in the head. It's the standard thing.
Now what does Google suggest..? Moving them to AFTER the closing html page. Not kidding.

Okay, I'm not sure I want to do that. Why should I generate a FOUC just to please PageSpeed Insight..?
So I looked into doing something else to improve parallelism... Moving my assets to new domain names. Which would also eliminate the problem with cookieless domains. Which PageSpeed Insight does NOT care about, but the Chrome Dev tools "Audit" section does, so I'm doing that.

Okay, we're on topic now.

I started by doing some tests with the skin system's <replace> tag, but I don't want to have to update the custom.xml files on all of my skins every time I add or remove a subdomain, so I spent my afternoon working on a UI to implement page replacements. Just simple str_replace calls, that you can control from within the "Pretty URLs" admin page.

Cool, uh?

Well, it works.
But it has problems, which I want to discuss. (Putting numbers next to topics, so we can refer to them individually.)

1/ If I move all of my assets (+css+js) to a single subdomain, Google's Audit complains that there are too many resources loaded from that subdomain (!!). Solved by moving to assets, js and css subdomains.

2/ Looks like Wedge is still creating cookies on these subdomains, even though I modified the cookie admin option to no longer be 'global'. After removing that cookie (once for each subdomain), though, I have yet to reproduce.

3/ Relative URLs will no longer work, of course, inside CSS and JS files. Because you can't access the /assets/ folder from a css subdomain which is restricted to the /gz/css/ folder as its base, I was forced to remove relative URL optimizations, and regenerate my cache. Not cool. It definitely adds a few bytes to CSS files, although not THAT many...

4/ PageSpeed Insights is now... giving me more complaints about <head> links. Yayz. My score actually went (for the same page), down from 78 to 70%!!! Way to go!

What do you think?
Why do you think my score has decreased that much, even when it should have actually increased...?

I was just wondering...
Two years ago, I added some code to the Wedge installer so that it detects your browser's default language, and then proceeds to show you the most appropriate language for the installer (either English, French or German.)
I was updating that to add German (it was missing), and then it struck me that maybe it should be done in all pages for guests..?!

- Does the user have a preference set in a cookie or session variable? Then use that.
- Otherwise, attempt to determine list of favorite browser languages.
- If it's available as a Wedge language (usually, all browsers have at least English as a fallback anyway), then use the language with the highest priority.
- If not, then use the forum's default language. Or, if this one's not even set, then English.

That's basically what the installer does. It does take some time to execute (a preg_match_all on a short string, a strtolower, an array_combine, 2 foreach's and a short array sort), but probably less than a millisecond. I guess, ideally, that would be nice for non-English users.

What do you think, guys..? Worth the minor performance hit or not? Should I do this only on guests, or everyone?