Well since 2.1 is pretty major, most, if not all, modifications will have to be redone.... It's kind of a new slate type of thing. Matt, can you add some kind of mod installer/manager? That way mod developers can make installation script that will install them automatically. Here are some ideas:

1) When you load a script it goes through it and makes the necessary modifications to the file. IF there is an error and a line cant be changed (because nothing matches), have an option for the admin to manually change the step during installtion, and then continue. The manually changed step will then be saved as an alternate step so if it's run again it will try the first one, then the alternate.

2) In the install script have an option to have an alternate step if a particular step fails. Good for supporting other modifications modders might make.

3) When you install mod's they have an order thing to them, so if you uninstall a mod, they can be uninstalled in reverse order.

4) Use the "Mod Installer" for IPB upgrades (maybe). When you run an IPB upgrade it uninstalls all modifications (the script part and template part) before upgrade. After upgrade is complete it re-installs the mod's (the script and template parts), or atleast try's to.

5) Have a mod packaging thing with it where you take the installation script and select source files (like new plugins) to bundle into an xml package.

6) Support SQL statements

Here's a possible example of a mod installtion file:



Well you kinda get the idea (i guess). And with the xml package, the selected files and new template sets are copied.

This has been said dozens and dozens of times.

You CANNOT make a perfect mod installer, it would be a waste of time and still wouldn't work very well.

Sounds like a great idea.

But I am not sure if Matt will support it or not by doing it. Never the less it is a great idea. And if Matt doesn't come around to it, maybe someone else could make it?

Though it looks like something that'd take quite the while.

I think you missed the point outlaw. Im asking Matt to atleast try to make something official. Yes any attempt to make a 3rd party mod installer would fail badly. If it was an official creation of IPB, it could work.

No, I think you may have missed it, think about these issues.

Modification A requires to find the line so and so and remove it, modification B requires you find that same line, and maybe replace it with something else, or add something below.

Modification A requires you add an extra field to be called in a query for example, lets say it wants you to find "m.id,m.name,m.mgroup,m.email,m.joined,m.posts," and replace it with "m.id,m.name,m.mgroup,m.somefield,m.email,m.joined,m.posts," and then another modification comes along and wants you to find "m.id,m.name,m.mgroup,m.email,m.joined,m.posts," but it can't now, because modification A replaced it with that extra field in the middle, this could also apply to skins and finding other edits.

Issues like safe mod will also come into effect, or a user could have some odd configuration that wont allow this to try.

Even edits to the skin can fail if they have a skin thats different enough from the IPB one. Or like the mod installer if you have edited IPB around it adds the possibility to fail since it can't find the edit.

And, if it was to actually be done it's not like every ones going to go "I must jump onto this and make an installer for it".
In the end, it's more work then it's worth, for very little gain.

Modification upgrading is very easy anyway, the 1.3 -> 2.0 upgrade for any large modification could be done in 2-3 hours. Matt has already said that this 2.0 -> 2.1 upgrade wont require much rewriting.

rightly said outlaw

Outlaw, not one said it would be completly perfect but that's what #1 was for. If at some point it's unable to do a step, the user can alter the step. In the end it cuts down on a lot of work with modifications. I dont know about you, but I dont like going through EVERY modification I've ever done. Id rather spend an hour than a week. Know what Im saying? And not all modifications are going to edit the same area. It's a 50 50 chance thing.

And as far as the mod installer in general someone else doing it would defeat the purpose. You would loose the mod installer once you upgraded. If IPS made something official, it would be supported in the next version. It could even be used for IPB upgrades.



The only difference between what I've suggested and what's being done is brunt work. Both ways they will conflict in some areas, and in most areas's shouldnt. The installer could modify the ones that dont, and then the admin can fix the few areas that do.

The authors can take the time you make the modification, but you can't take the time to just read through an installer?

It's a 50 50 chance thing is a stupid argument, IPS isn't going to add a feature that has a 50/50 chance of success, it would look stupid.

