Wedge

OK, so what's been going on lately? Nao's been busy with a variety of tweaks and gouges to the source, but I've been busy working away on plugins.

(Yes, careful readers will note that we used to call them add-ons, but they're officially called plugins now after the big conversation we invited everyone into. It's a small detail but an important one and since it affects usability, we wanted to make sure you were all involved.)

Why am I writing about it now? Apart from the fact it's been weeks since our last blog post, I really wanted to pimp out the fact that plugins now exist for it - you see, last month when I talked about it, it was still just fresh off the design board, had a few rough edges but worked. Now, some of those rough edges have been smoothed out - you can, for example, actually delete plugins now once they're disabled.

But that's not really what I wanted to talk about. I wanted to talk about the plugins themselves, and I've attached a screenshot from the plugin manager as it is on my PC right now.

First up, you might be wondering why WedgeDesk is broken, when it would be a plugin I'd be more inclined to keep updated. Well, it's only because I very recently changed the hook mechanics in the display page, phasing out the old display_buttons hook and I haven't yet updated WD for the new hook, but that's something I'll do soon enough. (It's also, incidentally, how I realised it wasn't possible to delete a plugin that couldn't be enabled for whatever reason)

All of the other plugins were discussed in http://wedge.org/pub/6929/personal-plugin-showcase-yes-i-m-an-attention-grabbing-git/ - a somewhat aptly named thread, if I may say so myself. ;) If you're curious about any of the plugins I would encourage you to go read that thread, as it has pictures and more details about them.

It's actually listing them alphabetically, though I think I need to change that to include natural case sorting (r in reCAPTCHA comes after Z in the ASCII table, and it probably should discount the case) and I suspect the interface may need some changes going forward to cope with lots of plugins at once - but that's why I'm opening the floor now, so that if you have any thoughts about that, that there's a venue to share them now that you can actually see what having multiple plugins at once would look like.

Oh, and I suppose to validate that it's not some kind of random hyperbole - these are real plugins that can be used :)

It's been a fun period these last few days, kicking out small plugins - I've spent maybe an hour and a half per plugin, and in that time I've been able to establish that the hooks are present for the plugins to work with, and if they weren't present, to make them available; until I wrote the reCAPTCHA plugin, the hooks to extend the verification system didn't exist, for example.

It's also interesting in other ways, I get to test other systems in Wedge, and find ways to enhance them; one of the screenshots I've posted for 'Flitter' in the above-mentioned thread shows a 'Your settings have been saved' message - this is an enhancement I only added recently as I couldn't be sure whether saving had been done without going into the DB. It's a usability enhancement, and it doesn't require plugins having to manually support it; it's covered totally automatically for standard settings pages :) And I managed to find a small bug in the admin pages because of doing plugins, there's really no better way to test how things work than by trying to break them!

My plugins repo is not publicly available (though a few people do have access to it) and I certainly wouldn't call these release-quality, in almost every case it's to prove the system is up to the job, rather than to make sure there's plugins for everyone when we get round to doing some kind of launch (and I can't see my releasing the plugins before Wedge 1.0 gold anyway)

Sadly, I'm going to have to leave it here for now, it's late, I have a few things to do before bed, and even more sadly I couldn't find a good musical reference to leave in this post :( But as the philosopher Jagger once said, you can't always get what you want. But if you try sometimes, you might just find you get what you need.
But there you are, that's where I am right now :)

Something Nao and I are keen on doing is getting away from the current recycle bin. While it works, there are quite a few caveats to it, not least the fact that it wasn't even enabled by default. Though we did that, it's not elegant or nice, and it's something that would be better served by replacing it.

Now, the general approach that we're looking to adopt is actually to have the recycle bin folded into the normal view rather than this separate entity.

I'm posting this up here before any real implementation starts simply because it's quite high profile, as it were. This is more my take on how it should be done from a user perspective, the technical perspective is going to be pretty much the same whatever happens.


The first thing that occurs is how it should be shown on the page; I'm thinking that deleted replies would be shown one of two ways depending on the user and their preferences.

Normal users would just see a very short post, 'This post was deleted by its author / deleted by a moderator' (I think it should be quite clear which it was done by), and moderators/suitably privileged users would get that, plus a 'click here to see the full message' much as you do with users you're ignoring.

That way, even if a post is deleted, you're aware of it in the context of the thread, and it solves other problems such as if we ever implement threaded replies, it simplifies the logic about re-routing parents, not to mention leaving the conversation quite clearly structured and without so much disjoint attached to it.

