Modification installer built in.

[sniggity]

Man, being able to go down a list of preloaded modifications and click on something like and "Yes" or "No" button that stated "Install this mod now?" would be great. Some other boards have this already. It would be like the program Fantastico, but only for Invision boards. All this coding and the possibility of messing up your files due to one little code glitch is getting old. Just my $.02


Thanks for the great work, keep it up. And get us a Mod installer, guys ! ;)

[UBERHOST.NET]

IPS has done their part by providing the components system, so you should really be asking those who provide the file mods to change the way they program modifications.

[bfarber]

Yeah, we can't really build in modification capabilities, however the component system is the first step to allowing mod authors the ability to extend site functionality without file edits, and we have plans to expand upon this idea in the future through event hooks. :)

[sniggity]

Just a suggestion, kewlceo. I'm only a user of the board software, not a programmer. :)

But if we can go to the moon, anything is possible. ;)

[UBERHOST.NET]

But if we can go to the moon, anything is possible. ;)

Mankind thinks going to the moon is impossible, then man goes to the moon, thus anything is possible.

That's like saying:

Pigeons are dirty, and pigeons are birds, thus birds are dirty.

Anyway, the components system is already in your ACP, and as Brandon said, it will be improved upon. This is the route for programmers to take, because mods that require file edits are not resistant to upgrades. It's just logic--if the upgrade writes new files over old files, you can expect to lose file mods. ;)

[Madd069]

Did you actually know if we wanted to go to the moon right now, we couldn't. We rely to much on technology, and went we went earlier, we rleied more on engineering.

[sniggity]

Anyway, the components system is already in your ACP, and as Brandon said, it will be improved upon. This is the route for programmers to take, because mods that require file edits are not resistant to upgrades. It's just logic--if the upgrade writes new files over old files, you can expect to lose file mods. ;)

I understand. I just meant when installing new, larger modifications -not upgrades or anything- you have to be so delicate and meticulous or you could destroy your board. I've done it unfortunately and lost tons of data. Nowadays, I just hire someone to do it for me that is more confident and knowledgeable. But yeah, it was just a suggestion.

You guys do what you can, I know this. Either way, even if it were a few years down the road and were possible to do, I know sales would go through the roof. It did when C-panel started with Fantastico.

Thanks guys !
:charles:

[ZeRoRaVeN]

As you said, you're a user not a programmer. The work involved is complex!

For example, how would you know where to insert the lines of code? The only reason some installers are like that are because;

#1 They're IPS components like the blog/gallery which already have the code in those areas. (not all of it)

#2 They used the components system

#3 They don't require heavy edits.

How would you know where to insert the code? Putting something like insert code into line 55 isn't accurate as then the mod might as well be .x.x specific. Every .x.x release does have an change, and then what about conflicting modifications? What if, you had some instruction to insert under

//=====

// BLAH!

//=====


$lawl = 2


echo "rawr!"


include ("blah/blah.php")

But then, what if this code was modified by another modification? Then how would they know where to insert it? You can't go by line numbers either since that's probably changed. I don't really see a solution into this unless there were specialiy alloted areas in the code designed for modifications. And not all of the board would have it.

[cojo]

Either way, even if it were a few years down the road and were possible to do, I know sales would go through the roof. It did when C-panel started with Fantastico.

Doing this would alienate a segment of the customer base. For example, businesses and those with large forums will not want to waste disk space on mods never used. They'll view the product as being severe bloatware.

Non-programmer types may like Fantastico's easy script installation. I suspect quite a number would be very unhappy if this tool's entire footprint was charged against their disk allocation instead of just the scripts they choose to install. They probably also would be very unhappy if their site was hacked with something they didn't install. This is the equivalent of what you're asking with preloaded mods built-in.

I understand your dilemma though. One should be able to add most mods without changing any lines of code. Only files of the mods chosen should be uploaded and stored. I'm not sure we'll ever see this occur. Mod authors are normally code tinkers not professionally paid programmers. Most aren't going to adapt their work unless the component/modification system is extremely easy to understand and use.

[dragon52225]

Event Hooks :) Err..... (if you are an IPSB member-> http://www.ipsbeyond.com/forums/index.php?showtopic=962 )

[Jdrid]

phpbb has made a mod for this...although you must create your mods with a specific format/layout...Just saying...

[bfarber]

Yes, this mod exists for IPB too, at least for 2.0.

That doesn't mean we'll build it into ipb though... ;)

[Ger]

I'm looking for an editor like that. Can you please tell me where to find it?

[Mark]

Hey, you all know how bad PHPBB is, right?

Well they pulled it off. (EasyMOD) Why can't IPB - exactly same concept, there's edits files, so so can IPB!

As for conflicting mods, why not just say "we could not do ths..... please do it manually now" should such an event arrise.

As for the modification injector that is around for 2.1 - similar idea, but not quite what we're after

As for 2.0 - we're not on 2.0 any more



HOWEVER, I do think this is best left to a mod. Perhaps if a really good one is made for 2.1 IPS will include it in 3.0 or later. But I don't see it as something to expect soon.

[Luke]

Even though the components system was a hudge improvement on the back end, the components system is very much incomplete. The XML file only imports settings to list the component in the adminCP. Yet componets can still operate even though they arnt in the list. So the "components list" part of the components improvement, besides integration with acp, is completly useless. The XML file needs to contain a LOT more than just an entry.

The XML file needs to contain the following:

1) The PHP files required for the component, whether in components_public, components_init, components_ucp, or components_acp. Can add graphics to skin folders, or other custom files. Language files as well.
2) SQL Queries to run that the components require to operate. Extra table, added column, whatever.
3) Custom templates added to the skin root that the component needs.
4) Template modifier which allows you to input a find and replace for specific templates for template modification. Not to the PHP files mind you, but the templates themselves. I want to add something special to the profile page, this would server me well. Then rebuild template cache after (after all template changes and additons are made)
5) Final notes at the end so IF php file modification were necessary for the component, the component author could include instructions in the final notes for the admin to make themselves.
6) For each action the admin is told exactly what's being done. If files are to be copied it says where they are being copied along with a "Continue" button. If quries are needed, display the quries with a "Continue" button.

If this could be done, I bet everyone would be extreemly happy. Myself included.

[bfarber]

A much anticipated overhaul of components (not so much an overhaul as additions to the system) as well as implementation of hooks or event handlers is expected for 3.0. It's going to be a lot of work though, so it's being left for a major version.