MOD Installation

[A_Jelly_Doughnut]

While one of our stated goals for Ascraeus is to require fewer file changes, largely with an expanded and improved hooks system, we aren't naϊve, and trust that MODX will still be around for phpBB 3.1.

We'd like to implement an automatic MODX installer, something along the lines of AutoMOD into Ascraeus.

The question to the community at large: if we use the existing AutoMOD as a basis for the MODX installer feature, what improvements should be made? And, is there any argument against using AutoMOD as the basis of such a system?

I'll sit back and watch for a few days, because this isn't a discussion I should be driving.

[callumacrae]

I would quite like to see AutoMOD being integrated with the phpBB MOD db:

• Admin browses MODs in the ACP instead of phpbb.com
• Admin can install MODs without having to download files
• ACP tells the admin when MOD updates are available, and makes it easier to update (maybe automatic?)

I can't think of any reason why AutoMOD shouldn't be used.

~Callum

[igorw]

IMO the code base of AutoMOD needs to be cleaned up. There needs to be better separation of concerns, less dependencies between the components. The MODX parser should use SimpleXML and XPath. There should be an API that can be used to install MODs programatically without having to load the whole phpBB environment with $template, trigger_error, etc.

Since this is a new addition to phpBB, there's a lot you can do with it. You can use dependency injection (passing information into classes instead of depending on globals). You can use Exceptions instead of trigger_error, which means you don't have to worry that trigger_error will mess up your CLI output.

The file writing API is frankly a bit of a mess. Since there is a proper storage abstraction planned for 3.1, it may be possible to use that too for FTP, SFTP, etc.

Having AutoMOD in phpBB 3.1 is greatly needed, but I'm not quite happy with the code base. I mean no offense Josh, it's constructive criticism. I would like to see better coding practices for new parts of 3.1, which would greatly improve re-usability of the code. There has already been some work on a CLI for 3.1, and there is potential for similar tools (development tools) with a web front-end. I'd like to see that happen.



This should be easier.

[Oleg]

I would like a facility to convert modx files to patch files and sql files.

All of my source code is version controlled. The way modifications are installed in production is this: first, changes are made in a development install. Then the changes are committed to vcs. Finally the updated source tree is deployed to production system. Neither development nor production source trees are writable by php process, there is no ftp anywhere in sight and I am not going to give any ssh passwords to php code.

Current automod is supposed to deal with this situation by serving an archive of modified files. However on my system all I ever get is an html page disguised as an archive. In effect automod does not work at all.

Automod cannot resolve conflicts. I say it's pointless to try. Convert modx to a patch and let me apply it myself. If it fails to apply I will resolve conflicts. Patch already provides conflict markers and rejected hunk files, why reinvent this wheel?

Sql changes are typically easier to do by hand but if the patch conversion is done why not give me sql statements in a usable format too.

[imkingdavid]

I think that including AutoMOD (or similar) into the core of 3.1 would be a great move for phpBB; this is one major complaint I've heard across the board; SMF has a package installer and MyBB MODs are easier to install via the ACP, but phpBB still requires manual file changes. So to include this would make a lot of people happy, and would make it easier for MOD authors to quickly test their MODs. Currently, they have to install a new phpBB, add AutoMOD, install the MOD to test, and then test. A step could be removed by having AutoMOD already in the core.

A suggestion I have is to be able to remove the need for a separate SQL install file. Possibly adding new tags to the MODX format to allow permission addition/set, SQL table addition/alteration, row insertion/removal, etc. and module addition/removal.

That or else have the SQL install file automatically run from within AutoMOD. Or even redirect from AutoMOD to the SQL installer and then back to the AutoMOD success page.

[DavidIQ]

A suggestion I have is to be able to remove the need for a separate SQL install file. Possibly adding new tags to the MODX format to allow permission addition/set, SQL table addition/alteration, row insertion/removal, etc. and module addition/removal.

That sounds like a good idea. Maybe somehow integrate AutoMOD and UMIL (or some form of it) which might make this easy to implement. Any of this would also need a new MODX btw (2.0?).

[DavidIQ]

I would like a facility to convert modx files to patch files and sql files.

That wouldn't be something for AutoMOD to handle though. Would be more for a future version of MODX (here I go mentioning 2.0 again...).

[igorw]

I have been in favor of patch files in the past too. However: patch files do not support inline actions and while you are able to resolve such inline conflicts manually, the average phpBB admin cannot. IMO changing this is not worth it, we should rather work towards eliminating file edits via hooks.

As to generating SQL instructions, I generally like this idea. I think this should be handled by UMIL, so perhaps it makes more sense to discuss it in that topic. But it can become more difficult once you have conditional queries, or data inserted that is obtained through a select. Example: A MOD creates a new user, the username is determined through user input (challenge 1), the user's default group is 'registered users', but the ID for that group needs to be determined from the database (challenge 2). These challenges need to be considered.

A suggestion I have is to be able to remove the need for a separate SQL install file. Possibly adding new tags to the MODX format to allow permission addition/set, SQL table addition/alteration, row insertion/removal, etc. and module addition/removal.

I'd prefer to see these kind of actions in a separate file instead of mixing file changes and db changes. I like the idea of an abstract xml/whatever definition of these UMIL actions. I'll just link to UMIL : data providers.

[code reader]

IMHO, using the MODx format is the wrong direction. true, we have tons of existing MODs, but i still feel that this will not be good.
MODx is propriatary (and ugly) format, that is meant to be used by humans, and is not friendly. it is ridiculously difficult to create, and not at all friendly to apply.

recently we switched to git. it is very reasonable to assume that every MOD developer has a full repo of the code.
the most natural format for a mod is the format of a patch.
of course, the patch itself is not enough - you need a manifest (name, description, author, mod version, compatible board version, etc.), and some stuff that UMIL would use to modify the database if the MOD requires it, but for the code change, we should use
git format-patch

peace.

[EXreaction]

And a patch is easier to read?
(let alone the added abilities of ModX over a patch file)