Page MenuHomePhabricator

install can't find config/index.php
Closed, ResolvedPublic


Author: compkarori

I've just installed mediawiki on a account. It installs fine when I
install into a subdirectory, but not when the domain itself points to that

What happens is that when I try to run the setup, it can't find
/config/index.php, and Apache offers me /config/index.html which is the control panel page.

So, to me it looks as though there is another directory "config" which the
installer is trying to read, and not the one in mediawiki distribution.

I changed the directory from "config" to "wikiconfig" and then I was able to
find /wikiconfig/index.php but then although it said it created the
LocalSettings.php file, it did not. /wikiconfig is 777.

Version: 1.3.x
Severity: minor
OS: Linux
Platform: Other


TitleReferenceAuthorSource BranchDest Branch
Refactor error handling for K8sError and BuildClientErrorrepos/cloud/toolforge/toolforge-cli!3raymond-ndibefix_build_logs_errormain
config: Add config modulerepos/cloud/toolforge/toolforge-weld!19dcaroadd_generic_config_functionsmain
Customize query in GitLab

Related Objects


Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 8:08 PM
bzimport set Reference to bz1379.
bzimport added a subscriber: Unknown Object (MLST).

You'll have to change the references to the 'config' subdirectory _in_ the
installer as well, or it may write its output to the wrong directory.

compkarori wrote:

I tried changing every occurence of config to wikiconfig in the index.php file,
but it now won't complete. Looks like it is saying there is now an error with
my mysql username or password, which are both correct.

compkarori wrote:

No matter, I tried it again this morning, and got it to complete in my
wikiconfig/ directory.

Still think you should consider changing the config directory name so that
others don't have this problem.

zigger wrote:

*** Bug 3815 has been marked as a duplicate of this bug. ***

  • Bug 9064 has been marked as a duplicate of this bug. ***

webmaster wrote:

Same problem here - please change the Name to /install.

Would be good to make this sort of thing easier to resolve.

cf bug 5125

Might make sense to go ahead and rename to something like mw-config,
keeping the config dir for compatibility/habit. (It can just include() the
file from the other dir to run cleanly.)

ezyang wrote:

Brion, wouldn't /install make more sense? Although I can understand the initial reasoning to call it /config, the script does more than create the LocalSettings.php file: it also initializes the database. Maybe /mw-install would be better just to make sure we don't get any naming conflicts with that either.

It's also used for upgrades, and may be used for other config in future.

ezyang wrote:

I've been looking over it, and it looks like it'll be a simple fix.


There's no way to do this cleanly in a patch, since the unified diff format can't keep track of file moves, etc: in short, it will destroy the history for /install. Is it possible for me to get Subversion commit access to fix this one?

ezyang wrote:

(In reply to comment #11)


Typo, that should be /config.

robert wrote:

Once I complete the back\front-end separation of the installation script it will be located at /maintenance/install (or maybe /maintenance/config)which shouldn't cause a problem.

robert wrote:

Maybe not as a sub folder of maintenance because I now realize that there is a .htaccess Deny from all.

*brushes off the dust*

Hi folks :) With new-installer in place it's presumably a lot easier to revisit this now. As I mentioned in bug 5125 comment 11, we don't want to write LocalSettings.php to /config anymore. In fact, we're moving even more code out of it entirely. In the end, it's just going to have the simple entry point script.

Should be fairly trivial to rename /config to anything we'd like now. /mw-config probably wouldn't conflict with anything.

Definitely doing this in 1.18 after the 1.17 release ships (I probably should've done this before branching, but too late now)

The following suggestions could work:

(In reply to comment #16)

Definitely doing this in 1.18 after the 1.17 release ships (I probably
should've done this before branching, but too late now)

I don't think it's too late, we still haven't released RC1.