Make WordPress Core

Opened 11 years ago

Closed 11 years ago

#4597 closed defect (bug) (fixed)

Change require to require_once for db.php

Reported by: intoxination Owned by:
Milestone: 2.3 Priority: normal
Severity: normal Version: 2.2.1
Component: General Keywords: has-patch wp-settings database dev-reviewed commit
Focuses: Cc:


If wp-content/db.php is found, it is just required, instead of require_once. This can cause problems in some versions of PHP 5.2.X on different OS. Patch attached

Attachments (1)

5790.diff (603 bytes) - added by intoxination 11 years ago.

Download all attachments as: .zip

Change History (8)

11 years ago

#1 @westi
11 years ago

While this change looks good and sensible could you give more details of the problem that not making this change causes.

The bug description is very vague and lacking in details of the actual problem.

#2 @intoxination
11 years ago

Sure - (it has been a nightmare). We have 2 sites running on a 8 core XServer OSX with Apache 2.2.4 and PHP 5.2.3 W/Eaccelerator. We are also using the HyperDB class. At very random times, the site would start giving blank pages. No error, no return header, no nothing. It happened to different users on different browsers and different pags (ie: the front page would be fine. The single post page would be fine in IE7, but in FF it would not show, until you clear the cookies out for commenting - no login cookies. In Opera it would give a connection refused).

I ended up installing WP 2.2.1 on a new sub-domain on the machine and left everything at default. It wouldn't act up. After a couple of days, I added HyperDB back in. Problem pops-up.

Thinking it was something with HyperDB, I replicated everything on my home Ubuntu box (including updating PHP and Apache to the same versions plus adding Eaccelerator). Everything continued to work fine. I even simulated load using siege along with AB. Still fine.

Finally we turned off EAccelerator on the main server. We then started getting "can not redeclare class WPDB" errors every couple of hundred hits or so (we are talking one site that does 300,000+ page views a day and another that averages close to 100,000 page views a day so these errors popped up every 5 -15 minutes or so). These would also appear on various pages (and even on /wp-admin/index.php and once on wp-cron.php).

Back to my test box. I killed Eaccelerator, ran back through thousands of hits with siege and AB simulating commenting, reading different pages, etc. The error never happened.

I changed the require to require_once and so far it has been running 36 hours with no problem.

So it appears to be something happening in OSx running PHP 5.2.3. I know they had similar problems in 5.2.2 that were supposed to be fixed in 5.2.3. It looks like a bug still got through. I want to do more testing and nail it down more to make sure of this. It sucks that it happens so randomly. I would install XDebug and trace everything, but since there can be a couple thousand hits before the problem, it would be a nightmare to find as well as a huge hit on the hard drive hehe.

I know the description is long, but not nearly as long as the past 2 weeks have been trying to find this LOL.

#3 @markjaquith
11 years ago

I've found that opcode cache solutions tend to produce issues when classes are declared conditionally. WP-Cache and APC have some strange interactions because of that.

#4 @intoxination
11 years ago

Any chance of getting such a minor patch into 2.3?

#5 @westi
11 years ago

  • Keywords dev-reviewed added


I don't see why not

#6 @markjaquith
11 years ago

  • Keywords commit added

I have no objection.

#7 @westi
11 years ago

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

(In [6017]) Switch to require_once for wp-includes/db.php when it exists. Fixes #4597 props intoxination.

Note: See TracTickets for help on using tickets.