Wedge

No... it's the tick of the 11th full hour after the stroke of midnight, which would make it 11am.

It's principally the same argument as the whole 'there is no year 0' argument - except in reverse.

Hmm, might have to go find that.Didn't say it was, but it was certainly released at the time when Pottermania was pretty high generally and it did provide some stiff competition.Hmm, haven't seen that.Am a bit tired right now, but will play with it.I need to go see a physician at least, if not a regular doctor, I gotta see a chiropractor, my neck and shoulders are beyond a joke right now.

But that says to me you need to take a break.You can certainly work iteratively in GIMP with layers, and if you're really crazy you can script things with Script-Fu however learning Scheme is not in my to do list.

Heck, I'd rather work on SVG by hand or use PHP ahead of that...

You're not telling me that the French *never* use the 2-digit shortened form... :ph34r:

Not yet it isn't... your clock is fast.

I already pretty much said that I was going to implement recurring events anyway, in the calendar plugin, but I'm seeing a more compelling reason to do so: to improve holidays support.

Right now it's implemented as a fun happy list inserted into a table, but really, that's not the way to do it, I feel. It sort of is a recurring event of sorts (at least, the exactly-annual ones are) but there's no reason why things can't be implemented a bit more nicely.

Or at least, some way of making it more sane to add/remove chunks of them. Perhaps give the mod many many dates and have it just only show the ones the admin is interested in. I can think of several ways that can be done performantly, too.

Also, the more I look at it, the more I realise the calendar has had little love in its life. The help text for 'cal_enabled' is a single item that lists everything on the page, is also a bit out of date :(

An interesting answer, yes. I'd forgotten about $user_profile, since you were talking about $user_info, I figured it was letting the user update their own settings rather than someone else's. (Though, intriguingly, virtually everything else stays the same; $user_profile just holds the same details for every user, $user_info holds a bunch of stuff for the current user, but all arguments about whether you reuse the information on the page hold true either way.)

On the whole, it's a pretty good answer from AngelinaBelle, there, the only thing that would have made it perfect is understanding what the cache level parameter is doing. Specifically, that ties into the cache level settings in the cache subsystem.

Level 0 is off, level 1 is the basic level of caching, and occurs on files if necessary or if a proper cache backend (XCache, APC, memcached) is specified. Level 2 and above physically require a proper cache backend, and don't really apply to file caching, and unless you have a really good reason you won't be using level 2+ anyway because you likely end up with more stale data than you really want, meaning that loadMemberData doesn't really ever fetch from cache for most users.

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.