WordPress.org

Make WordPress Core

Opened 12 years ago

Closed 11 years ago

#10126 closed defect (bug) (worksforme)

Warning upon saving draft page

Reported by: Beee Owned by:
Milestone: Priority: normal
Severity: normal Version: 2.8
Component: Warnings/Notices Keywords: reporter-feedback
Focuses: Cc:

Description

When I save a page as draft, I get this error.

Warning: implode() [function.implode]: Invalid arguments passed in /home/username/domains/domainname.com/public_html/wp-includes/post.php on line 1762

Attachments (3)

10126.diff (1021 bytes) - added by Denis-de-Bernardy 12 years ago.
10126.patch (1.1 KB) - added by hakre 12 years ago.
updated fix against current trunk incl. a fixme mark
10126.2.patch (1.2 KB) - added by hakre 12 years ago.
updated fix against current trunk, all params are now used in $wpdb->prepare statement

Download all attachments as: .zip

Change History (45)

#1 in reply to: ↑ description @Beee
12 years ago

When I publish it, this error comes on a white backgrounded screen

Warning: implode() [function.implode]: Invalid arguments passed in /home/allbabes/domains/all-babes.com/public_html/wp-includes/post.php on line 1762

Warning: Cannot modify header information - headers already sent by (output started at /home/allbabes/domains/all-babes.com/public_html/wp-includes/post.php:1762) in /home/allbabes/domains/all-babes.com/public_html/wp-includes/pluggable.php on line 865

#2 follow-up: @ryan
12 years ago

  • Keywords reporter-feedback added

Are you using hyperdb? If so it needs to be updated. If you're not using hyperdb, maybe wp-db.php wasn't updated properly, leaving the old version in place?

#3 @Denis-de-Bernardy
12 years ago

  • Component changed from General to Administration
  • Milestone changed from Unassigned to 2.8.1

#4 in reply to: ↑ 2 @Beee
12 years ago

Replying to ryan:

Are you using hyperdb? If so it needs to be updated. If you're not using hyperdb, maybe wp-db.php wasn't updated properly, leaving the old version in place?

Not using hyperdb and I didn't leave wp-db.php un-updated. Updated it all... 100% sure

#5 @ryan
12 years ago

Do you have a plugin that manipulates 'hierarchical_post_types'?

#6 @Denis-de-Bernardy
12 years ago

doubtful... the hook was introduced in 2.8, and barely shows up in WP:

http://www.google.com/search?q=hierarchical_post_types

#7 @ryan
12 years ago

Yeah, grasping at straws.

#8 @Beee
12 years ago

Only plugin I have (which could be related, responding to the reply above) is simply exclude to exclude pages from search results...

don't think it's related to this though...

#9 @Denis-de-Bernardy
12 years ago

  • Keywords has-patch added

sheesh... must have been really tired when we wrote that initial patch. the attached patch should fix this.

#10 @Denis-de-Bernardy
12 years ago

  • Keywords blocker added

#12 @Denis-de-Bernardy
12 years ago

  • Keywords needs-patch added; has-patch removed

bee: please check in your wp-content folder, in case there's a db.php file.

#13 @Denis-de-Bernardy
12 years ago

  • Keywords blocker removed

#14 @ryan
12 years ago

  • Milestone 2.8.1 deleted
  • Resolution set to worksforme
  • Status changed from new to closed

Closing for now since this is the only report of this and we can't reproduce. Reopen with requested feedback.

#15 @tobiasheuken
12 years ago

  • Cc tobiasheuken added
  • Milestone set to 2.8.2
  • Resolution worksforme deleted
  • Status changed from closed to reopened

#16 @Denis-de-Bernardy
12 years ago

Might you be overriding the wpdb class in your setup?

http://core.trac.wordpress.org/ticket/10126#comment:11

#17 @tobiasheuken
12 years ago

Hi Denis

??? I still updated the Blog from WP 2.7.1 -> 2.8.1

I did the following to Update the pages - after a complete backup (files + database)

  1. delete every file in the root-directory and the directorys /wp-admin/ and /wp-includes/ (without wp-config.php)
  2. Upload the new files and directorys
  3. LogIn, update database

So what do you mean with overwrite wpdb class?

By the way ... this phenomenon appears not in every blog I updated. There are differences between the webhosters. I found the error above at webhoster all-inkl.com and hosteurope.de - but not at artfiles.de.

#18 @Denis-de-Bernardy
12 years ago

can you give some precise details (server OS, apache version, mysql version, etc.) on servers that fail and those that don't?

#19 @tobiasheuken
12 years ago

it fails on:
System: Linux
PHP Version: 5.2.9
mySQL Client Version: 5.0.83
Apache API Version: 20051115

it works on:
System: Linux www3.www19.c.artfiles.de 2.6.24.2 #1 SMP Mon Feb 11 13:56:25 CET 2008 i686
PHP Version: 5.2.9
mySQL Client Version: 5.0.45
Apache Version: 1.3.34

#20 @tobiasheuken
12 years ago

I also can see this error when I install a complete NEW blog @ all-inkl.com with the latest original files / latest WP-Version which I can download from wordpress-deutschland.org

#21 @tobiasheuken
12 years ago

The same error on Website at German Hoster ProSite.de with WP 2.8.2

PHP Version 5.2.9
System: Linux w2.6.27.6 #1 SMP Tue Nov 18 11:48:02 CET 2008 i686
Server API Apache 2.0
Apache Version: Apache/2.2.11
mySQL Client API version 5.0.41

#22 @scribu
12 years ago

  • Keywords draft page warning reporter-feedback removed

