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.

Messages - Arantor
2086
Features / Re: New revs - Public comments
« on January 5th, 2013, 04:10 AM »
Quote
- 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.
Quote
- 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.
Quote
- 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.
Quote
- 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.
Quote
- 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.
Quote
- 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.
Quote
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.
Quote
- 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.
Quote
- Is manage_bans an existing permission, or one you added? I like that...
It's been there since 1.0.
Quote
- 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.
Quote
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.
Quote
- 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.
2087
The Pub / Re: Context object?
« on January 5th, 2013, 02:58 AM »
Quote
And it works really... Just rename __construct() to getInstance(), and remove the other getInstance() function... Voilà, it works perfectly that way too.
I'm sure there was a specific reason for NOT doing it that way, but I forgot what it is.
Quote
As long as you only access an object with static methods or variables, you don't need to instantiate it. That's why I'm tempted to remove getInstance() calls and replace them either with nothing, or with init() functions when needed. It makes things clearer IMHO.
So instead of having getInstance() calls, we're going to have init() calls. Means the same thing, yes? But I'm still sure there's a reason why it was done the way it was done rather than what you're doing. I'm also a little annoyed at the sake of change for the saving of a handful of bytes with no other benefit as far as I can see.
Quote
Also, I'm becoming serious about doing we::can('moderate_forum') instead of we::allowedTo(), it does seem very readable and blends in nicely with the we::is() function.
At this stage I don't really care. The whole permissions system needs to be rewritten anyway.
Quote
Well, as long as it doesn't reach the size you had before..?
I'd be tempted to say, why not just use the default zip loading classes and be done with it..? What do you need that they don't support?
Well, 199KB for a badly written and unmaintained class. 18KB, given proper documentation, is quite pleasant, not to mention the fact that I will be able to ditch parts of the old package manager in return.

As for the default zip loading classes... I guess I'll just repeat this yet again.

1. They all seem to rely on having various extensions for PHP which may or may not be included. Usually they are not included.
2. I explicitly need to be able to retrieve files from the zip file without creating ANY temporary files. I absolutely need to be able to step through the zip and extract individual files without ever writing anything to the filesystem anywhere, because I need to extract a zip file by file, specifically so I can use FTP to upload it.

I have spent many hours on this now, and I'm getting tired of people questioning why I'm doing it or what I feel I need to do, especially given that I have explained this multiple times, as well as the fact that I've had enough people telling me I should just take the easy option and strip it out (which also removes any possibility of easy patching from the admin panel, completely and utterly outright).

So, I will say this one more time. I am doing what I am doing with zip files and FTP. If you leave me alone to do it, we get nice and convenient uploads of plugins, including mostly magic updating of packages (i.e. upload a new version, it figures out, disables the old one, cleans up its files, then adds the new one), and that opens the door for patching Wedge with periodic updates as and when they come out.

If I keep getting people suggesting that what I'm doing is not worth the effort and that I should rely on methods that might not be available for users, I will end up just cutting all that functionality entirely because I know from experience that I can't rely on the ftp or zip extensions to be available.[1]

Also, if you're shitting yourself about a couple of hundred KB in the install package now, you're going to go fucking nuts in a few weeks when I update phpseclib and use an unflattened copy of the code, where I haven't stripped all its extra spaces and whatnot, because I won't spend two days manually patching phpseclib, I'll just include it wholesale.
Quote
Can't we just do a backtrace on allowedTo() and catch the place where it's done wrongly, and then add a flag to disable permission testing if they're not loaded in the first place...?
What would be the point? I know exactly where it's done wrongly. I've known for months where it's done wrongly. I even documented it and explained what has to be done to fix it being called wrongly. You might as well just replace the one expression with false for all the good it will do - yes, it will stop throwing an error but it doesn't fix the problem that's been there. The broken logic will still be broken, it just won't show you an error about it, like it hasn't been doing since forever.

