Wedge

He does have a point, though, and it wasn't lightly that I decided to up-end it as viciously as it was, because it means a lot of code changes, but it makes way for other things, not just aesthetic consistency.

For example, I'm planning on taking the AJAX assignment tool and applying it to all the configurable options instead of having multiple types of UI in play, which does demand the side area be bigger. The old size was 215px, the current size is 16em which equates to about 250px.[1]

I tried making the ticket details area 250px wide and it just looked too wide - here, it's 250px plus about 15 pixels that makes up the effective right margin (where the rounded border is)

Right now though, I'm concentrating on bulking up Wedge to support it editlessly, which means upgrading certain internal features in the hooks, new hooks and even new *types* of hooks.

1.	Surprisingly, though, with the sidebar and the wider details area, it doesn't feel cramped. Partly because the default Wedge font is narrower and partly because there's fewer hard vertical lines that instil the sense of a barrier.

It's a huge job, no doubt, but I suspect it almost depends on the permissions system being upgraded to a degree.

Before worrying about implementation, nail down the exact details of how it's supposed to work, where avatars and attachments should be stored (one folder for each, multiple folders?), how that should be referenced in the code (new album, mythical album 0 or something else?) and stuff like that.

It's a complex job and it has consequences that are far reaching, so best to look at that first before touching the code, IMO.

I can, actually, because it's so massively underutilised. I flippantly[1] remarked somewhere about the number of people who use template layers. It is, after all, a pretty select club.

The group ultimately consists of people who had to know about them to get the job done: themers who do anything of substance, portal authors, and the limited hardcore (people like me, Nao, Live, who can justifiably claim to know SMF at a sufficiently deep level).

Because it's such an elite club, it's practically black magic, that people will take the easier route of, like using file edits instead.

Fun fact: there is a mod out there that adds a footer menu. Nice idea, reasonably well done, and done with a template edit, leading to all kinds of hassle.

I suggested more than once that it could (and should) be done with template layers, because that would instantly remove almost all support queries about installation. But no, template edits are seemingly fine... or at least, the suggestion wasn't even dignified with a reply.[2]It depends what happens if a sub template requests through the likes of loadSubTemplate to be added to a given layer. If the content is discarded because its destination doesn't exist, there is arguably a problem.

One would assume themers would likely keep it or provide a space that can be called 'sidebar', so that content which expects to go into it can be diverted there.Yes, macros would be the term to use. (Emacs = editor macros :P)

I don't know the history of the term that gives you the derivation of pimp, but macro does have linguistic basis as a prefix for 'widening of range', of sorts, hence macro-management is where you manage the very broadest things (as opposed to micro-management where you manage the tiniest details)

1.

And, to be frank, somewhat rudely about one person in particular.

2.

I'm not bitter that they ignored the suggestion when it was made in sincerity to benefit them. I'm bitter that the author was at the time an SMF Customizer. I always felt that people in that position should be encouraging people to write better code, not just signing off on existing code. Sure, it's underutilised but in that position, you should either know the code relatively well - or learn about things like that which are documented and can be used to truly great effect with a little imagination.

It's a necessity not just for a portal or CMS but for plenty of other things, WedgeDesk already makes use of the earlier partial implementation, after emulating parts of itself before.

Logo madness is good :) And me, I'm just a miserable critic, not having attempted a logo myself yet ;)

You all know that lately there's been issues with certain SSL issuing bodies (the certificate authorities, aka CAs) having... issues, and browser vendors have taken a little responsibility to police which certificates they accept and refuse out of the box.

So, here we have a request to join Firefox's CA list.

https://bugzilla.mozilla.org/show_bug.cgi?id=647959

I have had different results in the past. It really depends on the content type as to whether JSON decoding will be faster.

My test data was 2-3 levels deep of arrays, where the final level would be an array of numbers. It's definitely faster decoding (indexed) arrays of numbers than anything that involves strings, I can definitely tell you that.

Fast decoder is more important than fast encoder, certainly.