Wedge

Well, good that you're aware of it. I like things clean. Enough work for translators already with the new strings... :)
Maybe we should do a script that takes all $txt[] strings and tests for them in the entire file set. If not found, add to a 'suspicious list' where we'll manually check that these strings aren't at least used in some more complex manners like string building ($txt['we_' . $string]), etc...It's very odd. If I just call we::init_user() and we::init_browser(), it works. If I load wedb without initializing it, it doesn't work. Does that mean we need to call a random method on the object in order for PHP to initialize it..?!Well, as it's a static object (at least static public methods...), with static variables in it, technically I guess PHP doesn't need to instantiate the object in the first place..? I don't know. I'm trying to learn.Yup, it's my only case of building a 'true' object, and making a 'clean' use of method visibility to simplify life for plugin/theme authors. It's actually what convinced me that objects can sometimes be more beneficial than procedural programming (I was fiercely opposed to objectifying anything before that... :P), but in the case of the system object, it's only static, it's not a 'real' object per se, although if you start moving allowedTo() over there, I guess it'll have to be... (Oh, how about a generic we::can(...) function? Lol.)I have no qualms with $user['permissions'] being private, actually I have no qualms with perms being moved to their own array outside $user, etc...I thought the comment next to that line sounded like you... What was the original implementation? I mean, if it's not using static late binding (because of compatibility), how did it do it? Multiple lines I guess? Can't bother to check it out...That's not what I meant... I had interest in seeing my IP's evolution over multiple messages, rather than my IP at the current moment. For instance, these days, my IP has been very static, it hasn't changed in weeks, perhaps months actually, even though officially I'm supposed to be on a dynamic IP... Things like that, I like being able to check. And I shall check that one. :PI feel for you. But just as my fellow Québecois cousins managed to gently bastardize French their own way, the 'main' language in here (as in 'used by the most people') is metropolitan French, i.e. they're the ones who have to take it on themselves to 'speak French' rather than Québecois when they want to address an international French audience. Same for the British... Because Americans can't stop thinking about sex, today the British have to speak American when they want to adopt a 'neutral tone'. Reminds me of that skit in The Meaning of Life... :lol:

Anyway! Can you check it out?You're welcome. I like to think my annoying diff reading sessions can sometimes help me catch a bug we wouldn't have found until much later otherwise. ;)Shorter function = more space for 'public' keywords, the very ones I complained about... :PDo you mean that this particular issue is caused by my topic privacy implementation...? Ooops. (Well, it's not even 'officially implemented' yet... And I doubt it'll ever be, because of all the performance issues we discussed?!)

It isn't planned. It's already there. We just won't distribute it until we enter the beta phase. ;)

It was written by TE by the way, not us, but wedge.org was converted very easily with it.

I see. Perhaps you forgot to add a static keyword to the variable? Which would be surprising...
Anyway, I can assure you that it works in all situations I tried.Lulz.

Okay, I'll be posting my comments on your latest commits here...

- ManageBans.english.php: this has exclusively $txt['ban_*'] entries, some of which are still present in other files. Do you think these other files have to be cleaned up, or they really need these entries separately from a custom loadLanguage('ManageBans') call...? It'd be nice to look into this.

- Actually a commit of mine...: I was wondering... Is ::getInstance() really THAT useful? I did a few class_exists('we') calls which I later realized return true not after calling we::getInstance(), but instead simply after loading the class file. Also, Wedge never actually requires getting an instance to treat it (for instance to get a list of variables or whatever, like I suggested in another post in this topic), so the only 'point' is to prevent getting two instances... However, it can also be done by providing a dummy __construct, a dummy __clone, and basically: what's the need for that..? Admins and users have no need for these, and plugin authors are unlikely to try and get an instance either (they'll 'do it' the way we do it, because they'll look at our code). So, I'd suggest simply having init() functions when needed (e.g. we object), and not bothering with calling new self() anywhere. Obviously, tested on PHP 5.2. One of the advantages is that you no longer need the strange call_array_func function call in Class-DB to extend the DB object. Because it doesn't do anything anyway... As you're more versed into objects than I am, please advise.

- Haven't tested your badge display order changes yet, but I was wondering... Couldn't my earlier system be replaced with yours? Or does it need both the display order thing and show_when stuff? (I'm not sure it can't be replaced with a negative value or whatever..?) I'm probably wrong, though. :)

- I liked, as a regular user, being able to view my own IP, so that I can determine if I'm on a dynamic or static IP. Though, it's also true that only power users would do that, and they'd usually have other ways to determine that... Or they'd own their own forum like I do, and check their IPs on them. ;)

- While I certainly don't mind you using British English in your comments (you are, after all, Her Majesty's subject), I'd like to point out that you're also using it in the language files (e.g. 'organise'), which is different -- AFAIK the language files are in US English, and British versions are to be provided in addition to them, not as replacements. I don't care what phpBB does, I just don't want to mix up British and US English, I already do it too much personally, but I have an excuse for that :lol:

More to (possibly) come later...

Good :)

Also please confirm that we::$browser now works as intended? It does for me. php 5.2 with apache 2.2.11.

rev 1822
(3 files, 2kb)

! Fixed class object instantiation not correctly initializing the browser array. (Class-System.php)

* Adding privacy tables to the list of protected tables. I think we should do a thorough check of all our table names before proceeding... (Class-DBPackages.php)

* Don't need to reset the permissions array at that point. (Still need to fix the fact that permissions can be tested against before 'we' is initialized...) (SSI.php)

@ Re: rev 1820, if we regularly update jQuery and jQuery UI, it'd probably be smarter to allow for plugin authors to link to an alias of these libraries, i.e. jquery.js and jquery-ui.js, which would then be redirected to the latest...? Or just rename the files.

I'll have a look when I'm on my pc.
Everything works fine for me locally, otherwise I wouldn't have committed. I'm very surprised.  Hopefully this won't represent the quality of my work in 2013 ;)

I probably forgot to declare the variables as static.
Can you verify it works if you do that? I'm pretty sure it does. 5.3 only allows NOT specifying the static keyword and still being able to access it.