I will say this a fourth time. THIS IS NOT A NEW BUG SUDDENLY BECAUSE OF YOUR CHANGES TO WE::*. This bug is months old. The only reason you're even noticing it is because now the call is being made before permissions are loaded and it won't be trapped by the old test in allowedTo(). I noticed the error in logic in November, but it's months older than that. The logic is still fundamentally wrong, the fact it throws an error now is merely the result of changes that made an already existing bug more obvious.
Quote
Then maybe call that function again later when permissions are loaded, to 'confirm' the actual user rights. Seems feasable to me, and most importantly, it saves time.
Are you not reading the words I'm writing? Am I talking to myself here about how all this stuff works? Did you read the topic I have mentioned (twice now in this topic alone) that spells out the problem, why it's a problem and how it can be fixed?

It's not going to save time to have to re-figure out all the permissions for boards and topics. The only way to fix this is to rewrite, once and for all, how permissions works.
Quote
I don't like seeing you waste time reinventing the wheel just to avoid a minor hack... SMF/Wedge are full of hacks, that never killed anyone.
How is it reinventing the wheel to avoid going through the entire permissions stuff twice because it's fucking broken?!

Oh jesus I can tell how furious I am right now about how much effort I've spent and how much of a waste of time it feels like. It is what it is. Good night.
 1. And if anyone so much as suggests that I don't need to worry about FTP and that I can rely on chmod, I will visit them in the small hours, cut their heart out with a spoon, then stick their head on a spike, above a sign saying "This is what happens to people who think making software insecure is a good idea." I won't of course, but there is absolutely NO WAY IN HELL I will encourage this sort of behaviour. It's FTP/SFTP or not at all.
2088
Features / Re: New revs - Public comments
« on January 5th, 2013, 02:32 AM »
Just to summarise where the add plugin is so far, it's able to accept the upload to the system temp folder, validate that it is a zip file, validate that it contains a plugin-info.xml file and validate the basic contents/requirements (PHP, MySQL versions plus required functions), and present a choice to the user in the event that it matches a currently enabled plugin.

There's so much still to do but getting to this point has been enough for me for now.
2089
The Pub / Re: When can I download Wedge? / Where can I download Wedge?
« on January 5th, 2013, 02:30 AM »
And guess what you can't do in Wedge right now? :P
2090
Features / Re: New revs
« on January 5th, 2013, 02:20 AM »
(5 files, 1 added, 43KB)

Revision: 1826
Author: arantor
Date: 05 January 2013 01:19:57
Message:
! Fixing an Englishism for Americanism as all the language files are "American" English. I couldn't immediately find any others. (Help language file)
! More of the plugin upload system including the magic new zip unpacking in place tour de force. This is part one of many, I should imagine a fair amount of it, including progression into the next step of installation, is broken but I want to commit where I am so I can rest a bit mentally. Bloody colds. (Class-ZipExtract.php, ManagePlugins.php, Subs-Plugins.php, ManagePlugins.template.php, ManagePlugins english)
----
Added : /trunk/Sources/Class-ZipExtract.php
Modified : /trunk/Sources/ManagePlugins.php
Modified : /trunk/Sources/Subs-Plugins.php
Modified : /trunk/Themes/default/ManagePlugins.template.php
Modified : /trunk/Themes/default/languages/Help.english.php
Modified : /trunk/Themes/default/languages/ManagePlugins.english.php

@ Remember the zip extract library is 18KB, not to mention the fact that the rest of the changes are not simple - there's a bunch of refactoring bits in there too.
2091
The Pub / Re: When can I download Wedge? / Where can I download Wedge?
« on January 5th, 2013, 12:31 AM »
I wouldn't hold your breath on getting a public alpha any time soon, though. While we've had some positive feedback to the private alpha, there are currently a few major overhauls going on that will enforce any further alphas happening particularly promptly, namely the plugin upload system, the ban system and by all appearances the permissions system.
2092
The Pub / Re: Context object?
« on January 4th, 2013, 06:46 PM »
Quote
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..?!
I don't know how you're calling wedb...
Quote
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.
That's the thing... if it is a object with static variables, the variables don't exist until they are set as such.
Quote
It's actually what convinced me that objects can sometimes be more beneficial than procedural programming
They're a tool, nothing more. What they really do is allow common groups of procedural functions, especially if they have data that is common to those functions, to be grouped together in one place. Especially if that data that the functions want to share doesn't need to go outside the group - e.g. DB connection resource.
Quote
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.
Therein lies the subtlety. If you're the admin, you have the ability to issue bans, therefore you can see IP addresses... it's really only an issue for those who can't issue bans, and most of the time those people aren't the webmaster ;)
Quote
Anyway! Can you check it out?
Sure I can, when I handle my next commit. This one's a bastard, though. If I were to say that I made a synopsis of what it needs to do and that was a list of 46 items in a row to be executed. I'm barely 6 lines into the list and already that's another 100 lines of code on top of the 18K class I already wrote... I could be here a while.
Quote
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...
The original implementation was all about $smcFunc. Back in $smcFunc days, $smcFunc was an array containing the names of functions to call in certain circumstances. db_extend would load the file referenced, then extend the contents of $smcFunc to refer to the newly loaded functions. I pretty much just turned that into some crazy class thing, rather than doing what I should have been doing, which was trimming what wasn't necessary and making a more sane method of calling those extra functions.
Quote
Do 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?!)
I'm not entirely convinced it's 100% right in SMF either. The problem is that post approval is checked very, very early - and before permissions are loaded. This has actually been an issue for months, I first documented it here back in November (private topic, id 7677 in the team board), but back then there were no visible signs, because allowedTo() just returned false for it.

