Make WordPress Core

Opened 6 years ago

Closed 20 months ago

#42362 closed defect (bug) (fixed)

WordPress database error Unknown column 'wp_mywordpresssite' in 'field list'

Reported by: lazam786's profile lazam786 Owned by: sergeybiryukov's profile SergeyBiryukov
Milestone: 6.1 Priority: normal
Severity: normal Version: 4.6
Component: Database Keywords: php8 php81 has-patch needs-testing
Focuses: Cc:

Description

I am trying to install wordpress 4.8 on PHP 5.6 and Windows 7 IIS 7.5. During new installation, I gave my database details adnd table prefix as wp_mywordpresssite. It throws an error as below.

WordPress database error Unknown column 'wp_mywordpresssite' in 'field list'.

Please let me know fi anybody has any solution to move forward with my installation.

I am using old PHP version to mimic my production instance. If that be the issue please let me know.

Attachments (2)

42362.diff (665 bytes) - added by pento 6 years ago.
42362.2.diff (676 bytes) - added by SergeyBiryukov 20 months ago.

Download all attachments as: .zip

Change History (46)

#1 @SergeyBiryukov
6 years ago

  • Component changed from General to Database
  • Milestone Awaiting Review deleted
  • Resolution set to duplicate
  • Status changed from new to closed

Hi @lazam786, welcome to WordPress Trac!

Thanks for the report, we're already tracking this issue in #40655.

#2 @lazam786
6 years ago

  • Resolution duplicate deleted
  • Status changed from closed to reopened

Hi SergeyBiryukov,

The ticket #40655 is all about changing the error message displayed. I am getting this error irrespective of my database connection is good and it stops with this message after I provide my db creds.

http://mywordpresssite.com:8090/wp-admin/setup-config.php?step=2

WordPress database error Unknown column 'wp_' in 'field list' for query SELECT wp_

It is not able to move forward after thsi step and no DB setup is performed.

I see 40655 is close as fix provided but I dont find a fix for the above issue. COuld you please help me in this regard.

#3 @Velochicdunord
6 years ago

I also ran into this error. I've asked a question about it at the users install forum.
https://wordpress.org/support/topic/problems-w-local-installation-of-wordpress-4-9-1-within-mamp-4-2-on-mac-10-11-6/

The details for my installation error as follows:

Setting up WordPress 4.9.1 within MAMP 4.2 on a Mac 10.11.6 OS for a friend to do some testing.

The installation is hanging up on the install.php file and not finishing. When I abort the installation, the files are installed, but I’m getting the white screen of death.

I’ve been using the MAMP logs to track the errors – the error message is:
WordPress database error Unknown column ‘customprefix_’ in ‘field list’ for query SELECT customprefix_

While we’re using PHP version 7.1.8 within MAMP, the Mac OS is running PHP 5.5.38.
I was wondering if there has been a significant change in some of the PHP call properties.

Last edited 6 years ago by Velochicdunord (previous) (diff)

#4 @SergeyBiryukov
6 years ago

  • Milestone set to Awaiting Review

#5 @SergeyBiryukov
6 years ago

#43167 was marked as a duplicate.

#6 @SergeyBiryukov
6 years ago

  • Milestone changed from Awaiting Review to 4.9.5

Let's try the suggestion from comment:2:ticket:43167.

#7 @audrasjb
6 years ago

  • Milestone changed from 4.9.5 to 4.9.6

Bumping to 4.9.6 due to 4.9.5 beta release.

#8 @blackawxs
6 years ago

I'm also having this issue as of today. Please let me know if anything appears as a red flag but I believe I have done everything correctly....

