Self-contained MODs

[naderman]

3.1 will contain a hook system to modify the behaviour of phpBB without code changes. So many MODs can be implemented without the need for anything like AutoMOD.

[uk_martin]

As I see it, yes having self-contained folders containing MOD's is all well and good, and sure, you can delete the folders, and the MOD is gone.

HOWEVER, the problem continues with the codebase changes to template, language, config files etc and with database changes.

I think that the further development of AutoMOD may be a better way to go with this, (call it "AutoMOD 3.1" if you like) in such a way that "AutoMOD 3.1" retains a full record of changes to files and the database that it makes during installation and that it also has a full uninstall routine that undoes any alterations to files and the database. It would need to be sophisticated enough to cope with inline edits of template files (etc) and that its current method of keeping backup files and replacing Modded files with the backup at the time of uninstallation is dropped. The system is fine for as long as there is only one MOD in the system, but if several MOD's are installed and the first of these is then uninstalled, the backup files won't contain the alterations that later MODs created.

I would also suggest and that full AutoMOD standards compliance is mandatory for any new MOD released, in order to ensure that a measure of reliability is introduced.

[nekkidblogger]

In my opinion you should go much further: Look closely at WordPress.

It ought to be possible to go directly from the Admin panel to the mod repository, search it, find a mod you like, and then click it and have it auto-installed. Likewise, there should be a list of installed mods in the Admin panel, and the ability to uninstall with one click.

That philosophy, by the way, ought to go for updates to phpBB as well: Admins should be able to see (easily) which version they have and whether a newer version is available. If they want, they should be able to upgrade by simply clicking on the link to the most recent version.

There is no reason whatsoever why people should have to download mods and updates to their hard-drives and upload them to their servers from there - much less to download, unzip, and then upload.

In my humble opinion, the focus on streamlined, simple, one-click and ready to go installs, upgrades, and changes in theme layouts and functionality ought to be a very high priority. It's not easy, and it requires very clear guidelines for modders as well as developers, but it can be done. That's the kind of philosophy that has made WordPress such a fabulous success - there are now over 50 millions blogs using it. And people using it don't need to know anything about CSS, HTML, PHP or MySQL. If you know it, fine - you can get things done others can't do and customize more, but you can run a WordPress blog and do fine without ever changing a line of code, downloading a single file to your PC or ever uploading to the server. That's a huge acheivement for WordPress and, I think, a smart philosophy for rapid growth and expansion of the user base.

Best,
Peter

[callumacrae]

In my opinion you should go much further: Look closely at WordPress.

It ought to be possible to go directly from the Admin panel to the mod repository, search it, find a mod you like, and then click it and have it auto-installed. Likewise, there should be a list of installed mods in the Admin panel, and the ability to uninstall with one click.

That philosophy, by the way, ought to go for updates to phpBB as well: Admins should be able to see (easily) which version they have and whether a newer version is available. If they want, they should be able to upgrade by simply clicking on the link to the most recent version.

There is no reason whatsoever why people should have to download mods and updates to their hard-drives and upload them to their servers from there - much less to download, unzip, and then upload.

In my humble opinion, the focus on streamlined, simple, one-click and ready to go installs, upgrades, and changes in theme layouts and functionality ought to be a very high priority. It's not easy, and it requires very clear guidelines for modders as well as developers, but it can be done. That's the kind of philosophy that has made WordPress such a fabulous success - there are now over 50 millions blogs using it. And people using it don't need to know anything about CSS, HTML, PHP or MySQL. If you know it, fine - you can get things done others can't do and customize more, but you can run a WordPress blog and do fine without ever changing a line of code, downloading a single file to your PC or ever uploading to the server. That's a huge acheivement for WordPress and, I think, a smart philosophy for rapid growth and expansion of the user base.

Best,
Peter

I've heard mentions of something like this for 3.2, but it definitely won't be happening in 3.1. I would like to see this, too

~Callum

[imkingdavid]

This is a great idea, but how will it work with MODs that still have to make edits that cannot be acheived with the hook system? One example I can think of is adding constants for new database tables. It is generally accepted/expected to edit the includes/constants.php file and add new constants at the end. Perhaps one way around this is to have MOD authors include a new file called constants_modname.php and then that file is automatically found and included if present? This is how I did it in one of my mods to reduce the code edits; I added a new file for constants for that MOD and automatically included it in a hook.

Also, how will it work with MODs that have need of a front-facing file? For instance, a MOD that adds an articles system might add a file called or articles.php. If the proposal were put in place, the user would have to go to board/includes/mods/articles.php instead of just articles.php.

Or perhaps we could do what some other software does and use index.php as the front-end file and use a query string to go to specific places, i.e. index.php?page=articles or index.php?p=viewtopic
But that might be a bit extensive of a change for 3.1.

[naderman]

Or perhaps we could do what some other software does and use index.php as the front-end file and use a query string to go to specific places, i.e. index.php?page=articles or index.php?p=viewtopic
But that might be a bit extensive of a change for 3.1.

I think this would absolutely be doable as a hook for 3.1. We'll keep the other files in phpBB as they are. But as you point out, this would allow hooks to add new pages easily.

[imkingdavid]

Or perhaps we could do what some other software does and use index.php as the front-end file and use a query string to go to specific places, i.e. index.php?page=articles or index.php?p=viewtopic
But that might be a bit extensive of a change for 3.1.

I think this would absolutely be doable as a hook for 3.1. We'll keep the other files in phpBB as they are. But as you point out, this would allow hooks to add new pages easily.

Should that be made an RFC or sub-RFC for this self contained MODs idea?

[naderman]

It should really just be a hook request RFC I think.

[*Daniel]

Or perhaps we could do what some other software does and use index.php as the front-end file and use a query string to go to specific places, i.e. index.php?page=articles or index.php?p=viewtopic
But that might be a bit extensive of a change for 3.1.

I think this would absolutely be doable as a hook for 3.1. We'll keep the other files in phpBB as they are. But as you point out, this would allow hooks to add new pages easily.

I think that is going to be a bad move. One example, What if someonw wants to (and yes you can do it right now) have a gallery mod installed in gallery.domain.com and their forum in forums.domain.com. If we go to having index.php as the main hook for everything like in ip.board, it may cause some issues for those who want to run different part of their site in a different subdomain.

[naderman]

We have never supported anything like that in the past and you can still simply put new files on your subdomain, nobody is stopping you.