- Are you absolutely sure that fclose(fopen()) is better than touch()? Faster? More efficient?
It might not be if all I wanted to do were update the timestamp. But touch can't guarantee the file is also empty, and I'd sort of like cache.lock to remain empty.
- 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.
Pretty sure. Not all the function calls need to be removed, e.g. isReservedName() is still in use, and that's cool, I just rewrote what it checked.
The key thing was to nail reserveName, IIRC it was called, which is gone along with reserveWord. I didn't see a need to go back and rename every little function that happens to share a word with the old feature name.
- 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.
Yes it is to replace the old code to prevent * in user names.
- Still against renaming .wmenu() to .dome(), right? :^^;: Well, it doesn't cost anything to ask...
You do what you have to do. As long as it doesn't break anything I'm working on, that's cool.
- 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.)
Aside from the fact it's bytes that don't need to be there, there are times it will actually damage the content of the file being sent, potentially with attachments and CAPTCHAs and most of the time that one or other of these fail, that's the reason.
- In Subs-Members.php, $replaceEntities uses $messages[2]... Couldn't it just use $messages[1], and we skip the surrounding brackets in $entity_name..?
That's pretty much taken just from SMF. There was doubtless a reason it was done that way but I was never privy to it. If you're going to change it, be sure that it works exactly as before.
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.
Again, such refactoring is cool, but only if we're absolutely sure it doesn't break anything. I'm still not entirely happy about the dropping of ENT_QUOTES on subject titles 'because it made it shorter' with the caveat that we have to go and put it back again in some places as opposed to just leaving it alone.
- If we rename allowedTo() to we::can(), I'd suggest renaming isAllowedTo() to we::enforce(), a name that makes more sense to me...
That's just names. Makes no difference to me what it's called. It's logical, it works.
- Is manage_bans an existing permission, or one you added? I like that...
It's been there since 1.0.
- 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."
That's primarily your department
;) As long as I can call it, I don't much mind how I can call it as long as if I do call it, it works.
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.
When you have a proper nested array there, it looks natural. But when you have an array like that, doing it without looks more natural to me. Whatever works, I guess.
- 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?
Firstly, heredocs or nowdocs? heredocs support 5.2+ while nowdocs are 5.3+ only. The key difference is in variable use - heredocs support parsing of variables like double quoted strings do, and just for fun, they're also at least as slow as double quoted strings, if not even slower. And it breaks indentation because the ending of the heredoc must be the first thing on the line, without any exception.
I'm not a huge fan of heredocs, personally and would rather they have never been added to the language. Note that some variables can be declared with heredocs, some cannot (e.g. certain static things) while anything can with a nowdoc.