My Specs:

  • I'm working within a Windows 2016 Server.
  • I have MySQL Community (Server only installed). Version 5.7.2.1.0 Tested it and its running
  • I have PHP 5.6.35 installed. Tested it and its running
  • I have IIS10 running with FastCgiModule running to serve the PHP. No issues there.
  • I created a virtual directory on my development machine, so I am able to go to mysite.sanbox/v01/wordpress and see the default wordpress page to pick a language. That is fine. I click next.
  • I then use phpmyadmin to create my new database table. That is fine.
  • I then go back to mysite.sanddbox/v01/wordpress and I put in my database information.
  • I then click next. The next page is white and says WordPress database error Unknown column 'wp_' in 'field list' for query SELECT wp_. I have attempted a different database name and different prefix, but no luck.
  • I have attempted to install WordPress versions wordpress-4.9.5.zip, wordpress-4.9.4.zip and also tried wordpress-4.8.1.zip. Same issue in all three cases.

Would anyone have a clue as to why this is happening?

Last edited 6 years ago by blackawxs (previous) (diff)

#9 @blackawxs
6 years ago

An unexpected behavior occurred...I went into my php.ini file and set an error_log directory, and set display_errors = On. From that moment, the wp-config.php was created and I was able to complete the installation process. I'm not sure if this solved it, but I'm working again now.

...I also made sure IUSR AND IIS_IUSRS had proper permissions on the directory....

Last edited 6 years ago by blackawxs (previous) (diff)

This ticket was mentioned in Slack in #core by desrosj. View the logs.


6 years ago

This ticket was mentioned in Slack in #core by desrosj. View the logs.


6 years ago

This ticket was mentioned in Slack in #core by desrosj. View the logs.


6 years ago

#13 @desrosj
6 years ago

  • Keywords needs-patch added
  • Milestone changed from 4.9.6 to 4.9.7

Punting due to lack of patch.

#14 @desrosj
6 years ago

  • Milestone changed from 4.9.7 to 4.9.8

Moving all tickets in 4.9.7 to 4.9.8.

#15 @codewhy
6 years ago

@desrosj Can you please advise if there is any recommended workaround for this problem (I just noticed a fix has been pushed back further from 4.9.7 to v4.9.8)? I've lost a couple of days systematically trying to fix this issue, finding it mentioned in various forms, scattered across the web. I eventually decided to log it as a bug and came across this ticket when searching on the PHP error.

My situation is very similar to @Velochicdunord - I have Mac OSX 10.11.6, MAMP 4.4.1 (PHP 7.2.1) and Wordpress 4.9.5. After clicking the Install Wordpress button, the same PHP error is logged and the browser is left hanging waiting for a response.

The main difference for me is that if I then navigate to the wordpress local hosting URL, the the basic website appears and I can log in to the Wordpress editor. So the database tables are also created - BUT I have no way of knowing if the installation has completed successfully - and if it hasn't, then what issues this will cause downstream if I continue regardless.

This has stopped me in my tracks in trying to setup a local dev instance of Wordpress. Would really appreciate any advice in how I can workaround it (other than setting up a virtual private server in the cloud), or how I can determine if the local installation has in fact completed successfully and won't cause problems later.

#16 @psykro
6 years ago

@codewhy have you made any changes to the PHP error reporting settings on your MAMP install?

I have just tried to replicate this on a clean MAC OSX 10.11 install and a clean MAMP 4.4.1 install and the install worked as expected. So I'd like to try and find out if there's any differences between your setup and mine that would help me replicate the problem.

This ticket was mentioned in Slack in #core by jon_bossenger. View the logs.


6 years ago

#18 @codewhy
6 years ago

@psykro Thanks for looking into this.

I worked through a simple installation of wordpress and only started changing settings like the PHP error logging when I encountered the problem, for troubleshooting purposes. I did increase logging verbosity purely to try to obtain the most detailed logging possible about the problem occurring (ie. the browser hanging after clicking 'Install Wordpress' with 'Waiting for localhost' displayed on the status bar).

The last error I was able to find that was logged was:
"[21-May-2018 13:19:29 UTC] WordPress database error Unknown column 'wp_' in 'field list' for query SELECT wp_"

