WordPress.org

1. trypgirl
   Member
   Posted 1 year ago #
   

   I have a WP multi-site installed and I am getting this error on my network admin dashboard, and on several of the sites on the network but not all of them.

   This is the error:
   Warning: strpos() [function.strpos]: Empty delimiter in /home/rachelsa/public_html/wp-includes/user.php on line 699

   Here are a few examples where I am getting a variety of errors:

   Error: rachelsadd.com
   Error: benshadis.com

   No error on site:
   http://thecraftyavenger.com/
   http://createdb.rachelsadd.com/

   Here is another example of errors I am getting:
   No error on site: springsuperheroes.org
   When I go the the wp-admin page and try to log in I get this after submitting my user name and password:

   Warning: strpos() [function.strpos]: Empty delimiter in /home/rachelsa/public_html/wp-includes/user.php on line 699

   Warning: Cannot modify header information - headers already sent by (output started at /home/rachelsa/public_html/wp-includes/user.php:699) in /home/rachelsa/public_html/wp-includes/pluggable.php on line 866

   I know folks have had similar troubles.

   Does anybody have a clue on the fix for this?

2. Samuel Wood (Otto)
   Tech Ninja
   Posted 1 year ago #
   

   Not that this fixes the problem per-se, but your site should be configured to have PHP's display_errors set to off, so you won't see warnings and such like this.

3. trypgirl
   Member
   Posted 1 year ago #
   

   I had turned it on so that the error was showing without me having to take a bunch of screen shots and share it here. Thanks though.

   Oh, when I try to add a new user I get errors as well.. but then it adds the user.

4. Ipstenu (Mika Epstein)
   Half-Elf Support Rogue & Mod
   Posted 1 year ago #
   

   What plugins are you running?

5. Ryan Marks
   Member
   Posted 1 year ago #
   

   I have this problem as well. Thinking it was a plugin or multiuser, I have disabled all plugins
   user@server [/home/user/public_html/wp-content]# mv plugins plugins_off
   and disabled sunrise
   user@server [/home/user/public_html/wp-content]# mv sunrise.php ~/.
   but I still have the error.

6. jk3us
   Member
   Posted 1 year ago #
   

   You can either change line 699 as described here or just comment those lines out. I'm not sure what the side effects of either of those changes would be, but commenting them out seems to fix both of the problems linked to.

7. trypgirl
   Member
   Posted 1 year ago #
   

   @Ipstenu
   I am running Akismet, Custom Post Type UI, Search Everything, WP Importer, and WP MU Domain Mapping

   Though my host just restored me to the previous version of WP. A momentary fix until some solutions can be road tested.

   Also will need to test with WP ecommerce / gold cart plugin.

   @jk3us
   Thank you very much.

8. jk3us
   Member
   Posted 1 year ago #
   

   @trypgirl, In another thread, one of the devs is saying that empty db prefixes aren't supported. So, unless someone changes their mind, all of us that have used empty db prefixes without a problem until now may have to rename all of our wordpress db tables with a prefix.

9. Ipstenu (Mika Epstein)
   Half-Elf Support Rogue & Mod
   Posted 1 year ago #
   

   What's your database prefix?

   I mean, mine's wp_ which is pretty normal. What did you make yours?

10. Ryan Marks
    Member
    Posted 1 year ago #
    

    Since I had unlimited databases available to me, I created database that would be dedicated to WordPRess and set the table_prefix to be blank. So, instead of having tables like wp_posts and wp_users, I just have posts and users.

11. Ipstenu (Mika Epstein)
    Half-Elf Support Rogue & Mod
    Posted 1 year ago #
    

    Yeah, that'd do it, RMarks.

    WordPress really shouldn't let you have a blank table_prefix like that, it can cause problems (and IIRC, Nacin said it's not supported).

    I want to say you can just go in and rename your tables and add it into the wp_config.php, but I don't know if any plugins have weird things coded... They SHOULDN'T.

12. jk3us
    Member
    Posted 1 year ago #
    

    According to liangzai's comment, this would mess up a bunch of other things as well. I'm not going to try it until I hear success stories from others :) I'll just stick with the change in the code that fixes the problem for now.

13. Ipstenu (Mika Epstein)
    Half-Elf Support Rogue & Mod
    Posted 1 year ago #
    

    *sigh* Yeah, I'm not surprised.

14. trypgirl
    Member
    Posted 1 year ago #
    

    I had a little bit of a back and forth with the folks at my hosting company (psek.com) who so graciously restored me back to the previous version of WP.

    @Ipstenu My db prefix was pretty straight up and per-determined by my hosting company as they specialize in WPMU. According to them a basic db prefix doesn't repair the later generated tables from plugins that didn't have prefixes... grrrrr.

    The prefix, they are talking about, is WP option, if you want to change/add it you'll need to modify your WP configuration and database tables manually. Better to wait for the new WP release/patch where this problem will be fixed.

    I am not holding my breath for the patch but fairly disappointed in WP development for I think the first time.

15. Ipstenu (Mika Epstein)
    Half-Elf Support Rogue & Mod
    Posted 1 year ago #
    

    Given how few people are having this issue, it's somewhat unfair of you to fault a development process that wasn't able to test everything for everyone. This doesn't mean it can't be improved, but if you look at the volume of people who use WordPress multisite, and then the number who're having issues, the perspective shifts a little.

    Problems happen with all upgrades, server or desktop, webapp or not. They just do, because it is mathematically impossible to be perfect. Every install of WordPress is different, and every sever is different. Even a cloned server is different. This is just one of the frustrating constants of life: nothign is perfect.

    Now all that said, none of that is an excuse for anything. It's just an attempt at explaining WHY things happen.

    I've opened a ticket with WordPress trac - http://core.trac.wordpress.org/ticket/19566 - to either nanny-gate this (and flatly make NO prefix not permissible) or fix it. As Andrew Nacin (one of the core developers said), NO prefix isn't supported, so it may not be possible to fix it past making that manual edit in core (and god knows I hate saying that).

    I would do this.

    Make a duplicate of your database.
    On that dupe, rename all the tables to have wp_<tablename> in them.
    Then copy your wp-config.php file to have a good backup.
    Edit your real wp-config.php file, and change your prefix to wp_ and point to that new database.

    If it doesn't work, you can fail back quickly.

Topic Closed

This topic has been closed to new replies.