Many new users find the installation instructions for a new theme or new module confusing. Because it tells them to place their new theme/module in sites/all/modules or sites/all/themes and those directories don't exist when you first unzip/un-tgz Drupal.
It may seem like an “obvious” thing that you need to create those directories, but many users think there must be something “special” about those directories and, since their installation of Drupal doesn’t have them, then their installation must be broken.
I know a lot of people have seen this kind of question on the forums or in IRC. And here's a recent one from IRC:
[The name has been changed to protect the noob. ;-) ]
NOOB: In drupal 6.8 there is no sites/all/themes folder.. trying to figure out where to put the custom Zen CSS module
JohnAlbin: yeah, I've seen that issue before.
NOOB: trying to figure out why the sub folder isn't there
JohnAlbin: You actually need to create the /sites/all/themes directory.
NOOB: lol right cause everyone's automatically going to know that it's something you need to create
JohnAlbin: so once you create that folder, you can stick the zen folder in there and you should be golden.
NOOB: haha thanks.. was wondering about that but figured maybe my install zip was missing something from an older version
Comment | File | Size | Author |
---|---|---|---|
#26 | 360415_23_readme_drupal.patch | 983 bytes | JuliaKM |
#22 | 360415_22_readme_sites.patch | 1006 bytes | ultimateboy |
ux-sites-all-modules-directory.patch | 937 bytes | JohnAlbin | |
Comments
Comment #1
JohnAlbinComment #2
Dave Reid1000 times yes. This is something that is needed to stop some people from installing modules into the /modules folder.
Comment #3
catchSubscribing.
It's not only a usability issue for new users, it's also annoying do cd sites/all/modules [..swear..] mkdir sites/all/modules [..swear again..] cd sites/all/modules cvs checkout ......
Comment #4
keith.smith CreditAttribution: keith.smith commentedHow about:
(and again for modules)
And, this is a great idea.
Comment #5
FiReaNGeL CreditAttribution: FiReaNGeL commented"1000 times yes. This is something that is needed to stop some people from installing modules into the /modules folder."
It is natural behavior to spot /modules and put modules there because:
-It works
-Its in the root folder
Maybe what we really need to stop this kind of confusion is a /core/modules directory or something similar, we could even put /includes and /themes in there, maybe even rename the folder /core-modules and /core-themes to avoid confusion.
Comment #6
JohnAlbinI talked last month with webchick, quicksketch, moshe and some others (I've forgotten who all was there) about inverting the directory structure of drupal so that all of core's files were in a core/ directory and stuff that is in the sites/ directory structure were in the root. It sounds like a great idea to me, but I know there was some issues for why this would be difficult to accomplish (which I've also forgotten). :-p
Anyway, I think that should be a separate issue. This issue could be considered an easy interim solution.
@Keith: The text I used in my patch is straight from the /sites/all/README.txt file. In your suggestion, I fear that the sentence “In a multisite installation, themes in this directory are available to all sites.” will cause new-comers to think “okay, I don’t know what a multisite installation is, so this must not be where I put my stuff.”
Basically, we should be telling newcomers that themes and modules should always go in sites/all. Only when they learn about multi-site installations do they need to know that they can put stuff in sites/example.com/, etc.
I'm not opposed to changes in the text, but we need to be very careful how we phrase stuff. chx and sepeck wrote the original text over in #93750: Provide a sites/all directory.
Comment #7
catchI've also wanted to put all core themes and modules in the profiles/default folder before. A /core folder sounds better though. Agreed it's a separate issue, I assume the main problem would be moving the files around in CVS.
Comment #8
apadernosites/all/modules, and sites/all/themes are not present in CVS because they would not appear in the .tar archive Drupal creates from CVS if those directories don't contain anything.
The use of such directories is already documented; if even somebody would have the doubt the archive he downloaded could be corrupt, it would not take too much to understand that is not the case, and that he simply needs to create the directories.
After all, he has been able to install Drupal; he could resolve the issue easily enough.
Comment #9
Frando CreditAttribution: Frando commentedWell, that's what this patch is about, isn't it? It puts a README.txt into these directories to make them appear in the tarball.
Our goal should always be to make installation, usage and updating of Drupal as easy and straightforward as possible. This is why we created the installer, after all. So +1 from me for this patch.
Comment #10
Dave ReidMoving the current core modules/themes will be very difficult since users would have to delete the folders manually when upgrading. Although I guess we could add a check in the D6->D7 update.php to make sure the /modules and /themes folders do not exist in root, but rather in the proper location.
Comment #11
apadernoI agree that the installation must be as easy as possible.
My point is that still the user must do something manually (and read a file to understand what to do). After somebody created an user for the database, after he created a database, and he assigned that user to the database (and gave to that user the right access permission to the database), I find rather rare he would block on the simpler step.
Comment #12
JohnAlbin@Kiam: Yes, you would think so. But the conversation I quoted from IRC proves differently. And its not rare as I've had others in the community tell me they've had to help new users with this step as well.
Comment #13
Damien Tournoud CreditAttribution: Damien Tournoud commentedMakes total sense.
Requalifying as a bug report (I agree with catch on this: this should backported to lower versions).
Comment #14
catch@Kiam, one issue is that the sites/all folder is relatively new - prior to Drupal 5 (I think) we used to recommend putting everything in /modules and /themes - and since they're at the root of the installation, it's easy to assume that's where modules and themes should go.
Do we have an issue with people upgrading on some operating systems if we include these folders? I seem to remember default.settings.php was added instead of settngs.php to avoid Mac users overwriting their settings.php - presumably the same thing could happen for minor version upgrades to the themes and modules folders as well. Or is it only files that overwrite and not folders in that case?
Comment #15
Damien Tournoud CreditAttribution: Damien Tournoud commented@catch: Mac users have issues with merging anyway. Copying a clean Drupal folder with the Finder over an existing one will wipe the original one completely, regardless of everything.
Comment #16
catchCool. I also doubt that many sites are actually managed on Macs via the GUI (and would rather we shipped with settings.php too actually since that'd remove a step for 99% of users) so still completely RTBC.
Comment #17
Dries CreditAttribution: Dries commentedLooks good to me. What about the snippets provided by Keith?
Comment #18
catchI think John Albin is right that we should avoid the reference to 'in a multisite installation' - since we just want to make sure people put their modules and themes here when they start , and they can get into the nitty gritty of which modules to share between multisites at a much, much later stage. Also " separates your custom files" - contributed modules and themes aren't custom files, and we have a files directory in sites/default/files by default as well, so while custom modules and themes should go in here, we can't refer to them like that.
Here's a pass at it, which takes Keith's text and just hacks those bits out.
Place downloaded and custom themes in this directory to simplify future updates to Drupal core.
(replace modules for the modules version).Comment #19
keith.smith CreditAttribution: keith.smith commented@Dries, JohnAlbin addressed that in #6. Essentially, the model he used is that found in /sites/all/README.txt. The model I used is that found in /modules/README.txt, which does mention multisite installations.
I'm fine with the patch being committed as is, as it is consistent with at least one of the existing READMEs. We can always clean this up later by patching all these READMEs so that they all use very similar language (the odd one out, at that point, will be /modules/README.txt).
Or, as catch suggests, we can try to consolidate and conform these various files in this issue. I'm ok with either approach.
Comment #20
webchickYAY! This has been one of my pet peeves forever. :) Committed to HEAD.
Marking back to CNW to make the various README.txt files consistent, which should be much easier now that these files exist in HEAD.
Comment #21
webchickComment #22
ultimateboy CreditAttribution: ultimateboy commentedThe readme file really was not that far off.. but regardless, here is a slightly updated version.
Comment #24
ultimateboy CreditAttribution: ultimateboy commentedLets try this again...
Comment #25
ultimateboy CreditAttribution: ultimateboy commentedOr again...
Comment #26
JuliaKM CreditAttribution: JuliaKM commentedHere's a re-rolled patch.
Comment #27
JuliaKM CreditAttribution: JuliaKM commentedComment #28
JuliaKM CreditAttribution: JuliaKM commentedComment #30
ultimateboy CreditAttribution: ultimateboy commentedLets try this again... something is quite odd here.
Comment #31
JohnAlbinAfter kicking the testbot, all looks good.
Comment #32
Dries CreditAttribution: Dries commentedCommitted to CVS HEAD. Thanks all! :)