WordPress.org

Ready to get started?Download WordPress

Forums

strpos(): Empty delimiter (15 posts)

  1. Inposure
    Member
    Posted 2 years ago #

    After 3.3 update, I see the following warning in the logs:

    PHP Warning: strpos(): Empty delimiter in /var/www/***/wp-includes/user.php on line 699, referer: http://***/wp-admin/index.php

    Line 699 says:

    if ( 0 !== strpos( $key, $wpdb->base_prefix ) )

    Right, I have no DB prefix. Therefore, this seems to be a minor bug with WordPress itself.

  2. esmi
    Forum Moderator
    Posted 2 years ago #

    Try:
    - switching to the Twenty Eleven theme by renaming your current theme's folder in wp-content/themes and adding "-old" to the end of the folder name using FTP or whatever file management application your host provides.

    - resetting the plugins folder by FTP or phpMyAdmin.

    - re-uploading all files & folders - except the wp-content folder - from a fresh download of WordPress.

    - re-running the upgrade via wp-admin/upgrade.php

  3. trypgirl
    Member
    Posted 2 years ago #

    Arrrrghhh. I am getting this same error. I am running multisite and all this redo would be an extreme hassle for each of the domains. Has anybody else come up with other solutions?

    Oh, and to make it more fun, not all sites are returning the error. Just some. The only thing unique is the themes. though I do get the error on the dashboard of the network admin.

  4. esmi
    Forum Moderator
    Posted 2 years ago #

    @trypgirl: It is considered impolite to interrupt another poster's thread. Please post a new topic.

  5. trypgirl
    Member
    Posted 2 years ago #

    @esmi

    It wasn't my intention to interrupt. I am having the same issue and wanted to add detail in order to facilitate problem solving. I will start my own thread and if I find a solution post it back here as a link in a comment.

  6. jk3us
    Member
    Posted 2 years ago #

    changing line 699 of that file from

    if ( 0 !== strpos( $key, $wpdb->base_prefix ) )
           continue;

    to

    if ( strlen($wp->base_prefix) && 0 !== strpos( $key, $wpdb->base_prefix ) )
           continue;

    makes the error go away, but I'm not sure if it changes the behavior of this section, since I'm not familiar enough with what this bit of code is doing. (I'm not sure if an empty prefix should trigger that continue or not.)

    Edit: It seems like this portion of code is also causing this problem, if that helps in troubleshooting.

  7. Inposure
    Member
    Posted 2 years ago #

    Ditto, I am also on a mulstisite install, and just regained my site listing in the admin panel after manually changing the code snippet.

    However, that is a hack, not a fix; it will be gone by the next update unless WordPress acknowledges that this is a bug and that it has nothing to do with plugins or themes.

  8. jk3us
    Member
    Posted 2 years ago #

    Here is the change that introduced the problem. Before, they were effectively doing what I suggested above, checking the strlen of the prefix before trying that match.

    I've left a comment on the ticket that seems to have introduced the problem.

  9. Andrew Nacin
    Lead Developer
    Posted 2 years ago #

    An empty database prefix is not supported.

  10. Andrew Nacin
    Lead Developer
    Posted 2 years ago #

    An empty database prefix is not supported.

    If you'd like, a new ticket could be opened to suggest support for it, but we use prefixes in interesting ways, and I doubt compatibility could be uniform.

  11. jk3us
    Member
    Posted 2 years ago #

    yikes. That should be in the wp-config-sample.php file. It says "You can have multiple installations in one database if you give each a unique
    prefix." I assumed that since I didn't intend to run multiple installations in the same database I could safely use an empty prefix.

    It looks like a couple years ago some work was done to support empty prefixes, why was that dropped?

    Edit: Also, I've been using the empty prefix for quite some time, and until now have never experienced a problem (that I've noticed).

  12. Inposure
    Member
    Posted 2 years ago #

    Well, if it works, why not break it? After all, you get fly-out menus instead of speed and stability…

  13. jk3us
    Member
    Posted 2 years ago #

    since wordpress "uses prefixes in interesting ways" is it safe to simply rename all my tables with a prefix and set that in wp-config.php, or will those interesting ways cause problems with my new prefix?

  14. Inposure
    Member
    Posted 2 years ago #

    No, that will kill your site immediately. You need to add a prefix (other than wp_, something more secure) to a) all tables, b) fields in the options table, c) fields in the usermeta table.

    a) is straightforward, but in b) and c) fields don't necessarily have any prefixes attached to them. How are you supposed to know which ones to change?

    When I installed Wördpress (without frakking camelcase) years ago, there was NO information saying that an empty prefix was ”not supported”, and if it indeed were not supported it shouldn't even be allowed to proceed with an empty field; that's BAD programming.

    If this later changes, Wördpress needs to accomodate for this by adding a prefix automatically when upgrading. You can't just leave your users in the dark because you can't program properly. This is pure evil.

  15. Andrew Nacin
    Lead Developer
    Posted 2 years ago #

    You can't just leave your users in the dark because you can't program properly. This is pure evil.

    We're not evil, no. We restored "support" for empty database prefixes in 3.3.1. And we'll begin to prevent installations from occurring when an empty prefix is defined in 3.4.

Topic Closed

This topic has been closed to new replies.

About this Topic

Tags

No tags yet.