But now the bug is more visible. Checking whether we is defined won't fix it, because it will be defined, it just won't have had permissions loaded (which should *really* be a method of the class anyway)

There is a sort of cyclic dependency issue - we can't load permissions until we know what board we're trying to access, and we can't load the board without knowing something about permissions (since loading the board is when we figure out topic privacy and that's dependent on permissions). We could juggle the ordering around a bit, I guess, but really what we should be doing is overhauling it entirely and that would have other consequences that need to be attended to.

I've already outlined how I think it should be overhauled, both structurally and semantically but when I'm not stuffed up with cold and overflowing with zip file craziness, I'll explain how I think it should work, what the consequences are for the admin panel / permissions UI and the rest of the codebase are etc.
2093
Off-topic / Re: Happy New Years
« on January 4th, 2013, 06:20 PM »
Where's the dislike button? :lol:
2094
The Pub / Re: Context object?
« on January 4th, 2013, 01:05 AM »
Also, I looked at r1825. Thanks for fixing my typo :)

As to the other changes regarding the we object, the change of __clone, yes, technically it can be a void method though returning false is more 'correct'.

As to the other loading, it doesn't matter whether we::* is defined or not, because that's not really the problem. The problem is that the permissions haven't been loaded yet, and we::* doesn't deal with permissions anyway other than storing them. There should never be any reason to check permissions prior to permissions being loaded, other than the fact topic privacy is currently fatally broken.

I think I'm going to have to implement what I said about fixing permissions before, and restructuring it entirely. Ugh, not looking forward to that, but I guess it's got to be done. Let me tackle that job, because I know what I have in mind, and it has a lot more consequences than just the loading order.
2095
Other software / Re: Discussing Wedge on simplemachines.org
« on January 3rd, 2013, 10:17 PM »
Quote
The compromise, of course, on "rules for the forks board" was among the at-the-time team members.
Team members are decision makers on that board.
And there's the first problem: too many decision makers.
Quote
On top of that, by simply being the first to fork the BSD-licensed SMF 2.0 code, you helped the entire SMF community (including the SMF team) get their heads around what it means to have more community participation in SMF code development.
Except as we've seen, we've done it mostly in spite of SMF's attempts to engender such participation, not because of it. Yes, we've broadened awareness of what forks are, of what it means to have forks - and to have competition. But in the same breath, we've heard from a number of people who feel that - however wrongly that might be - such rules and restrictions on discussion are in fact a way to protect SMF from Wedge, because it is perceived to be a threat.

I will also note that certain other things have happened today that make my previous posts in this topic look extremely harsh, and unnecessarily so, and on the basis of that I am more amenable to it than I have been in the past. Indeed, I'm not even sure I'd describe one of the two parties ostracised from Wedge as I did above, because he has more humility than I'd ever have believed. It is not an exaggeration to say I am humbled by what I have seen today.
2096
The Pub / Re: Context object?
« on January 3rd, 2013, 10:07 PM »
Quote
- 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.
Yup, I'm aware of that. They are going to be cleaned up in due course when I finish the rest of the UI. Mostly it's going to be pushed to the ManageBans file, the only stuff actually needed in the main admin language file is stuff that is needed for the main admin menu itself.
Quote
- 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()
Well, it's sort of required, if you're not calling getInstance(), you need to do something else to instantiate it and its content. Just loading it isn't enough.
Quote
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 if you don't get the instance, how exactly does it get any of its content? Just loading it is not enough.
Quote
so the only 'point' is to prevent getting two instances...
That's the other aspect to it. Really though it's about a sense of correctness as well as anything else. The whole point of creating singletons as true singletons is to prevent them being abused, in particular around the class properties.

