Wedge

The editor shouldn't be a singleton, if it is that's a bug. There are some functions that are callable without an instance of the editor, and there some functions that rely on instantiation (i.e. creating an instance with specific content etc.)It's more a semantic thing than anything else.It is sort of initialisation, but what it also does is quasi-instantiate the object in the process. And yes, it does get a pointer to the object - and promptly stores in the object too.I understand this. There's a need to feel like you've justified yourself. That's entirely human, too.I generally tend to trust your instinct, and I look over it to make sure there's nothing horrific or train-wreck about it, and I go through and debug it if there's a problem, but other than that, I tend to leave it alone, partly because I don't like touching other peoples' things and partly because it doesn't *need* much effort.So why the push to remove 'public' everywhere? Seemed to me as though it wasn't about readability but saving space - at least that's what I took from it.It probably should use the CDN setting, and perhaps we need some kind of function to handle this. Normally jQuery is loaded every page as far as I remember, be that from local or from CDN, but I can see the logic of having a flag somewhere to include just jQuery or jQuery + jQuery UI that a plugin can call for?This is one of the things that annoyed me a lot. I'd already explained about the existing solutions and why they're not exactly acceptable. Zip_Archive doesn't work properly on 5.3+ (the PEAR one), the various extensions may or may not be installed, so either I craft a solution that only works on a minority of servers (and thus isn't worth the effort), or I look at PclZip or roll my own. PclZip was horrific, weighing in at 199KB, with tons of options that I didn't really see a need for, with properly ugly code.[1] So in the end I just concluded that rolling my own was quite simply the best approach as it allowed me to do exactly what I needed - and I can. The fact that the plugin manager is capable of receiving uploads and extracting just the plugin manifest is proof of that.Not necessarily, no. It's not a security error, in the sense that it doesn't allow the user to do anything they couldn't do before. All the error means is we're checking a permission but the permission isn't loaded - the permission doesn't get granted or anything. There's no way to exploit that to escalate privileges or indeed do anything but add to the error log.

But this has been present for months, it's present on this very site right now for all users who are not you. The difference is, it doesn't have any visible sign that it's happening here, there's nothing going to the error log. It's the same class of error that you could stuff a @ in front of, knowing that it's probably going to fail and you don't care if it does. And there are times when that's acceptable; there's plenty of cases in wextr where I've done that, with the expectation that it's going to fail, but I didn't want any kind of error being thrown by PHP when I will be cleaning it up myself.

In this particular case, though, putting a @ in it will stop the error being thrown but it won't actually fix the problem. It's not like the error must always be thrown and there's no way to fix that; I used it with extreme prejudice in wextr because I'm dealing with fopen/fread etc, where they're relying on things outside of Wedge's control to behave, but here, everything is under Wedge's control and there is no reason why we shouldn't fix it once and for all - properly.

The danger of doing a hack is much like putting a band-aid on a problem; it doesn't fix the problem. It just prevents it getting obviously worse. What we should be doing is fixing the root problem instead.I get that - probably more than most. And it would have been fine, had these issues suddenly come out of nowhere. But the zip stuff I've been talking about on and off for 18 months, and the permissions stuff I documented months ago, so it just felt like I'd wasted time in doing those things.I think I might just do that. I'm usually happier working with code - except for last night when nothing seemed to be bloody working properly, even the stuff I did after fighting with zip files and plugin management. Yup, last night I tried to make another game in Impact, except that the player's ship image isn't showing up for some reason. Except there's no reason I can see why not. :(

1.

Crazy indentation, and C-style return values, e.g. sending everything into a function by reference and returning zero on success or non-zero for an error. Even when options were set, you'd pass them in as $class->function(PCLZIP_OPT_SOMETHING, its_value, PCLZIP_OPT_SOMETHINGELSE, its_value, PCLZIP_OPT_WITHOUTVALUE, PCLZIP_OPT_SOMETHING, its_value), it was horrendous. I understood the mentality, but I didn't like it. I spent maybe a week on a partial rewrite, cleaning up the code, trimming methods I didn't see a need for like duplicate (what's wrong with copying the damn file?) and restructuring the API but in the end I accepted that a general purpose zip library didn't really need to be written, Wedge already had a crude zip maker library, I just needed a zip extraction library that allowed me to work without unpacking the entire archive at once.