I tried an array of other things to get to the bottom of this but without success.

Not sure if this sheds any light on the problem for you? If not, can you please advise if there is any way I can determine with certainty if the wordpress installation has in fact completed successfully?

This ticket was mentioned in Slack in #core by jon_bossenger. View the logs.


6 years ago

@pento
6 years ago

#20 @pento
6 years ago

  • Keywords has-patch added; needs-patch removed
  • Version changed from 4.8.2 to 4.6

This message is occurring because [41631] wasn't suppressing all errors, 42362.diff suppresses the error more aggressively. We want this error to be triggered (it proves that it's an appropriate table prefix), but we don't want it to be displayed at all.

This should also fix the problem where the install process appears to stall. After this error messages is displayed, setup_config_display_header() is called, which has a header() call. I suspect some browsers get confused when they're sent content, then a header, then more content.

As a workaround, you should ensure display_errors is set to 0 in your php.ini file. This will prevent errors from being displayed in the browser.

#21 @pento
6 years ago

  • Keywords needs-testing added
  • Milestone changed from 4.9.8 to 4.9.9

As this patch still needs testing, I'm moving it to 4.9.9. If an existing commenter can confirm that the bug is fixed in the next day or two, it can potential be moved back to 4.9.8.

#22 @codewhy
6 years ago

Thanks @pento . I will try to test that the install process no longer stalls soon. Given testing involves performing a fresh installation, can you please advise where I should obtain the download file (that includes this patch) from? I've had a look at the Releases page, Beta/Nightly page, Beta Testing page and the needs testing tickets, but can't see where I can obtain the install file that would allow me to test this installation bug.

Or would you rather I unpacked the latest stable release version (v4.9.7) and replace the setup-config.php file with the file containing your fix from the source code repo, before running the install.php script?

#23 @pento
6 years ago

Thank you for offering to test this, @codewhy!

There isn't a location to download the file, you'll need to unpack the latest stable version, and edit the changes into setup-config.php. If you're comfortable applying patch files, then 42362.diff can be used for that. Otherwise, the manual edits you need to make are:

  • On line 287, replace hide_errors with suppress_errors.
  • On line 289, replace show_errors with suppress_errors.

Once you've applied these changes, please run through the normal install process.

#24 @codewhy
6 years ago

Sorry @pento - no joy with the testing. I've tested the same setup described in my previous post, except using wordpress v4.9.7 and then following your instructions. The page hangs in exactly the same manner described previously.
I also tried adding in debug config lines into wp-config.php:

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);

...but no log files were created - not surprising I guess given the suppress_errors setting we're testing in the setup-config.php file, but thought I would try it anyway in case it gave you something more to go on.

#25 @pento
6 years ago

  • Keywords needs-testing removed
  • Milestone changed from 4.9.9 to Future Release

Thanks for testing that, @codewhy.

This is going to need more investigation to figure out the cause.

#26 @SergeyBiryukov
5 years ago

  • Milestone changed from Future Release to 5.1
  • Owner set to SergeyBiryukov
  • Status changed from reopened to reviewing

This ticket was mentioned in Slack in #core by pento. View the logs.


5 years ago

#28 @pento
5 years ago

  • Milestone changed from 5.1 to Future Release

#29 @burgiuk
5 years ago

I'm still getting this in a fresh install of 5.2.1. I'm running IIS on Windows 10. I've never had this problem before.

What do you need from me for testing?

#30 @mdrago
4 years ago

Been 2 days fighting with this same problem...

Scenario:

  • Windows 2019, clean install (IIS 10)
  • PHP 7.4.5 nts
  • MySQL 8.0.20 (also tried with 5.7, same error)
  • WP 5.4.1

To solve the issue you must edit your php.ini in your PHP folder:

display_errors = On
error_log = php_errors.log

Setting error_log solves the issue... I guess that when error_log has no value (default configuration), PHP decides to send the error back to the calling program, resulting in the error message column 'wp_' in 'field list' during the WP installation.

