Wedge

I mean, once it's created (through the first fopen/fclose call), why not just touch it..? Who's going to edit it and add stuff to it anyway..?I double-checked, and it seems to be all fine in the end. :)After some testing (sigh), .wmenu() and .dome() pretty much use the same amount of bytes in gzipped mode... It depends on other factors, but it's not worth doing it I guess.So, how about removing the ?> altogether..?SMF had plenty of lame regexes that I fixed over the years, so this particular one was probably built by someone who didn't know about (?:) (non-capturing parenthesis)...I don't remember that :P
But isn't entity fixing a feature of westr? So why not just rely on westr to call our thingies...? It's easy enough to set a method as a callback for preg_replace, after all.Then thus shall they be named... :PIt's not about what looks natural here, it's mostly about following the SMF guidelines.
There was a hickup in the SMF 2.0 query conversion in that they committed a 'bad' copy with lots of bad automatic replacements, and had to modify them manually, one by one, for weeks... I remember that. I also remember that's pretty much when they started taking a lot of space for any single query (like, 3 lines of PHP for a single line query...)

So, anyway, I've gotten used to SMF's way, but have no qualms with yours either. What do we call? "Anything goes for the query call indenting format"...?I said heredocs :POkay, then dropping the idea! I only got it after re-reading through the commits... Some areas were a bit unreadable due to the string effect.

Lots of time, so little feedback -- removing alpha tester badge.
User never even came back after that post... Removing badge.
No feedback, no badge.

I noticed today that jQuery released a beta version of v1.9 three weeks ago.
It removes a few features that Wedge uses (such as .hover()), nothing that can't be added back manually or just modified anyway, so that's good, and the uglified (packed) version, once zipped, is about 1KB shorter than version 1.7, which is good.
However, it's still 3KB more than jQuery 1.5... I thought their plans was to release a 'final' version for earlier IE compatibility (i.e. v1.9), and a 'semi-final' version for other browsers (i.e. v2.0), without any of the IE compatibility code. I honestly doubt that the IE compat code is more than a couple of kilobytes when gzipped, so it makes it unlikely that there are any filesize advantages in the end over earlier versions of jQuery. Bummer.
I don't see any bugs arising from the use of v1.5.2 these days, so I'd be tempted to call it quits and leave it at v1.5, but I'd like to get opinions on this.
Of course, 29KB versus 32KB isn't much in the end ('only' 10%), and I'd like to delve into the new features, but I don't know what's best for now.

I think I know why... There are two ways of making a singleton. One is static (the ones we usually use), one is dynamic (I think the editor somehow uses instances, would have to dig into it). Here's an example:
http://www.matthewelliston.com/php-singleton-database-class/
As you can see, this one has the getInstance() function too (it seems to be a common name for class init functions...), but it also uses $this inside the object itself. I haven't tried it, but perhaps it could also work if replacing all $this-> call with self::, I don't know, what I'm interested right now, is in the fact that I'm still learning about OOP and as a geek, I need to *understand* the inner workings of objects, rather than just "copy and paste code that I saw elsewhere and worked perfectly" (which, I'll admit, is something I've been doing a lot when it comes to objects... Trial and error is my thing, rather than reading docs :P)

So, I'm thinking that we could simplify these objects, maybe not even care about singles instances, because what's the worse that could happen...? A plugin calling for another instance of an object? Why? At best, it would simply not work. They can't "hurt" Wedge as far as I know by doing that. Generally speaking, my pushing wetem methods to public or protected statuses was only done to help plugin authors understand what methods are there for them to use, and what methods are part of the magic trick that they don't *need* to call (not that they can't look into it... They just don't need it.)

