Jump to content

PLugin System like VB3


Guest Matt Saunders

Recommended Posts

To make code modifications you have to modify the code. IP.Board has a components system which allows 'plugins' or components without editing any files (and these should also work without reinstalling after upgrades).

Link to comment
Share on other sites

but the vB plugin system is basically the same as the IPB Component system original.gif



That's not correct. IPB doesn't have hooks system. That's a principal difference. It's just promissed to IPB 3.0, but no timelines, as usual :)

Componets system is good only for stand-alone tasks.
Link to comment
Share on other sites

That's not correct. IPB doesn't have hooks system. That's a principal difference. It's just promissed to IPB 3.0, but no timelines, as usual :)



Componets system is good only for stand-alone tasks.




Tasks? :s you can add whole new features to your board with the components system. With the new php allowed in templates aswell, you can make it as complicated as you want with your board...
Link to comment
Share on other sites

To make code modifications you have to modify the code. IP.Board has a components system which allows 'plugins' or components without editing any files (and these should also work without reinstalling after upgrades).



Yes, most components require no file edits, whereas some may need a couple, but the vB plugin system is basically the same as the IPB Component system :)


But that's for IPS software mainly. Other modifications like: ibpArcade, ProBattle and shoutbox are installed external to that and thus include some coding.

I agree there needs to be a better form of installing modifications, it's not due to laziness before anyone says.
Link to comment
Share on other sites

@Digi: hooks are just part of vB's plugins system, they're not separate.


Ah ok, sorry for the confusion :)

But that's for IPS software mainly. Other modifications like: ibpArcade, ProBattle and shoutbox are installed external to that and thus include some coding.


You are completely wrong. The modifications you mentioned above, and any component if planned properly, could work with far less destruction to the main source files.

I agree there needs to be a better form of installing modifications, it's not due to laziness before anyone says.


It is laziness and lack of knowledge/understanding of the IPB system (which also ties in with laziness most times). Though you can't complain too much about free services, so you get what you pay for as usual. ;)
Link to comment
Share on other sites

You are completely wrong. The modifications you mentioned above, and any component if planned properly, could work with far less destruction to the main source files.


It is laziness and lack of knowledge/understanding of the IPB system (which also ties in with laziness most times). Though you can't complain too much about free services, so you get what you pay for as usual. ;)


But the simple fact remains, just with those above modifications you cannot install using simple installation formats. So I'm not so wrong, thanks.

It isn't laziness I personally add modifications on a regular basis and nine times out of ten fine with it, but code editing does open allot of opportunity's for things to go wrong thus a better installation method would be justifiable.
Link to comment
Share on other sites

But the simple fact remains, just with those above modifications you cannot install using simple installation formats. So I'm not so wrong, thanks.



It isn't laziness I personally add modifications on a regular basis and nine times out of ten fine with it, but code editing does open allot of opportunity's for things to go wrong thus a better installation method would be justifiable.



Unfortunately, you said it yourself. You aren't a modification or component developer, so you don't know what tools are available for those whom are developers to take advantage of. With php allowed in templates, components, and proper planning and execution of any modification one can make things far easier for people like you to install without mistakes. It isn't laziness on your part, the end-user, (which is how I think you took it) it is laziness on the part of developers in the community. It is just all about efficiency and usability. Sometimes it is more efficient (and the only way possible) to use a direct source edit, others a template edit is perfectly fine. Couple that with the ability to directly edit the master template files on import, thus being able to scale all skin edits down to children that aren't modified, and php within templates, and there is little to no need for a direct source edit in most cases today. :thumbsup:

We, the IPB community, might not have a hooks system, but we do have something. Why make a hooks system installed by default when the community surrounding it can't even make use of the tools they already have? A hooks system is going to be far more complicated than what we have now. Education is key, but those in the position to educate themselves tend to focus little on that and more on "getting noticed". Frankly, this is the biggest difference between free and paid modifications, to a point. ;)
Link to comment
Share on other sites

I think too much is expected of a hooks system. I don't see how it could be designed in a way that would do away with most of the file edits of current mods, although I hope to be pleasantly surprised.

On the other hand, the component system is seriously limited. A lot of modification ideas are simply not possible to implement without multiple code edits. Some modifications may be worth making for yourself, but there's no point in releasing them because admins without programming experience can't copy'n'paste without fault that many times. (Just making the installation instructions can take close to the time you wrote it). My impression is that modifications involving a number of file edits are often in demand, just that modders don't want to support that kind of modification. That doesn't mean the implementation is wrong, it could be the only possible way.

Link to comment
Share on other sites

My impression is that modifications involving a number of file edits are often in demand, just that modders don't want to support that kind of modification.


I'd agree with you on this. I think it says something for the demanding attitude of the end-user community as well. From my experience there is less and less thanking going on, regardless of "faults" and more demanding responsibility on the developer's part, even if they are not to blame.

That doesn't mean the implementation is wrong, it could be the only possible way.


