Wedge

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.