Wedge
Public area => The Pub => Plugins => Topic started by: ziycon on June 11th, 2012, 08:17 PM
-
Is there anymore information on writing plugins apart from the 'mechanics' topic? I'm wondering how you can go about creating a plugins when a hook doesn't exist, do you need to define a new hook and if so any tips appreciated.
Just getting my head around it till it's released whenever that maybe. :)
-
If a hook doesn't exist, you ask nicely and we add it. The plugin manager enforces that the hooks a plugin is trying to use actually exists (though plugins can also declare their own hooks to call)
The plan is that we add hooks as necessary, but there's a great many hooks available already.
-
Plus it gives us an opportunity to suggest a better alternative ;)
-
I was looking at the 'universal register login' functionality so would need the ability to modify the register and login interfaces an associated functions.
-
While I greatly appreciate the thought of and implementation of hooks (SMF has added some 200 hooks for 2.1+), I think that you folks may be doing a disservice by removing the full-code editing capability of the package manager.
Hooks should be encouraged and/or required, where they exist and can be used... but having the ability to add your own hook into a piece of code or edit code if absolutely required instead of waiting for a new release is very powerful...
Just out of curiosity, why did you completely remove the code editing capability of the package manager?
(other than, people are stupid and can't figure out overlapping code edits)
-
I was looking at the 'universal register login' functionality so would need the ability to modify the register and login interfaces an associated functions.
While I greatly appreciate the thought of and implementation of hooks (SMF has added some 200 hooks for 2.1+), I think that you folks may be doing a disservice by removing the full-code editing capability of the package manager.
1. How many errors in core functionality are caused by mod errors, either soft or hard errors, exactly? (Soft errors are logic errors that merely cause errors or inaccurate behaviour, as opposed to parsing errors) How many 'I installed this mod and get a white screen' type errors are there?
2. Got a plugin that's causing fatal errors? Rename or remove the folder, the plugin is disabled. No mess, no nothing.
3. Got some errors in your forum? The error log will tell you which plugin caused them.
4. Not editing raw files means you never have to worry about permissions on the files, never have to change permissions of core files to make them writable (especially given how infrequently people put them back again)
5. You can make version dependency basically an irrelevance by making it detect what hooks and other features are available and only allowing installation if the requirements are met. (Plugins can also declare their own hooks for other plugins to work too.)
If people absolutely need to edit their own code, there's nothing to stop them, but the out-of-the-box experience should be to avoid doing that.
I would also point out that this isn't theoretical stuff. There are a couple of dozen plugins already existing; the calendar, birthdays, SimpleDesk, reCAPTCHA and plenty of others, have all been made available and all work without any file edits.
Also, we might as well compare SMF's implementation of hooks to Wedge's. SMF's can call some functions per hook, but there's only a few places where files can actually be loaded. In Wedge's case, hooks can load files, and they can also have a priority set so that some functions are called before or after others.
Mind you, let's be clear. I didn't 'remove' the functionality. SMF's package manager is still present in the code, but only until I finish writing the plugin manager - I built it all from scratch.
-
ok...
(and I wasn't suggesting that you did it wrong... just curious of the logic behind the decision)
I get your reasons 1-5... (although I think 4 is really minor :P)
I think that 5 is really the most important one...
1, 2 and 3 are nice (and good features), but really only affect users who don't know what they're doing. :P
and I know it's not theoretical... I read through your stuff and see that you've got it mostly working and working well....
I think SMF's new version of hooks can call files (although I am not certain of that) but the priority thing sounds interesting (and original)
-
5 was the big one that made me go down that road, 1-3 are mostly convenient by-products of implementation.
If 4 is so minor, how come there are so many reports of people getting hacked?
SMF's hooks as of RC4 could not call extra files, but I don't know what 2.1 can do.
The original plan was to have the plugin manager be able to carry out file edits, but in the end I considered that I'd rather take the more restrictive route. I'd also note that other forum systems do actually do something similar - XenForo, for example, only allows you to upload plugins via FTP (and just for fun you then have to upload an XML file to the admin interface, or point to the file on the server, because that's user friendly...)
-
Hooks should be encouraged and/or required, where they exist and can be used... but having the ability to add your own hook into a piece of code or edit code if absolutely required instead of waiting for a new release is very powerful...
Think of it this way, Hooks and the new plugin system is in a Wedge going more modular and it won't take at least 2 years to get there. Because it already works (not that its available, don't want to confuse anyone :P )
-
godboko, I think you may have read me wrong. I am all for hooks. Hooks make everything easier for the admin and especially for the general public admins who have less than zero experience with code.
My question was not on the use of hooks... it was on the reasoning of removing the file-edit capability.
I get what Arantor was saying... although I still think that having the ABILITY of direct code/file edits through the interface is a useful tool that should not necessarily be discarded. but that's just me... and I know that I am the exception to most things. :D
-
The only way I'd allow direct file edits is if the admin has to enter their FTP password every single time, and I certainly wouldn't automate it.
-
The #1 reason for me agreeing to ditch file edits in plugins is that -- you can update Wedge without having to re-do the file edits.
Sure, SMF 'tries' to re-apply mod edits after updates. But first of all, they're not guaranteed to work, and secondly you have to package your own custom edits into a mod if you want it to work... Noisen.com had thousands of custom edits (the patch file for it was 600+KB), and as a result it took me weeks to make the switch from SMF 1.1 to SMF 2 back in the day...
Basically, going from a SMF2 RC to Final was also going to be too long a job if I wanted to just apply the Final changes to my codebase. It was, simply put, a nightmare. And it's the same for most web software out there.
So, with Wedge, of course I'm in a position where I can simply commit my own code edits and pass them off as a "general feature" for the betterment of Wedge, but I think that the structural change makes it easier to encourage people to use hooks rather than file edits.
Also, one of the parts that get edited the most in SMF is the template, obviously. This is one of the reasons why I spent so much time tweaking the template system to allow for easy overriding of pretty much everything in it. You don't need to 'target' a specific hook when you just want to overload an element in the template. You can add CSS code or CSS files at will, you can add a custom file with functions to be executed before or after a template function, and you can even override these functions... Heck, if you really want you can even override a function that asks to be executed after the 'before' function of a stock template function. You can disable and enable template functions at will -- you can reorder them, enable them based on whether the current skin is marked as mobile-targeted or not, etc.
In fact, Wedge has so much to offer in that area, that I would feel VERY bad if I ever had to go back to silly file edits. (I did do that for a few parts of Wedge.org, like the Facebook link in the footer, but they'll be gone by the time we go public...)
-
I was looking at the 'universal register login' functionality so would need the ability to modify the register and login interfaces an associated functions.
In reality I'm just using this as a test for myself to get as much upto speed as I can with plugins for wedge so chances are it's never released when wedge is available. :)
With that said I have one or two other features I'd be interested to see if you'd be willing to implement, one of which I got working as a mod for SMF but just never got to finish it. ;)