New installer/issues

This is a list of known issues in the new-installer branch. List started from Tim's list at.

All open installer bugs which can be fixed in the branch. Tracking bug
 * Already fixed in branch: 198, 2837, 10541, 10596 , 11013 , 13230, 13409, 16902 , 17394 , 17691, 17762 , 19129 , 20627 , 21576
 * Bugs not yet fixed (but could be)

Critical

 * Evaluate restart possibilities for failed install step
 * Does not go well at all. Also: re-entry on a half-working install is bad. Should be more robust in its checks.


 * Fix flush
 * Checkboxes are positioned insanely
 * Long single word field labels can run under input fields. Example on page=DBConnect in Dutch 'config-db-prefix' (Databasetabelvoorvoegsel:) like this
 * (to be clarified by Chad) Reorganize the way made settings are handled. Something about them all being evaluated each page load, making things slow.
 * Makes more sense to me now. We talked about being able to move between steps (not just forward/back, but skipping around). I said the issue with this is that we have to validate settings after each page and this makes that more difficult. Tim said more about it when I tried it before. ^demon


 * Do not create the main page, but just display the message in user language on it if it does not yet exist using a hook.
 * Better/more JS (Roan)
 * Fix non-JS behavior, refactor stuff in to use hiding by JS
 * After returning to page=DBConnect with browser back button, everything's unhidden
 * Tweak installTables and specifically the createTables implementations to be more useful. (eg: tables.sql is a failure issue, interwiki.sql is a warning, etc). Do not want to call output directly from InstallDBType children...maybe pass some Statuses back up to the caller?

Features
I (Ævar Arnfjörð Bjarmason) am doing some work on making it pluggable and extensible (to e.g. corporate installs).


 * Make it pluggable

Experimenting with whether it's best to do this with $wgHook or by subclassing the installer for custom tasks. More support in the core for abstraction is needed. Mostly I want to do this by making the code more generic and modular. E.g. turning the  into classes. And making them return  objects instead of spewing messages directly.


 * Support post-installation

It would be very cool if we had support for post-installation tasks. E.g. installing extensions & configuring them, installing content packages on the wiki (importing XML dumps) etc. This would need some smart auth support, currently we just recommend deleting config/index.php and refuse to do anything if LocalSettings.php exists.

Non-critical

 * Get someone to fix the error box styling
 * proprietary DB support, https://bugzilla.wikimedia.org/show_bug.cgi?id=15493
 * This is not a blocker. Mysql, Postgresql, Sqlite are the only requirements. The rest are a bonus.


 * Review initial main page text
 * Text is fine, it just looks like it's in the old installer still. Could some some visual cleanup. For the environment checks, make passed tests obviously good, failed obviously bad.
 * I think it could be made more beautiful and informative. -- Tim Starling
 * I'm going to add support for importing a dump at the end of the installation process (or post-install). I'd planned on just constructing XML from the current main page i18n messages + Feeding it to the import process. It would allow for installing more stuff, like a basic wiki with Template:* libraries. --Ævar Arnfjörð Bjarmason


 * Logo stuff:
 * Initial path is wrong, points to MediaWiki.org, not http://$localhost
 * Allow uploading of a custom logo
 * In the installer? Wouldn't it be better to list it in post-install tasks somewhere? --Ævar Arnfjörð Bjarmason
 * Preview of logo


 * Fieldset legends are very small, smaller than the labels for fields.
 * Selecting a different interface language on first page, should reload the page in the chosen language.
 * Allow enabling instant commons if outside access is possible
 * Remove span from 'config-sidebar' message
 * I don't see a span. Maybe you mean config-env-good right below it?


 * Fix parsing of multi line messages in the i18n files. In page=Welcome multiline messages get a &lt;>p> for the second line causing it to be displayed on two lines instead of in one paragraph. Example: 'config-gd'
 * Make table of access rights profile for easier overview
 * CC license picker is buggy (doesn't load image, name of license, etc)
 * Consider not embedding the CC license picker, but a list of CC licenses
 * We have 2 of the most common ones listed, would like to keep the selector though if we can get it. Also cf bug 17429. ^demon


 * Return Status objects more often
 * SQLite DoS issues: because it doesn't need a password for DB access, an attacker could create an infinite number of database files around, depleting disk space. Need to handle this, including cases where LocalSettings is not writable and installer offers the user to create it manually.
 * Command-line installer: I (Max) have started working on it.
 * Max said on IRC that he didn't get far with it. I'm interested in it, and config-driven installation. Ideally it should be generic enough for Wikimedia to use it when installing new wikis, and Debian should be able to interface with it to install wikis via apt. --Ævar Arnfjörð Bjarmason


 * UPGRADING doc (others too?) will be wrong and need updating.
 * In case of DB errors, only (SQL query hidden) is displayed.
 * Because $wgShowSQLErrors is false by default. Set to true for install?
 * Did that in 64091, probably it's too much and may disclose system information.
 * If some field does not validate, it should be highlighted in addition to error messages somewhere in the page.
 * Field for sqlite data dir could be longer. The directory usually doesn't fit.
 * Some help could perhaps be shown by default, like the short ones and the more unclear ones, like "User rights profile"
 * Lifebuoy's meaning is not culture-independent, better replace it with something like a question mark.
 * Oh come on, it's a Pango icon! --Ævar Arnfjörð Bjarmason
 * What? Max Semenik 19:31, 30 April 2010 (UTC)
 * Isn't it used widely by GNOME for this? Anyway a nice question mark would be nice too. --Ævar Arnfjörð Bjarmason 20:11, 30 April 2010 (UTC)


 * require_once( './maintenance/updaters.inc' ); // sigh...
 * See r65155. Why is this in the main file? Isn't it only for SQLite? Maybe turn the update functionality into a library. --Ævar Arnfjörð Bjarmason
 * updaters.inc doesn't work if included from an autoloaded file. The same solution will apply for all other updaters, I just haven't got to it - only SQLite has a functional updater currently. And I intentionally haven't touched the updaters, to avoid extra problems when merging - we could refactor it later. Max Semenik 19:31, 30 April 2010 (UTC)
 * Sweet. --20:11, 30 April 2010 (UTC)
 * I still think we need to do some refactoring now. Grabbing the output from updaters.inc and shoving it to the installer isn't elegant. ^demon 13:59, 4 May 2010 (UTC)


 * Input fields forgotten on re-submit
 * When you re-submit http://aoeu/config/new-index.php?page=Name (due to
 * e.g. "The two passwords you entered do not match" error) it'll recall
 * "Your name" from the previous form, but not "Name of wiki".
 * --Ævar Arnfjörð Bjarmason
 * --Ævar Arnfjörð Bjarmason