Prior to the release that allowed executable php within templates (2.2.0? not sure) I would agree with you on this too. However, with this new ability (even though it was possible since 2.1 and saw limited usage then) and the ease of enabling such, there is little merit in this now for most of the popular modifications I've seen. And, since skins are store in SQL, if properly planned out, the installation process could be a breeze. Tweaking is another thing though, where anything but file edits wouldn't be possible (ie some dynamic bbcodes because it would be silly if not impossible to re-initiate the post parser). However those types of modifications typically have only a couple edits to the source as you've mentioned. It's the bigger ones that require some large number of edits that are, for the most part, unnecessary in many cases now.
Link to comment
Share on other sites

To be perfectly honest with you Digi, I'm not exactly sure how many code edits most modifications have. I'm mostly basing my assumptions on some of the mods (published and unpublished) and edits I've done, plus the suggestions I see at IPSB. It's difficult to discuss without examples though. Lets say you want to add fields to the registration page, information that you can already enter in My Controls, then to do it properly you must add error-checking on the client side (javascript) for usability, error-checking on the server side (php) for security as well as template changes, so in total a lot of edits. Or if you want to add poll result visibility for different user groups on a per topic basis decided by the topic author, then that also seems difficult to accomplish without many edits. Another mod idea I've not looked into but I believe would have many edits, would be displaying member search in the ACP one line below the other with checkboxes and mass-edit options. If the modification idea is very connected with what IPB already offers, just not to the full satisfaction of admins, then it often seems to involve a lot of edits.

Link to comment
Share on other sites

Anything that involves javascript is bound to be an issue. I won't deny that. Nor will I deny that some cases qualify needing direct source edits. However, what I was saying was (from my experience over time), too many modifications don't use the abilities that IPB already has and edit source files unjustly or inefficiently. Even some of my older stuff suffers from this. It depends on the developer's true interest in learning the software and getting a better understanding on how to work with it. If we can't even get developers to use the tool we have now, how can we get them to properly understand and use (correctly at that) a hook system. If you want to get technical, the way I see it at the moment, the php in templates option is basically a hook system of it's own if implemented by the modification developer properly. :)

Anyway, if you'd like examples (other than the 3 components mentioned above which are glaring examples imo) feel free to contact me and I can provide them, as well as explain what I mean in a fuller detail. I would post a lot of this sort of stuff on IPSB, but my available time and plans for change related to that site tend to thwart the appeal to do so. That and the continued production of the developer documentation, which, at this time, makes doing something like that fairly moot...hopefully :P

Link to comment
Share on other sites

I also agree with you, with the PHP in templates which was 2.2.0, you dont really need any file edits. Unless you were editing existing Javascript, you wouldnt need to edit them, just add a script tag to global_board_header, or whereever you want it :)

I know I cant say much, (Looking at edits for reputation system :P ), but a couple of recent modifications we did (Task and report mgrs) were easy to accomplish with no file edits, because of <if="include_once()"> etc...

But seeing the reputation is not actually mine, half the edits aren't needed, and I am sure I can weed them out :)

I dont feel we need a hooks system with the template php now :) We kinda already have one :)

Link to comment
Share on other sites

your being way too one sided here digi to get your point across i agree that alot of mods are inefficient and this can be from editing unneeded files to having code in multiple files that might have been to be kept in one file therefore cutting down file edits and i know this from experience as i've just cut down the edits in a mod to half (mostly thanks to universal installer) however even from experience it isn't always possible to keep things in one place and editing of the source files is a requirement. IPB knows this otherwise i'm pretty sure that if it wasn't the case they'd have encoded their files a long time ago. This said however even a hooks system isn't flawless and still might require edits but it does give coders alot more flexibility and options to make mods work better and not require edits, saying that all mods can be installed just with components and will never need a code edit it just not realistic. Although with standalone mods this is true its not the case with larger more complex mods. The arcade mod does need file edits however its separated so the mod will install without them which is nice but its nicer with those little extra as i'm sure many will agree.

Link to comment
Share on other sites

Digi is still right in this case though Jaggi... With the new PHP templating, I could get that Arcade modification down to no edits, even with the extra addons, for example, the topics.php edit. What a waste of time? With the PHP thing, I could use a <if="include_once( 'arcade/whatever.php' )"></if>. I can then get that file to setup $ipsclass to another file, from that file I can get it to print the output it does on topics.php. All with one skin edit, and no file edits.

IPB already has a mini hooks system with the 2.2 templates already, this is what Digi is saying :)

Link to comment
Share on other sites

I don't really see how I'm being one-sided. In fact, from your post it almost looks like you agree with everything I said :P

I never denied that file edits weren't necessary still in SOME cases. I simply said that in today's IPB most of the file edit abuse could be reduced due to the tools that are available to us (the developers). No system is perfect, but to demand a "better" one when most of the developers aren't even taking advantage of what we have now is worthless. Especially since, if they took the time to learn the software, they'd see that a hook system would offer little more than we already have.

