Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Messages - Dragooon
211
Plugins / Re: The whole "core feature" thing
« on March 11th, 2013, 06:30 PM »
Perhaps a third option, a new folder in Sources that means something like modules (?) with the whole feature sitting there like a plugin folder (minus maybe the plugin-info.xml (automatically deleted on install?)) and included in a separate place then later merged with plugin behaviour on run time. Although to be honest this is more or less a special case of plugins as core plugins. You gotta trust the user a bit.
212
Plugins / Re: The whole "core feature" thing
« on March 11th, 2013, 06:12 PM »
You're assuming that by making things plugin-esque I'm implying that they're removable. That's two different things. I'm merely saying that just because a thing is core doesn't mean that it has to be directly embedded into files, but it can (and probably should) use hooks.
213
Plugins / Re: The whole "core feature" thing
« on March 11th, 2013, 06:03 PM »Would you be inclined them to break more 'core' features into modules like that?
214
Plugins / Re: The whole "core feature" thing
« on March 11th, 2013, 05:59 PM »
That's fair enough, it's just that I'm more of a plugin guy than a core feature type guy and modifying files things. Hence most of the things I implement are consolidated and run via hooks (even most of the projects I've created work like that). So I'm not a fan of including it into the core, IMO things should go the other way with more things being plugin (in the sense of how they are coded, not how they're presented if that makes sense. As in code should run via hooks and module).
216
Plugins / Re: The whole "core feature" thing
« on March 11th, 2013, 05:40 PM »
I'm fairly sure vBulletin had some default plugins, but it's been a long while since I used vB4 so I'm not too confident about that. But Joomla/Drupal and majority of CMS definitely do.Quote This is perhaps a problem that's most prevailing to me. If a person wants to screw up his forum he can do n number of ways, deleting a couple of essential files being one of them.Quote Currently the notifications system is based on hooks, if you want to integrate into core how would you deal with that?
The other problem is that whatever gets made as a plugin will get less attention than the core itself when it comes to bug fixing. Just because it's consolidated in a single place, unless that place is in the core properly, it's likely to get overlooked. I found this more than once. Sad, but true, and a lesson well learned from SimpleDesk - the amount of bugs I discovered through that bastard front page plugin was incredible.
Particularly in the case of the notifications system, which to me is not just a core feature but it's a core feature you'd never want to disable, in which case there's no need to provide the infrastructure that gives the chance of it being disabled. That's the real advantage of it being a core feature, and I don't like having to run around pretending to the outside world that something is other than what it is.
217
Plugins / The whole "core feature" thing
« on March 11th, 2013, 05:02 PM »
I really think a separate topic for this is a better idea rather than Arantor barging in all the threads and beating the drum :P. Basically:
1) I really want to maintain my GitHub repository
2) I'd love (some) my plugins to be core (partially because I think they're quite good candidates, but mostly because that'd be quite neat)
3) I really want to develop the features further as they're something I enjoy making and improving (especially the notifications thing, I think it's awesome). But I want my main GitHub repository (really!)
So, any ideas on how to solve this problem? I got a couple,
1) Make them plugins included by default and enabled, similar to how Joomla does a lot of it's things (or even vBulletin I think?)
2) Make them pseudo plugins, something that internally work like plugins but cannot be disabled or ironed out (and hence has no UI in Plugins area), hence make them automatically build from the latest GitHub revision (or tag, we can decide that later).
Making them plugins vs no plugin is more or less an argument of semantics, I'd say they're better as plugins because:
1) It's not really any slower or faster either way
2) They are good examples of how plugins can be made
3) Plugins are easier to maintain as they're consolidated in a single place
Any ideas anyone?
1) I really want to maintain my GitHub repository
2) I'd love (some) my plugins to be core (partially because I think they're quite good candidates, but mostly because that'd be quite neat)
3) I really want to develop the features further as they're something I enjoy making and improving (especially the notifications thing, I think it's awesome). But I want my main GitHub repository (really!)
So, any ideas on how to solve this problem? I got a couple,
1) Make them plugins included by default and enabled, similar to how Joomla does a lot of it's things (or even vBulletin I think?)
2) Make them pseudo plugins, something that internally work like plugins but cannot be disabled or ironed out (and hence has no UI in Plugins area), hence make them automatically build from the latest GitHub revision (or tag, we can decide that later).
Making them plugins vs no plugin is more or less an argument of semantics, I'd say they're better as plugins because:
1) It's not really any slower or faster either way
2) They are good examples of how plugins can be made
3) Plugins are easier to maintain as they're consolidated in a single place
Any ideas anyone?
218
Plugins / Re: Hooking into e-mail templates
« on March 11th, 2013, 04:39 PM »
I see, well I'll wait for you to implement a good solution. E-mail thing is way off into my list anyway.
219
Plugins / Re: Hooking into e-mail templates
« on March 11th, 2013, 04:30 PM »
There are a couple of things, the e-mail template shows a better UI for e-mails simply because of the replacement documentation, secondly all e-mail stuff is better at one place. Plus, perhaps you can exclude any language string defined as an e-mail template? That'll be easier than to splice it into the DB and having to define all the templates.
220
Plugins / Re: Hooking into e-mail templates
« on March 11th, 2013, 03:48 PM »Remember where I said about plugins being able to extend the language files? The exact same process would apply ;)
Though yes there needs to be a hook to extend the actual definitions too.
221
Plugins / Hooking into e-mail templates
« on March 11th, 2013, 03:44 PM »
There should be the ability to hook into e-mail templates, I'd like to use the existing interface and give the user an option to change language strings as they please. Seems like a neat idea.
222
Plugins / [Plugin] Re: User Mentions v1.0 (9th March 2013)
« on March 11th, 2013, 03:35 PM »
Index is about 1/3rd of the table itself, members has a lot of them
223
Plugins / [Plugin] Re: User Mentions v1.0 (9th March 2013)
« on March 11th, 2013, 10:12 AM »
Looks like the index is kicking in?
Code: (EXPLAIN) [Select]
EDIT: This is actually on a SMF's member table with ~22k records, but I don't think that should make a difference
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: smf_gallery_members
type: range
possible_keys: real_name
key: real_name
key_len: 767
ref: NULL
rows: 44
Extra: Using where*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: smf_gallery_members
type: range
possible_keys: real_name
key: real_name
key_len: 767
ref: NULL
rows: 44
Extra: Using where*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: smf_gallery_members
type: range
possible_keys: real_name
key: real_name
key_len: 767
ref: NULL
rows: 44
Extra: Using where*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: smf_gallery_members
type: range
possible_keys: real_name
key: real_name
key_len: 767
ref: NULL
rows: 44
Extra: Using where*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: smf_gallery_members
type: range
possible_keys: real_name
key: real_name
key_len: 767
ref: NULL
rows: 44
Extra: Using where
EDIT: This is actually on a SMF's member table with ~22k records, but I don't think that should make a difference
224
Plugins / [Plugin] Re: Notifications system (1.0)
« on March 10th, 2013, 04:45 PM »
Yeah that'll probably be the best option.
225
Plugins / [Plugin] Re: Notifications system (1.0)
« on March 10th, 2013, 08:34 AM »
Ahah, this is the public topic....reminder: implement the option to automatically subscribe to your threads.
Also, for the others:Quote Okay, this is one of the last issues I'd like to work out before giving it a go for installation on a live site for testing, any ideas where this can go? I'm thinking either:
1) Make a big number counter next to the site's title
2) Make a menu entry and display the counter there, which expands to show quick unread notification with the option to show all.
3) Make some sort of floating box?
EDIT: I'd like any suggestion anyone has
Also, for the others:
I know the plugin uses the sidebar but I'm not entirely convinced that's workable at present - I would never, ever see my own notifications on the desktop because I have my window sized at around 1000px, gives me enough room for dual pane work, but has the side effect that the sidebar is pushed to the bottom. Makes me wonder about having something up in the header area for the user.
1) Make a big number counter next to the site's title
2) Make a menu entry and display the counter there, which expands to show quick unread notification with the option to show all.
3) Make some sort of floating box?
EDIT: I'd like any suggestion anyone has