#23 @janeforshort
12 years ago

  • Milestone changed from 2.9 to Future Release

Four months with no reproduction, punting.

#24 @ravetildon
12 years ago

  • Cc ravetildon added

I am also getting this error.

I believe it happened when a person tried to publish a post, but the post didn't publish due to heavy server load.

They then hit reload to this page multiple times:

www.example.com/wp-admin/post.php

After that the blog is unable to post new articles or pages.

Also all the "pages" (not "posts") had the post slug (the one they tried to publish when server was under load) inserted into every page slug.

Any help to you? Any ideas?

#25 @subvii
12 years ago

I saw this error as soon as I installed but fixed using instructions here http://wordpress.org/support/topic/289261.
Still see error on upgrading to 2.9 but now error on line 1980

PHP 5.2.6, FreeBSD 6.2-RELEASE, Apache 2.2.3

#26 @subvii
12 years ago

Debugged the problem down (at least for me) to sqlite plugin. The pdo/db.php function escape($string) does not cope with arrays. Commenting it out, so original function is used seems to fix it.

#27 @ravetildon
12 years ago

I ended up just reinstalling wordpress and re-inputting posts...

Couldn't figure out where the bad characters in the database were coming from...

#28 follow-up: @hakre
12 years ago

  • Milestone changed from Future Release to 3.0

Just reviewed. The original patch author was right: $hierarchical_post_types is actually an array. currently it is passed to esc_sql (line 1980) which only accepts strings. This needs to be fixed. I create an updated patch.

@hakre
12 years ago

updated fix against current trunk incl. a fixme mark

@hakre
12 years ago

updated fix against current trunk, all params are now used in $wpdb->prepare statement

#29 @hakre
12 years ago

last patch better reflects $wpdb->prepare usage as it should according to wordpress coding guidelines.

#30 @scribu
12 years ago

  • Keywords has-patch added; needs-patch removed

#31 @Denis-de-Bernardy
12 years ago

in the second patch, %%s is a typo, no?

#32 @dd32
12 years ago

  • Keywords needs-patch added; has-patch removed

in the second patch, %%s is a typo, no?

..No, That'd be because of the crazy sprintf there...

I'm also warey about the loss of $post_ID and $post_parent in the query by the look of it.

needs-patch simply for the sprintf, and the loss of WHERE

#33 in reply to: ↑ 28 @dd32
12 years ago

Replying to hakre:

Just reviewed. The original patch author was right: $hierarchical_post_types is actually an array. currently it is passed to esc_sql (line 1980) which only accepts strings. This needs to be fixed. I create an updated patch.

Just rechecked that for you.. esc_sql() uses $wpdb->escape, And like Ryan posted higher in the thread, Handles arrays.

The entire reason for the warning, will be that $hierarchical_post_types was not an array, Now, For whatever reason that is, It shouldnt be happening.. so escaping will not help here.

#34 @hakre
12 years ago

I think my patch is broken. I'll update it.

#35 @hakre
12 years ago

I do not see a problem with the patch after another review (maybe hard to read because of having sprintf() and then ->prepare()). what do you mean with "escaping will not help here" ?

and what about the loss of $post_ID and $post_parent? Those are passed as parameter to ->prepare():

$params    = array( $slug, $post_ID, $post_parent ) + $hierarchical_post_types;
...
$post_name_check = $wpdb->get_var($wpdb->prepare($check_sql, $params)); 
}}}}

#36 @hakre
12 years ago

  • Keywords has-patch added; needs-patch removed

#37 @dd32
12 years ago

  • Keywords needs-patch added; has-patch removed

what do you mean with "escaping will not help here"

Quite simply, The error is BEFORE the database is brought into it, You can escape all you want, But the simple fact is, implode() is not being given an array, thus the Warning.

Warning: implode() [function.implode]: Invalid arguments passed in /home/username/domains/domainname.com/public_html/wp-includes/post.php on line 1762

Well.. Looking at it closer, You're right it -could- be due to escaping, if someones Database class was not updated to support arrays in wpdb::escape() - Which was done in 2.8. Again, something WordPress cannot support.

and what about the loss of $post_ID and $post_parent? Those are passed as parameter to ->prepare():

They're passed to prepare() but they're not used anywhere. You cant just pass params to prepare() and expect it to apply them to the query if there are no placeholders for them.

The query will end up like this if under a default configuration

'SELECT post_name FROM $wpdb->posts WHERE post_name = %s AND post_type IN ('<POST_ID_HERE>');

maybe hard to read because of having sprintf() and then ->prepare()

Yes, It makes utterly no sense to use sprintf(), This is the common form in WordPress and is readable:

$check_sql = "SELECT post_name FROM $wpdb->posts WHERE post_name = %s AND post_type IN ($pattern)";

using sprintf to insert them into the phrase gives no benefit, other than making it hard for people to read.

I'm all for converting it over to prepare(), But please test the function's output is the same as before, using the edge cases. The patches here will NOT pass that test - And will only work around the original problem, not solve it.

#38 @Denis-de-Bernardy
12 years ago

  • Component changed from Administration to Warnings/Notices

#39 @nacin
12 years ago

After re-reading the thread, have we actually confirmed that this happens on an install not using a db.php drop-in?

#40 @nacin
11 years ago

  • Keywords reporter-feedback added
  • Milestone changed from 3.0 to Future Release

#41 @solarissmoke
11 years ago

  • Keywords needs-patch removed

#42 @scribu
11 years ago

  • Milestone Future Release deleted
  • Resolution set to worksforme
  • Status changed from reopened to closed

*crickets* for almost a year.

Feel free to re-open with more details.

Note: See TracTickets for help on using tickets.