Ordering of modules

I think this is an evil hack that lacks transparency. If we want to be able to sort the order of invoked hooks we should do it the right way and offer sorting on some admin page.

There is another thing related to the way admin/modules work, that often needs to increase the PHP memory limit. It is that all modules need to be loaded in order to get access to their hook_help, etc.

Maybe it would be nice to normalize the README.txt file provided by modules in a similar way WordPress plugins/themes work. That is, the module name, version, description, could be placed on a text file that could be loaded and parsed instead of including the PHP code itself. Then, you could also add a field to specify something like "this module should be loaded after this one, if present" or something of that sort.

I already commented something about it here (just for self reference):
http://drupal.org/node/39647#comment-58934

I we want ordering of hook invocations (and I do) we need to do it right. That is, by adding a weight for each module. I know that our weighting interface sucks, but that is unrelated and needs to be dealt with separately.

Yesss.

Some remarks:

the new field is still called depth in database.*

the change in function system_modules seems not needed.

I guess we should add some help text.

The concept is nice.
I'm using it to order things getting called via form_alter.

Drumm brought up some good points about more specific ordering systems specialized to their tasks.

It looks like you're leaving a stray asort in modules_list, which breaks the functionality of this patch altogether.

much needed, and very drupalish. code looks good. i haven't tried it yet.

Since you're now ordering by weight+filename, you may want to add filename to the new key of the system table. I believe it may save an internal SQL sort.

Much needed, but do we want people to reorder modules themselves?
Do you know of any other software that lets the end user tweak stuff like this?
This is going to confuse the hell out of people, and there is no mention of it in the help text?
How do we explain this to the user?
Do we really want such a prominent GUI option for this?

As en example, if you create a module that need to redefine a menu callback, then you would love this feature so you can write in the INSTALL.txt file a step such "enabling this module and change its weight so it's ordered after module xxx".

For instance, the LDAP integration module uses a mini-module named "zcallbacks" to redefine user/login.

I hope that makes sense.

Now. I first created a solution without a GUI. You folks called that hackish.

Dear Chx. We called your directory solution hackish.

chx: nothing to worry about. I'm just polling for opinions on the GUI changes, and will commit the proper patch accordingly.

Module order dependency should never even make it to the GUI.

If Module A requires that Module B run before it, then that is true at all times. The user shouldn't be able to change something and break that.

If Module A doesn't care when it runs with respect to Module B, then there's no reason why the user should be able to change it since it would have no effect.

Whatever the solution, it should be code-based, not UI-based. Nothing good can come of users futzing with module order.

Crell - you'd be a fan of http://drupal.org/node/5491

IMO, this isnt about dependencies. We are usually talking about reordering visible elements like a list of links or a list of fieldsets such as what appears at end of the node form

I'm fine with weight showing on admin/modules. If that seems distasteful, take chx's patch without the system.module piece and let a contrib module provide the UI.

wow chx. thats a clever use of form api 9add weight fields and change $theme. i hadn't thought of that.

conditional +1
as a dev tool and a temporary thing for 4.7.

I agree with drumm's comments about more task oriented ordering in http://drupal.org/node/5491. This is a sledge hammer for situations like upload processing, where you may want things to have an effect in different order per node-type, and may cause conflicts if several nodeapi modules are written to be dependent on execution ordering.

That said, I've already found two uses for this patch...

1) ordering form creation(access the upload form to add more fields).
2) handling post processing uploads (generation of file derivatives on submit).

Its working fine... haven't found any problems yet... going live with it on a site tomorrow.

Patch no longer applies. Sorry.

re-rolled

Committed to HEAD. Thanks for the quick reroll.

Committed to HEAD. Thanks.