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
Comment #1
icecreamyou commentedI can't duplicate the issue.
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.
Comment #2
johnnocYes. Javascript is turned on.
Yes....but slide effect doesn't work in user pages, right?
Yes
tested with UID 1 and 2 normal registered users with proper permissions.
UID 1 - All permissions | 2 different Registered users - Edit own, View all
PHP 5.2.8, MySQL 5.1.30
Nope. just using the user profile
Tested on Safari, Chrome, IE8, and Opera
Nope
Drupal - no caching enabled. Browser - browser default for all the 4 browsers
D6.10 default
Upgrade from the 6.x-1.0 to 2.0-beta1
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.
Comment #3
icecreamyou commentedThat'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.
Comment #4
johnnocTaken 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.
Comment #5
icecreamyou commentedThat would probably be a good idea. I simply cannot duplicate the issue; I've reinstalled from CVS and everything.
Comment #6
johnnocMessage 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.
Comment #7
icecreamyou commentedNo, 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):
Then try saving a new status twice and let me know what error messages you get.
Comment #8
icecreamyou commentedI 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.
Comment #9
icecreamyou commentedWell, 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.Comment #10
icecreamyou commentedFixed in dev (thanks katbailey).