[drupal-devel] Cleaner Directory structure
There has been a discussion in the forums of having a cleaner directory structure for Drupal. Here http://drupal.org/node/22269#comment-38302 I said: -- BEGIN This will simplify upgrades and other things. It isolates Drupal in its own directory, so other stuff can exist in their own directories. All data files, image files, and other things have to be outside drupal. Only additional modules, themes and settings.php files should go under the Drupal directory. As a matter of fact, even local modules and local themes, and even the sites directory can be located in its own directory For example: public_html - .htaccess - index.php - drupal/ - drupal-local/ Under drupal-local we have: - drupal-local/sites/ - drupal-local/sites/site1.com/settings.php - drupal-local/sites/site1.com/themes/ - drupal-local/sites/site1.com/modules/ - drupal-local/sites/site2.com/settings.php - drupal-local/sites/site2.com/themes/ - drupal-local/sites/site2.com/modules/ - drupal-local/themes (themes shared by all sites) - drupal-local/modules (modules available to all sites) Drupal can search for drupal-local/ first for configuration files, then search drupal/modules and drupal/themes for modules and themes, then search drupal-local for modules and themes. The "drupal" directory should contain the standard Drupal distribution with no modifications whatsover, with instructions to move or copy the .htaccess and index.php to the directory above, so local changes can be merged on upgrades manually. This way, upgrades will be much easier: everyone should leave the drupal/ directory alone, and only mess with the drupal-local directory. -- END What do other developers think of this? It will address one gripe that people have, which is the difficulty of doing upgrades.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08 May 2005, at 2:36 PM, K B wrote:
What do other developers think of this? It will address one gripe that people have, which is the difficulty of doing upgrades.
My install system would address that too. I just don't like it because of the extra typing it requires of me, but I like the idea of seperating contrib and core modules/themes. Also, the name drupal-local is bleh. I recommend local. - -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iD8DBQFCfhdjgegMqdGlkasRAuHzAKCbGGKzwkFN3/aRE3G+NlPiAtRlMwCgzuRj jnmfyUCZ2XvlTLGSRhPaCRI= =9IJY -----END PGP SIGNATURE-----
On 5/8/05, Adrian Rossouw <adrian@bryght.com> wrote:
On 08 May 2005, at 2:36 PM, K B wrote:
What do other developers think of this? It will address one gripe that people have, which is the difficulty of doing upgrades.
My install system would address that too.
That is great.
I just don't like it because of the extra typing it requires of me, but I like the idea of seperating contrib and core modules/themes.
Yes. core, contrib AND configuration. This way Drupal core upgrade is very simple. Just rename the existing drupal directory and copy a new one in its place. The less we make people change things, the easier the upgrade is.
Also, the name drupal-local is bleh. I recommend local.
There could be name clashes with such a generic name. How about drlocal or something like that? We can even make that name configurable, by changing a file under the drupal directory, but then we are back to "configuration files under code directory" thing which we tried to avoid in the first place. Also, if we expand the idea a bit more, we may want to move the 'drupal' directory on level above public_html. This way, only Drupal can include files from it, and they are not accessible to anyone else, hence can be seen as added security (not that Drupal is insecure or anything). This helps in cases where a host configuration gets botches up and php files are served as plain text, and people can see the passwords in the settings.php and other info. This has drawbacks though, it adds complexity for people who only have one directory they serve content from, and not the parent.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08 May 2005, at 4:35 PM, K B wrote:
On 5/8/05, Adrian Rossouw <adrian@bryght.com> wrote:
On 08 May 2005, at 2:36 PM, K B wrote:
What do other developers think of this? It will address one gripe that people have, which is the difficulty of doing upgrades.
My install system would address that too.
That is great.
I just don't like it because of the extra typing it requires of me, but I like the idea of seperating contrib and core modules/themes.
Yes. core, contrib AND configuration. This way Drupal core upgrade is very simple. Just rename the existing drupal directory and copy a new one in its place. Also, while we are re-organizing files, I feel we should move all modules into their own directories.
With our new propensity towards conditional including of code as needed, and the install system work which will end with multiple files per module, I feel it's necessary .
There could be name clashes with such a generic name. How about drlocal or something like that? We can even make that name configurable, by changing a file under the drupal directory, but then we are back to "configuration files under code directory" thing which we tried to avoid in the first place. Drupal will still have name clashes with things, due to the path system it uses; The htaccess will make entire parts of the system unavailable if such a directory already exists (ie: people who have an admin/ directory)
anything). This helps in cases where a host configuration gets botches up and php files are served as plain text, and people can see the passwords in the settings.php and other info. Could be a good idea, except some people might not have access to anything but their public_html directories.
- -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iD8DBQFCfitKgegMqdGlkasRAqo/AJ0fMZxoOcd6lHfgYqllz8tv2MxcWQCfeyBX wSSg0w5Eo5S5z+AHnKigGfc= =VCId -----END PGP SIGNATURE-----
On 8 May 2005, at 16:07, Adrian Rossouw wrote:
Yes. core, contrib AND configuration. This way Drupal core upgrade is very simple. Just rename the existing drupal directory and copy a new one in its place. Also, while we are re-organizing files, I feel we should move all modules into their own directories.
+1 on separate directories for core and contrib modules and themes. This will make it much easier to update Drupal installs, and for administrators to go through contrib modules to check if they are up to date with a new core release. Hopefully this will cut down on a number support requests, and make them easier to deal with. I'd suggest changing '/drlocal' to '/custom' to make it much clearer to average Joe installer what goes in the directory. Best regards, Robert
I opened a feature request for this: http://drupal.org/node/22336 Not only modules and themes, but configuration also should be under the custom directory. On 5/8/05, Robert Castelo <services@cortexttranslation.com> wrote:
On 8 May 2005, at 16:07, Adrian Rossouw wrote:
Yes. core, contrib AND configuration. This way Drupal core upgrade is very simple. Just rename the existing drupal directory and copy a new one in its place. Also, while we are re-organizing files, I feel we should move all modules into their own directories.
+1 on separate directories for core and contrib modules and themes.
This will make it much easier to update Drupal installs, and for administrators to go through contrib modules to check if they are up to date with a new core release.
Hopefully this will cut down on a number support requests, and make them easier to deal with.
I'd suggest changing '/drlocal' to '/custom' to make it much clearer to average Joe installer what goes in the directory.
Best regards,
Robert
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08 May 2005, at 6:46 PM, K B wrote:
Not only modules and themes, but configuration also should be under the custom directory.
Another interesting point is that we could add custom/includes to the include path, which would allow you to customize .inc files. Also, copying core modules before you modify them also simplifies upgrades. Wether this is a good idea, I don't know =) - -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iD8DBQFCfkuzgegMqdGlkasRArw0AKDctP3PeHyfHyMza5oJzDBlAUBa0gCgtByS CacVvg1r/gXalL6vPDGmJMg= =I1j2 -----END PGP SIGNATURE-----
+1 I already put all contrib modules in their own subdirectory of the modules directory. On 5/8/05, Adrian Rossouw <adrian@bryght.com> wrote:
Also, while we are re-organizing files, I feel we should move all modules into their own directories.
With our new propensity towards conditional including of code as needed, and the install system work which will end with multiple files per module, I feel it's necessary .
On 8 May 2005, at 11:07 AM, Earl Dunovant wrote:
+1 I already put all contrib modules in their own subdirectory of the modules directory.
On 5/8/05, Adrian Rossouw <adrian@bryght.com> wrote:
Also, while we are re-organizing files, I feel we should move all modules into their own directories.
With our new propensity towards conditional including of code as needed, and the install system work which will end with multiple files per module, I feel it's necessary .
+1 This seems like a particularly good idea. At the moment I have to keep all of the files associated with a module (README.txt, database.mysql, etc.) in a separate directory so I can refer to these when needed.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The other thing I should add, that i really like about this, is how simple it is to go back to a core installation. One of the things I have always loved about FreeBSD above all other *nix' i've used it it's /usr/local/etc directory. At any point, I could delete /usr/local and be restored to a base system. On 08 May 2005, at 4:35 PM, K B wrote:
On 5/8/05, Adrian Rossouw <adrian@bryght.com> wrote:
On 08 May 2005, at 2:36 PM, K B wrote:
What do other developers think of this? It will address one gripe that people have, which is the difficulty of doing upgrades.
My install system would address that too.
That is great.
-- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iD8DBQFCfjVsgegMqdGlkasRAn1EAJ0XdhcTHejPf0uFtCgsAFhr3iHffgCeK+H4 XQMY0Dp0MwwfJtbMr5uzr8k= =8GVf -----END PGP SIGNATURE-----
On Sunday 08 May 2005 09:42, Adrian Rossouw wrote:
Also, the name drupal-local is bleh. I recommend local.
For what it's worth -- and "what it's worth" may == "nothing" -- that is the directory name that was used in another content manager that I co-wrote several years ago (and later abandoned when I discovered one that did it "the right way", namely Drupal!). The reason I mention this is that "local" was an intuitive-enough name that at least one other project came up with it independently as "the right place to store CMS config files local to the site that shouldn't get overwritten during updates". "local" also has precedent as a directory path component in the *NIX filesystem for files with semantics similar to the above. Scott -- ------------------------------------------------------------------------------- Scott Courtney Drupal user name: "syscrusher" http://drupal.org/user/9184 scott at 4th dot com Drupal projects: http://drupal.org/project/user/9184 Sandbox: http://cvs.drupal.org/viewcvs/drupal/contributions/sandbox/syscrusher
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08 May 2005, at 9:31 PM, Syscrusher wrote:
"local" also has precedent as a directory path component in the *NIX filesystem for files with semantics similar to the above. Yeah. I don't think you should rely on being able to store any other applications in a Drupal directory, since the cleanurl system would very often conflict with them.
Creating a dir called 'admin' makes your admin section inaccessible. So +1 for 'local' - -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iD8DBQFCfmxUgegMqdGlkasRArbZAJ4sjKIkY81UzXDrxcmZVeEEnfAcQgCgkiLe tt/LE1ZLgVulgTig51rQvMk= =of/R -----END PGP SIGNATURE-----
+1 for 'local'. I like the name mainly because it is short and simple, just like all the directory names that we currently have (e.g. 'modules', 'themes', 'sites'). Giving a new directory a name like 'drupal-local' would be inconsistent. However, I don't like the structure of the root directory that was proposed: public_html - .htacccess - index.php - /drupal - /local This structure might confuse people into thinking that everything drupal-related is in the 'drupal' directory, and that the stuff in 'local' is not related to drupal at all. I suggest this structure as an alternative: public_html - .htaccess - index.php - /drupal --- /core --- /local That way, all drupal-related stuff is inside the one directory, 'drupal'. The internal structure of 'local' doesn't need to change (I like what's been proposed so far for that). And when you want to upgrade, you just replace everything in 'core'. Also, I have two concerns about the new proposed system of loading modules and themes: 1. Performance: what would be the performance impact of this system? To load all the modules, for example, Drupal would have to look in /core/modules, then in /local/modules, then in /local/sites/site1.com/modules. Three different locations for one site's modules. Probably wouldn't be a problem, but I'm no expert. 2. Duplicate files: what will Drupal do if it finds three instances of the same module, each in a different location? This is not a problem ATM, because all modules are in the one directory. Will it load the instance that is 'most local' to that site, and ignore the others? E.g. it would load the instance in /local/sites/site1.com/modules, and ignore the instances in /local/modules and /core/modules. This makes the most sense, as it follows the 'scope' principle, much like the scope rules for variables in PHP (and other programming languages). It would also allow modules to be 'overloaded', that is, you could have one version of a module in /local/modules, but you could have a different version of the same module, specifically for site1.com, in /local/sites/site1.com/modules. What would be the performance impact of finding the 'most local' module? The other option would simply be to give an error message if the same module exists more than once, and to not load any of the instances. Overall, I agree with the concept of separating all core files from site-specific files. But we have to think carefully before we implement anything - changing the directory structure is not something that should be done lightly, or often. Jaza.
Great points Jaza On 5/8/05, Jeremy Epstein <jazepstein@gmail.com> wrote:
+1 for 'local'. I like the name mainly because it is short and simple, just like all the directory names that we currently have (e.g. 'modules', 'themes', 'sites'). Giving a new directory a name like 'drupal-local' would be inconsistent.
However, I don't like the structure of the root directory that was proposed: public_html - .htacccess - index.php - /drupal - /local
This structure might confuse people into thinking that everything drupal-related is in the 'drupal' directory, and that the stuff in 'local' is not related to drupal at all. I suggest this structure as an alternative: public_html - .htaccess - index.php - /drupal --- /core --- /local
That way, all drupal-related stuff is inside the one directory, 'drupal'. The internal structure of 'local' doesn't need to change (I like what's been proposed so far for that). And when you want to upgrade, you just replace everything in 'core'.
I think I can live with that. Provided that ./drupal/core does not contain any configuration or contrib stuff in it, I am fine. This will also solve the name clash objection, since all will be under drupal. We ship an empty local with only subdirectories in it (no files), and instruct users to copy the sample provided settings.php to drupal/local/sites/default or drupal/local/sites/sitehostname
Also, I have two concerns about the new proposed system of loading modules and themes:
1. Performance: what would be the performance impact of this system? To load all the modules, for example, Drupal would have to look in /core/modules, then in /local/modules, then in /local/sites/site1.com/modules. Three different locations for one site's modules. Probably wouldn't be a problem, but I'm no expert.
We already search two places, ./sites/modules and ./modules. I am not sure, but I think that Drupal only searches for modules when they are being enabled from the admin menu the first time. After that, the location is in the database, and no search for modules occur.
2. Duplicate files: what will Drupal do if it finds three instances of the same module, each in a different location? This is not a problem ATM, because all modules are in the one directory.
They can be in either of two directories, as I outlined above. So the potential for clash is already there in 4.6 today.
Will it load the instance that is 'most local' to that site, and ignore the others? E.g. it would load the instance in /local/sites/site1.com/modules, and ignore the instances in /local/modules and /core/modules. This makes the most sense, as it follows the 'scope' principle, much like the scope rules for variables in PHP (and other programming languages). It would also allow modules to be 'overloaded', that is, you could have one version of a module in /local/modules, but you could have a different version of the same module, specifically for site1.com, in /local/sites/site1.com/modules. What would be the performance impact of finding the 'most local' module? The other option would simply be to give an error message if the same module exists more than once, and to not load any of the instances.
Interesting points. I think we can either: 1. Define an order of precedence, and take the first one that is found. This is problematic for support, and will be the cause of a lot of grief for site admins and for Drupal developers down the road. That is, unless we can list in the admin pages what the path for the module is (something that we need to do anyway, and is long overdue). 2. Report that modules with the same names exist and give an error message and do not activate this module at all until that conflict is resolved. We hence disallow the practice of having modules with the same name in different directories. I think that this is best in the near term at least. 3. Module overloading and such is too problematic for my taste from the support point of view. I would not recommend it, at least for now, before thinking it over thoroughly and discussing it in the developer community.
Overall, I agree with the concept of separating all core files from site-specific files. But we have to think carefully before we implement anything - changing the directory structure is not something that should be done lightly, or often.
Agree. I like to hear from more old timers (Dries? Killes? Moshe?)
I like to hear from more old timers (Dries? Killes? Moshe?)
I'm OK with this as long we document this properly and provide some best practices, as well as clear instructions on how to move your existing site. In short; keep going. :-) -- Dries Buytaert :: http://www.buytaert.net/
At 5/8/2005 07:36 AM, K B wrote:
There has been a discussion in the forums of having a cleaner directory structure for Drupal.
Would it be useful to bridge email-list content with corresponding forum content so that each community (the email-listers and the forum posters) could see each other's submissions automatically (and with zero change to their current mode of operation)? I suspect so. Right now I see two different Drupal communication areas (forums and lists) talking about the same thing, and it seems that it would be useful to merge the two areas. (Alas, this problem is duplicated only about a million times over in various web communities...well, I might embellish a bit with "a million," but probably not much.) Some existing solutions: Mail2Forum: http://mail2forum.com CM2F: http://www.digitalgraal.dynalias.net/ Someday I hope the world can agree on a global means sync email lists and forums (and other similar mechanisms like Usenet) with the same content. Until then: would it be useful for Drupal to implement something like this for its forums? -Matt
+1 great proposal. While on this theme it might be a good idea to consider the different deployment scenarios, their merits and how does that change the configuration. For example: In shared hosting: drupal/core drupal/local drupal/index.php drupal/.htaccess Custom (non-distribution) unix install: (in /usr/local) lib/drupal - equivalent to core above var/drupal - equivalent to local above var/www/drupal/sites/example.com/files - this is configurable anyway lib|var/drupal are not in the web-server's display paths, this potentially makes sharing the same web-server location with other apps easier windows based installs: I'm clueless there The changes to the current drupal are minimal, mainly in the multi-site file include code. Apropos. Recently there was a lengthy discussion on the debian-security mailing list about the general security status and practises of php applications. There was, let's say, discomfort about exposed configurations, 'talking' files, etc... While drupal is relatively good in this respect, we should be able to enable better practises and offer advice on the site configuration choices. Not everyone is experienced. Some people are willing to learn. Cheers Vlado
While on this theme it might be a good idea to consider the different deployment scenarios, their merits and how does that change the configuration. For example:
In shared hosting: drupal/core drupal/local drupal/index.php drupal/.htaccess
No, it is like this: public_html/ public_html/.htaccess public_html/index.php public_html/drupal/ public_html/drupal/core public_html/drupal/local Then the admin can put: public_html/files public_html/somethingelse As long as they are outside of the drupal directory. This way, the index.php is in the public_html directory of the account, and .htaccess affects how it works.
Custom (non-distribution) unix install: (in /usr/local)
lib/drupal - equivalent to core above var/drupal - equivalent to local above
var/www/drupal/sites/example.com/files - this is configurable anyway
lib|var/drupal are not in the web-server's display paths, this potentially makes sharing the same web-server location with other apps easier
I think this is a bit overkill. We do not do this now, and it works fine for both shared and dedicated hosting. The admin of such a system can do all the tricks he wants separating filesystems and such using symlinks.
windows based installs: I'm clueless there
The changes to the current drupal are minimal, mainly in the multi-site file include code.
Apropos. Recently there was a lengthy discussion on the debian-security mailing list about the general security status and practises of php applications. There was, let's say, discomfort about exposed configurations, 'talking' files, etc... While drupal is relatively good in this respect, we should be able to enable better practises and offer advice on the site configuration choices. Not everyone is experienced. Some people are willing to learn.
This is why I mentioned the possibility of moving Drupal to the directory ABOVE the public_html, so nothing can be read at the web server level, and if the web server misbehaves, and does not process .php files, no peeping Toms can see the configuration. I have done this in the past on a crude CMS that was home grown. It needed changes to the php include path to work correctly, which we still can do in the .htaccess anyway, and guaranteed a certain level of security.
I elaborate a bit: public_html/drupal/core public_html/drupal/core/modules public_html/drupal/core/themes public_html/drupal/local public_html/drupal/local/modules public_html/drupal/local/themes public_html/drupal/local/sites public_html/drupal/local/sites/whatever/modules public_html/drupal/local/sites/whatever/themes
Yes. And we ship files only under core, and under local just empty subdirectories. This way, if the admins untar the tarball over what is there, we do not overwrite what they did to their site, and he has to move the .htaccess manually (or merge the changes manually). They now can proceed to sort out whatever they did to local on their own. They put stuff in it in the first place, and it is outside the responsibility of the Drupal core team. On 5/9/05, Karoly Negyesi <karoly@negyesi.net> wrote:
I elaborate a bit:
public_html/drupal/core public_html/drupal/core/modules public_html/drupal/core/themes public_html/drupal/local public_html/drupal/local/modules public_html/drupal/local/themes public_html/drupal/local/sites public_html/drupal/local/sites/whatever/modules public_html/drupal/local/sites/whatever/themes
Taking it a bit further, we can even ship settings.php.example, under local/default, with instructions to rename it to settings.php and edit its content. This way again, we can overwrite the .example file everytime without affecting the local changes. This way, there is no need for a sites directory under drupal/core at all. On 5/9/05, K B <kbahey@gmail.com> wrote:
Yes.
And we ship files only under core, and under local just empty subdirectories.
This way, if the admins untar the tarball over what is there, we do not overwrite what they did to their site, and he has to move the .htaccess manually (or merge the changes manually). They now can proceed to sort out whatever they did to local on their own. They put stuff in it in the first place, and it is outside the responsibility of the Drupal core team.
On 5/9/05, Karoly Negyesi <karoly@negyesi.net> wrote:
I elaborate a bit:
public_html/drupal/core public_html/drupal/core/modules public_html/drupal/core/themes public_html/drupal/local public_html/drupal/local/modules public_html/drupal/local/themes public_html/drupal/local/sites public_html/drupal/local/sites/whatever/modules public_html/drupal/local/sites/whatever/themes
On Monday 09 May 2005 15:49, K B wrote:
Taking it a bit further, we can even ship settings.php.example, under local/default, with instructions to rename it to settings.php and edit its content.
public_html/drupal/core public_html/drupal/core/modules public_html/drupal/core/themes public_html/drupal/local public_html/drupal/local/modules public_html/drupal/local/themes public_html/drupal/local/sites public_html/drupal/local/sites/whatever/modules public_html/drupal/local/sites/whatever/themes
There is no local/default in my list for a good reason. Did you thought of local/sites/default/ ? Or...? My problem with this whole discussion is that I can't grasp what do you want to where. That's why I have provided a nice long list. Please follow suit.
On 5/9/05, Karoly Negyesi <karoly@negyesi.net> wrote:
On Monday 09 May 2005 15:49, K B wrote:
Taking it a bit further, we can even ship settings.php.example, under local/default, with instructions to rename it to settings.php and edit its content.
public_html/drupal/core public_html/drupal/core/modules public_html/drupal/core/themes public_html/drupal/local public_html/drupal/local/modules public_html/drupal/local/themes public_html/drupal/local/sites public_html/drupal/local/sites/whatever/modules public_html/drupal/local/sites/whatever/themes
There is no local/default in my list for a good reason. Did you thought of local/sites/default/ ? Or...?
My preference is this: under drupal/local we provide only empty directories, with only one file: So we have the following public_html/.htaccess.example public_html/index.php public_html/drupal/core public_html/drupal/core/modules public_html/drupal/core/themes public_html/drupal/local public_html/drupal/local/modules public_html/drupal/local/themes public_html/drupal/local/sites public_html/drupal/local/sites/default/settings.php.example public_html/drupal/local/sites/default/modules public_html/drupal/local/sites/default/themes Admins are then asked to manually copy the .htaccess.example to .htaccess, and the settings.php.example to settings.php. Then they enter the database name, user name and password and the base_url in in the new settings.php. Adrian's upcoming install can do these steps, perhaps after checking that there are no existing .htaccess or settings.php, or renaming them to .orig if they exist. Is it any clearer now?
public_html/.htaccess.example public_html/index.php public_html/drupal/core public_html/drupal/local Is it any clearer now?
Clear, yes, sensible, not. If you are doing this, then lose drupal from path, like this: public_html/.htaccess.example public_html/index.php public_html/core public_html/local and so on. You can put the whole thing under a subdirectory as you do now. What's the point in having a drupal when you already put index.php into / ? This means http://mysite will be drupal.
On 5/9/05, Karoly Negyesi <karoly@negyesi.net> wrote:
public_html/.htaccess.example public_html/index.php public_html/drupal/core public_html/drupal/local Is it any clearer now?
Clear, yes, sensible, not.
If you are doing this, then lose drupal from path, like this:
public_html/.htaccess.example public_html/index.php public_html/core public_html/local
and so on. You can put the whole thing under a subdirectory as you do now. What's the point in having a drupal when you already put index.php into / ? This means http://mysite will be drupal.
This is the original scheme then, but with the word drupal replaced with core. So to rephrase what you said: public_html/.htaccess.example public_html/index.php public_html/drupal/ public_html/drupal/includes/ public_html/drupal/modules/ public_html/drupal/themes/ public_html/drupal/misc/ public_html/drupal/doc (contains all the .TXT files) public_html/local/ public_html/local/sites public_html/local/sites/default/ public_html/local/sites/default/settings.php.example public_html/local/modules (contrib modules that are shared for all sites - empty) public_html/local/themes (contrib themes that are shared for all sites - empty) The above is all what we provide, and the site admin can optionally create a modules and a themes directory under sites/whatever if they so wish, as they can do today. So, untarring a drupal dist in public_html can be completely safe (unless you patched the core, which means you know what you are doing). I am personally OK with this provided that core be renamed drupal (as I did above), but others have expressed concerns about it. I don't really care either way, as long as we have ONE DIRECTORY THAT NEEDS NO CHANGES TO ANYTHING UNDER IT. I volunteer to write the documentation for this also, as per Dries request. Now, to take this to the next level, I assume that all this is done by some script that packages Drupal and produces the tarball. Am I right? Also, some changes are needed in some .inc files to search the appropriate locations. No?
So to rephrase what you said:
public_html/.htaccess.example public_html/index.php public_html/drupal/ public_html/drupal/includes/
What's the point in having one more directory depth? public_html/.htaccess.example public_html/index.php public_html/includes/ public_html/modules/ public_html/local/ public_html/local/sites public_html/local/sites/default/ public_html/local/sites/default/settings.php.example public_html/local/modules (contrib modules that are shared for all sites - empty) Please stop CC'ing me, I get all your letters twice.
On 5/9/05, Karoly Negyesi <karoly@negyesi.net> wrote:
So to rephrase what you said:
public_html/.htaccess.example public_html/index.php public_html/drupal/ public_html/drupal/includes/
What's the point in having one more directory depth?
public_html/.htaccess.example public_html/index.php public_html/includes/ public_html/modules/ public_html/local/ public_html/local/sites public_html/local/sites/default/ public_html/local/sites/default/settings.php.example public_html/local/modules (contrib modules that are shared for all sites - empty)
The idea is to avoid clutter in the directory, and isolate drupal core in its own directory. Currently the following directories exist for any drupal installation database/ includes/ misc/ modules/ scripts/ sites/ themes/ sites/ will be moved to the local directory, that leaves the others. Having them up in the root directory makes it cluttered and prone to manual errors. If we move all the non-changing core drupal stuff to its own directory this makes it clearer and easier for everyone.
On 5/10/05, Karoly Negyesi <karoly@negyesi.net> wrote:
If you are doing this, then lose drupal from path, like this:
public_html/.htaccess.example public_html/index.php public_html/core public_html/local
Now that you do it like that, I agree that having 'drupal/' is just one more unnecessary path depth. The way you did it above looks good to me. I'm a bit concerned about renaming 'core' to 'drupal' - might be confusing (or even technically problematic) since 'drupal' is also the name of the core CVS repository? We would end up with the path '/cvs/drupal/drupal/[subdirs]'. The ViewCVS address is already http://cvs.drupal.org/viewcvs/drupal/drupal/. Do you want to add a third 'drupal' to this path? I sure don't. Also, if and when this new directory structure gets committed, we need to encourage module developers to create new folders only within the 'local' directory tree. E.g. the 'files' directory, which is used by upload.module (and others?), should NOT be in /core/files, but instead in /local/files, or possibly in /local/sites/site1.com/files. Jaza.
On 5/10/05, Jeremy Epstein <jazepstein@gmail.com> wrote:
On 5/10/05, Karoly Negyesi <karoly@negyesi.net> wrote:
If you are doing this, then lose drupal from path, like this:
public_html/.htaccess.example public_html/index.php public_html/core public_html/local
Now that you do it like that, I agree that having 'drupal/' is just one more unnecessary path depth. The way you did it above looks good to me.
I'm a bit concerned about renaming 'core' to 'drupal' - might be confusing (or even technically problematic) since 'drupal' is also the name of the core CVS repository? We would end up with the path '/cvs/drupal/drupal/[subdirs]'. The ViewCVS address is already http://cvs.drupal.org/viewcvs/drupal/drupal/. Do you want to add a third 'drupal' to this path? I sure don't.
All this does not need to go in CVS as it is. The CVS can largely remain as it is. What the developers see when committing code and what the end user (site admin) sees are two different things. The script that creates the tarball can deal with all this and everything else remains the same.
Also, if and when this new directory structure gets committed, we need to encourage module developers to create new folders only within the 'local' directory tree. E.g. the 'files' directory, which is used by upload.module (and others?), should NOT be in /core/files, but instead in /local/files, or possibly in /local/sites/site1.com/files.
Again, in the respository, things will remain the same. Part of documenting this new change would be to instruct site admins that ALL CONTRIB MODULES AND THEMES WILL GO TO local. And that all configuration goes to local/sites. ANY DEVIATION FROM THIS WILL CAUSE UPGRADE PROBLEMS which is what we are trying to avoid. If Vlado's idea gets implemented, we also document that distros can change where things are, such as putting things in /usr/lib and /var/lib if they need to. The files directory can be under local, or one level above. It can be anywhere the user likes it to be, provided that they do not put it under drupal, since this can be erased on an upgrade.
On Wed, 11 May 2005 21:54:22 +0200, K B <kbahey@gmail.com> wrote:
On 5/10/05, Jeremy Epstein <jazepstein@gmail.com> wrote:
On 5/10/05, Karoly Negyesi <karoly@negyesi.net> wrote:
If you are doing this, then lose drupal from path, like this:
public_html/.htaccess.example public_html/index.php public_html/core public_html/local
Now that you do it like that, I agree that having 'drupal/' is just one more unnecessary path depth. The way you did it above looks good to me.
I'm a bit concerned about renaming 'core' to 'drupal' - might be confusing (or even technically problematic) since 'drupal' is also the name of the core CVS repository? We would end up with the path '/cvs/drupal/drupal/[subdirs]'. The ViewCVS address is already http://cvs.drupal.org/viewcvs/drupal/drupal/. Do you want to add a third 'drupal' to this path? I sure don't.
All this does not need to go in CVS as it is. The CVS can largely remain as it is. What the developers see when committing code and what the end user (site admin) sees are two different things.
I usually do CVS checkouts rather than download tarballs. I won't be able to take advantage of this new setup as easily if CVS isn't updated. Please update CVS as well. -- Tim Altman
On Mon, 9 May 2005, Karoly Negyesi wrote:
I elaborate a bit:
public_html/drupal/core public_html/drupal/core/modules public_html/drupal/core/themes public_html/drupal/local public_html/drupal/local/modules public_html/drupal/local/themes public_html/drupal/local/sites public_html/drupal/local/sites/whatever/modules public_html/drupal/local/sites/whatever/themes
If we get this convoluted, I demand benchmarks to see if the additional directory reads don't affect performance too much... Cheers, Gerhard
Isn't the searching only done from two admin pages in Drupal? The "admin/modules" and the "admin/themes"? Every other page just checks the path to said module/theme from the database anyway, and they do no searching at all. So, only two infrequent admin functions are potentially affected, and the rest of Drupal performs the same way. Right? Or am I mistaken?
If we get this convoluted, I demand benchmarks to see if the additional directory reads don't affect performance too much...
This way, the index.php is in the public_html directory of the account, and .htaccess affects how it works.
Custom (non-distribution) unix install: (in /usr/local)
lib/drupal - equivalent to core above var/drupal - equivalent to local above
var/www/drupal/sites/example.com/files - this is configurable anyway
lib|var/drupal are not in the web-server's display paths, this potentially makes sharing the same web-server location with other apps easier
What I am suggesting is a small change like the one at the end of this email. It will give the opportunity to maintain all or modst of the scenarios described so far, and will make drupal more packageable by the distributions, as . The downside is that it will require a central configuration file ( put in /etc/drupal ;) This suggestion should not have any performance implications, as far as I am aware, apart from the loading of the configuration file, let's be serious. I wouldn't argue with any default directory scheme suggested, I like the current one myself, as long as it is trivial (read standard and configurable) for an admin to set up the directory structure they like, and drupal is packageable without modifications bar config by debian. Be flexible if it doesn't hurt you. Cheers, Vlado ========================== this should go in the configuration file //Linux FHS $drupal_core = '/usr/lib/drupal' //core $drupal_sites = /var/lib/drupal //local path, private uploads go under //this one[advisory] //One of the proposed 'clean' structures $drupal_core = "$webroot/core" //core $drupal_sites = "$webroot/local" //local path //crurrent head structure $drupal_core = "$webroot/core" //core $drupal_sites = "$webroot/local" //local path $drupal_core = $webroot //core $drupal_sites = "$webroot/sites" //local path $www_root = /var/www //illustration, could get it from the $www_root = $webroot //illustration, could get it from the //index.php path, $drupal_conf =/etc/drupal //core configuration ========================== illustration only, the changes need to be ========================== done in conf_init() foreach (array("$sites/$config/$dir/$file", "$sites/$config/$dir/$name/$file", "$core/$dir/$file", "$core/$dir/$name/$file") as $file) { if (file_exists($file)) { $files[$type][$name] = $file; break; } }
participants (13)
-
Adrian Rossouw -
Dries Buytaert -
Earl Dunovant -
Gerhard Killesreiter -
Jeremy Epstein -
K B -
Karoly Negyesi -
Matt England -
puregin -
Robert Castelo -
Syscrusher -
Tim Altman -
vlado