* Setting up database... Done * Creating tables... Database error
 * When I install the wiki and then go to new-index.php again I get this:

CREATE TABLE user ( user_id INTEGER NOT NULL PRIMARY KEY AUTOINCREMENT, user_name TEXT NOT NULL default , user_real_name TEXT NOT NULL default , user_password BLOB NOT NULL, user_newpassword BLOB NOT NULL, user_newpass_time BLOB, user_email TEXT NOT NULL, user_options BLOB NOT NULL, user_touched BLOB NOT NULL default , user_token BLOB NOT NULL default , user_email_authenticated BLOB, user_email_token BLOB, user_email_token_expires BLOB, user_registration BLOB, user_editcount INTEGER )

from: „DatabaseBase::sourceStream“. error „1: table user already exists“.

Backtrace:

#0 /home/avar/src/mw-git/new-installer/phase3/includes/db/Database.php(538): DatabaseBase->reportQueryError('table user alre...', 1, 'CREATE TABLE us...', 'DatabaseBase::s...', false) #1 /home/avar/src/mw-git/new-installer/phase3/includes/db/Database.php(2237): DatabaseBase->query('CREATE TABLE us...', 'DatabaseBase::s...') #2 /home/avar/src/mw-git/new-installer/phase3/includes/db/Database.php(2170): DatabaseBase->sourceStream(Resource id #30, false, false) #3 /home/avar/src/mw-git/new-installer/phase3/includes/installer/SqliteInstaller.php(135): DatabaseBase->sourceFile('/home/avar/src/...') #4 /home/avar/src/mw-git/new-installer/phase3/includes/installer/Installer.php(845): SqliteInstaller->createTables #5 /home/avar/src/mw-git/new-installer/phase3/includes/installer/WebInstaller.php(1573): Installer->installTables #6 /home/avar/src/mw-git/new-installer/phase3/includes/installer/WebInstaller.php(162): WebInstaller_Install->execute #7 /home/avar/src/mw-git/new-installer/phase3/config/new-index.php(52): WebInstaller->execute(Array) #8 {main}
 * --Ævar Arnfjörð Bjarmason 20:11, 30 April 2010 (UTC)

Fixed issues

 * Test canCreateAccounts
 * Fix session expiry message "$1"
 * Object cache settings
 * Make sure usernames are trim'd
 * RELEASE-NOTES does something funky with left sidebar font sizes :-\
 * Additional e-mail settings need adding
 * Continue button on "Completed installation" leads to null page
 * Spews ugly warnings if sessions path is not writable (old installer did not)
 * Project namespace, the first alternative, the javascript needs to add space or it looks like this Same as the wiki name:Foobar
 * Object caching defaults to Memcached, while APC installed . Should check that APC cache is big enough.
 * SQLite installation fails with no error, only output is: "   * Setting up database..."
 * "Advanced configuration" box on options page is empty.
 * Don't offer "MediaWiki" as custom project namespace name by default, it's invalid (what other sane value could it be?)
 * Sqlite permission values are confusing at best, useless for Windows users, and don't even work as advertised (usual oct/dec conversion issues). Probably just remove?
 * Does it make sense to add version of MediaWiki that generated LocalSettings to that file to keep track of things?
 * We currently have two sidebars with partially duplicated content.
 * Sniff languages from Accept-Language?
 * Check if config/ is writable
 * Write LocalSettings' content on the page if it failed to write the file
 * Major: Post upgrade, if you choose to regenerate LocalSettings, it runs the full install. This is bad.
 * README/RELEASE-NOTES/COPYING all need to be properly wiki formatted, else we need to include wiki-formatted version
 * Easier to just force wiki formatting in the files, waste of time to have two
 * Or you can regex-foo it like here and here


 * Check with Mike Godwin if translated license with link to original text is OK
 * Put GFDL licenses one level down, and possibly mark as not recommended. At least display CC above GFDL
 * Yeah, this is out of date:
 * If you want to be able to use text from Wikipedia, and you want
 * Wikipedia to be able to accept text copied from your wiki, you should
 * choose GNU Free Documentation License 1.2. However, this license has
 * some features which make reuse and interpretation difficult.
 * Should say that Wikipedia uses CC. More lawyering needed. --Ævar Arnfjörð Bjarmason


 * Creating ... Done
 * Either use no HTML or enable it in these status messages


 * Hide "Memcached servers" input whem memcached is not selected.