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.

Topics - Nao
The Pub / PHP 5.4?
« on March 18th, 2017, 01:02 PM »
Since Wedge is 5.3+, maybe it's safe to simply up the min reqs to 5.4..?

The main advantage is the ability is use [ ] instead of array( ) inside the code. It's really just that.
I could also modify Subs-CachePHP.php to automatically replace [ ] with array() as needed. I can't be arsed for now.

I just checked, and 5.3+ is supported by ~90% of the user base, and 5.4+ by ~70%... Hmm. Then again-- what we care about is the current userbase, as I've long given up on turning Wedge into a popular engine. It's just the cool engine that people in the know use.

Anyway, I'm likely to go for PHP 5.4 + some support for PHP 5.3, but I can't be arsed to code said support for now. ;)
Bug reports / Couple things to look into...
« on March 18th, 2017, 11:25 AM »
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.

The Pub / How I miss the freedom of coding the easy way...
« on November 17th, 2016, 05:44 PM »
Quote from Nao on November 10th, 2016, 05:12 PM
Added a generically generic template for the generic purpose of showing generic text in the usual generic place.
Gosh, I should have done that years ago...
To hell with MVC! Anything that makes reading code is a plus of course, but if it makes WRITING code much more annoying, then it also kills spontaneity.

It's a bit like the language translation system... SMF does it with $txt['item_name'], when really they should do something like txt('Actual text'), and then call a function that checks if a translation is available for that particular string... Maybe a txt('Actual text', 'Context') allowing for multiple strings within different contexts, of course... Things like that. That would make it easier to just write plugins without having to bother about translations, and then anyone can translate any string that way (plus, they don't have to refer to a master file to get the original translation, and if the English version is modified, the translation will need to be updated otherwise the text will now show up in English -- in the current Wedge and SMF, a modified English string won't be updated at all in translated version).
Yes it's a bit slower at parsing time, but it's not a problem with Wedge, because all files are cached, and thus you can parse & run that function at cache time and not at runtime, and then save the cached file to something like 'Something.template.french.php', etc...

Of course, it's too late to do that now...
Off-topic / How did I miss that..?
« on September 13th, 2015, 03:31 PM »
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!
Off-topic / Windows
« on March 12th, 2015, 12:49 PM »
Okay, since most of the talk is unrelated to Wedge these days and devoted to Linux (of which I'm not a big fan......... Not that I'm a fan of any OSes these days), I'm also taking a break off it and trying to get a real project off the ground (by "real", I mean "not as fantastic and ambitious as Wedge, but one that people are actually willing to pay for.")

So I installed Visual Studio Community on my C: drive (because SSD!), which only had 11 GB of free space...
The installer said, "10 GB required". Good. Go ahead, I'm going to bed. This morning, I woke up to a disaster: VS obviously filled my entire C drive, and in the process many programs crashed... Except for the VS installer, which didn't seem to care.

Only, it had filled my entire drive (that is, NOT 10 GB), so I decided to uninstall that piece of crap because I don't like false promises, AND it filled my control panel's Programs tab with dozens of useless programs I didn't want, like their awful SQL Server... Or ASP.Net, etc.

