Wedge

It's the change logs that do it, I'm sure...

No worries - with the mad late-summer heat here it's entirely possible I'd got confused. You know what they say about mad dogs and Englishmen and the mid-day sun, right? We've just had mid-day sun run on for much later in the day at the moment :(

Uh, yeah... you wouldn't store that stuff in the UI anywhere, it's purely in the XML for a given plugin, and avoids having to include a file just to have a function with one line in it.

I just realised a weakness in the system that hasn't been accounted for: new actions.

Right now in order to add new actions, a file still has to be loaded (or already have been loaded) to extend the action array. Now, properly complex action juggling is going to have to remain in the hook behaviour (like what WD does, until I add more hooks :D) but for simple hook behaviour there's no need for having to load a file.

What I'm thinking is that there would be an <actions> block:


On a technical level, I'd push that into the per-plugin cache in $modSettings['plugin_' . *] as a new key, and pop it off the stack during the load phase.[1]

It's less of an issue for menu changes because menu changes all require more than a single line of code to define, so loading a file for those isn't the hassle it is for actions.[2]

1.	Yes, even before starting to post, I'd already assessed all the technical implications :P This is more of a pre-flight warning as to what I'm going to implement...
2.	Your choices are to have a tiny file just for the action change plus the action itself as a separate file, minimising parsing but has the file overhead, or to have a single file that contains the action's code as well but then you have to load a larger file every single page load, unnecessarily in most cases.

:)

Same here, I now have a very large list of plugins I want to write, and over the next few days I'll probably bash a few of them out because the only way I can prove the system works, and spot any holes in it, is to actually thoroughly use it.

I do already foresee one problem: folks who have masses of things installed - it's going to make a very long page, so I might have to do something about that, but that's the sort of thing only experience can teach, as theory only goes so far.

I have to admit, I have browsed through the list of mods for SMF lately, to see the different sorts of things people have done, which has given me a variety of ideas, and already highlighted a couple of weaknesses that can readily be addressed and a couple of things that do need refinement in the system (not specifically plugin related)

I'm going to find it interesting going back over my old mods though, to see how cleanly they can be rewritten ;)

Well, I've been toying around with a list of plugins I want to write, stuff that I don't want in the core but stuff I want to have available.

The question for me is how I manage development; using version control is a given, and I'm used to working with SVN. But I'm wondering if I should maybe try using Github, though I'm not really enthusiastic about opening the source to people until I'm happy to release it and traditionally I've not been happy about people breaking the things I've written (as used to happen), and I'm also feeling a bit burned after mods of mine got tweaked and republished without my permission.

So, what I guess I'm saying is that I'm leaning towards SVN and closed development still, but if anyone has any strong reason to convince me, please speak up!

- Yeah, I've seen enough copied code in my time.

- The only reason a host would disable glob is out of some misguided notion of security, and frankly, if they're doing that, best to move hosts to someone competent.

- Good. Every little thing that isn't needed, should go.

- Sounds like the right decisions have been made. Unfortunately I don't have the luxury of just ripping code out with phpseclib, but I can certainly trim the comments. I did also have to attend to a PHP 5.3.3 backwards-incompatible change while I was at it.[1]

- Hmm, that's interesting! And yeah, that doesn't surprise me, actually, though a goodly number of them are derived from the DB.

1.	phpseclib is 4.x compatible which means although it's in classes, it uses the class name as constructor. As of 5.3.3, those are not going to be called. I just renamed the constructor functions to __construct instead.