Wedge

 Guest
 Today at 10:29 PM
 Type of error: General
http://localhost/wedge/index.php?localhost/wedge/index.php?action=admin;area=ban;sa=soft;ace465ae=80b35724d62f371a37399bdcebf8345e
 2: in_array() expects parameter 2 to be array, null given
 File: C:/wamp/www/wedge/Sources/Security.php
Line: 804

This is interesting. That particular line is:


That implies that we::$user['permissions'] never gets declared properly for guests. The code changes are so vast that I can't practically review them line by line. I'm not sure why the reported URL is even flagged, because I see no reason why it should be called.

What I need to do is extend error handling to be able to provide a full backtrace as well on errors. That might at least explain how we get to where we are.

Note: at no point have I been a guest in this installation; I've been logged in as an admin the whole time.

And once again, I left wetem alone knowing full well it was going to change over time - and be subject to big changes. Once it's settled down, we can go through and clean it up should we decide it is necessary. Little point changing it if it's going to change again.

Remember, the code isn't just for you to read.

How about C++? Java? Pretty much any C-like language with OO is (and requires) explicit-declaration of scope. It's purely laziness in the half-assed approach PHP had to implementing OO originally. The only other C-like language that doesn't have explicit declaration of OO scope is JavaScript and that's even more insane to debug.

And no, I'm not agreeing with that at all :P It's simply that because most things are public, it doesn't 'matter' that stuff isn't declared.

Private methods are not about 'preventing others from accessing their methods and properties', at least not as the end in itself. The point of declaring public/private/protected, is that you get to enforce certain behaviours as well as logical separation.

For example, in the zip class I've been working on, there is a bunch of private methods. They're private because there is absolutely no reason to call them from outside the class, they are specific to that class. The only variation would be if I were to make classes that depend on that class, where protected might be better.

The idea is that you get to contain behaviour inside a given class. A better example might be the wedit component and subclassing it to implement a different editor (not currently possible, but trivial enough to make possible since it's geared up for it). Some of the stuff in there would be public - the functions called from outside the component, e.g. creating, outputting the editor and buttons. Meanwhile, some stuff you wouldn't change or allow to be changed (preparsecode comes to mind), and some stuff you wouldn't want to expose into the subclasses because they don't apply (some of the tag fixing stuff comes to mind)

Achoo. Definitely getting this sneezing bug that's going around.

Part of the issue with it is that pretty much everything in our objects is public anyway, there's very little that's protected or private - if there were more objects with visibility clauses, it would be more natural to have explicit declarations of public.

As said before, people who have joined pretty much just to ask if they can participate aren't really the people we're interested in. They're a certain kind of people, a group of people who have historically been observed to ask and get but not contribute anything meaningful - and why should they? They've got their shiny.

I'll say this again: if you want to help, demonstrate a willingness to do so. Asking for beta tester access isn't the way to help us - because if you can't be bothered to contribute to conversations much, you probably aren't going to contribute much in the way of testing. As it stands, the trend is holding up this time as well.

If you do want to help and are prepared to spend some time, read the discussions that have gone on. Add your thoughts - and don't just add '+1' or 'Great idea' comments. Tell us why you think they're great ideas. Or why they're not. There are people around here who think Nao and I can't do any wrong. Those people either don't know us well enough or don't watch what's going on - we make mistakes, errors of judgement and so on. The trick is that we recover and figure out what the best path is.

I guess what I'm getting at is that we don't need people much who are interested in the destination. We need people more who are interested in the journey as well, who are interested in looking at what we're suggesting, and being prepared to say it's wrong if it's wrong. We may not agree to start with, but at least if you're willing to tell us something's wrong, we might be able to fix it. And that begins BEFORE releases. That happens during development.

Participating in our discussions is at least as important as any amount of beta testing, and in the long run possibly more so.

Achoo. Notice the difference between banning an individual user and banning types of names. The latter means you can ban types of name from registering should you want to do so (and more flexibly than the current reserved user names)

And yes, I added who made the ban. Seems logical.

I thought Alpha 3 was going to be before the banning stuff but I already committed some.

Part of the problem is I don't know how to make the ban interface work well and partly that I think I need to make wider changes than I originally thought.