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.
* 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. |