Actually, until a few months ago, I thought that ::getInstance() was some sort of magic function without the double underscore convention. It's only after making a google search on this that I realized it's not a feature, it's just a naming convention. And in my humble opinion (you don't see that one spelled out entirely a lot these days :P), it was created for objects that are actually instantiated (either once or several times), and just re-used by developers who made a copy and paste and rewrote the code to prevent further instances -- without really thinking about the fact that the function itself may not be needed. If you'll kindly look into our code, none of the Wedge files call ::getInstance() for anything else than object initialization. And some of these initializations are absolutely not needed. Again, just try removing all of the new self() calls, most objects will not only initialize fine, they will work the way they're expected to. And that's with PHP 5.2 enabled on my dev platform (I'll admit that it's best to use the lowest common platform for my testing, otherwise I'm bound to have issues in the future.)I can sense the tongue in cheek, but really it isn't the same thing. getInstance() means to me "get a pointer to that object", while init() means "initialize that object". The fact that getInstance() initializes the singleton isn't something we are to 'expect', it's a convention. If you're just a rookie programmer, you'll be puzzled by that call. I know I was when you started implementing it for wesql and others. I just didn't know what it was about. I let you do that magic because frankly it's quite harmless and I'll admit I didn't want to seem like a complete OOP rookie (which I was, I've never been comfortable with objects), but I know better now, at least when it comes to singleton concepts, and I think that we should cut rookies some slack and rename that to init() and only call it if the object actually needs some filling before being used ;)Mostly clarity, in my mind. And making me more comfortable with OOP, which in turns encourages me to use objects even more (given that I've already created quite a handful of critical objects for Wedge, such as wess, wetem and we, it's good time that I get comfortable with developing them further without relying on pre-existing code.)Do I have your go for moving allowedTo and isAllowedTo to we ASAP? (i.e. are you working on this right now yourself?)I thought you'd said that you'd managed to reduce it to something like 80KB but that it was still messy. So I figured, if it starts like Wess (an easily manageable 15KB file which progressively got new features added and ended up at 55KB, although not a mess this time ahah), I'm just trying to help and save you time.
I must say though, what you committed yesterday looks great, and I also forgot about some of the requirements you had for your object.I need to make a few things clearer, I guess.
- This month hasn't been easy on either of us.
- After your leave of absence (in terms of commits-ment) of several months, I kinda grew accustomed to being the 'guy in charge', so it's proven difficult for me to dive again into something I've never liked (proof-reading others' code), because eventually I'll always start nit-picking about this or that, not because it NEEDS to be said, but because I feel I'm wasting my time if I don't have at least a line or two to change. I don't know how you do it yourself, maybe you don't proof-read much of my code, I don't know, maybe you just don't feel the need to add your touch, in which case you're lucky, but in the end that's what I am: an annoying partner who's full of good intentions, but not exactly good at explaining them or justifying them other than saying it 'makes more sense'.

Your architect analogy reminded me of The Fountainhead... Or was it How I Met Your Mother :lol:No, actually I don't give a damn about filesize. ESPECIALLY when it comes to the admin area -- go crazy and waste as many bytes as you like over there, because it's a private area that has absolutely zero impact on overall server performance or bandwidth. You didn't see me complain about the addition of jQuery UI, did you? :P Nah, really what I thought is that maybe you shouldn't kill yourself over rewriting a class if there's already an acceptable solution out there. Then again, we're both all about challenge, aren't we..? We're long past the work-hour efficiency stage, otherwise we'd have released Wedge back in 2011, and our lives would be less complicated ;)Again, do as you like in the admin area. I'm just conservative on general forum page bytesize ;)
For instance, it's your job to determine that you'd rather use jQuery UI for the badge manager. Which is great. Then it's my job to determine that if plugin authors want to use that copy, they should access it through 'jquery-ui.js' in case we update the file.