Classes aren't just a specific way of breaking functionality up, they're also there for protecting class parameters from outside the class. For example, the template list can only be modified from within the wetem class. In the case of user information and permissions, I'd argue that we::* should be keeping that as a private member if it isn't already, because there is no reason the permissions need to be exposed outside the we object except for allowedTo(), and arguably that should be a method of we::* anyway, as should loading permissions really.
Quote
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.
I've been tempted more than once to rewrite that in some fashion to clean it up, it's mostly a thinly veiled port of how it was done before.
Quote
- 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.
Your earlier system just got a little supersized. All I did was put a UI to what you'd implemented with show_when and then been able to set the *order* of badges to be displayed. For example, I know one site that uses a forum to manage its software development, and there are teams such as Map-Maker, Graphic Designer, Administrator and some others. This way, they could put the badges in whatever order they liked, regardless of what the user's primary group may actually be - that other forum puts them all in alphabetic order for example.
Quote
- 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. ;)
I give you http://www.whatsmyip.org/
Quote
- 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:
That's mostly just a mental lapse. It's hard work for me to consciously use bastardised English.
2097
Features / Re: New revs
« on January 3rd, 2013, 05:12 AM »
(5 files, 2KB)

Revision: 1824
Author: arantor
Date: 03 January 2013 04:11:14
Message:
! Protect all the instances of calling plugin XML files against XXE. (Admin.php, ManagePermissions.php, ManagePlugins.php, ManageSettings.php, Reports.php)
----
Modified : /trunk/Sources/Admin.php
Modified : /trunk/Sources/ManagePermissions.php
Modified : /trunk/Sources/ManagePlugins.php
Modified : /trunk/Sources/ManageSettings.php
Modified : /trunk/Sources/Reports.php

@ If anyone asks me what XXE vulnerabilities are, I will explain. For now, just understand that it is a vector of vulnerability that SMF does not have because SMF doesn't use SimpleXML and we do; SMF, because of its history, rolled its own XML handling class while SXML is installed by default on PHP 5 and we can make use of it as such.
2098
Features / Re: New revs
« on January 3rd, 2013, 03:54 AM »
(90 files, 4KB)

