Wedge

OK, so what's been happening in the last month? It's been... pretty busy, actually. 71 commits since the last blog post, including:

* OpenID got removed
* some purging of $scripturl from the system in favour of a cleaner method of handling it
* links to profiles now get coloured by membergroup colour through the code (if the current user is not able to visit other profiles, the link is removed, saving bandwidth and preventing search engines from repeatedly trying links that won't go anywhere)
* improved replacement of fetch_web_data, that allows for using cURL on hosts that support it (which is cleaner), and for images on remote servers, attempt to only get as little information as possible for the image rather than the entire image itself, which is great for massive photos, for example
* quite a few new hooks
* Noisen-like thoughts system added

Not to mention various clean-up and overhauling of structures internally.


Today, though, I'm going to talk a little about what I've been working on... the calendar.

If you were to go back through the threads, you'd probably find the earliest discussions on it a year ago trying to find reasons to keep it or lose it, arguing both in favour of keeping it core and turning it into a plugin. At the time the conclusion was that we could keep it and see if we could find reasons to make it worth keeping.

But interestingly, a year later, I'm still having trouble finding reasons to keep it core, when I can make it a plugin and give it better treatment that way.

So, that's what I'm doing, and I'm actually more surprised than I thought I'd be when I realised how intertwined the calendar really was in SMF's core (and, thus by extension, Wedge's core)

If you're curious, just do a search for 'calendar' on the SMF 2.0 codebase, even before you get into all the places where it's just a cal_ prefix, it's hundreds. Far more than I certainly expected, but it's interesting to note that it's prompting new hooks and new ways to extend things that I'd never have thought of.

For example, SimpleDesk came with its own maintenance/find-repair routines. Had I been thinking about it, I'd probably have integrated that into the general find/repair routines, if there were a convenient way of doing so. Which there wasn't, but now there is, so that's good.

It does also suggest one thought to me; the SMF team have long since indicated that it is a desire of theirs to do much the same thing. The one lesson I would take from this, and it is quite important to understand this, is that doing it in the SMF methodology of file edits... this would be beyond a nightmare.

I haven't even gotten to the display or posting pages yet and I've still modified:
* index.php (to remove the calendar action)
* Admin.php (for the admin menu)
* Class-DBPackages.php (to remove the calendar tables from the list of reserved tables)
* ManageMaintenance.php (to remove the calendar tables from the list of tables considered by the old converter[1])
* MoveTopic.php (to remove functions that update calendar entries when moving topics plus adding a hook for the same)
* RemoveTopic.php (to remove the code called when deleting a topic, so that the calendar is updated at the same time)
* RepairBoards.php (to remove the code from find/repair for the calendar, and adding a hook for the same)
* Subs-Boards.php (to remove the code deleting calendar items when deleting a board, and adding a hook for the same)
* Who.php (to remove the entry regarding permission to view the calendar)
* various language files, notably Admin, Help, ManageMaintenance, Who

Naturally all the removed code is converted to hooked functions, and Calendar.php, Calendar.template.php, ManageCalendar.php, ManageCalendar.template.php and Subs-Calendar.php aren't in the trunk any more

That's also not all of it, either, there's plenty more. I still have 323 mentions of 'calendar' to clean up in the source, and some of those - just for fun - are calendar_month and calendar_day language strings that aren't calendar uses (paid subs, if you're wondering)

But that should indicate how big and complicated the calendar was, and if it's just converted to a mod, it's going to be pretty vile to maintain because of all the edits it necessarily has to make to make everything else work. Doing it without a proper plugin setup is just madness if support is to be a realistic goal, IMO.

I'm actively adding support for things as I go to make it possible to make the conversion, and I hope that if the SMF team are seriously considering it, that they either read this and do something about it, or more likely that they come up with their own game plan as to making extensions fundamentally cleaner to write, because allowing it to go on to be a classic mod is simply a very bad idea.

1.	That whole function is probably obsolete now, though.

The last day or so I've been working on a one-off site, pretty privately. The site has a lot of potential to it, and regulars on another forum will probably know what the domain name for it is too. But I'm not prepared to share that here, not yet.

The technical design is one-off, utilising a modified forum backend as the admin area (and only the admin area) while not showing anything of the forum on the regular user side, at least not directly. (The site blog will be using SSI to pull from the forum, the login system will use the forum login core, making use of the API to handle authentication and registration, with comments going back to the forum too)

