Topic on Project:Support desk/Flow

I have an old version of Mediawiki (1.16.4) which I use for local history research. When I tried to access it today, none of the content would display. Regardless of which page I navigate to, the Mediawiki code can be seen in edit mode but does not render when I exit that mode. Any suggestions, please?

Hi!

This most likely is this problem: Manual:Errors_and_symptoms#All_pages_have_no_content.2C_but_when_editing_a_page_the_wiki_text_is_there.

Most likely a MediaWiki upgrade should solve it!

Thanks. The reason I'm still using 1.16.4 is my lack of knowledge regarding upgrading. Is it 'easy'? Which version can I move too with minimal hassle? How do I protect the wiki text during upgrade? There are around 2.5m words, hundreds of images and thousands of hours invested in the project so far.

Just seen reference to upgrading to a minimum of 1.22.1 but I'd welcome advice on queries posted previously. I'm a bit out of my depth!

Upgrading is not really difficult. When you do it for the first time, you will need some time to do it, but it should be feasible.

Some notes:

Make sure you have a working backup: All files of the MediaWiki installation and the database!

Your wiki text, images and so on will all stay as they are during upgrade; anyway, I can only repeat that: Make sure, that your backup is working! Try extracting it and see, if a wiki, which you have set up from the backup, works!

Finally: Which versions of PHP and of MySQL are you using? The page Special:Version in your wiki will tell...

In Special:Version, it is like all the other pages, blank wiki page template with no content. However, my server cPanel shows that it is using PHP version 5.4.35 and MySQL version 5.5.40-cll.

Although you're making it sound like a 'small' job, I would prefer that the upgrade be carried out by someone who knows what they are doing. Is there anyone on here who would consider taking on the task for a few bob?

My prime concern is for the wiki content which is very 'valuable'. I simply cannot risk it.

On the subject of upgrading, I have access to Softaculous in my server's cPanel. Would you recommend using a Softaculous script to uggrade from MediaWiki 1.16.4 to either 1.19.21 or 1.23.6 both options being available to me. I ask because I am aware that there have been some issues with using Softaculous to update various packages.

Well, 1.16 is not supported anymore and has security bugs. You should upgrade to one of the supported versions.

As a last resort, apply the patch provided in bug 58640 in your code.

The bug fix seems to relate to MediaWiki 1.22.0 and not 1.16.4 which I've been using?

On the bugfix: You could try to integrate this into MediaWiki 1.16 somehow, but I would not recommend doing so: MW 1.16 still will no longer be supported after that and hacking the Core is evil. Doing an upgrade really is what you should do.

And good news is: With your PHP and MySQL versions you will be able to update to MediaWiki 1.23.6 (which btw is a release with long term support until May 2017). The question of how much work such an update is then depends on two factors:

• Which MediaWiki extensions are you using? You can check that by looking into the extensions/ folder of your MediaWiki installation.
• Second: Which skin are you using? Is it the Vector skin (which is what wikipedia looks like) or do you use a different skin? If so, which one?

Thanks for the advice.

I have only one extension which is "Who's Online". This is not critical. I just want my wiki back!

I have always used the default skin.

Will an upgrade retain permissions and other security tweaks?

I have access to Softaculous through my cPanel and am toying with the idea of upgrading to either 1.19.21 or even 1.23.21. Still asking a few questions in this respect particularly as regards backups and potential issues around skipping versions when upgrading.

Thie Extension:Whos_online should then be uninstalled before you upgrade.

Your situation with the extensions and the default skin makes an upgrade as easy as it could be. Here is more information on how to back up a wiki: Manual:Backing_up_a_wiki.

What do you mean with "permissions and security tweaks"?

It will help to read upgrade while you do it or before you start. I would go for version 1.23.6, which you are offered through Softaculous.

"permissions and security tweaks" refers to the settings I have in place for those who can edit content and this is currently restricted to four users.

Settings in LocalSettings.php will be unaffected by the upgrade.

That's good, thanks.

So, I upgraded to MediaWiki 1.23.6 using the Softaculous script. The Wiki is back with one or two minor issues like some text is now depicted in bold where it wasn't in version 1.16.4. However, nearly all functions including special pages are returning database errors:-

Upload File

Database error

A database query error has occurred. This may indicate a bug in the software.

Special Pages

Database error

A database query error has occurred. This may indicate a bug in the software.

Any ideas, please?

A database query error has occurred. This may indicate a bug in the software.

Any ideas, please?

See Manual:Upgrading#Web_browser

OK, so my host updated the database via the command line.

"MediaWiki 1.23.6 Updater

Going to run database updates
Depending on the size of your database this may take a while!
Abort with control-c in the next five seconds (skip this countdown with --quick) ... 0
Turning off Content Handler DB fields for this part of upgrade.
...have ipb_id field in ipblocks table.
...have ipb_expiry field in ipblocks table.
...already have interwiki table
...indexes seem up to 20031107 standards.
...hitcounter table already exists.
...have rc_type field in recentchanges table.
...index new_name_timestamp already set on recentchanges table.
...have user_real_name field in user table.
...querycache table already exists.
...objectcache table already exists.
...categorylinks table already exists.
...have pagelinks; skipping old links table updates
...il_from OK
...have rc_ip field in recentchanges table.
...index PRIMARY already set on image table.
...have rc_id field in recentchanges table.
...have rc_patrolled field in recentchanges table.
...logging table already exists.
...have user_token field in user table.
...have wl_notificationtimestamp field in watchlist table.
...watchlist talk page rows already present.
...user table does not contain user_emailauthenticationtimestamp field.
...page table already exists.
...have log_params field in logging table.
...logging table has correct log_title encoding.
...have ar_rev_id field in archive table.
...have page_len field in page table.
...revision table does not contain inverse_timestamp field.
...have rev_text_id field in revision table.
...have rev_deleted field in revision table.
...have img_width field in image table.
...have img_metadata field in image table.
...have user_email_token field in user table.
...have ar_text_id field in archive table.
...page_namespace is already a full int (int(11)).
...ar_namespace is already a full int (int(11)).
...rc_namespace is already a full int (int(11)).
...wl_namespace is already a full int (int(11)).
...qc_namespace is already a full int (int(11)).
...log_namespace is already a full int (int(11)).
...have img_media_type field in image table.
...already have pagelinks table.
...image table does not contain img_type field.
...already have unique user_name index.
...user_groups table exists and is in current format.
...have ss_total_pages field in site_stats table.
...user_newtalk table already exists.
...transcache table already exists.
...have iw_trans field in interwiki table.
...wl_notificationtimestamp is already nullable.
...index times already set on logging table.
...have ipb_range_start field in ipblocks table.
...no page_random rows needed to be set
...have user_registration field in user table.
...templatelinks table already exists
...externallinks table already exists.
...job table already exists.
...have ss_images field in site_stats table.
...langlinks table already exists.
...querycache_info table already exists.
...filearchive table already exists.
...have ipb_anon_only field in ipblocks table.
...index rc_ns_usertext already set on recentchanges table.
...index rc_user_text already set on recentchanges table.
...have user_newpass_time field in user table.
...redirect table already exists.
...querycachetwo table already exists.
...have ipb_enable_autoblock field in ipblocks table.
...index pl_namespace on table pagelinks includes field pl_from.
...index tl_namespace on table templatelinks includes field tl_from.
...index il_to on table imagelinks includes field il_from.
...have rc_old_len field in recentchanges table.
...have user_editcount field in user table.
...page_restrictions table already exists.
...have log_id field in logging table.
...have rev_parent_id field in revision table.
...have pr_id field in page_restrictions table.
...have rev_len field in revision table.
...have rc_deleted field in recentchanges table.
...have log_deleted field in logging table.
...have ar_deleted field in archive table.
...have ipb_deleted field in ipblocks table.
...have fa_deleted field in filearchive table.
...have ar_len field in archive table.
...have ipb_block_email field in ipblocks table.
...index cl_sortkey on table categorylinks includes field cl_from.
...have oi_metadata field in oldimage table.
...index usertext_timestamp already set on archive table.
...index img_usertext_timestamp already set on image table.
...index oi_usertext_timestamp already set on oldimage table.
...have ar_page_id field in archive table.
...have img_sha1 field in image table.
...protected_titles table already exists.
...have ipb_by_text field in ipblocks table.
...page_props table already exists.
...updatelog table already exists.
...category table already exists.
...category table already populated.
...have ar_parent_id field in archive table.
...have user_last_timestamp field in user_newtalk table.
...protected_titles table has correct pt_title encoding.
...have ss_active_users field in site_stats table.
...ss_active_users user count set...
...have ipb_allow_usertalk field in ipblocks table.
...pl_namespace, tl_namespace, il_to indices are already UNIQUE.
...change_tag table already exists.
...tag_summary table already exists.
...valid_tag table already exists.
...user_properties table already exists.
...log_search table already exists.
...have log_user_text field in logging table.
...l10n_cache table already exists.
...index ls_field_val already set on log_search table.
...index change_tag_rc_tag already set on change_tag table.
...have rd_interwiki field in redirect table.
...transcache tc_time already converted.
...*_mime_minor fields are already long enough.
...iwlinks table already exists.
...index iwl_prefix_title_from already set on iwlinks table.
...have ul_value field in updatelog table.
...have iw_api field in interwiki table.
...iwl_prefix key doesn't exist.
...have cl_collation field in categorylinks table.
...categorylinks up-to-date.
...collations up-to-date.
...msg_resource table already exists.
...module_deps table already exists.
...ar_page_revid key doesn't exist.
...index ar_revid already set on archive table.
...ll_lang is up-to-date.
...user_last_timestamp is already nullable.
...index user_email already set on user table.
...up_property in table user_properties already modified by patch patch-up_property.sql.
...uploadstash table already exists.
...user_former_groups table already exists.
...index type_action already set on logging table.
...have rev_sha1 field in revision table.
...batch conversion of user_options: nothing to migrate. done.
...user table does not contain user_options field.
...have ar_sha1 field in archive table.
...index page_redirect_namespace_len already set on page table.
...have us_chunk_inx field in uploadstash table.
...have job_timestamp field in job table.
...index page_user_timestamp already set on revision table.
...have ipb_parent_block_id field in ipblocks table.
...index ipb_parent_block_id already set on ipblocks table.
...category table does not contain cat_hidden field.
...have rev_content_format field in revision table.
...have rev_content_model field in revision table.
...have ar_content_format field in archive table.
...have ar_content_model field in archive table.
...have page_content_model field in page table.
Content Handler DB fields should be usable now.
...site_stats table does not contain ss_admins field.
...recentchanges table does not contain rc_moved_to_title field.
...sites table already exists.
...have fa_sha1 field in filearchive table.
...have job_token field in job table.
...have job_attempts field in job table.
...have us_props field in uploadstash table.
...ug_group in table user_groups already modified by patch patch-ug_group-length-increase-255.sql.
...ufg_group in table user_former_groups already modified by patch patch-ufg_group-length-increase-255.sql.
...index pp_propname_page already set on page_props table.
...index img_media_mime already set on image table.
...iwl_prefix_title_from index is already non-UNIQUE.
...index iwl_prefix_from_title already set on iwlinks table.
...have ar_id field in archive table.
...have el_id field in externallinks table.
...have rc_source field in recentchanges table.
...index log_user_text_type_time already set on logging table.
...index log_user_text_time already set on logging table.
...have page_links_updated field in page table.
...have user_password_expires field in user table.
...online table already exists.
...site_stats is populated...done.
...Update 'populate rev_len and ar_len' already logged as completed.
...Update 'populate rev_sha1' already logged as completed.
...img_sha1 column of image table already populated.
...protocol-relative URLs in externallinks table already fixed.
...fa_sha1 column of filearchive table already populated.
Purging caches...done.

