--- On Mon, 8/24/09, Chad <[email protected]> wrote:
> Why skip trying to find the location?
> If MW_INSTALL_PATH
> is already missing, what have we got to lose from trying
> to guess the location? The vast majority of people don't
> screw with the default structure, so it should be just
> fine.
That's a reasonable question, stating in another way the useful maxim, "if it
ain't broke, don't fix it." The problem is I think it's "broke".
Here is my take on the pros/cons of leaving things unchanged:
Pros:
* Some administrators are used to simply typing the line php <utility>.php.
Making them type:
MW_INSTALL_PATH=/var/wiki/mediawiki php <utility>.php
would be inconvenient.
In answer to this, for the MW installations running on unix, it is pretty
simple to alias "MW_INSTALL_PATH=/var/wiki/mediawiki php" and put the
definition into .bash_profile (or the appropriate shell initialization script).
This is a one time effort and so the change isn't as onerous as it might seem.
I assume there is a similar tactic available for windows systems.
Cons:
* The use of file position dependent code is a problem during development and
much less of a problem during installation and production (as you suggest).
Right now there are ~400 sub-directories in the extensions directory. It seems
to me reorganization of the extensions directory would help understanding the
relationship between individual extensions and the core. For example, having
two subdirectories, one for cli utilities and another for hook based extensions
would clarify the role each extension plays. However, currently there are 29
extensions where $IP is set using the relative position of the file in the MW
directory structure (a couple of other extensions set $IP based on
MW_INSTALL_PATH). Reorganizing the directory structure has the potential of
breaking them.
* CLI utilities are moved around for reasons other than a reorganization of the
extensions directory. For example, as I understand it, DumpHTML was moved from
maintenance/ to extensions/. dumpHTML.php sets $IP based on its relative
position in the distribution tree. It was a happy coincidence that when it was
moved, its relative position didn't change. However, it is unreasonable to
think such reclassifications will always be as fortunate.
Since the cons outweigh the pros, I remain convinced that the change I
suggested (using die()) improves the code.
Dan
_______________________________________________
Wikitech-l mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