The other matter is displayed deleted threads. I'm sensing we'd track whether a board had deleted threads or not, and have that as an option at the top of a board listing, whether to show deleted topics (assuming you're a moderator or similarly empowered user). The idea is that topics should be accessible but not immediately up in your face, at least not as visible as normal posts might be.


Does that make sense? Would it be worth providing mockups of how it might look?

A friend of mine is interested in writing a story as a series of blog posts, which is cool. I've seen their writing style, and I suggested a blog type format to let loose each of the pieces of the story over time, sort of like a classical serial.

And naturally, once I said 'blog', they went looking around, and pretty naturally hit up on WP first.

Something funky hit us though - my friend isn't particularly interested in making it public yet, not until a decent amount of the stuff is written. So he asked me to have a look at how you'd do just that.

And the more I look at it, the more confused I'm becoming with. I realise I'm not a hardcore WP user, but I'm genuinely confused by 3.2.1's permissions. Or more accurately, the lack of them.

Users can be assigned roles, that's cool. There are several roles (subscriber, contributor, author, editor, admin) but I'm mystified as to how this works.

I cannot, for example, find anywhere to actually set what these roles can actually do, let alone configure them or anything. I have no idea what the difference between them is, or even whether it's possible to make a blog sign-in-to-view or not.

Now, you'll probably say that it's in the manual, and it probably is, but I've been through the entire ACP and cannot find it, which says to me that the UI is broken.

OK... so I then looked it up in the manual. I can, fairly easily, find a list of what permissions each role has, though it's written almost more in programmer terms than anything else.[1]

But, OK, so I found what basic information I was looking for, and check this: I don't think I can probably remove the permission I want to remove from the basic subscriber role (which is after all what it seems like guests have), and even if I could, I'd have to add a plugin if I want to do anything more awkward.

Am I going mad or is this actually quite ridiculous? I have no doubt in my mind that handling permissions is complicated but to provide only the most simplistic of UIs is actually stupid... isn't it?

I've heard that it's "the greatest CMS since sliced bread" but the more I use it, the more I think it doesn't actually DO all that much, and that the only reason it's so 'great' is because there are some plugins that handle doing good stuff with it.

1.	Kid you not. http://codex.wordpress.org/Roles_and_Capabilities

I'm curious to know what people think of this, because I have the feeling that I'm going to be seen as snobby for the approach I'm about to implement - if only because I value putting security and not-breaking-things above convenience.

We all know that file permissions on Unixish type systems can be problematic, and none more so than leaving things at 777, because on shared servers it's a pain, and on systems with suExec in place, it will actually cause system failure.

Now, because of my design structure, moving as much as possible outside of the standard tree, there's only a single place that requires permissions to be set in such a way as to allow for file changes (for the vast bulk of the time, and for the time file edits are actually needed, well, the same framework will be able to change them)

Here's the thing: I'm not planning on doing what SMF does, which is allow you to make all the folders and files writeable from Admin > Packages > File Permissions. I consider that quite dangerous, and have done for some time.

What I'm planning is that if the files are already writeable, for whatever reason, it'll just do what it has to do. (That means if you're crazy, or brave, or have suitable configuration, you can just get on with it. It also means that if you do change it, you're doing it manually, and all bets are off, we can't support you particularly effectively if you break it.)

When things aren't writeable, it'll prompt you for FTP (and hopefully, the option for SFTP details instead if possible) details, make the necessary changes, and here's the clever bit: it'll put them back again.

That means you're exposed to elevated permissions for a short period of time, rather than generically, and it should mean that even if files/folders are made 666/777 for writing purposes, that change is undone afterwards so things don't die in the suExec case.

The caveat is that you'll have to enter your FTP(/SFTP) details every time you add a plugin (or anything else), but frankly that seems preferable to me than making it possible to 'brick' it on a very typical setup and have to fix it through FTP afterwards.


Is that an acceptable compromise for users, or would it be better to allow the current state of play? (Remember: if your configuration allows the PHP script to alter files naturally, e.g. on some Windows configurations, or everything's uploaded as the Apache user, or everything's at 666/777 anyway, you won't be prompted - but it's then on your own head anyway.)

Heh, well, the title might have given you a clue what's going on.

In order to more thoroughly test the plugin system, and indeed a few other things while I'm at it, I'm slowly going to be writing some plugins for Wedge. Most of them won't be huge, in fact I suspect a number of them will fall into the tweaks category, and no doubt I'm going to have to patch them as Wedge itself evolves, but it's a good indicator that I'm on the right direction if I can build these.

Two things:
1. This IS NOT a requests thread. DO NOT request plugins. I'm not taking requests, nor functionality requests for things I've already mentioned here. They will be published when I'm ready and not before.

2. I'm not sharing the plugins here. Apart from the fact that they're likely to need changes as Wedge evolves, you can't even get Wedge yourself yet. And even if you could, it's likely that something will break as things go on, so that until Wedge is at a stable position, there's no point in my handing out anything more than tiny code samples.


Anyway, the first one is a quick hack of the 'Users Online Today' functionality that's used here, though it's without configuration, options or indeed anything other than the absolute minimum functionality.

This is also interesting for me because it's the first time I've bent the rules about code placement. I think I've also found something up with the template skeleton functionality but that's another matter entirely.

Controversially, the entirety of the template and language strings are in the one file. Given that the template is 10 lines of code (and only 2 PHP statements, a global and an echo), and that I'm using 5 language strings out of nicety as 2 or 3 would probably do, with the entire plugin weighing in at 75 lines... having three files (source, language, template) seems just wasteful, and definitely inefficient.

But anyhow, here's a screenshot. It's nothing special - but it does work (after I added a hook to the board index, though I think I'm going to change that hook a bit to suit something else I have in mind). It won't look much different even if I do change that hook, though.

Well, I've been toying around with a list of plugins I want to write, stuff that I don't want in the core but stuff I want to have available.

The question for me is how I manage development; using version control is a given, and I'm used to working with SVN. But I'm wondering if I should maybe try using Github, though I'm not really enthusiastic about opening the source to people until I'm happy to release it and traditionally I've not been happy about people breaking the things I've written (as used to happen), and I'm also feeling a bit burned after mods of mine got tweaked and republished without my permission.

So, what I guess I'm saying is that I'm leaning towards SVN and closed development still, but if anyone has any strong reason to convince me, please speak up!

As per: http://googlenewsblog.blogspot.com/2011/09/recognizing-publishers-standout-content.html

I'm waiting to see how quickly someone asks us to support that for every post, or new posts in each board etc. ::)

So, someone pointed me at http://www.simplemachines.org/community/index.php?topic=453157.0 - it's not even officially by a current team member and yet it's still the closest thing to a guide for 2.1 that anyone outside the team has.

Funny, it's almost as if he read through Wedge's feature list, you know.

I mean:
* Database Support
* Browser Support
* CSS3 & jQuery Implementation
* Bloated Profile Fields

These are things we've actually done already in Wedge, almost word for word.

Then the other stuff that is listed is stuff that has been talked about here, and it seems there is a lot of common ground there, you know, almost as if he'd been reading the forum...

Though I think he's talking out of his ass with PDO. While, yes, PDO does offer some things, sanitisation isn't exactly one of them (though, there is a valid argument to be made that prepared statements can deal with it for the most part), moving it to use PDO "just because" isn't really a good idea - and less hosts have PDO installed. There is an argment for making it an object, which we did, and are likely to expand on in the future.

I take exception, however, to:I'm assuming that he's referring to the db_insert stuff where you have to state the column type. Unfortunately for him, he's actually wrong on at least two counts where it can't be determined safely by PHP, though I will admit both cases are fairly rare.[1][2]

That, and the fact that you do actually have to state the list of columns you're inserting anyway, unless you're inserting an exact row into the table with all values added, and all columns in the exact same order.


Last but not least, I can't see them ever adding ReCaptcha, not least because that's a third party service and they don't use third party services (ever) in the core, but that it's unreliable at very best. I prefer our CAPTCHA, in all honesty, and I'm not saying that because I wrote it.

Also if you want a laugh, they have a new board dedicated to discussion of what's in the next version. Took them long enough.

Mind you, there's still some absolute gems such as http://www.simplemachines.org/community/index.php?topic=375491.msg3165582#msg3165582 - if he thinks it's that simple, I'd love to see him write it.

1.

They are bigint and set/enum cases where the individual values are numeric. In the former case, PHP may munge the data if it's bigger than 2^52 and on a 32 bit setup, and in the latter, if provided as numeric it won't encapsulate the data and will likely cause a query error. In both cases, the data should be sent in quotes, you know, using the string type. Been there, done that.

2.

Mind you, if it were to assume that everything was a string instead and *always* quote everything in the SQL, which is perfectly valid in MySQL even for integers (which it isn't in other DB systems, which is why it's done the way it's done), you could skip specifying both, and just pass everything to the quote function, but that does have a slight performance implication on things that insert a lot of numbers, which is more common than you'd think.