Namespace top-level directories

[ewinslow]

Wordpress does this. We could take it down to three top-level directories and two top-level files with this approach:

• elgg-engine/ everything else
• elgg-plugins/ Just a renamed "mod"
• elgg-data/
  • uploads/ default location of Elgg filesystem
  • simplecache/
• index.php
• README.txt points to other .txt files

Benefits:

1. Simple
2. elgg-engine becomes an almost perfect example of what your plugin's structure should look like.
3. We all like "plugins" better than "mod".
4. Virtually eliminates chances for conflicts when we implement #2228.
5. Encourages use of page handlers even more because now you'd have "elgg-plugins" in your url (yuck)
6. Default location of data directory makes common setup even easier

[cash]

-1 I really don't like this idea and generally think WordPress is not an example we should be following.

1. current dir structure seems simple
2. the bundled plugins should serve as examples
3. we can do that without adding a namespace
4. seems that it would be very rare to have a non-elgg data directory in elgg already
5. true
6. this can be done without namespacing

Plus, one of my favorite changes in 1.8 is getting rid of the top level entities directory. It is so nice hitting e - tab to get to the engine directory.

[ewinslow]

@Cash, interesting. I did not expect such a strongly negative response.

I'm probably conflating a few issues:

1. namespacing the directories
2. moving certain directories from root/ into /engine/.
3. renaming mod/ to plugins/
4. Support for a data/ dir within the elgg root

I'm definitely more interested in (2) and (3) than (1) or (4).

One of the most commonly recurring bug reports over the last two years (as you know) is the "action" vs. "actions" thing. Moving actions into the engine dir would (hopefully) make it clear that this isn't just a typo. And if we move actions/ in there, it makes sense to do pages, languages, and views as well, just like plugins. That makes for a consistent structure all around. Consistency == less learning curve, which is something Elgg suffers from greatly.

Should we open different tickets for (2) and (3) and close this one as wontfix?

[cash]

I definitely like 3 and we should have a ticket for that if we don't already.

I'm not sure 2 is worth the effort. It means developers need to relearn the structure (It still takes me a little while to find the core page scripts). It means people will have old code mixed with new code (I think this will be a problem with the 1.8 release due to the views work and plugin structure re-org). I appreciate that we'd end up with

/engine
/plugis
/vendors

or something similar and that is a very simple structure. A change like this is more likely to annoy with only a small benefit.

As for actions, those problems should go away with the 1.8 installer. Not only does it not use the actions system but it does a rewrite check. The problem before was that it left you with a 404 error. I know I changed the directory name that first time I tried to install.

Plus, longer term the actions may end up as methods of a controller class. Same with page scripts.

[cash]

I pulled out (3) as #3334. If there are other things that we want from this ticket, let's reopen or create a new ticket for that specific item.

[ewinslow]

perfect