Oh, by the way this reminds me... Why not follow the CDN setting for jQuery UI too? I mean, the same file is available through here as well...
ajax.googleapis.com/ajax/libs/jqueryui/1.8.24/jquery-ui.min.js (latest hosted version is 1.9.2)
And other CDNs like code.jquery.com, of course.
Or directly use that one only. I'm not 100% sure about it though, I'm not even 20% sure about it, because if we encourage plugin authors to use the CDN version, there's hardly a way to determine that they're not double-loading it -- IIRC Wedge deletes duplicate URLs, but we can't be sure they're not going to use a different CDN or version.
(Then again, the most likely conflict to happen is that people start making a plugin out of a JS script that also requires jQuery UI, and then they add another JS script that also requires it, and voilà, conflict...)

Oh, my head...!
What was I talking about already..?But permission error = security error, right...? Doesn't that warrant an immediate hack fix?I *did* understand that part, at the very least ;)As I said at the beginning of my post, ever since you went back in full gear, I've been having a very hard time catching up with your topics... And I actually stopped trying a couple of weeks after your numerous new topics. I just couldn't keep up, so I just focused on the new ones. It's hard. I guess I'm more of a "code first, ask questions later" type...

Actually, I think you should do that as well. Your code is always of the utmost quality, you have great ideas, you don't have to explain them and ask for opinions because we're always here telling you to do it. And whatever comes later -- well, at least you'll have done it, which is not something many people can brag about.

So, here are my other points... Most of them are not very interesting, but these are things that came to mind while reading the latest commit logs.

- Are you absolutely sure that fclose(fopen()) is better than touch()? Faster? More efficient?

- Since you removed the reserved words feature, well, rewrote it as part of the ban system, are you positive that you removed all occurrences of it that aren't needed in your rewrite? Doing a search on 'reserved' in the project sends me back a lot of results, some of which SEEM like remnants of the previous system to me... Can't say for sure, though.

- Also, is the code block at the beginning of isReservedName() the replacement for the extra code that prevented the use of jokers in a user name? I think it is, just want confirmation.

- Still against renaming .wmenu() to .dome(), right? :^^;: Well, it doesn't cost anything to ask... :whistle:

- I'm afraid I'm the one who tends to add empty newlines at the end of files... Is there something wrong with that? More odd HTML parsing? I tend to forget. One could also say, "just get rid of the closer tag"... No? (It was done that way in Class-FTP.php until you added it back, as far as I can see.)

- In Subs-Members.php, $replaceEntities uses $messages[2]... Couldn't it just use $messages[1], and we skip the surrounding brackets in $entity_name..? There's also a similar function, $fixchar in Dlattach.php, which could need your attention in a similar fashion ;) Oh, and $entity_replace in ManageMaintenance.php. And another $fixchar in Subs-Post.php... And two functions in Subs-PrettyUrls.php (entity_replace and fix_accents).

Makes me think it would be better to use existing functions for that, eh. I think westr has one... If not, we could make one. It would at least be faster than always redefining these with create_function(). Maybe just do a wide search for "& 63", that could be enough.

- We should do, for good, a template-wide replace of $scripturl with <URL>... It's so much cleaner, and it's no slower (probably a bit faster at this point.)

- Suggesting we remove $context['user'] entirely. Can do it if you want. It's about 215 matches, most of which should be done manually.

- If we rename allowedTo() to we::can(), I'd suggest renaming isAllowedTo() to we::enforce(), a name that makes more sense to me...

- Is manage_bans an existing permission, or one you added? I like that...

- From my changelog: "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."

- Noticed this in a few places...

+            wesql::query('
+               UPDATE {db_prefix}membergroups
+               SET ' . implode(', ', $clauses) . '
+               WHERE id_group = {int:id_group}',
+               $array);

Aren't we used to putting the final ")" on the next line, at the same level at 'wesql::query'...? I think that's how SMF does it.

- Sometimes, we define very long functions inside a string, and I was wondering if, for readability's sake, it wouldn't be more logical to use the heredoc syntax on these?

Oh, please... -_-

The usual answer for spam fighting: fill in anti-spam questions that are unique to your forum... This actually works, at least for spam bots. When it comes to human spammers, though, there's not much you can do but ban them...