Warning upon saving draft page

[Beee]

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

[Beee]

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

[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?

[Beee]

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

[ryan]

Do you have a plugin that manipulates 'hierarchical_post_types'?

[Denis-de-Bernardy]

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

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

[ryan]

Yeah, grasping at straws.

[Beee]

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...

[Denis-de-Bernardy]

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

[ryan]

escape() should handle arrays.

​http://core.trac.wordpress.org/browser/tags/2.8/wp-includes/wp-db.php#L478

[Denis-de-Bernardy]

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

[ryan]

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

[tobiasheuken]

The problem is still there with the latest Version 2.8.1

-> ​http://forum.wordpress-deutschland.org/installation/55007-fehlermeldung-wp-includes-post-php-line-1762-a.html

-> ​http://wordpress.org/support/topic/289261

[Denis-de-Bernardy]

Might you be overriding the wpdb class in your setup?

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

[tobiasheuken]

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.

[Denis-de-Bernardy]

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

[tobiasheuken]

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

[tobiasheuken]

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

[tobiasheuken]

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

[janeforshort]

Four months with no reproduction, punting.

[ravetildon]

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?

[subvii]

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

[subvii]

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.

[ravetildon]

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

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

[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.

[hakre]

updated fix against current trunk incl. a fixme mark

[hakre]

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

[hakre]

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

[Denis-de-Bernardy]

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

[dd32]

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

[dd32]

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.

[hakre]

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

[hakre]

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)); 
}}}}

[dd32]

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.

[nacin]

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

[scribu]

*crickets* for almost a year.

Feel free to re-open with more details.