WordPress.org

Make WordPress Core

Opened 5 years ago

Closed 5 years ago

#9741 closed enhancement (wontfix)

Database issue allows creation of articles

Reported by: davehope Owned by:
Milestone: Priority: normal
Severity: normal Version: 2.8
Component: Upgrade/Install Keywords: needs-patch
Focuses: Cc:

Description

My host killed the mysqld process, causing some of the MySQL tables to be flagged as corrupt (wp_options for one).

Wordpress thought it was a new installation, and showed wp-admin/install.php. Visitors were going through the install process setting the title of my site and wordpress created the "About" page, the example post and comment.

When I awoke, I repaired the corruption with myisamchk. In my case the page title hadn't been changed but the new items were created.

Some options I think would prevent this ocuring for others are:

  • The installation page should require an admin to login if it's not the first installation. I'm not sure what would happen if the table holding user accounts was corrupt though.
  • Do some checks on the status of the tables and halt the installation if any of the tables aren't in a healthy state?

My suggestion is probably more of an enhancement request that a bug, so I've filed it as such.

Thanks

Dave

Change History (8)

comment:1 Denis-de-Bernardy5 years ago

  • Component changed from General to Upgrade/Install
  • Keywords needs-patch added
  • Milestone changed from Unassigned to Future Release
  • Owner anonymous deleted

First suggestion is not possible -- you'd need the wp_options to be OK to be able to log in as admin.

Second section is workable, with a SHOW STATUS call. Maybe the installer could try a REPAIR statement before proceeding...

comment:2 DD325 years ago

Second section is workable, with a SHOW STATUS call. Maybe the installer could try a REPAIR statement before proceeding...

We've been down that road before. A repair command can potentially cause lost data, WordPress isnt going to automatically run such a command.

The installer could add some more checks(ie. if its going to re-use the same user tables, then check a user/pass combo from there), Infact, I think theres a recent ticket for this already.

comment:3 davehope5 years ago

Perhaps install.php should check the status of all the tables? - all the needed settings are in wp-config.php so as Denis-de-Bernardy says, perhaps do a SHOW STATUS call. Wordpress would know the tables exist, and the credentials are invalid so should then halt and maybe provide some information on how to manually resolve the problem?

It's fairly unlikely that there'd be any corruption after a fresh install, and this would prevent visitors inserting endless content into your database.

comment:4 Denis-de-Bernardy5 years ago

Personally, I use the following on a daily cron:

	function maintain_db()
	{
		global $wpdb;

		$tablelist = $wpdb->get_results("SHOW TABLE STATUS LIKE '$wpdb->prefix%'", ARRAY_N);
		
		foreach ( $tablelist as $table )
		{
			$tablename = $table[0];
			
			if ( strtoupper($table[1]) != 'MYISAM' ) continue;
			
			$check = $wpdb->get_row("CHECK TABLE $tablename", ARRAY_N);

			if ( $check[2] == 'error' )
			{
				if ( $check[3] == 'The handler for the table doesn\'t support check/repair' )
				{
					continue;
				}
				else
				{
					$repair = $wpdb->get_row("REPAIR TABLE $tablename", ARRAY_N);

					if ( $repair[3] != 'OK' )
					{
						continue;
					}
				}
			}

			$wpdb->query("OPTIMIZE TABLE $tablename");
		}
	} # maintain_db()

the repair is only triggered when there's an actual error, so as to never get any loss of data -- when it gets fired, data is lost already, so might as well try to retrieve as much as we can.

comment:5 Denis-de-Bernardy5 years ago

improved version of the latter function:

	function maintain_db() {
		global $wpdb;
		
		$tablelist = $wpdb->get_results("SHOW TABLE STATUS LIKE '$wpdb->prefix%'", ARRAY_N);
		
		foreach ( $tablelist as $table ) {
			$tablename = $table[0];
			
			if ( strtoupper($table[1]) != 'MYISAM' )
				continue;
			
			$check = $wpdb->get_row("CHECK TABLE $tablename", ARRAY_N);
			
			if ( $check[2] == 'error' ) {
				$repair = $wpdb->get_row("REPAIR TABLE $tablename", ARRAY_N);
				
				if ( $repair[3] != 'OK' )
					continue;
			}
			
			$wpdb->query("OPTIMIZE TABLE $tablename");
		}
	} # maintain_db()

it's on a weekly cron.

comment:6 follow-up: vladimir_kolesnikov5 years ago

  • Cc vladimir@… added

Denis-de-Bernardy, mysqlcheck is better and safer. Just my opinion.

comment:7 in reply to: ↑ 6 Denis-de-Bernardy5 years ago

Replying to vladimir_kolesnikov:

Denis-de-Bernardy, mysqlcheck is better and safer. Just my opinion.

Agreed. I use neither, personally, as my own DB runs on NDB. But customers can't be bothered to worry about this using the shell... :-)

comment:8 Denis-de-Bernardy5 years ago

  • Milestone Future Release deleted
  • Resolution set to wontfix
  • Status changed from new to closed

see #4677

Note: See TracTickets for help on using tickets.