|
|
(10 intermediate revisions by 2 users not shown) |
Line 1: |
Line 1: |
− | The state wiki require some maintenance and an urgent upgrade. This page documents what needs to be done, and what should be done. There is a thread on dev (Wiki maintenance) where the decisions are made.
| |
− |
| |
− | At the moment we have the following work list:
| |
− |
| |
− | * Change LocalSettings.php to close for "create user" '''DONE'''
| |
− | * Update UA- code for google-analyics '''DONE'''
| |
− | * open for "create page" again '''DONE'''
| |
− | * Check "nofollow" setting, to be sure it's on (True) '''DONE, added $wgNoFollowDomainExceptions and $wgNoFollowNsExceptions'''
| |
− |
| |
− | * remove accounts older than a year WITHOUT any contributions
| |
− | ** Scripts is being prepared, about 24.000 accounts out of 32.000 will be removed.
| |
− | ** word contribution is defined as text/newtalk/comment
| |
− | * remove all accounts from the time of the spam period
| |
− | ** Scripts are being prepared, but wait for a decision on the time period (see dev)
| |
− | ** due to lazy consensus and no objections the period will be 1May2012 to 23Nov2012, but incl.
| |
− | ** delete include all pages/newtalk/comments made be these accounts
| |
− | * Discuss on whether to add anti-spam measures for the currenct MW version.
| |
− | ** A cool-off period (which is highly effective) has received objections
| |
− | ** A admin confirm of new users has received objections
| |
− | ** Other anti spam measures needs to be investigated
| |
− | * open for create user
| |
− | ** this task caused concern, so it will be discussed again
| |
− | ** Decide on anti-spam measures for current MW version, install and set them, ''then'' open for create user.
| |
− | * Clean database, for "deleted" pages, unused files.
| |
− | * repair "broken redirect", "double redirect", "non categorized pages"
| |
− | * Convert all pages to UTF8 (mysql),
| |
− | ** most pages are defined as latin1, but some have UTF8 content, this will not work after an update.
| |
− | :: The fix for this is to pass the tables manually through the conversion process using "binary" as an intermediary from Latin1 to UTF-8. Note though that this only "needs" to be done on tables that are incorrectly types as Latin1 but actually contain UTF-8 data. Not all tables in the OOoWiki dB have this issue.
| |
| UPDATE table_name SET col_name = CONVERT(CONVERT(CONVERT(col_name USING latin1) USING binary) USING utf8); | | UPDATE table_name SET col_name = CONVERT(CONVERT(CONVERT(col_name USING latin1) USING binary) USING utf8); |
− | :: Another way to do this (and possibly a more effective solution since it can be done during the MWiki upgrade) is: | + | :: |
| + | Another way to do this (and possibly a more effective solution since it can be done during the MWiki upgrade) is: |
| mysqldump -h DB_HOST -u DB_USER -p DB_PASSWORD --opt --quote-names --skip-set-charset --default-character-set=latin1 DB_NAME > DB_NAME-dump.sql | | mysqldump -h DB_HOST -u DB_USER -p DB_PASSWORD --opt --quote-names --skip-set-charset --default-character-set=latin1 DB_NAME > DB_NAME-dump.sql |
| mysql -h DB_HOST -u DB_USER -p DB_PASSWORD --default-character-set=utf8 DB_NAME < DB_NAME-dump.sql | | mysql -h DB_HOST -u DB_USER -p DB_PASSWORD --default-character-set=utf8 DB_NAME < DB_NAME-dump.sql |
| :: (source: http://blog.hno3.org/2010/04/22/fixing-double-encoded-utf-8-data-in-mysql/ ) | | :: (source: http://blog.hno3.org/2010/04/22/fixing-double-encoded-utf-8-data-in-mysql/ ) |
− | * make a new test wiki as a copy of the existing wiki
| |
− | ** testwiki.openoffice.org works with only apache conf changes
| |
− | ** ALL /etc changes most go through Infra!
| |
− | ** the test wiki, must have a .htaccess with e.g. wikitest/testwiki, so no user can get confused
| |
− | ** mail must be disabled (and can therefore not be tested)
| |
− | * upgrade test db.
| |
− | * upgrade php source
| |
− | ** Install a naked source, and do all changes again, while recording them (not SVN, see later).
| |
− | * have people testing test
| |
− | * Copy production db, and upgrade it
| |
− | * copy test to production.
| |
− | * Assemble all files and inform community/infra about further action
| |
− |
| |
− | no goes:
| |
− | * there are objections against using openoffice SVN
| |
− | ** no intermediary changes will be recorded and reproduceable snapshot steps for testing most be done with zip files
| |
Another way to do this (and possibly a more effective solution since it can be done during the MWiki upgrade) is: