Birthday, calendar, plugin, core [VOTE NOW!]
Poll

So, what, exactly should be done with the birthday and calendar?

Birthdays and calendar should remain CORE
Birthdays CORE, calendar PLUGIN
Calendar PLUGIN with the birthdays built in to it
Birthdays PLUGIN, Calendar PLUGIN - separate but able to work together

Nao

  • Dadman with a boy
  • Posts: 16,080

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Birthday, calendar, plugin, core [VOTE NOW!]
« Reply #31, on October 13th, 2011, 12:41 AM »
That's the thing, I actually need to do some right now, mostly because it's how I'm finding bugs in the plugin manager, as well as making sure there are hooks in meaningful places.
Posted: October 13th, 2011, 12:19 AM

Just that right now, after today's fandango, I'm a bit tired before carrying on with the split of the birthday plugin, especially because of the way the email templates are physically handled, and what looks like I'll have to re-engineer the sending process to get around it, which probably means reformatting all the email templates to be conventional language strings.

Speaking of which, the entire way email templates are done is a bit ridiculous, and they can't even be edited in the language editor :/
Re: Birthday, calendar, plugin, core [VOTE NOW!]
« Reply #32, on October 13th, 2011, 02:13 AM »
OK, so I tackled that, and have refined the structure into something usable (and cut the code down in various places)

Right now, it's just a case of taking a machete to the core code to strip it of birthdays stuff, so I can put it in to the plugin. (In other news, there's various ways that things need to be extensible in the calendar that currently aren't. There's no reason, for example, why any arbitrary events shouldn't be able to be added to the calendar. I could envisage it in WD for example for ticket deadlines to be embedded into the calendar.)

But if I don't do things as plugins, I can see them sitting there as red-headed stepchildren, and no-one wants that.
Posted: October 13th, 2011, 02:01 AM

Also, please note that the little thing of leaving a cake image in the user's profile if it's their birthday, that probably should stay core for the time being.

I really don't want to add a hook that can cope with that, that would be inappropriate IMO. (Or we can remove it entirely, not fussed, and have something add to the user's profile underneath or similar. Don't really mind.)

Mind you... when I spent a little while looking last night for a suitable cake image, I found the image used in SMF, and I don't think it's actually compliant with the licence for it... it actually says 'free for desktop use', nothing about distributing it. Though I would hope they asked about it.
Posted: October 13th, 2011, 02:05 AM

Hmm. Do I commit this or do I leave it just removed while I work on things? (Using the power of diff to see the code itself, at least what I haven't just copied over to the new plugin. It does have to do other things that the original code doesn't)

That's a sure sign I haven't had enough tea, if I have to ask such philosophical questions.
Posted: October 13th, 2011, 02:07 AM