Okay, so I installed VS automatically and ended up with 9.1 free GB, then after installing everything else one by one, I was at 8.8 GB... Yep. Then I rebooted, and was at 8.7. (My page file is fixed sized, so it's not related to that.) I launched the drive cleanup utility from Microsoft, and eliminated 1.5 GB of old backups and 1 GB of 'pending logs' as suggested by it, and after a reboot, I was at 9.1 GB. I'm not kidding you guys... I uninstalled XP Mode (1.1 GB), rebooted, and was at 9.1 GB again. This whole 'uninstall and cleanup' process is very cool, since I apparently got robbed of about 5 GB of disk space by Microsoft since last night.

And don't tell me to go for Linux, quite obviously from reading the other topic, it's even worse! :lol:
Also, when I removed XP Mode, Microsoft 'forgot' to remove the diff drive (8 GB!), so I had to remove it manually. Thankfully, I didn't forget about it myself... Now at that point, I'm at ~20 GB when I should be at 25 or 26, maybe more.

My question is: what the hell is happening with Windows and the C drive..? I never really looked into that one, because I'm mostly dealing with my data drive, but for instance, a few seconds ago I noticed my drive was at 24.6 (!!!!), then I refreshed, and it was at 19.4. Currently at 19.5. There's something fishy in here... And I couldn't find answers about that issue. So, are you aware guys, of anything that could cause these free space fluctuations? Is it Windows? Is it the hard drive? Do I actually have 25+ GB free space, and I just need to try and fill it somehow..?

Still at 19.5... :-/
Posted: March 12th, 2015, 12:44 PM

Also, it hasn't uninstalled ASP.Net since Windows Update is offering an important update for "ASP.NET Web Frameworks - Security Update for Microsoft ASP.NET MVC 4.0", and yes, I don't want to have ASP.NET anywhere near me, AND it's not showing up in the control panel as an installed program...!!
Test board / Merger 1
« on February 2nd, 2015, 12:13 AM »
Development blog / The obligatory Christmas update.
« on December 10th, 2014, 03:58 PM »
Ho ho ho, hello there! Merry something, I don't know if it's too early, I'm not too good at social things.

As you probably know from my earlier blog post, my life these last few months has been quite hectic, me being a new father and all. Of course, Wedge had to take a back seat and I focused more on real life. I guess when things cooled down a bit, I wasn't so much in a mood to work again, and decided to dive again into one of my other passions, and a much less brain-melting passion at that, movies and TV. Bought myself a new quality TV, and discovering the joys of 1080p. I even went to my local theater yesterday (for the first time in like, 2 years ?!), because I really wanted to watch Interstellar. Which I loved, if you're curious.

I also had a couple of requests regarding a 'proper' beta for Wedge. I'm not a strong believer in compartmentalizing versions or whatever, and with my current lack of time/interest, I can't bring myself to doing proper release control anyway. All I can say is: the day Wedge went public (and it's already been nearly a year!), I considered it not 'alpha', not 'beta', but simply 'public'. That is, ready for production use. You just need to keep in mind that if you want to use Wedge, it's in your best interest to install a Git client and keep a copy of the Wedge repo somewhere, so that you can upload updated files as they're made available.

Short of getting paid for my work on the software (and I have 4 years of expertise on the subject, without even including my SMF years, so I really deserve some kind of repayment), you'll have to settle on my occasional bursts of passion to keep the project going.

For instance, right after I came back from Interstellar, around midnight, I decided I couldn't go to bed after seeing scientists do their math, and I did mine. As a result, plugin authors should now be able to edit Wedge source files the same way they can edit SMF files through mods. This should, basically, save you the hassle of having to request for hooks wherever they aren't conveniently being offered to you. If you're a Wedge plugin author wannabe, but you don't like the idea of having to rewrite your SMF mods from the ground up, that feature might be of interest to you. Have fun! And don't forget that it's not finalized, so I may have to rewrite it substantially after I get some feedback.
Features / Let's discuss privacy openly!
« on August 18th, 2014, 12:20 PM »
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!
Features / Weaving feedback
« on June 6th, 2014, 01:23 PM »
I'd like to gather here all feedback regarding Weaving:

- Your opinions about the "back to the roots" redesign.
- Any bugs you might encounter.
- Any suggestions to improve it in any way you see fit, without removing the 'bare' aspect.

To participate, just switch to the Weaving skin, of course... :P

I'll start: hey Nao, why didn't you also remove alternate colors from posts...?!

My answer: okay, give me a break man! You, out of all people! I'm not trying to make the forum look bad. For now I'll just start with tests on non-topic pages, then we'll see about topic pages a bit later. Okay?
The Pub / Hosting
« on May 12th, 2014, 01:08 AM »
I just installed a fresh copy of Wedge on a sub-folder of and then a sub-folder of (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.
Development blog / Alphababy!
« on April 15th, 2014, 04:11 PM »
Next July, I'll be readying myself to transmit all of my geeky knowledge. Word by word, letter by letter. Okay, at first, it'll have to be diaper by diaper. I guess I can't have everything at once!

What does it mean for Wedge?
Well, being a dad doesn't imply I'll stop working on it, of course. It's not like my life has always been centered around Wedge, although I simply like to make people think it is. I usually spend a couple of hours a day working on it, and the rest of my days is just me watching TV, browsing Wikipedia or the iMDb and thinking, "I should really get started on Wedge!", and then doing so an hour before I'm supposed to go to bed.

So, yeah, I'll keep working on it. I just wanted to make sure, back in January, that Wedge was out of beta before the due date, simply because I was afraid I would lose interest after. Well, I won't. And I don't know if it'll be 'gold' by then. I'm already late for an official beta -- in fact, I was planning to go through official alphas first, but then I realized I couldn't be bothered to make GitHub 'releases' for these, and I decided that Wedge was, right now, in its 'official alpha phase', rather than 'pre-alpha'. Wedge is currently being used in production by quite a few forums, without much trouble, and I suppose it's just the perfectionist talking whenever I say it's not ready for mass consumption. In my mind, it never will be, but I'm still aware that Wedge, even with its many remaining bugs, is currently largely ahead of SMF, and (but your opinion here may vary) still superior to the pretty fine ElkArte. (If you haven't heard about it, just Google it.)

Anyway, please bear with me while I'm trying to deal with everything that's happening around me, and hopefully it'll all make for a better world in the end. Yayz!
Features / Cookieless domains and other things...
« on April 8th, 2014, 08:35 PM »
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...
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...?
Features / [Poll] Board status icons: what's the point?
« on March 27th, 2014, 07:50 PM »
Regarding "New Post is indicated where none exists", I'm interested in knowing if people actually use the board index icons (or "New" label) to determine where they have unread posts.

Personally, whatever the forum, on the homepage I'll only use either the recent topics, unread posts, unread replies and recent posts links. Or, if I have to deal with a board index, I'll look for the last post's date on the right of each forum.

As such, then, I could imagine using board icon transparency to determine whether a board is 'hot'. Even if you've already read it... It could simply take the latest post's date, and if it's older than a day, decrease icon opacity by 10%, if it's older than a week, decrease by 20%, if it's older than a month, decrease by 30%, if it's older than a year, decrease by 50%. To me, that would be more interesting. Maybe it'd encourage admins to 'revive' some boards that have less user investment, I don't know.

Yes, the issue mentioned seems to be a Wedge bug, probably related to a commit I made a few years ago where I was cleaning up some 'boardseen' links, and $_SESSION work on board read states. I just don't know if this 'feature' is something that other forums do because 'it's the natural thing to do', or because it's 'what others do, so let's do it too.'
Features / Poll: Default language
« on March 25th, 2014, 05:59 PM »
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?
Bug reports / Repo missing some history
« on March 24th, 2014, 01:25 PM »
I just discovered that I screwed up part of the SVN to GIT conversion of the Wedge repo.
I clearly remember deleting the /other folder from history, because it was renamed and other stuff, but apparently I used to have an /other folder at the beginning of history, which was then renamed to /root, but any files that are in /root at that point appear as if they were thrown into the repo without prior history (on November 1st, 2012 for the curious.)

Unfortunately, this includes install.php and install.sql, which are IMHO two important files.
I don't know what to do at this point... I still have a backup of the original SVN repo, but I don't know if it's worth converting it (again!) to GIT, and removing all history after November 1st, and then limiting the repo to the /other folder, and publishing that repo somewhere, as 'documentation' for those trying to blame some install history.

What do you think, guys..?