How to duplicate the bug:
Go to your user account
Change your status
Without reloading the whole page, change the status again.

What happens:
The status will save as expected the 1st time but if you decide to change your status again the 2nd time without leaving your page then the changes won't save anymore. You can only change the status when you reload the whole page again.

Comments

icecreamyou’s picture

Status: Active » Postponed (maintainer needs more info)

I can't duplicate the issue.

  • Is JS turned on in your browser?
  • Is the Slide Effect enabled in your settings?
  • Is Legacy Mode enabled for user profiles?
  • Is the user you're trying this with allowed to have a status?
  • What are the permissions of the user you're trying this with?
  • What version of PHP and what version and type of SQL are you using?
  • Do you have the status update block enabled anywhere on the page?
  • What browser are you using?
  • Does it work anywhere else?
  • What level of caching do you have, both in your Drupal installation and in your browser?
  • Do you have any version of JQuery Update installed?
  • Is this an upgrade of FBSS or a new installation?
  • What exactly is happening here? Does it not save into the database or does it just not update? When you refresh the page, does the edited status appear or the first one?

If a status is updated within 12 seconds of the previous status update by the same user, it's supposed to overwrite the old status. My first guess on this one is that you're using PGSQL and the UPDATE statement isn't working.

johnnoc’s picture

  • Is JS turned on in your browser?
    Yes. Javascript is turned on.
  • Is the Slide Effect enabled in your settings?
    Yes....but slide effect doesn't work in user pages, right?
  • Is Legacy Mode enabled for user profiles?
    Yes
  • Is the user you're trying this with allowed to have a status?
    tested with UID 1 and 2 normal registered users with proper permissions.
  • What are the permissions of the user you're trying this with?
    UID 1 - All permissions | 2 different Registered users - Edit own, View all
  • What version of PHP and what version and type of SQL are you using?
    PHP 5.2.8, MySQL 5.1.30
  • Do you have the status update block enabled anywhere on the page?
    Nope. just using the user profile
  • What browser are you using?
    Tested on Safari, Chrome, IE8, and Opera
  • Does it work anywhere else?
    Nope
  • What level of caching do you have, both in your Drupal installation and in your browser?
    Drupal - no caching enabled. Browser - browser default for all the 4 browsers
  • Do you have any version of JQuery Update installed?
    D6.10 default
  • Is this an upgrade of FBSS or a new installation?
    Upgrade from the 6.x-1.0 to 2.0-beta1
  • What exactly is happening here? Does it not save into the database or does it just not update? When you refresh the page, does the edited status appear or the first one?
    Only the first one, even on refreshing the page.

I don't know if it matters .. I have css overridden. ..#edit-status-wrapper has extra padding on the top. #edit-fbss-submit is also styled...using also a custom profile page. there wa no problem with the same set-up with 6.x-1.0

I'll try to completely uninstall and reinstall...let's see.

icecreamyou’s picture

That's really weird. Do you happen to know what OS is on your server perhaps? I have a very similar setup and I'm not getting this problem at all. I would guess it was a database upgrade problem except that it's saving properly the first time apparently... does it work if you wait 12 seconds between saves?

There's also a remote possibility that I committed the wrong files to beta. I'll try to get a new setup locally and I'll also try to ask some other people if they've had this issue.

Also, have you run update.php? That's a critical upgrade step.

johnnoc’s picture

Taken from the admin/reports/status page... Webserver: Apache/2.2.11 (Unix) mod_ssl/2.2.11 OpenSSL/0.9.8i DAV/2 mod_auth_passthrough/2.1 mod_bwlimited/1.4 FrontPage/5.0.2.2635

No, it doesn't save even after 12 seconds between saves.

Update.php when upgrade from 6.x-1.0 to 2.0-beta1?... of course :-)

Uninstalled, deleted cache, reinstalled 2.0-beta1. unfortunately, same problem. Dunno if it matters but strings are translated....but I tested it also with english then it's the same :-(

I can send you via contact form the details for a demo user account of the dev site, if you wish to test as a registered user.

icecreamyou’s picture

That would probably be a good idea. I simply cannot duplicate the issue; I've reinstalled from CVS and everything.

johnnoc’s picture

Message sent.

It seems that the bug is in the settings /variables table. I can change the width of the status update textfield in the admin/settings/facebook_status page but it does not take effect on the profile page itself.

icecreamyou’s picture

No, that's intentional. See http://drupal.org/node/421336 under "Hidden Options."

I looked at your site and I still have no idea what's going on. I'm inclined to say it could be a problem with some of the mods you have enabled on PHP that may conflict with Drupal's AHAH capabilities since nothing else seems to come up. Where is this site hosted?

Do you get any log errors? Can you look at the {facebook_status} table in your database and tell me if you see anything unusual, like statuses owned by the anonymous user for example?

Try putting this line after both lines 737 and 738 in facebook_status.module (so it should be there twice):

drupal_set_message('$new_status: '. print_r($new_status, TRUE) .' --- $account->uid: '. print_r($account->uid, TRUE), 'error');

Then try saving a new status twice and let me know what error messages you get.

icecreamyou’s picture

I have this module running on two sites that are set up almost identically and one of them spontaneously developed this problem even though I didn't make any changes that should have affected it--unless there is a conflict with a module I upgraded recently. I know that admin_menu had a problem with devel 1.16 but this issue didn't seem to go away when I disabled devel even though that seemed like a likely culprit... unfortunately I still have no idea what would be causing this but I will look into it as soon as I get time.

By the way, I recently moved hidden options to a new "Advanced" settings page - that change should be in dev.

icecreamyou’s picture

Assigned: Unassigned » icecreamyou
Status: Postponed (maintainer needs more info) » Needs work

Well, I finally figured out what the problem is: the form isn't getting cached in some configurations, and the AHAH must pull the form from the cache in order to process it. Setting $form['#cache'] = TRUE; doesn't seem to be fixing it at the moment, but I will continue to look into this and hopefully I will have a fix sometime next week. This week is going to be too busy for me to get anything done on this module.

icecreamyou’s picture

Version: 6.x-2.0-beta1 » 6.x-2.x-dev
Status: Needs work » Fixed

Fixed in dev (thanks katbailey).

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.