Wedge

https://github.com/mattdiamond/fuckitjs#readme

No other comment necessary, hahahaha.

OK, so I've been wrestling with a new feature and it's been annoying me because I can't find a UI I actually like. Let me explain - maybe something will occur to you, maybe you'll hate the idea entirely (in which case I'd love to hear an alternative)

I want to gut the current warning system to something more powerful, and in so doing I want to have it set up so that you can warn people and do things selectively.

So that you can remove a user's avatar, signature, moderate their posts, prevent them from posting, prevent them from logging in, and a few other things. The problem is how to manage all those options, it's bad enough with the three levels of moderation as it stands and this would make it worse.

So in response, I sat down with a couple of colleagues of mine who know far more about good UI than I do and thrashed it out and what we came up with is that you could turn on/off each type of sanction, then set a minimum level of % warning for it to be applied at, and then some control as to who would be able to apply that sanction.


So, for example, the default might be:

* Remove user avatar (off by default)
* Remove user signature (off by default)
* Moderate all users posts (available at 35% warning, any moderator can apply)
* Prevent user from posting (available at 60% warning, any moderator can apply)
* Prevent user from logging in (available at 80% warning, admins only)

Then in the issue warning area, you'd have the slider as currently, but instead of it telling you what action would happen, you'd get tickboxes to apply that sanction at the relevant % warning, so if you had an issue at 0% warning, there would be no options, but give them a 40% warning, and you'd have a tickbox to activate moderation.

If you were an admin and pushed it straight to 100%, you'd get all the options (moderation, post ban, full ban)


The issue warning screen is easy enough but I can't figure out how to make the admin screen not look like a mess. Or, for that matter, how to set it up as being anything other than 'admins' or 'anyone who can issue a warning' as the choices for who can apply certain sanctions.

Oh, and by the way, do note that I have a few ideas I'm not sharing here just yet for other things that can be done to user accounts (so we're not just talking the aforementioned half a dozen options or so, but it's realistically nearer to 10, so it needs to be quite lean), you'll understand why I'm not sharing when it's done, I don't want to influence anyone on a side track as to the options for dealing with troublemakers, the point here is to nail down the user interface side of it.

Would appreciate some thoughts on this.

So, I've been watching this for a while, ever since I heard that PHP 5.4 would deprecate call-time pass-by-reference, knowing full well that both SMF and Wedge's hook caller uses this.

I was not surprised to discover there were issues, nor was I surprised to note what the issues were, and now that I think about it, I was not surprised to note that my observation was entirely correct.

OK, here's the deal. When a hook is called, normally all the variables are shoved through call_user_func_array by reference. As of PHP 5.4, that won't work as expected.

Specifically, it won't work if the receiving function's signature doesn't state it's expecting things as references. Which meant that most of the mods written using hooks actually didn't work properly under PHP 5.4, though oddly enough this was never an issue for mine, because I always indicated everything should be by-reference anyway in the signatures, I found it a good practice to get into.

What that also means we should probably strip all the & signs from call_hook calls, because in both 5.3 and 5.4, the function's signature should be indicative of receiving-by-reference and in both cases it should be honoured.

In any case, any plugin using hooks should note that all variables received, that are intended to be modified in place should be indicated in the function xyz() definition as function xyz(&$variable) not function xyz($variable).

OK, so I thought about implementing a CAPTCHA for the reminder widget. It is a method of identifying email addresses - and it never gets trapped by the error handler anywhere - and ultimately something that's going to limit the points of intrusion can only be a good thing.

So I started looking at the code and something odd about action=reminder struck me: it still works for logged in members too. Now this is really weird because I'm not sure it isn't a bug, but I'm not sure it isn't intentional behaviour either.

Let me explain. If you hit up action=reminder, you get thrown into the reminder handler, which has a bunch of subactions. But if no subaction is given, it will actually load the 'please give us the username or email address' prompt, due to no specified subaction, the relevant template being loaded and then hitting up template_main from Reminder.template.php.

That part seems half like an oversight, but the more I play around with it, the more I'm not sure about it being one. It seems almost fortunate that it happens to fall into the main reminder template (as opposed to other places, i.e. almost everywhere, where it explicitly sets the subaction if no valid one was found or none was supplied), but I don't see any 'is_guest' checks.

Then it hit me. You can't change your own password if you don't know your current one - and there's no way in the profile area to change your own password directly if you have forgotten it, meaning if you did want to change anything, you'd have to go through the reminder section - and it would let you, though whether you should be able to do so is debatable.

So, there's the question: should you be able to call the reset-password stuff if you're logged in, and if not, how should you be able to reset it from inside the profile area, since you can't change your password if you can't remember your current one?

It's a tricky one, but something that occurs to me. (Of course, I could just ignore it, implement the CAPTCHA anyway, and just not bother if the user is a registered member at the point of filling in the form)

Just occurred to me. We could have a button that says "I'm having a drink" and you press it every time you start a new bottle of beer, and it records roughly how much alcohol you'd had.

Then it attaches a flag to each post written while drunk to say 'I was pissed while writing this' and the alcohol count goes down over time, so as you sober up you can look back and see what you wrote while pissed and others can forgive you if you wrote something stupid while drunk.

I thought I'd share some of my frustrations with you all.

I won't get into the detail of it but the last few days I've been snowed under - as I mentioned briefly - in building an app using Node.js, Express, Socket.io and MongoDB. I'm not going to explain what the app is, hopefully you'll see soon enough, but it's certainly been an interesting experience for me so far, and I feel like sharing what I've found.

First up, for those of who aren't familiar with Node.js, let me explain. We here are far more used to deploying apps where we have a web server like Apache, which receives requests, passes some of them onto PHP to process the contents of the page, and handles the page until it's ready and sends it back to the user.

It's convenient, practical and we're all used to it, but the app I've been working on lately requires longlife connections, what we would normally consider to be Comet style. I could have done it in AJAX but Comet is far less vicious on the server, especially given the real-time nature of the app in question, but in Apache/PHP this just is not practical.

Enter, then, Node.js. At first glance it sounds fantastic - you're working in JavaScript on the server side (so it's easy to learn, in theory) but there's no webserver. In other words, you write some JS that also functions *AS* the webserver.