No i mean it's a 50 50 chance that two mod's would conflict. Do you like to argue just for the sake of arguing?

I'm just saying this mod installer thing could cut down on a lot of modification work. In the areas that DID conflict the admin could fix those areas.

You say this is a bad idea because of previous attempts of 3rd party installers. I truely believe things would be different if an official mod installer were created. No one can say so for sure if it would work until it really happens.

That logic says that Matt should go waste time to create one, worst case it doesn't work and it can be thrown away. It is not something that could just be done within a week or two and you have something fully working.

50/50 chance is incorrect by the way.

I think Outlaw, being one of the admins at Invisionize probably knows a little bit more about modifications than you do.

I'm just sick and tired of having to reinstall all my mods and redo all my custom mod's just because of an IPB upgrade. I mean heck, I'd consider not upgrading but when there is an upgrade it's usually too good to pass up. Unfortuantly I have to put up with hell to get there. If I wait longer, it get's worse. I would not modify the software, but it doesnt do everything I want it to do. I just want better support for modifications. What ever it is, just make hell a little cooler!

Plugins arnt bad, but when you have to modify existing source files on a regular basis, especially when you have to do it a lot, it gets bad.

Does anyone feel my frustration??? I mean it would be all fine and dandy if I had all the time in the world, but when you work 10 hours a day, you don’t exactly have a luxury.

Well here's an idea....



When you do that the output is "hi"



When you do that the output is "hello"

Why not do something simular with IPB? Have a file called mod.php, or something like that. Inside have all the classes IPB uses with no functions. Have it included in the wraper before the existing classes and make the existing ones extended classes. That way moders have a blank file to work with that woulnt be modified. If they need to modify a function they can insert it into the blank class which will over-ride the main one.

It doesnt have to be exactly like that, but you get the idea. You could have a secondary file for every class.

Well...

Even though it sounds like an idea / time saver. Outlaw is right.. And I doubt Matt would implent this into IPB.

Even if _Cy_ isn't part of the team of invisionize, he still have some expierence with mods due to his selfcustomized board... (both have experience and I am not trying to compare here, as this is not the goal of this discussion)

I think _Cy_ has some good ideas. It is perhaps good to look at some possiblity, and not say something like this is not possible.
Some official integration could make that probably possible, and if this would work (even if it needs time to devlop, like waiting for to 3.0) this would be a great achivement.

An semi automatic way of upgrading mods (that you need if you want to offer something unique) is in my opinion the GREATEST feauture that I still could think of, and that could ever have been implemented.

Lets think of some system, nothing is inpossible.
It would be worth it.

Cy, that idea works for the first modification but it again fails with a second modification to the same code.

Ok after talking with a few friends I've revised my idea:

---------------------------------

A Mod Installation Gateway

Basically it's a section in the AdminCP that connects to a "modification server". This modification server houses many user-made modifications. When you find a mod you like and "install" it, it goes through an installation script. If a step (change) doesnt match, then it gives you a list of alternative steps that will work (these alternative steps are provided by people that install the mod's). If an alternative step isnt found, the admin can enter in a manual modification for that step. This manual modification is sent to the modification server for that modification for others as "alternative steps". After an alternative is given, it continues on with the rest of the steps. In order for alternative steps to be used, the admin would have to review and approve it (by looking at it, and saying "ok"). When you do an alternative step, it is logged in a list called "alternative steps taken" under each modification installed. Through this list you can choose "undo" to reverse that alternative step and choose another for that modification. When you install a modificaton it cross-references modified sections of other installed mod's and locks previously installed modifications from being uninstalled if there is a confliction, until this current modification is uninstalled. This could be like if Mod B modified fileA.php and Mod A already modified fileA.php, Mod A is locked from being uninstalled until Mod B is uninstalled. If Mod A modified fileA.php and Mod B modified fileB.php, Mod A would not be locked. As far as IPB upgrades, they could be treated as modifications in this system. And for the purpose of 3rd party mod sites (like invisionize), have an option to change "gateways".

