WordPress.org

Make WordPress Core

Opened 6 years ago

Closed 6 years ago

Last modified 6 years ago

#11083 closed defect (bug) (fixed)

wp_posts.post_name gets too long to save in DB, after repeated updates

Reported by: knutsp Owned by:
Milestone: 2.9 Priority: normal
Severity: normal Version: 2.8.5
Component: Administration Keywords:
Focuses: Cc:

Description

When the post_name is generated the post_name field is an url encoded evrsion om the same string, with some exceptions (like a space translates to a dash). So far so good.

But for every save of a post this string is increased in length with more and more such %nn substrings. Example: hello-%73%23%54%10

In the end the field gets too long to save in the database, and the save fails.

Also: When the default permalink structure is used this behaviour cannot be seen or crrected in the edit post page, but may bee seen and corrected when using Quik Edit, if one is aware of this bug.

Some of the users I serve have some private posts for internal use, which they update up to one hundred times over a period . They complain that ther changes no longer gets saved. And their titles often consists of Scandinavian characters (ÆØÅ) and slashes.

  1. The post_name must not grow in length for each update
  1. When the post_name is too long for the DB to handel, it should be truncated to avoid DB errors.
  1. When a DB error occurs the users should be warned that the post, or any object for that matter, for some reason, was NOT saved. This does not happen in this case, at least.

(This my first bug report to this community)

Change History (6)

comment:1 @scribu6 years ago

Welcome. Pretty neat reporting.

I'll try to make a patch that fixes at least nr. 2.

comment:2 @scribu6 years ago

  • Keywords reporter-feedback added; post_name save removed

Can't seem to reproduce.

Please update to a nightly build (using the WP Beta Tester plugin) and see if the problem persists.

If it does, please provide an example string that is causing the problem.

comment:3 @scribu6 years ago

I tried the string you mentioned hello-%73%23%54%10 and nothing changes when I repeatedly update the post.

comment:4 @knutsp6 years ago

Installed WordPress 2.9 and I can no longer reproduce this behaviour (growth, the main reported bug).

Details:

Version 2.8.5: The character ø (o-with-slash) gets encoded to %c3%b8 in the first save. The next save encodes %c3%b8 to %25c3%25b8 (as you can see the %-sign gets re-encoded.

Version 2.9: The character ø (o-with-slash) gets encoded to %c3%b8 in the first save. The next save keeps %c3%b8 with no additional encoding.

It seems fixed nicely. Before submitting, I tried to do a search for tickets addressing such an issue, but could not find any.

But there may still be situations where this field, or a field, is allowed to grow, by applying encoding/escaping for "illegal" characters. Stings longer than the database defined maximum length should not be allowed to enter a SQL INSERT or SQL UPDATE. At least as long as such exceptions are not handeled properly.

May be close this an open another ticket when the second issue is investigated further. I have no idea on the what checks are made on string lengths, inside or outside $wpdb or other classes/functions.

The third issue (no error message on failed save) seems to me to be quite serious.

I leave it up to you how to close, split or re-summarize this ticket, according to best practices here.

comment:5 @scribu6 years ago

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

In WP 2.9, wp_insert_post() does throw a WP_Error if the query fails.

Closing this as fixed.

comment:6 @scribu6 years ago

  • Keywords reporter-feedback removed
Note: See TracTickets for help on using tickets.