What I will say is that it will be powered by nginx, PHP, and Wedge (though, really, there's no reason why I can't do it in SMF, I'm not using the forum core, but it will mean I have to fix the API) and make heavy use of the GD or Imagick libraries (might be a good time to learn that really)

But I'm stuck primarily on the site's look and feel (generally; I already have some of the very specific elements on the site planned out and even drawn in some cases).

What I guess I'm wondering is whether anyone has any resources or places they go for general inspiration for design. I don't even have a colour scheme at this point in time; time is the theme of the site, and I did contemplate doing some kind of steampunk clock motif around the border (since the majority of the main content is its own thing), but not sure about that at this time.

Sorry I can't give any details out, trying to keep this one sort of a surprise until I'm closer to being ready with it.

In the depths of my research into how WordPress updates (for plugins) work, I bumped into a separate site entirely.

In particular, this post caught my eye: http://w-shadow.com/blog/2011/01/31/lazy-load-avatars/

Now, it makes more difference on WordPress where the bulk of content will be without avatar, and only the comments are, but it strikes me that it could make a difference in terms of perceived load performance if applied to avatars in Wedge.

Thoughts?

Right, I've been asked (here privately, and elsewhere) about a few plugins that apparently Wedge 'must have', and instead of answering the requests individually, I thought I'd collect them here.

NOTE: I am not preventing anyone from writing them. Just that I will not write them for Wedge and no amount of bribery or anything else for that matter will convince me.

---

Hide mod

This is apparently one of the most 'important' mods. The notion that hiding some content away from users until they post is a good way to get their attention and get them posting.

Yes, it generates posts. It generates stupid one line posts where people make the post solely to see the content, and invariably don't even bother replying afterwards to *actually* contribute something meaningful. You turn the problem of lack of participation into a problem of crap participation. I'm not going to condone or encourage it.

Look but no read

This is to allow guests to see into a board and see the names of topics but not let them into the topics themselves. Apparently this is a good incentive. Oh, it's an incentive alright, to discourage search engines from visiting your site - if a search engine visits, they're only going to see what guests see. And if you fudge it for search engines, apart from the fact you just gave users a reason not to sign up, search engines have been known to send out requests that don't identify themselves as search engines, and if the content is different, you can be penalised.

Stop Forum Spam

Although it's gotten better in recent times, it's still somewhat unreliable as far as submitting data goes, and it's still too easy to get unvalidated "I just thought it was a spammer" entries in there. There are better methods of keeping spammers out, it just requires a little more effort on the admin's part (like spending 30 seconds writing a question and answer)

WordPress bridge

Seriously, why would we do this? We have blog support built in...


There may be more, but that's it for now at least.

This is something I've thought about more than once, and went far enough as to implement a helper function in SimpleDesk for it.

If you can't see other user profiles (e.g. you're a guest), why show the link? It'd save bandwidth, because it's not adding the variety of links per page, plus it means search engines aren't given links to your user's profiles - which means they don't try access them, which saves you a fairly surprising amount of server load.

The downside is *doing it*. Gut instinct tells me it should done after the member group colour replace operation so that we don't have to stick conditional logic throughout the templates.

For once I had trouble deciding where to post this. It's sort of plugin related, sort of feature related and sort of rant related. Eh, let's go for off-topic then, heh.

OK, so my current project for this evening is to break up that damn post template. Seriously, even with the changes I made before, which split the poll creation and event creation and some other oddments out into their own functions, there's still a massive unit that is the post form.

And, sadly, the more I hack away at it the worst I feel like I'm getting with it :/ In the new template skeleton structure, you have layers and blocks. A block is, semantically, an atomic piece of content that doesn't need to contain anything inside it, e.g. one item in the info center, while a layer is a container of blocks, as in it has one or more blocks in it and maybe some code before or after the list of blocks in it. The info center itself is a layer, the bit before the contents is the opening of the IC, then the content blocks, then the end of the IC.

And, that's stored inside the sidebar layout so you can add things either before or after the info center as a single item or you can add things inside the IC. It's pretty cool actually.

But the post form is enormously complex, far more than anything I've yet made with the system.