That would make no sense. It's honestly not that hard to upgrade and install modifications if you're good at it.

Still, it doesn't sound like something Matt would do.

I'd say someone that is capable would have to make it as a module for IPB. 2.1 or 2.0.3.

Though it sounds great.

Yeah, maybe you have the time to redo over a dozen custom modifications. Others dont have that kind of time every time there's an IPB upgrade

About 40 to be exact.

It took about two hours to upgrade IBStore.
20-30 minutes to upgrade some of the medium modifications.
10-20 minutes to do small ones.

If you don't have the time to even upgrade them, making modifications is probably not for you, since it takes longer to make them, then upgrade.

...

The point im trying to make is most people either dont have the time, patience, or even knowledge to do it. And at the same time, IPB doesnt do everything they need it to do. Cusomers shouldnt have to redo custom made things every pain steaking upgrade, there should be better support for them! Instead of contributing to the problem, try contributing to the solution, will ya? Make some suggestions on how IPS can better support modifications. I dont see you coming up with any bright ideas. Can you? Please?

Invision doesn't officially support the modification of their code anyway (they'll support mods they've custom-written, but not third-party modifications), so including a feature for something they don't even support seems a bit odd to me.

Doing so is like denying the customer. The software isnt going to meet the needs for each person exactly. A lot of boards have modifications of many varieties. They could atleast make upgrade transistions a little better.

Anyway I'm not going to make further comments. Some people like to argue rather than come up with solutions no matter what has been said. In the end we're just going to agree to disagree, and the problem will still exist. How unfortunate.

IPB has a module system, but its not yet at a stage where it can be easily used for most modification. From the looks of v2.1 this module system has been greatly upgraded and hopefully some of the major modification coders will use this system.

A mod installer is not a good idea, if you make your own custom modification the write down all the edits you made and then reapply them after the upgrade. Its not hard. And if you cant find the same lines then you have to rewrite the modification. The idea for a mod installer is so that users with no modding experiance can install modifiaciotns, the problem with this is that when it errors they will get stuck and come to IPS for support as its their system not a 3rd party mod giving them the error. IPS dont offically support modifications, therefore creating a modificaiton installer is undermining their own TOS

Wish I wrote every one of the down.

Wouldnt it be nice if you could make modifications to the source externally, locallizing the modifications apart from the actual source. Must be a way to do that.... Nothing is impossible. Not talking about plugins either. A way to make changes to existing source without touching the origonal.

Anyway I'm done...

Normally I would not comment on these topics, but I think I have something to add to the discussion.

First of all, making an official mod installer for IPB is not a good idea. This will simply not work on all occasions, and probably on most occasions. You also have to chmod all source files to 0777 and there will be a lot of conflicts with modifying source files between different mods.

But IPB allready has some options to help the mod authors. First of all; use the module system of IPB. This means automodule=mymod; instead of changing index.php and adding a new act=mymod. And also use your own sql files (if needed).
Let's say the mod changes settings in IPB; use a xml settings file to update it.
Let's say the mod needs SQL modifications; use a SQL script to make the modifications (in a perfect world; mod authors would use a simular system IPB uses, by supporting DB specific SQL files).
When designing your mod; allways think twice about any modification made to any of IPB's source files. Only do it, if it cannot be avoided.
Skin modifications? IPB has a buildin system for that. This all could be done from an installer script.

IPB2.1 will also give mod authors more possibilities to do something without changing the source files.

The only thing that might be an option in this situation is provide an installer script that can do skin / SQL / settings edits. I am not saying this will be in IPB2.1 tho.

Besides the fact that you make a very good point that IPS is trying to make producing mods easier, a huge concern is support.

If IPS makes this, people will think they also support all of the mods that it installs, which isn't true.