From the Node.js docs, this would be pretty much the simplest possible webserver in Node:

Yup, you see that right. You're handling raw HTTP requests and headers. For someone like me who's been behind the cosy framework of PHP for years, this is... something of a change of pace. It's not a bad one at all, it's just a lot to take on board.

Especially with the heavy-going view it has towards I/O. In PHP, the script runs from top to bottom, and it waits for I/O to complete - so execution of a given page waits while a DB query completes, for example. This doesn't happen in Node, or at least it shouldn't.

The idea, really, is that you push the request off to another function and handle its response in a callback, so that mainline execution can get back to whatever it was doing. This, for me, is a *major* change of pace because it's just not a mentality I'm used to working in.

But, so far so good, actually. I was able to fashion something workable with that, but it wasn't really what I wanted, I wanted something that did some of the work for me. Yes, that's right, I started looking at frameworks and ended up with Express.

Express makes a lot of the work easier, but it has two problems. The first is that its documentation is absolutely crap. No, really, it's ABSOLUTELY SHIT. http://expressjs.com/guide.html is the entire official guide.

There's several sub-problems. Firstly, it makes no mention of Express 3.0 at all and only barely mentions 2.x in passing for migration. It would be OK reading the source, if Express were all the source, except it isn't. It's a framework on top of another framework, called Connect, and it's very hard to figure out WTF is going on when Express doesn't seem to point to another about Connect, like any other documentation.

The second problem is probably a bigger one in the scheme of things. A lot of people did figure out how to use Express and muddle through. And some people have written blogs on it, others have asked and answered things on StackOverflow. The result was that I've had dozens and dozens of tabs open in my browser for the last couple of days as I start to piece things together.

I mean, I have a functioning webserver, it receives requests, if they're dynamic pages, they're routed properly. If they're static resources, again routed properly. 404 and 500 have their own proper pages with correct headers and everything. But it took me over a day to figure all this out to make it work how I wanted because the documentation is so poor. And I mentioned that I had dozens and dozens of tabs open... I still have about 18 tabs open for the next stage of the project, and that's the problem in itself: there's so many bits and pieces on it but they're all haphazard and many of them are legacy items.

For example, I found one tutorial from late 2010 which refers to using Express methods for handling static content, and it refers to staticGzip and staticProvider; the former indicating that content should be gzipped and the latter to indicate that a given path is where static content should be served from.

But the manual doesn't mention these, it only talks about a method simply called static, which has a slightly different calling argument structure to staticProvider but does mostly the same job. After 20 minutes of digging around I found that staticProvider was deprecated in favour of simply static[1] and that staticGzip is no longer directly available because most people deploying such apps would serve static content like that from a CDN and not from your own server. A reasonable if slightly misguided idea, I think. As it happens in this case I'm looking at deploying with sufficiently long-life expiries that it doesn't really matter so much.

But anyway, I've spent so long trying to piece everything together that it's just left me feeling so frustrated.

I haven't actually told you the worst part yet, actually. Node has a nifty-in-principle tool called npm for installing packages. There's a central repository that lists packages and most of the time you can do npm install <package> and boom, it'll download. Unless it's Express, in which case you have to have make installed to be able to install it. This took me a while to figure out due to no-one describing it anywhere and npm giving me less than helpful messages.

It gets a bit better, actually. You can declare a package.json file which indicates a package's dependencies. This can be the Node versions supported, or it can be the version(s) of packages you need. My project needs Express, Socket.io and MongoDB's connector, seems straightforward enough. Until you hit the joys of figuring out which versions you need, of course.

Oh, and there's more fun. Each of those has other dependencies which also needs to be met. And it's not clear whether some of those come installed or as optional extras, Express for example states a 'devDependency' of Jade, though it doesn't actually install Jade unless you ask it to. Again, not documented anywhere. Then more version juggling.

Jade is actually pretty neat, though. Had we not had the template skeleton I might have suggested a move to it, because it allows for replacing blocks of a document, for prepending/appending content to blocks and so on. Plus the fact that Jade's syntax is incredibly tight and descriptive and not the usual verbosity of HTML itself. http://jade-lang.com/ if you're curious.


Anyway, that's enough rambling and venting from me. For my next challenge, figure out how sessions work (and figure out how to make them compliant with the EU laws, ahahahahah) and then bolt on Websockets type connections to it and maybe see if we can't do something truly wonderful from there on in!

The bottom line is that Node and its tools make for a very interesting and flexible platform for deploying unconventional applications but the lack of good documentation for major components (Node itself is well documented, just not its good bolt-ons so much) really makes it a struggle to implement anything.

1.	Including a snide mention from Express's author that JSLint is 'lame' because it can't differentiate between 'static' being used as a method name as being used to indicate something being static.

I know it's been mentioned somewhere else but I wanted to discuss it here properly... eh, I did subsequently find it in the test board, http://wedge.org/pub/test/7303/test-topic/ where I mentioned the following:Here's the problem: we don't re-encode it again in the display template. However, part of me thinks it would be better to re-encode it on saving and display the safe version at all times, rather than have potentially unsavoury content in the DB that could be used by plugin code that assumes it's safe like SMF does.

Thoughts?

Since there's nothing in the default SVN for this, it's going to throw errors. Not sure how you want to handle this, really.