Wikimedia Bugzilla is closed!

Created attachment 1420 [details]
Patch to config/index.php to streamline config file location

Created attachment 1421 [details]
Better config location patch for config/index.php

Apologies for that first patch - I had misinterpreted the purpose of $sep. This
patch is better (using DIRECTORY_SEPARATOR instead), and also improves
interface feedback to reflect the actual location of files written.

Why was this classed as invalid? It's pretty dumb to have multiple hardcoded paths at the best of times - MediaWiki's own code spends 
considerable effort working out an include path - why not apply the same approach to the config file? If it really is considered invalid, then there 
should (by definition) be a documentation change saying 'MediaWiki CANNOT be installed on servers that do not allow write access below the web 
root'. If on the other hand you don't consider that statement to be true, then this patch is not invalid, so make your mind up. If on the other hand 
you had an objection to the particular implementation, then you could at least have had the decency to say so.

You're always free to do a manual installation if your host is 
broken.

Well that's what I did by fixing the installer, thus making it easier for others to do the same, and making 
MediaWiki more reliable, flexible and able to be installed easily on 'broken' hosts such as SourceForge. I can't 
think of any real downside to this patch - duplicated, hard-coded paths are considered by many to be a bug 
in their own right. I'm sorry if I got the impression that this was a collaborative, open-source project 
supported by contributors.

(Note that MediaWiki is primarily in-house software for Wikipedia, so the 
installer doesn't get much lovin'.)

I don't really like this implementation; since it requires hacking up the 
source it's still not providing for a clean install out of the box. Would 
it be better to allow, say, automatic selection of a temp directory or 
just dumping the config file to output for copy-and-paste?

I mentioned something to that effect in my original post - yes it would be nice to be able to set this from an 
installer form - perhaps one that appears if it finds that the default file location is not writable? I also agree 
that while hacking the source to fix the install is not great, it's much better to only have to hack it in one 
place instead of six or so (and with a far greater chance of failure). Having changed the code so that it does 
have a single definition for the file location also means that writing an interface for it will be easier. I wasn't 
really planning to, but I could give it a go if you like.
I appreciate that MW is mainly in-house - that's why you need contributors to be annoyed by the bits you 
don't use ;^)

Hello,

I just ran into this bug posting after pulling my hair out why MediaWiki would
not install in our project team's sf.net webpage. [1] 

I know of at least one other person that gave up on trying ot get their sf.net
webspace up and running with mediawiki, and so loaded it on his own domain.

Action Item (just suggestions, but could help, I don't know if this this a
thread hijack but this topic is directly related to sf.net setup and user
workarounds):

- WikiMedia is great software and lots of project teams benefit from a wiki
being used to maintain doc. Please post some kind of information article
directed towards users of sf.net on the sf.net project webspace about the
problems sf.net users encounter and how it is recommended we should resolve them. =(
- Perhaps have a bug listing in Mantis with the words sf.net sourceforge.net in
the title of the submission (I wasn't able to locate one, so as a result I dug
inside the bug threads and found this! =) )
- Idea (may not be practical or appropraite): If you detect sourceforge.net as
the hostname in the wikipedia autoconfigure process, present a link in the
autoconfigure to tell someone to visit a particular link.
-- Better yet, maybe if you can detect somehow the the config folder cannot be
writable (how?- maybe if the user reruns the web based autoconfigure process
multiple times and keeps getting the same message...), present some information
to the user about the specific problem he/she could be experiancing and how to
resolve it (or where to read more on it)


Thank you so much for this thread. I hope we can at least save some time and
effort of future installers of mediawiki on sf.net. =)


[1] I've tried installing wikimedia months ago then recently retried to get the
same error message regarding my config directory not being writable, and thus
began looking into it deeper. I was able to get it working without a problem
many times in the past on my own domains, so didn't understand where the problem
could have originated.

I'm claim to be no expert on this issue, but from what I've digested and
understood, I've posted a support request to sf.net on this issue. Please review
it, correct it, and lobby, as necessary, to see advancements in this area:

SourceForge.net: Modify: 1523144 - Web tree under web root is not writable by
the web sever
https://sourceforge.net/tracker/?func=detail&atid=200001&aid=1523144&group_id=1


This is also left here as a footprint for those trying to resolve this issue as
well, from a policy standpoint.

Getting SF.com to make their web space globally writable is not a good idea - because all project sites are run under the same user, it 
would mean that any site could write into any other. A better solution would be for mediawiki to support an alternative to writing a local 
config file, such as displaying the config file contents in the installation page so that it can manually be saved in a local file via non-web 
means.

I'm WONTFIXing this for several reasons.

1) We're not going to change the name of LocalSettings.php or make it customizable.

2) The name of the installation path "/config/index.php" is static and also does not need customization. Whether or not this is a good name (/config seems to conflict) is under discussion at bug 1379.

3) Writing to /config is unsafe. Plans for the new-installer are to ditch writing of LocalSettings.php to the /config directory, and instead offer it as a download to the site administrator to then put in place.

Goodness, I'd forgotten I'd written all this.

I find your conclusion nonsensical - My changes for 1 above does not amount to customization, merely that making the definition only in one place (aka DRY), which is just good coding practice IMHO. WHEN you decide to change it, chances are you'll write code that does pretty much the same thing. Either that or invite disaster by making changes in multiple locations.

3 directly conflicts with 2: you say that writing to config is dangerous (which is why SF doesn't allow it), but then refuse to provide a workaround. Also, again my changes really only amount to making this so it's set only in once place, it doesn't represent any change in policy. Allowing someone to hack the path simply (for example so it writes somewhere that's writable but not under the web root) seems like a handy side effect.

To summarise: my patch would:

a) simplify changing paths used by mediawiki and make doing so safer and more reliable, pre-emptively fixing future bugs in that area
b) have a side effect of making changing them again easier, even though that may not be the primary aim
c) make mediawiki installations on sourceforge easier

I'm mystified why you'd not want this fix; the alternative means you're deliberately choosing to live with bad code for no good reason.

(In reply to comment #12)
> Goodness, I'd forgotten I'd written all this.
> 

Lots of installer bugs are old. None of the patches on them apply to the new installer.

> I find your conclusion nonsensical - My changes for 1 above does not amount to
> customization, merely that making the definition only in one place (aka DRY),
> which is just good coding practice IMHO.  WHEN you decide to change it, chances
> are you'll write code that does pretty much the same thing. Either that or
> invite disaster by making changes in multiple locations.
> 

/config isn't hardcoded in a bazillion places these days. It wouldn't be hard to find and fix the few manual usages. Like I said above, if we decide to change where the entry point is, that's being discussed at bug 1379

> 3 directly conflicts with 2: you say that writing to config is dangerous (which
> is why SF doesn't allow it), but then refuse to provide a workaround. 

Writing to /config isn't safe. Neither is writing to /foobar or /mysecretinstaller. Changing the directory does nothing to mitigate the issue. We don't want the web server being the owner of the config file at all. See http://www.mediawiki.org/wiki/New-installer_issues?diff=334526&oldid=333913 for more information.

>Also,
> again my changes really only amount to making this so it's set only in once
> place, it doesn't represent any change in policy. Allowing someone to hack the
> path simply (for example so it writes somewhere that's writable but not under
> the web root) seems like a handy side effect.
> 
> To summarise: my patch would:
> 
> a) simplify changing paths used by mediawiki and make doing so safer and more
> reliable, pre-emptively fixing future bugs in that area
> b) have a side effect of making changing them again easier, even though that
> may not be the primary aim
> c) make mediawiki installations on sourceforge easier
> 

To summarize, we're changing the installer so that you no longer have the web server writing the config file. So customizing it is no longer an issue :)

> I'm mystified why you'd not want this fix; the alternative means you're
> deliberately choosing to live with bad code for no good reason.

You haven't seen the new installer, have you? The code is far better than when you submitted that patch ;-) http://svn.wikimedia.org/viewvc/mediawiki/trunk/phase3/includes/installer/