Meh, committed. If I broke anything (which I don't think I did) it's a revert away. Meantime, I'll crack on with the plugin.
When we unite against a common enemy that attacks our ethos, it nurtures group solidarity. Trolls are sensational, yes, but we keep everyone honest. | Game Memorial

Nao

  • Dadman with a boy
  • Posts: 16,080
Re: Birthday, calendar, plugin, core [VOTE NOW!]
« Reply #34, on October 13th, 2011, 08:57 PM »
A note on the latest commits: it seems like a few 'bday' strings are left in the codebase. They're usually linked to the 'birth date', but since 'cal_showbdays' was removed from the options, it should logically be removed from install.sql and upgrade.sql, I suppose.
I'm not doing it myself because it all has to end up in the various plugins... ;)

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Birthday, calendar, plugin, core [VOTE NOW!]
« Reply #35, on October 14th, 2011, 11:09 AM »
Yeah, it's all going to go into the calendar plugin. Essentially a case of throwing divine lightning at them and letting $deity sort it all out :D

Going back a few posts, the question came up about plugins and turning originally core features into plugins.

Now, PMs and the memberlist were candidates (and of course the calendar will be), but I'm wondering about the print-page option and OpenID.

I know we talked about OpenID before, but I'm just wondering how important it really is; it's not like a lot of sites use OpenID - how many sites do you know that allow you to sign in with it?[1]

In short, is it worth the effort required to make it a plugin?
 1. It should be no surprise to note that it's primarily technical sites. SourceForge, StackOverflow and all its related sites and LiveJournal are the only consumers I actually know of outside of SMF. MyOpenID and LJ are the only providers I know of. Then you have PHPClasses and family that adopted the OpenID protocol but only from their own server, defeating the point.

Nao

  • Dadman with a boy
  • Posts: 16,080
Re: Birthday, calendar, plugin, core [VOTE NOW!]
« Reply #36, on October 14th, 2011, 02:06 PM »
My opinion. Pm should be core. Memberlist I'm not sure. Print can be plugin although it's not important. Openid should be a plugin at the same level as Dragooon's Fb plugin, or simply gone if it's too complicated.

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Birthday, calendar, plugin, core [VOTE NOW!]
« Reply #37, on October 14th, 2011, 02:08 PM »
Well, it's not that it's too complicated. I can't see how it's any more or less complicated that FB Connect, frankly - however it's sliced, it's still the same basic process: throw some data at an external source and use that to authenticate, creating a user account if necessary.

I'm inclined to agree about PMs, but memberlist I really don't have a problem with it being pushed to a plugin. If it isn't pushed to a plugin, it needs an overhaul in terms of what's displayed and possibly the general look of it.
Re: Birthday, calendar, plugin, core [VOTE NOW!]
« Reply #38, on October 14th, 2011, 06:05 PM »
In other news, I'm really not looking forward to splitting the calendar up. Not only will that require splitting the insane post template up, it'll require rewriting a decent amount of post handling to support hooking... >_<

I'm almost tempted to go write a small mod - say, an arcade mod - before doing that :o

Nao

  • Dadman with a boy
  • Posts: 16,080

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Birthday, calendar, plugin, core [VOTE NOW!]
« Reply #40, on October 14th, 2011, 07:37 PM »
Making the post form hook able will be awesome though, it allows me to write a great many neat plugins. It's just a big job I didn't want to tackle just yet, and I probably should do some of the plugin server stuff first (feedback wanted in the appropriate thread)

Nao

  • Dadman with a boy
  • Posts: 16,080
Re: Birthday, calendar, plugin, core [VOTE NOW!]
« Reply #41, on October 14th, 2011, 08:34 PM »
Re OpenID, my main issue with the OpenID code is that it only creates a 'subpar' account and requires more work on the user's side to get full privileges... It sucks. Any non-SMF/Wedge login system SHOULD give users the same privileges. They can be asked for a user name at registration time, whatever, all they need is a user name, their password is checked by Facebook is all... (Heck, if a password really needs to be generated, it can be done automatically by Wedge and sent to the Facebook e-mail or shown on screen or something....)

Re post form hooks, I suppose that'll be in the quick reply form as well...?
(I should get started on rewiring the quick reply form to below individual posts. Just need to figure out the best way of showing the link...)

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Birthday, calendar, plugin, core [VOTE NOW!]
« Reply #42, on October 14th, 2011, 08:41 PM »
Yup, the whole implementation is a shade sub-par. I'm tempted to just ditch it and rewrite it later if anyone wants it.

As far as the hooks go, I'd rather have separate post and QR hooks, with a hook actually in the QR block for extension (as opposed to adding a new block after)

I don't know how the code will cope if you create multiple editor components that all have the same form name and are implicitly inside another form (the quick moderation one)...

TE

  • Posts: 286
Re: Birthday, calendar, plugin, core [VOTE NOW!]
« Reply #43, on October 14th, 2011, 09:23 PM »
OpenID with its current implementation is IMHO completely useless, simply because it's a OpenID 1.1. Most OpenID-Providers such as Google / Yahoo don't accept 1.1 but use 2.0 instead.

Just drop it, no one will miss it  ;)
Thorsten "TE" Eurich - Former SMF Developer & Converters Guru

Nao

  • Dadman with a boy
  • Posts: 16,080
Re: Birthday, calendar, plugin, core [VOTE NOW!]
« Reply #44, on October 14th, 2011, 09:25 PM »
According to my threaded post at sm.org, it isn't a problem. I didn't make multiple qr forms though. Iirc I just moved the form as needed.

Btw what is the advantage of single post pages versus quick reply?