Revision: 1823
Author: arantor
Date: 03 January 2013 02:52:40
Message:
! Lots of loose bytes saved. (many files)
----
Modified : /trunk/Sources/Admin.php
Modified : /trunk/Sources/Ajax.php
Modified : /trunk/Sources/Announce.php
Modified : /trunk/Sources/Boards.php
Modified : /trunk/Sources/Buddy.php
Modified : /trunk/Sources/Class-DB.php
Modified : /trunk/Sources/Class-Editor.php
Modified : /trunk/Sources/Class-FTP.php
Modified : /trunk/Sources/Class-System.php
Modified : /trunk/Sources/Credits.php
Modified : /trunk/Sources/Display.php
Modified : /trunk/Sources/Dlattach.php
Modified : /trunk/Sources/Errors.php
Modified : /trunk/Sources/Feed.php
Modified : /trunk/Sources/Groups.php
Modified : /trunk/Sources/Home.php
Modified : /trunk/Sources/JSModify.php
Modified : /trunk/Sources/JSOption.php
Modified : /trunk/Sources/Like.php
Modified : /trunk/Sources/Load.php
Modified : /trunk/Sources/Lock.php
Modified : /trunk/Sources/Login2.php
Modified : /trunk/Sources/Logout.php
Modified : /trunk/Sources/Mailer.php
Modified : /trunk/Sources/ManageBans.php
Modified : /trunk/Sources/ManageBoards.php
Modified : /trunk/Sources/ManageMaintenance.php
Modified : /trunk/Sources/ManageMembers.php
Modified : /trunk/Sources/ManageNews.php
Modified : /trunk/Sources/ManagePlugins.php
Modified : /trunk/Sources/ManageScheduledTasks.php
Modified : /trunk/Sources/ManageServer.php
Modified : /trunk/Sources/ManageSmileys.php
Modified : /trunk/Sources/Memberlist.php
Modified : /trunk/Sources/Merge.php
Modified : /trunk/Sources/MessageIndex.php
Modified : /trunk/Sources/ModerationCenter.php
Modified : /trunk/Sources/Modlog.php
Modified : /trunk/Sources/MoveTopic.php
Modified : /trunk/Sources/Notify.php
Modified : /trunk/Sources/Packages.php
Modified : /trunk/Sources/PersonalMessage.php
Modified : /trunk/Sources/Poll.php
Modified : /trunk/Sources/Post.php
Modified : /trunk/Sources/Post2.php
Modified : /trunk/Sources/PostModeration.php
Modified : /trunk/Sources/PrintPage.php
Modified : /trunk/Sources/Profile-Actions.php
Modified : /trunk/Sources/Profile-Modify.php
Modified : /trunk/Sources/Profile-View.php
Modified : /trunk/Sources/Profile.php
Modified : /trunk/Sources/QuickMod.php
Modified : /trunk/Sources/QuoteFast.php
Modified : /trunk/Sources/Recent.php
Modified : /trunk/Sources/Register.php
Modified : /trunk/Sources/Reminder.php
Modified : /trunk/Sources/RemoveTopic.php
Modified : /trunk/Sources/Report.php
Modified : /trunk/Sources/Search.php
Modified : /trunk/Sources/Search2.php
Modified : /trunk/Sources/Split.php
Modified : /trunk/Sources/Stats.php
Modified : /trunk/Sources/Subs-Admin.php
Modified : /trunk/Sources/Subs-Auth.php
Modified : /trunk/Sources/Subs-BoardIndex.php
Modified : /trunk/Sources/Subs-Boards.php
Modified : /trunk/Sources/Subs-Captcha.php
Modified : /trunk/Sources/Subs-Editor.php
Modified : /trunk/Sources/Subs-Login.php
Modified : /trunk/Sources/Subs-Membergroups.php
Modified : /trunk/Sources/Subs-Members.php
Modified : /trunk/Sources/Subs-MembersOnline.php
Modified : /trunk/Sources/Subs-Menu.php
Modified : /trunk/Sources/Subs-Moderation.php
Modified : /trunk/Sources/Subs-Post.php
Modified : /trunk/Sources/Subs-PrettyUrls.php
Modified : /trunk/Sources/Subs-Sound.php
Modified : /trunk/Sources/Subs.php
Modified : /trunk/Sources/Subscriptions-PayPal.php
Modified : /trunk/Sources/Themes.php
Modified : /trunk/Sources/Thoughts.php
Modified : /trunk/Sources/Unread.php
Modified : /trunk/Sources/UnreadReplies.php
Modified : /trunk/Sources/ViewQuery.php
Modified : /trunk/Sources/Who.php
Modified : /trunk/Themes/default/ManageBans.template.php
Modified : /trunk/Themes/default/ManageBoards.template.php
Modified : /trunk/Themes/default/ManageMedia.template.php
Modified : /trunk/Themes/default/Themes.template.php
Modified : /trunk/Themes/default/index.template.php

@ This is literally cleaning house after that big ol' find/replace operation. Whatever tool was being used, when it was told to use Unix format, it was using strict Unix format, which says there must be a blank line at the end of the file >_<
2099
The Pub / Re: Context object?
« on January 2nd, 2013, 11:57 PM »
I haven't got PHP 5.2... haven't had it in almost a year... but back a year or so ago I was trying to make a weusr object and it wasn't working :/

If it's working for you, it'll almost certainly work for everyone else. But I'm going to be doing some real testing on real hosting before long (not a VPS I have total control over)
2100
The Pub / Re: Context object?
« on January 2nd, 2013, 11:14 PM »
Just as a quick footnote, I realised that in actuality a zip creation library is not really needed - we already have a limited one as it is. So I'm just going to shave that stuff off and concentrate on it being a read library as I originally intended. Much closer to 18KB than 80KB.