[meta] Smarter UI/API separation for modules

Created on 11 October 2010, over 14 years ago
Updated 21 June 2025, 3 days ago

I've noticed a distinct trend, ever since Views started doing this I think, of people creating a Foo and a Foo UI module. I think this is an absolute horror and should be eradicated from the earth.

Why?

- It's double the amount of work for site builders in terms of clicking things on.
- Only increases the frequency of, "Where the (*&@# did my admin page go? Is it under Structure instead of Configuration? No... Am I on the wrong server? No... Are my permissions set incorrectly? No... OH FOR THE LOVE OF."
- Bloats the number of places for Drupal to check for hook implementations when firing system events. (Granted, this is less severe a problem in D7 than in D6 due to caching, but nevertheless....)
- Bloats the number of places for developers to look for where the *&!@ that function/template file/menu definition/hook implementation is.

Seriously, this is just horrible UX-wise, DX-wise, everything-X-wise. Please. Stop. What prompted me to post this was I installed Drupal Commerce, a single module package which takes up three page scrolls of my module page due to this split. Ugh. :\

I think the reasons people do this is two-fold:

1. UI modules can sometimes involve a lot of code. Since all .module files are loaded on every page to check for hook implementations, and module developers don't want a bunch of jQuery crapola loaded on every page, they make it a separate module.

To which I respond:

"That's why the good lord invented the 'file' index in hook_menu() and hook_theme(). So you can keep your heavy UI code in separate files that are not loaded on every page."

2. They want to get their configuration right and then lock out non-technical users who don't know what they're doing so they can't screw it up.

To which I respond:

"That's why the good lord invented the 'administer foo' permission. If you give non-technical users access to uid 1, you deserve what you get."

I assume I'm missing something obvious, so filing this as a feature request so we can figure out whatever that something is, and then fix it in core, so we can stop this horrible pattern from extending further.

πŸ“Œ Task
Status

Active

Version

11.0 πŸ”₯

Component

extension system

Created by

πŸ‡¨πŸ‡¦Canada webchick Vancouver πŸ‡¨πŸ‡¦

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • πŸ‡ΊπŸ‡ΈUnited States nicxvan

    Ok I've read through this whole issue, there is a lot of great information.

    For all intents and purposes the ui module split is well entrenched both in core and contrib and as mentioned there is no real way to enforce this.

    As I was reading I was thinking recipes solves a lot of these issues. Also project browser will help with discovery.

    I think there are still two big things missing even with recipes:

    1. You have to discover the recipe (which also requires someone building them)
    2. The module page, how do we organize it in a way that makes these groupings easier.

    Is the solution a combination of recipes and a ui for browsing them so that the module page is only for advanced users like drush?

    I might share this with the project browser initiative to see if this is being considered.

Production build 0.71.5 2024