Wedge

On one forum I'm a member of, they have both like and dislike, and as well as it being per post, each user can see how many times their posts were liked/disliked in total.

I don't post there *that* often, 186 posts in a shade over 3 years, of which Like/Dislike only appeared in the last year or so, and I've personally had 270 likes and 55 dislikes (of which 12 were a single post)

But I've seen people get 70+ dislikes on a single post in the past.

(This forum is quite big, about 1.1m posts, but mostly because that's all comments on new stories, and many stories do readily hit 100+ replies. Mind you, the readership is mostly cynical people, so downvotes do happen quite often, and invariably there's a "Before the haters downvote me[1]...")

I suspect the fact names aren't attached to it does make a difference, and I can see providing the option both ways (names/no names, maybe names for author only as an option) could be good.

1.	They use upvote and downvote, but it means the same thing, since names aren't given.

It's been a while since we've posted anything on the blog, so I figured I'd do just that, heh.

Of recent times I've been playing with the replacement for the package manager, which while still rather incomplete, is taking form in the code - it even enables and disables simple add-ons right now (meaning that simple add-ons can actually be used in the spirit in which they are intended)

For those who haven't seen the pictures already posted on the subject, I present a screenshot that I took at the weekend.

Details

It's close enough to how things are currently, with the difference that it actually works for both enabling and disabling simple add-ons (ones that don't create or modify the existing DB tables, that is)

I know it was left very much at a disjoint at the end of the last time I wrote about the replacement for the package manager, so I just want to cover off everything that's happened, because there's an awful lot of it, and it's why there haven't been any commits from me lately despite there being a lot of coding going on.

A lot of the stuff I talked about before as being almost whimsically answered is now pretty much finalised, so without further ado... I should point out that there were a surprising number of "Oh, that hadn't occurred to me" moments in the design, but I'm pleased to say that I think they've all been ironed out now.[1]

If you're not interested in technobabble, here's the point where you probably want to stop, with the understanding that it's being designed in a way that promotes add-ons that don't need file edits and should thus survive updates and so on a bit better.

---

There's an Addons/ folder, right up there next to Packages/, and each add-on gets its own folder in there. Doesn't matter how big or small it is, that's what happens. Everything that happens, happens in that folder. Sources, templates, language files, CSS, JS, images, etc. It's all in there.

I will write a proper tutorial on this sometime but here's the rundown of what the system does.

Here's where it gets really funky. You know as well as I do that users are unpredictable, and often prone to doing odd things, so I took care of that. It doesn't matter what folder an add-on is created with, it could be myaddon/ or my_addon_1.1/, it doesn't actually matter, because you never directly refer to it.

When you create the add-on, you give it an ID, that has the author and add-on name, e.g. Arantor:WedgeDesk, and it's *this* that's used. Everything that you do with an add-on will make use of this ID.

Let's say you have a big add-on that has multiple source files and multiple template files, arranged in src/ and tpl/ respectively, and just live in your add-on's folder. I'll use WedgeDesk as an example.

I want to load the main source: (The .php is added automatically.)

It doesn't matter what folder it's in, you never have to worry about it. Similar deal with loading templates and language files:

No more dumping files throughout the different folders - everything's in one place.

There is a caveat at this point: it does mean that an add-on can't magically have different templates for different themes and just drop them into the relevant folders. That's not to say that it can't be done, it just means having the multiple templates stored inside the add-on and making sure that the theme is checked before calling loadAddonTemplate.

There is more, since there's functions for loading CSS files from your add-on, plus JavaScript files, and in both cases they must be called so that the proper caching and substitution comes in.

Lastly, you may be wondering how you insert images, if you're not using $settings['images_url'] or $settings['default_images_url'], well, there's a method for that too.

Specifically, if you ever need to refer to an add-on by URL, the base URL (i.e. www.example.com/Addons/youraddon) is available in $context['addons_url']['addonid'], so I can always call WedgeDesk images through $context['addons_url']['Arantor:WedgeDesk'].

There's more, too. If an add-on uses only hooked files (the recommended method), when an error occurs, it's possible to attribute that error to that add-on in the error log, so you'll know if an add-on is acting up.

There's plenty more to do, of course, like provide facilities in the language editor for editing the language files in add-ons, but for now at least, there's an awful lot of work done to facilitate strong add-on support. There's also file editing to provide, plus quite a bit of the DB support, but it is coming along nicely now.

(Oh, and one last thing. If you rename an add-on's folder to something different, or just delete it, it should automatically disable. If it uses file edits, all bets are off, of course, but that's discouraged anyway.)

1.	This is why I've spent a lot of the last week converting SimpleDesk to run on WedgeDesk, wherein it has been renamed WedgeDesk. A good deal of this stuff only came to light when actually trying to use it in a real and practical sense. I've now done that, and altered the design accordingly.

Somehow I like the logo combination less, it looks there as though it's misaligned somehow.[1]

1.	And this is why I'm not a designer.

I deliberately started out by going to one of their paid plans up front, because I wanted to manage through my domain ($34.95/yr) and that still ends up cheaper than my old hosting account.

Yes, yes it is. I thought that might amuse you.

Like that the two parts of the logo look disjointed (the blue should be lower down and to the left), IMO. But it looks pretty good though.

Well, the webhost I moved pretty trivially to my existing VPS (which was fine since that old webhost had almost zero traffic) but the fun was moving all my mail, which is now with FastMail.fm.