Thread

Discussions has been moved the to Wiki discussion thread. 😊

“Matchbox is a set of extended libraries for CodeIgniter”
Does that mean you can bundle this with a CI installation just by adding the libraries? i.e. no core manipulation.

Exactly. 😊

If Module Manager was released as a module, it could be considered optional and an independent download.

Yes, that would seem the most logical solution. However, that would mean users would have to not only distinguish module and standard CI contributions, but also modules with and without requirement for the module manager. But that might not be that big a deal…

Congratulations Zacharias! A great tool now also has a great name 😉

Do you guys feel a Module Manager is a worthy addition, and if so, what features would you like to see implemented?

It would be handy to have at least an example on how to build such a module-manager. And if you were to take it to extremes it would of course be great if the module-manager would contain zip-upload, so users can easily add modules through a web-based admin panel. But I don’t know if you were thinking along those lines.

A question though: I read that in Matchbox 0.9 modules can be placed in application/ or system/, but would it also be possible to place the modules-folder in the BASE_PATH of CI? So the same place where the main index.php resides? Or would I have to hack into Matchbox to achieve that?

Thanks, I fond of the name as well ^^

A full-fledged module manager with downloadable modules have crossed my mind, yes. What do others think?

Regarding the BASE_PATH, the BASE_PATH is in fact your /system folder. But if you wish to place it where your index.php reside I would like to ask: why? 😊

Regarding the BASE_PATH, the BASE_PATH is in fact your /system folder.

Sorry, I meant base_url.

But if you wish to place it where your index.php reside I would like to ask: why?

I thought you’d never ask 😉 The reason for this is that I develop open-source software, and I want to make the software as easy to use as possible for non-technical people. This is also reflected in the directory-structure: everything that should be easily accessible to users, is in a seperate folder called /user-content/: layout themes, widgets, config, etc. Another benefit of this approach is that users can upgrade to the latest version of my app, without overwriting any changes they made to their themes, config files, etc.

I’ve also created an architecture for widgets, which are basically mini-CRUD “modules”, which can be dragged around and placed anywhere in the layout. I don’t have a zip-installer for widgets, so I thought it would be easy to also place the widgets-folder inside that user-content folder for easy-accessibility.

Anyway, a zip-uploader for modules would solve this “issue” in an even user-friendlier way, so I opt for that one!

Well if it is just for user-friendlynes I think I’d rather go with the module manger. The resource locater already looks in quite a few places. However, I’d still like to hear peoples thought on what features one such manager should include.

(I’ll still have a look at how one might go on about having it look at the base url 😊)

EDIT: One thing you should note about having modules in the base url (root) or any other place than in the APPPATH. Controllers won’t work. So if you want to use modules with controllers (which I assume you do) you have to have them in your application folder. However, modules just containing helpers, libraries, etc. can go in BASEPATH.

Great stuff, I really like the direction you are going with it.

What would be the scope of the module manager would it handle set up/removing module related database tables. As for the interface it would have some form of authentication procedure i guess so will it be build in or would it be up to the developer to implement it?

EDIT: One thing you should note about having modules in the base url (root) or any other place than in the APPPATH. Controllers won’t work. So if you want to use modules with controllers (which I assume you do) you have to have them in your application folder. However, modules just containing helpers, libraries, etc. can go in BASEPATH.

Ok, that’s very useful information 😊 Thanks! If this is the case I’m even more in favor of a module-installer. Though I think it might be hard to make one that fits in with everyone’s application: user-management, menu-system, etc. I think you should start simple: just an interface to upload or delete modules. Maybe activate/de-activate too, and users can adjust it to their own application/needs.

gerben, I found out that I might actually be able to make modules in places other than APPPATH that can also load controllers, I’ll find out. I’m thinking of adding an config file where you have an array of places to look for modules (since some people won’t need the BASEPATH and some might to store them in the root).

Regarding the manager. xwero: setting up and removing related database tables was the first reason i started thinking about a module manager. However I’m unsure of how feature heavy it should be. I mean I could stuff it but developer might be annoyed with the extra work required to make a matchbox module.

I was considering making a module interface that uses a matchbox library for most of it’s functionality so developers could load that library and use it for their own module manager (with their own authentication and layout) and just disable the standard one.

Maybe there should be a database config file so that developers can adjust the tables/fields for each site they add the module to. You never know if you can start from scratch or that you have to use existing tables. The problem is how to give maximum flexibility and keep it programmable.

gerben, I found out that I might actually be able to make modules in places other than APPPATH that can also load controllers, I’ll find out. I’m thinking of adding an config file where you have an array of places to look for modules (since some people won’t need the BASEPATH and some might to store them in the root).

Cool! I thought it had to be possible, because I already run all sorts of CI stuff from outside of the application/system folders.

A config file would be marvelous, and make the module manager very flexible. A nice side-effect would also be that you can have different kinds of modules in different places. Yesterday I managed to load a module as a widget (so it can be dragged around anywhere in the layout), and with a config-file I could have seperate folders for normal modules and widget-modules.

As for a table-installer: you can first keep it simple by letting module-designers just create an install.php which contains all queries, and then call it from the admin-panel.

xwero: I think that enabling table/field custamization is up to the programmers of the modules to get right. I mean if the table names are hardcoded they will be hard to custamize. However, I will encourage not doing so on my “Standards” wiki page if/when I get the manager done.

gerben: Guess what? I got it working 😊 I’ve made a config file containing an array of directories relative to your application folder in which codeigniter should look for modules. It’ll be included in the next release (it’ll require some more tweaking and testing). About the table-installer in the module manager, what I am doing is giving developers the opportunity to include and modulename_module.php file with methods like install(), remove(), etc. So developers could easily put table creation in there as well as some pre installation configuration forms.

I also updated a few files so they’ll be compatible with CI 1.5.5.