In case you're wondering why it's so complex, just imagine what the post form might contain.

Start the post form
    Preview area
    Display any errors
    If it will require moderator approval, advise user
    If locked, advise user that only moderators can reply
    Begin the post header
        If guest, ask for name and address
        Post subject, icon
    End the post header
    Optionally, the calendar event builder
    Optionally, polls
    The postbox
    Additional options
    Attachments
    Verification/CAPTCHA
    The submit buttons
End the post form

(And that's all inside just the main area) Small wonder it's been giving me a headache, and that's before I begin to worry about how the wireless template is going to support any changes, though to a degree I almost don't care about WAP2 support for extensibility; it's not like most post-form mods extend WAP2 anyway, but that's not the right attitude to have.

Yeah, it's complicated, but the upshot is that adding items into the form is absolutely trivial now, and you have a pretty good degree of control about where things go. (Note that some of these already have other related facilities, e.g. the post/preview/save draft buttons are manipulatable through another interface, so you don't need to mess about to add buttons, as well as extending CAPTCHA types is done through other hooks)

That wasn't much of a rant. I guess I'm a bit tired of ranting :P The problem is that it's a very large block of a template, and that sort of thing has to change. The downside is that it ends up being lots of little bits rather than one big bit which can make it harder to deal with.


:edit: I missed some stuff. Duly added.

Hmm, I just tried to do this today, and while I applaud the elegance of the given setup, it's a pain for plugins to have to do, not to mention inefficient.

To put it into perspective, right now when I add the menu icon, I have to add the following line of code as well to add the class, because there's no easier way of doing it, not even a prototype. While it may be efficient to just extend m_home in the CSS, there's actually no way to access that from the menu code, not even a way to specify a custom side-along class (e.g. to specify .m_home and then override the background property)


I can't help but think we can do this better by crafting a general icon class and adding the specific item to it as well which means the new menu icon styling only has to override background for that icon.

If there's another way of doing it, I'm all ears, but I didn't find one in the menu template and nothing better occurs to me right now...

Also note that this will be more important if themes decide to restyle the menu, because if they restyle it without adjusting the markup, the style might be totally off. At least if the general style is inheritable, the worst that can happen is the icon is the wrong size, rather than being totally broken.

This is sort of plugin related and it more directly affects plugins than it does anything else, I guess.

I think one of the current paradigms in SMF is wrong, that permissions should intrinsically be added to the permissions page - when it just doesn't make sense to do that sometimes.

I lost count a long time ago of the number of threads of people asking about things like nneonneo's shoutbox and asking how to set it so people see the shoutbox. Of course, the answer is to set permissions - but when permissions are set somewhere else from any configuration/settings that the shoutbox might have, it's illogical.

Ironically, SMF also features one method to actually deal with this, though most people don't realise it.

When I split the calendar out, as I will be doing shortly, I don't have to rework the permissions too much - because the UI of the calendar settings actually has an inline permissions facility, where you can set access by group (which feeds into the permissions system natively) to different calendar features, just as you can with general permissions.

Weirdly, though, it never really hit home to me until tonight just how broken the paradigm is. I dug out an old SMF 1.1.x test site, and decided to play around with the chess mod. It's pretty neat actually. But you have the Admin > Chess Admin area with Settings and Maintenance pages - then you have to go elsewhere for the permissions, and it jolted me when I had to get out there and reset it myself.

Had the permissions been inlined into the config pages, I wouldn't have had to look and no doubt had I been a newbie, I'd have been way more confused.

It makes me wonder though. When I get round to ripping permissions out and replacing them, do I actively need to consider putting roles in, with directly extensible support (like we have now), or is it actually better to bar plugins from touching the core permissions and making them put permissions in their own settings pages? (Obviously, provide facilities for doing this, SMF 2.0 and Wedge do actually do some of this, though it needs expanding to cope with _own/_any and non-general/context-specific permissions, as right now only general permissions can be dropped in easily)

I'm just thinking that simple plugins only need a permission or two and can trivially pull that in, complex plugins need something bigger but might as well get a dedicated section for it in their own admin area, without having to clutter up the core permissions - and it means that we don't have to worry about making it extensible on a UI level, and more importantly, plugins get to keep their facilities all under the one roof.

At least, that's how it is in my head. Would love to know what others think.