Suggestion:
During the installation process, the WP installer should check that PHP is configured correctly to continue with the installation.

#31 @kykyfyfyf
4 years ago

To me was solution next(in your php.ini) :

fastcgi.impersonate = 1
fastcgi.logging = 0
cgi.fix_pathinfo=1
cgi.force_redirect = 0
Last edited 4 years ago by kykyfyfyf (previous) (diff)

#32 @SergeyBiryukov
2 years ago

#54579 was marked as a duplicate.

#33 follow-up: @SergeyBiryukov
2 years ago

  • Keywords php8 php81 added
  • Milestone changed from Future Release to 6.0

Just noting that the error appears to be more prominent with PHP 8.1, as reported in #54579:

[php:error] [pid 18811] [client 127.0.0.1:36932] PHP Fatal error:  Uncaught mysqli_sql_exception: > > > Unknown column 'wp_' in 'field list' in /var/www/mylocalsite.com/wp-includes/wp-db.php:2056
Stack trace:
#0 /var/www/mylocalsite.com/wp-includes/wp-db.php(2056): mysqli_query()
#1 /var/www/mylocalsite.com/wp-includes/wp-db.php(1945): wpdb->_do_query()
#2 /var/www/mylocalsite.com/wp-admin/setup-config.php(317): wpdb->query()
#3 {main}
  thrown in /var/www/mylocalsite.com/wp-includes/wp-db.php on line 2056, referer: http://mylocalsite.com/wp-admin/setup-config.php?step=1

I am running Ubuntu 20.04, PHP 8.1.0, MySQL 8.0.27, Apache 2.4.41

#34 follow-up: @maythamalsudany
2 years ago

What is the purpose of SELECT $prefix in wp-admin/setup-config.php:317?

If it's causing the issue and has no purpose, then might as well remove it.

This ticket was mentioned in Slack in #core by mike. View the logs.


2 years ago

#36 @sumitsingh
2 years ago

  • Keywords needs-patch added; has-patch removed

#37 @sumitsingh
2 years ago

I have checked and above added patch is not working.

This ticket was mentioned in Slack in #core by costdev. View the logs.


2 years ago

#39 @peterwilsoncc
23 months ago

  • Milestone changed from 6.0 to Future Release

I'm moving this to a future release as RC1 is next week. The patch needs a refresh and there hasn't been any progress during the 6.0 cycle.

#40 @deksar
20 months ago

Hello there, I've the same problem and have been looking for a solution since around 2 months all over the Internet.

Wordpress version: 6.0.1
PHP version: 8.0.20
Web server: nginx

Getting the following error output in error.log file;

2022/08/01 17:16:22 [error] 17788#100281: *143 FastCGI sent in stderr: "PHP message: WordPress database error Unknown column 'wp_' in 'field list' for query SELECT wp_" while reading response header from upstream, client: 17x.xxx.yyy.zzz, server: mysite.com, request: "POST /wp-admin/setup-config.php?step=2 HTTP/1.1", upstream: "fastcgi://10.10.45.42:9000", host: "mysite.com", referrer: "https://mysite.com/wp-admin/setup-config.php?step=1"

So is there any update on this issue? It seems the fix was/is postponed. Any reason?

Best.

Last edited 20 months ago by deksar (previous) (diff)

#41 in reply to: ↑ 34 ; follow-up: @SergeyBiryukov
20 months ago

  • Keywords has-patch needs-testing added; needs-patch removed

Replying to maythamalsudany:

What is the purpose of SELECT $prefix in wp-admin/setup-config.php:317?

The purpose is to disallow table prefixes that would cause a syntax error, see [37581] / #36422.

There is some more context in comment:20:

We want this error to be triggered (it proves that it's an appropriate table prefix), but we don't want it to be displayed at all.

[41631] / #40655 was supposed to silently discard the error, but appears to not always work as expected.

42362.2.diff refreshes the patch, testing would be appreciated.

#42 in reply to: ↑ 41 @deksar
20 months ago

Replying to SergeyBiryukov:

Replying to maythamalsudany:

What is the purpose of SELECT $prefix in wp-admin/setup-config.php:317?

The purpose is to disallow table prefixes that would cause a syntax error, see [37581] / #36422.

There is some more context in comment:20:

We want this error to be triggered (it proves that it's an appropriate table prefix), but we don't want it to be displayed at all.

[41631] / #40655 was supposed to silently discard the error, but appears to not always work as expected.

42362.2.diff refreshes the patch, testing would be appreciated.

I have just tested the patch, it solved the problem, no more errors.
Test environment: PHP 8.0.20
WordPress 6.0.1

Thanks.

#43 in reply to: ↑ 33 @SergeyBiryukov
20 months ago

  • Milestone changed from Future Release to 6.1

Replying to SergeyBiryukov:

Just noting that the error appears to be more prominent with PHP 8.1, as reported in #54579:

[php:error] [pid 18811] [client 127.0.0.1:36932] PHP Fatal error:  Uncaught mysqli_sql_exception: > > > Unknown column 'wp_' in 'field list' in /var/www/mylocalsite.com/wp-includes/wp-db.php:2056
Stack trace:
#0 /var/www/mylocalsite.com/wp-includes/wp-db.php(2056): mysqli_query()
#1 /var/www/mylocalsite.com/wp-includes/wp-db.php(1945): wpdb->_do_query()
#2 /var/www/mylocalsite.com/wp-admin/setup-config.php(317): wpdb->query()
#3 {main}
  thrown in /var/www/mylocalsite.com/wp-includes/wp-db.php on line 2056, referer: http://mylocalsite.com/wp-admin/setup-config.php?step=1

To follow up on this, I believe the fatal error was resolved in [51582] / #52825, which prevents mysqli_sql_exception from being thrown.

I was able to reproduce the initial issue:

  1. Remove wp-config.php if it exists.
  2. Open the home URL, which should then redirect to wp-admin/setup-config.php.
  3. Start the installation and proceed until wp-config.php is created.
  4. Check the error log for the Unknown column 'wp_' in 'field list' message.

Replying to deksar:

I have just tested the patch, it solved the problem, no more errors.

Thank you! It resolves the issue in my testing too.

I also tried the suggestion from comment:2:ticket:43167. It does not log an error for valid prefixes like wp_, but still does for invalid ones like 7e1_:

You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near '7e1_' at line 1"

So changing the query does not seem to make a difference here, as it would still need some kind of error suppression.

Moving to 6.1, as 42362.2.diff appears to work as expected.

#44 @SergeyBiryukov
20 months ago

  • Resolution set to fixed
  • Status changed from reviewing to closed

In 53812:

Database: Suppress errors when checking the validity of table prefix during installation.

There are some table prefixes (for example, 7e1_), which the database will try and parse as values unless they are quoted in backticks. Because not everyone remembers to quote their table names, WordPress discourages use of such prefixes during setup.

To test if the table prefix is valid, WordPress executes a query deliberately trying to generate an error:

Unknown column 'wp_' in 'field list'

which means the prefix is safe to use, as the database was not able to parse it as a value.

Previously, this error would not be displayed to the user in a typical configuration, but would be logged on the server via wpdb::print_error(), and in some cases could block the installation.

This commit makes sure the error is still checked to display a proper message in case the prefix needs to be edited, but otherwise is silently discarded instead of being logged.

Follow-up to [37581], [41631], [51582].

Props pento, lazam786, Velochicdunord, irecinius, mikemanzo, dd32, blackawxs, codewhy, psykro, burgiuk, mdrago, maythamalsudany, peterwilsoncc, sumitsingh, deksar, SergeyBiryukov.
Fixes #42362.

Note: See TracTickets for help on using tickets.