WordPress.org

Make WordPress Core

Opened 5 years ago

Closed 3 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 5 years ago.
10126.patch (1.1 KB) - added by hakre 4 years ago.
updated fix against current trunk incl. a fixme mark
10126.2.patch (1.2 KB) - added by hakre 4 years ago.
updated fix against current trunk, all params are now used in $wpdb->prepare statement

Download all attachments as: .zip

Change History (45)

comment:1 in reply to: ↑ description Beee5 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

comment:2 follow-up: ryan5 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?

comment:3 Denis-de-Bernardy5 years ago

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

comment:4 in reply to: ↑ 2 Beee5 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

comment:5 ryan5 years ago

Do you have a plugin that manipulates 'hierarchical_post_types'?

comment:6 Denis-de-Bernardy5 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

comment:7 ryan5 years ago

Yeah, grasping at straws.

comment:8 Beee5 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...

Denis-de-Bernardy5 years ago

comment:9 Denis-de-Bernardy5 years ago

  • Keywords has-patch added

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

comment:10 Denis-de-Bernardy5 years ago

  • Keywords blocker added

comment:12 Denis-de-Bernardy5 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.

comment:13 Denis-de-Bernardy5 years ago

  • Keywords blocker removed

comment:14 ryan5 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.

comment:15 tobiasheuken5 years ago

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

comment:16 Denis-de-Bernardy5 years ago

Might you be overriding the wpdb class in your setup?

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

comment:17 tobiasheuken5 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.

comment:18 Denis-de-Bernardy5 years ago

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

comment:19 tobiasheuken5 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

comment:20 tobiasheuken5 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

comment:21 tobiasheuken5 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

comment:22 scribu5 years ago

  • Keywords draft page warning reporter-feedback removed

comment:23 janeforshort4 years ago

  • Milestone changed from 2.9 to Future Release

Four months with no reproduction, punting.

comment:24 ravetildon4 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?

comment:25 subvii4 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

comment:26 subvii4 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.

comment:27 ravetildon4 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...

comment:28 follow-up: hakre4 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.

hakre4 years ago

updated fix against current trunk incl. a fixme mark

hakre4 years ago

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

comment:29 hakre4 years ago

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

comment:30 scribu4 years ago

  • Keywords has-patch added; needs-patch removed

comment:31 Denis-de-Bernardy4 years ago

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

comment:32 dd324 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

comment:33 in reply to: ↑ 28 dd324 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.

comment:34 hakre4 years ago

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

comment:35 hakre4 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)); 
}}}}

comment:36 hakre4 years ago

  • Keywords has-patch added; needs-patch removed

comment:37 dd324 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.

comment:38 Denis-de-Bernardy4 years ago

  • Component changed from Administration to Warnings/Notices

comment:39 nacin4 years ago

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

comment:40 nacin4 years ago

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

comment:41 solarissmoke3 years ago

  • Keywords needs-patch removed

comment:42 scribu3 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.