Before I posted people were trying to say that modifications are difficult to install due to the file edit requirements, especially those with very large numbers of file edits and that this was the major reasoning for a hooks system (easy installation). All I was saying is that many developers over do file edits far beyond what is necessary, yes even with arcade, because they either don't want to learn the system or don't understand it yet.

You can do what AH did above if the if( include()) to include any php in to a skin template, or you can do it a less hackish way and require one minor file edit to allow the use of the <!--exec.file=''--> functionality (edit init.php to turn this on in templates). Though with AH's method, the include would be called when the function is called, thus bringing it into the current scope at that exact moment, and requires no file edits. With exec.file='' it would be brought in to scope within the display class, thus the information passed to the skin function wouldn't (necessarily) be available and with the init.php edit you actually might not need the edit if enough mods used it ;) Either way, in many cases, this effectively kills most file edits in modifications today. And, because most things can be done via the skin, there is little need for the end-user to actually do the installation with a properly set up installer. On the chance that the template bit that needed to be changed has been edited by the user, then they MAY need to do it manually in some cases. However, again, in a properly setup installer one could actually to search and replace that would be successful most times, unless the specific string to be searched was the item changed. This (edit collisions) would still be a fairly rare occurrence in most cases though simply because most skins don't edit a lot of actual template files.

Beyond all that, I touched on it before, a hooks system offers little more than we already have. Trust me I know....I'm building one :P The most it will offer is an increased ease of installation because it would, at least mine will, set a standard for installation processing and format. There are the downsides to it was well such as additional resource usage, etc.

So, to summarize, yes, not everything can be done without a direct file edit, but a lot more can be done, even since 2.1, with far less alteration of the core source files than we see now. :thumbsup:

Link to comment
Share on other sites

Sorry for the bump, but I couldn't edit.

One thing I would like to see, in effort to reduce the overhead of including/opening external files, is the ability to add php directly to the templates. This is, in effect, the same thing as including a file and the skin template system already has to run a parse check for the "html logic" as it is now. Addition of a new tag (ie <php>) would be great B)

Link to comment
Share on other sites

I don't really see how I'm being one-sided. In fact, from your post it almost looks like you agree with everything I said :P



i did :P i just said it needs opening up a little. I'm not so sure about the whole php in templates idea as i probably wouldn't be too happy with the overhead of a including/opening a external file, although tiny its still overhead and i put performance before everything (even before ease of installation). Although in my mod i've managed to cut down the file edits by half its still quite a bit to do, i'm sure i can't cut that down entirely but most the edits i find are for adding to queries to join to a another table as part of my mod. Another big area which isn't possible even in templates is some code in the attach system which decompiles data from a file uploaded and other small things. i still believe in the html in templates and php in php file etticute tho... although php in the templates is a nice idea i'm not sure on its security... just thinking the sql tool box is restricted to root admin however whats stops someone running a query in the templates? (i'm not exactly sure on the amount u can do in the templates but a valid question it think?).
Link to comment
Share on other sites

although php in the templates is a nice idea i'm not sure on its security...just thinking the sql tool box is restricted to root admin however whats stops someone running a query in the templates


You can already do it via an include, even without the exec.file being enabled, as AH mentioned above. Is this a problem? Yeah. IPS should improve the execution handling to not allow includes, or anything that opens a file when the constant in init.php is set to not allow includes in php templates, within html logic (especially if there is an init constant that supposedly removes this ability). Regarding the include vs. direct php via a <php> type tag, the is no functional difference except that it would allow that you could get around the file opening overhead (which is the only downside atm). If the constant I mentioned above is disabled, neither the proposed <php> tag or the "exec" tag should work.

i just said it needs opening up a little.


How can I open up anymore? ;) Everything else you've said is unnecessary. I've already said that there are occasions where you can do nothing but a file edit. There always will be. If you want advice on how you can reduce file edits I can give you that, in the proper location, but this is hardly the place to post every example that requires a file edit and every example that doesn't. It doesn't add to this argument other than to reiterate the general statement I've already said, which was, "You will be required to make file edits in SOME cases, and always will." :)
Link to comment
Share on other sites

The way I see it, replacing a source code edit with a skin edit that might do some include or something is not really that much better of a solution. It's still one manual 'change' you have to do to install the mod. Say there's a mod like Members Online Today that is just one source code edit, and you want to change that to be a skin edit instead. When you have to do a version upgrade, and keep that mod installed, you just have to re-do that source code edit if you keep the mod's edit as a source code edit, but if it's a skin edit, you could run into the problem of what to do if that skin template you edited got changed in the next IPB version. The edit for the mod is still in the template, but because the template is now not the default, you have to get into the mess of manually editing the template via the info in a skin differences report.

Bottom line: replacing source code edits with a skin template edits (and possibly an init.php edit) on a one-to-one ratio isn't making the installation process any easier. You can be fancy and replace your source code edits with adding something to the skins, but in my eyes that's almost always just being fancy for fancy's sake. Don't get me wrong, I certainly try to eliminate source code (and skin template) edits as much as I can, but either way, an edit is an edit, whether it's in the source and in the skins.

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...