IPS needs to stick to their product. Their product is theirs, and they aren't obligated to accomidate people making modifications THAT FAR.

They already accomidate mods, people just don't take advange of those accomidations.

I just want to say that I do also see this as a customer wish.
I also undestand that the main issue is that IPS don't want to support modifications. And I understand that. It is normal.
If there would be any solutions considering this fact, this would be a enormeous addition.
And most of the time there is a solution to any given problem...

Simply, everyone is thinking about a Modinstaller working like it does in PHPBB.

As I See it, thier are 3 types of Modification:

• Alters a Feature that is already Present
• Adds a new "thing" to the Board - such as the Blog, or IBStore

now, the former type of modification will require file edits.

The Latter type does not. using the Current automodule system (See Wizzys post), you can avoid having to do the index.php edit. If matt could do somthing Similar with the AdminCP Pages, and the UserCP Pages, then a module would be able to install itself without affecting the code. if the module needs Custom Profile Fields, then it can create them via an install Script.

As for upgrading mods, i would guess thier are a few key changes that could be compiled into some sort of upgrader Script. it probably wouldnt work on all mods though.

For the issue of an installer deleting code then another one looking for it, that could be solved by the installer commenting it out, but still I dont think it would be worth while having to create and use a mod installer. Easy solution - use small number of mods - If u need lots (I mean LOTS) then code your own as IPB isnt really for you LOL

Maybe I've missed it or something, but I haven't seen any documentation on the concepts W1lz0r stated... perhaps this is why people don't take advantage of them as much as they could/should?

Its all Documented in the Knowledgebase.

If mod authors stuck to using already IPB existing methods, then you can eliminate maybe 70% of the current "find this... replace with this..." work.

IPB 2.1 will have a more modular system with more API classes which will be documented. Use the energy you're using trying to convince us to manage everyone else's modifications to convince mod authors to use existing methods to integrate with IPB.

Well said Matt... IPB is very mod-friendly as it is... Even when you don't use the module loader, adding your act to the array isn't hard at all

IPB 2.1 will have these (well documented features):

A total components framework, which allows, via custom module files the following:

- Board Header Link Generation
- UserCP Menu Links Generation
- ACP Menu Links Generation
- Active Users List Entry Generation ( Matt | Viewing Lindy's Gallery ), etc

A total API framework, which will help with mod install files:

- Add language (add words and phrases to existing language packs)
- Alter components settings (to edit, change, etc ACP menu and Board header links)

If mod authors use the new components framework, then the need to physically hack up existing skin and source files is dramatically reduced.

EDIT: (from Matt's post above) Oooooo that seems nice.

Well some people dont like to do this in their links I guess:

?act=module&module=mymodule

They would rather do this:

?act=mymodule

And the thing is, atleast for me, some modules have been indexed by search engines already and changing the link wouldnt be a very good idea, especially to those that have them bookmarked (one of mine is a guide system).

What you could do is have an option to go both routes in the system. Have an option in adminCP to check for action plugins not listed, or not to. You could simply do something like this:

Change:



To:



It's not exactly like that I asume, but you get the idea. And have an adminCP option in the new if statement to allow this or not.

You can always use:

index.php?automodule=blog

But my links are already pointing to and indexed to ?act=mymodule

Not trying to be stuborn or anything, but would be nice to have an option to use ?act= like the rest of the modules do automatically. And with mod's the biggest issue isnt editing index.php, it's the other files :-". Something I need to change that just "doesnt fit". I mean if you could do everything I need IPB to do in 2.1, that would be great.

Got some good examples too:

#1

http://www.toontask.com/index.php?showforum=5

I direct your attention right under the users browsing this forum thing, "Moderators". Want to point out that Admin's (group color red) and Supermod's (group color orange) are added to this list along with forum moderators (group color green).

Then I disabled the "Forum Led By" thing. Option to disable that in AdminCP would be nice.

#2

http://www.toontask.com/index.php?

You'll notice the (# Viewing) on some forums after their titles. Be nice if you made something official. The use of it is: If others see on the index people are browsing that forum, chances are they will look there too.

#3

Bottom of my forum index "Members Online Today". Now I'm not asking for this specifically, but there's a thing that does it for the past 15 minutes. Maybe have an option to display multiple ones w/ custom icon and custom timer interval. Maybe even a custom title. So I could have the every 15 minutes one and in AdminCP add one with a 24 hour interval. Would be cool to have.

#4

Disable year on the birthdays. This is VERY VERY important. I run a kids site, and hiding somone's age is quite important. So an AdminCP option to hide their age and disable the option to choose year would be good, plus make year optional.

#5

Custom forum icons for each forum. If not for any forum, atleast give the trash can it's own icon.

#6

A lot of mod's require you change the sql cache in /sources/sql/. A number of mod's do at invisionize, and so do a couple of mine. More in the area of loading member information though. Any ideas on that?

#7

Reason for editing. This is a must need moderator option. Reason for editing should be made avaiable for all though and the "add edit by" thing should be the same, an option in user groups.

#8

In the java script there are a couple commands I use for brining my own pop-up window. Maybe add an off-shoot global js file to add my own functions in there (so I dont modify the origonal).

#9

In the navigation thing (Item -> Item -> Item) you do it like this:

Forum Name -> Forum Name -> Topic Name

An option to do this would be good (home being your portal)

Home -> Forums - Forum Name -> Topic Name

And lastly (with #9) have an option for modules to remove the "-> Forums" part from the navigation. This is important because if I'm building a site around IPB, there's some sections I dont want to appear under "Forums".

#10

A lot of people add onto the portal. New replaces with the <TAGREPLACE> thing, new functions for new features. Would be cool if you had a to add that stuff externally to an editable file instead of modifing the portal directly. Some way to easily add onto the portal.

What you could do is add an secondary class for custom functions (used by the portal) and use special replace tags to load them: <!--- PORTAL[mycustom] --->. Then use some preg_ commands to locate and strip out the "mycustom" part and use the custom function.

#11

PLEASE Fix this one. An option for a user group to bypass password protected forum. Or at the very least allow admin's and super moderators, and mod's of that particular forum to bypass the password. You think this would be obvious, but I guess not.

#12

Option to save forum passwords to your profile. outlaw did a nice modification that required a custom table to save passwords. If you did something like this that would be really cool. Atleat an option to do cookie or mysql stored. You could have a special field in members_extra that's serialized to store these passwords.

#13

Some things in adminCP that you "might" have already done. Really not sure since it looks like you've completly redone it, but these would be nice editions:

Resend Validation in Validating Section
See IP address of validating members
Favoirite Queries (Dean did this, nice idea)

#14

Mod Center like in the Tip's forum as an option over email and pm's. Of cource one with more options though

#15

Something I havent added (yet), but topic rating like vB has. An option to enable/disable it per forum.

------

Well that's all I can remember for now. But those are some of the big things that I have changed. If I remember more I'll post them. Do these, and you'll take away my reasons for editing hte origonal source

IPB2.1 will not have so many queries in the SQL cache...

Example for the Blog, I was able to remove all but 4 of them.

And you can allways load your own query cache file; that's better then adding queries to the current ones.

Um... no... Let's say you're loading $ibforums->member information. There are specific fields that are being loaded in a sql cache. There are some edits that simply add an extra field. Doing it in a secondary query is quite ridiculus. It's way better to load it at the source, not load something twice.

( EDIT: Added to by list, hehe )

EDIT 2: Please see this topic: http://forums.invisionpower.com/index.php?showtopic=167262

You could always have a cache of the module arrays and array_merge the two arrays together, that would allow the modules to use the act array if so needed

That sounds good.
Will there be a(n easy) way to put the generated UserCP Menu in an IP.dynamic content block ?