Done in 0:01.

Also, the following is now a typical error message returned when trying to edit a wiki page:-

A database query error has occurred. This may indicate a bug in the software.

Query:
SELECT ipb_id,ipb_address,ipb_by,ipb_by_text,ipb_reason,ipb_timestamp,ipb_auto,ipb_anon_only,ipb_create_account,ipb_enable_autoblock,ipb_expiry,
ipb_deleted,ipb_block_email,ipb_allow_usertalk,ipb_parent_block_id FROM `mw_ipblocks` WHERE ipb_address = 'WikiSysop'
Function: Block::newLoad
Error: 1054 Unknown column 'ipb_by' in 'field list' (localhost)

Just updated to 1.24.0 using Softaculous. Currently waiting for my host to attempt a database update direct from the server command line. As it stands, I am still getting the same errors when attempting to edit pages.

Database update failed.

Still have a 1.16.4 backup, though no point in going back if there is then no route forward. As it stands I have a viewable wiki which cannot be edited. I suppose it's better that the other way round!

Just saw your post. As a member of the WikiReleaseTeam, I'd like to help you get your wiki working. Please email me and I'll try to help you fix it.

Have emailed you. Many thanks for getting in touch.

Job sorted. A big thanks to MarkAHershberger for mending my wiki. I cannot expand upon what was wrong and how it was put right. Excellent work nevertheless.

One of the updates was somehow missed. Since the log provided by your hoster shows it wasn't needed, I can only think that they must have run it against the wrong DB. Or the affected DB fields were removed somehow.

Mark.

If a specific update did not work, why can it then be marked as "was run successfully"? This question puzzles me since years...

Don't lose sight of the fact that the two updates were carried out using Softaculous scripts. This option was chosen by me because I didn't feel confident following Mediawiki's 'manual' upgrade guidance. I hope in the future that efforts will be made to simplify guidance to newbies like me to get jobs done 'solo'.

However, I mustn't lose sight of the fact that MarkAHershberger came to the fore and solved the problem. To him I am very grateful.

Since I had someone else with a CPanel hosted wiki come to me for help here, I'm posting the SQL that I had to use to fix their problem. Probably Softaculous should be notified, but I don't know how to do that right now.

The SQL:

ALTER TABLE mw_ipblocks ADD COLUMN ipb_create_account bool NOT NULL default 1;