Closed (fixed)
Project:
Facebook-style Statuses Comments
Version:
6.x-1.x-dev
Component:
Miscellaneous
Priority:
Critical
Category:
Bug report
Assigned:
Reporter:
Created:
10 Feb 2010 at 21:00 UTC
Updated:
20 May 2010 at 02:40 UTC
Jump to comment: Most recent file
Comments
Comment #1
icecreamyou commentedAs the module's page and the download notes clearly say,
Your problem may also be related to #709996: Status entries disappear when fbssc is enabled.
Also see the Troubleshooting guide here
Comment #2
Gyt commentedI have this problem too. When I submit status and there are some statuses on profile page this message appears (see screenshots). I think, it happens, because main status form includes comment forms. The only solution I can see is to disable ajax in status form and separate facebook_status view from it. Or to delete comment forms on profile pages :)
And yes, I use last 6.x-2.x-dev version of Facebook-style Statuses module and check all versions of fbssc.
Comment #3
baff commented>> clearly say,
>> This module should only be used with the latest dev of FBSS or a version released after 4
>> February2010!
Thank you very much for your friendlyness!
I have tried all versions, including the latest ones ...
Comment #4
icecreamyou commentedI was finally able to reproduce this, but only in Internet Explorer. Is that the browser you all are using?
I don't have any idea what is causing this and I'm going to be AFK for a week starting tomorrow morning, but I will look into this when I get back.
Comment #5
Gyt commentedIt's "form in form" problem. Comment forms located inside the status form. The error appears only in Opera and Internet Explorer, but it's definitely wrong use of "form" tag.
Also I can't comment the first status on profile page. This related error appears in all browsers.
Comment #6
milktin commentedSame problem;
yes, only in Internet Explorer. (no problem in FireFox)
Comment #7
icecreamyou commentedAh, okay. Thanks, Gyt, for identifying the cause of the problem; it would have taken me forever otherwise. I'm not sure if there is a solution to this. I'll have to think hard about workarounds.
Comment #8
icecreamyou commentedMarked #718262: Comment field disappears after submit. Content Profile, Panel, and comment (ajax) as duplicate because I'm fairly sure that bug exists for the same reason.
Comment #9
icecreamyou commentedChanging title to something more descriptive.
Comment #10
pribeh commentedThanks for linking here IceCreamYou. This appears to be virtually the same problem as what I'm currently experiencing using FBSS to load an Activity 2.x view with Activity comments. The very first comment loads inside a duplicate FBSS status form after examining the html/javascript.
Related issue is here: http://drupal.org/node/732966#comment-2852644
Comment #11
icecreamyou commentedAn update: thanks to pribeh's support I'm now part of the way through fixing this issue. The approach I'm taking is to move views out of the form itself, and update them via AJAX when the status update form is submitted. This allows the updated view to be anywhere on the page (and actually, allows any part of the page to be refreshed when the status is submitted). It's currently working the first time a status is submitted after a full page load, except that the Drupal.behaviors aren't getting re-attached. While completing this fix isn't trivial, I just wanted to update here to say that the fix is not particularly far away.
Comment #12
icecreamyou commentedAnother update: I've fixed most of the problems I was encountering before. The one main remaining problem is due to a feature-that-is-really-a-bug in Drupal core where settings passed from PHP to JS get combined into arrays if they are set in multiple places. This shouldn't be terribly difficult to solve however and I expect that once it's finished, anything on the page should easily be able to be refreshed when a status is submitted. (Views attached to status update forms will refresh automatically, and other parts of the page should be able to be refreshed with only a few lines of code.)
I have a lot of "real world" work to do today so it's looking unlikely that I'll get a chance to work on this tonight. However, I'm hoping to finish it sometime this week.
Comment #13
hugafish commentedsubscribing
Comment #14
icecreamyou commentedThe attached patch is against Facebook-style Statuses dev (not FBSSC). It basically works -- or at least, it's working for me -- but there are some weird things going on with attached behaviors. Essentially, most behaviors get attached twice, which is particularly problematic for Views paging. For some reason this also means that "undefined" elements keep getting appended to the refreshIDs array, which doesn't actually cause noticeable problems but could theoretically take up a lot of the client's memory if hundreds of statuses were submitted without refreshing the window.
The idea behind the refreshing that happens here is that the internal JavaScript browser silently re-loads the current page when a status is submitted, and then writes over the refresh-able parts of the page with the updated content. This is slower than a callback built specifically for a view (the only thing that will actually end up getting refreshed for most people). However, it is a more generic solution that makes it very easy for any area of the page to be refreshed. This will allow designers to put the view and status update box in different locations, for example, and still have them update correctly. In addition, there are some fringe cases where the method I took will actually yield more accurate results -- specifically where something in the refreshed content needs to know the URL of the page on which it was generated.
Oh, and I haven't tested this with comments. Even if this works, comments might still be broken due to core-related problems discussed here. And they'd probably be broken anyway by the duplicate behavior attachment, although that's just a guess. What this patch does is just move views outside of the FBSS form and makes sure they get updated via AJAX when necessary.
Anyone capable of helping fix the code, I would appreciate your eyes on this.
Comment #15
pribeh commentedHi Ice,
I've attempted the patch and received the following
Also, now that I've patched FBSS with the above patched I'm unsure of what to do next. How can I get a view (or part of the page) to refresh upon submission of the status form?
Thanks
Comment #16
icecreamyou commentedHmm. facebook_status.js is the more important file so if the patch didn't work for that file then nothing interesting will happen when you submit a status. You could always hand-apply... but I've attached the modified files you need. Remove the .txt extension and then drop them into your facebook_status folder to test. That's all you need to do; everything else should work without any changes.
Comment #17
pribeh commentedHi Ice,
Thanks for posting the file. I've added those files, hit update.php, and cleared the cache. When submitting a status using the FBSS "stream" block the form seems to load but the view does not refresh. Is this supposed to happen? Sorry, perhaps I'm just tired - it's been a long day. You can test it out at testing.londonfuse.ca - I believe you have an account you should be able to use already.
Let me know what I should try next.
Comment #18
icecreamyou commentedpribeh if I have a username I can't remember what it is, and creating a user doesn't work for the testing site. But make sure AHAH refreshing is enabled -- it's probably disabled because it used to be that AHAH refreshing and FBSL weren't compatible -- but it turns out that's probably because of this issue.
Also, maybe this isn't obvious, make sure the files are named facebook_status.js and facebook_status.module rather than facebook_status.js_ and facebook_status.module_0... make sure your theme's cache is cleared... I would disable JS aggregation and try it in Firefox with the Console open.
Comment #19
pribeh commentedHi Ice,
I'm fairly certain I've tried everything on your list but to no avail. I've sent you a new password I made for the account at testing.londonfuse.ca
Comment #20
icecreamyou commentedYou need to also be using the latest dev. There's a modification to facebook_status_ahah.js that is crucial to getting this whole system to work. When I modified my local cache of your site to include that change, it worked as expected for me.
Comment #21
icecreamyou commentedIt turns out that I was wrong about all the problems I mentioned in #14. The code actually works as expected. I committed the patch to FBSS with some performance optimizations.
However, there are four caveats.
The first is that I haven't tested this patch extensively. It works for me, and I've thoroughly examined the logic, but I would appreciate testing to make sure this works consistently. In particular I haven't tested refreshing anything other than a single view attached to a status update form (I haven't documented how to update anything else yet either, though). I also haven't tested this on pages with Panels.
Second, as I've mentioned before, comments still might not work, although I don't know because I haven't tested FBSSC after applying this patch.
Third, there are other bugs in FBSS dev. The most important one is that if you are using the Facebook-style Statuses Tags submodule, tags will no longer get linked to their category page in Views. The most obvious solution on the back-end is straightforward but potentially bad for performance, so I may have to be creative. But it's at the top of my to-do list for FBSS.
Finally, the AHAH-update JavaScript trigger is getting called more often than it should be after the first AHAH-driven status update upon fully loading a page. There are checks in place that make this essentially a non-issue, but it's kind of annoying from a technical point of view. If someone sits on a page without ever refreshing and updates their status hundreds of times, it could potentially get slow. I don't quite understand why this is happening but for some reason every AHAH update seems to force Drupal.ahah.prototype.success() to run two extra times for each successive update. I have an idea for how to possibly fix this but it may very well not be fixable without changes in core.
The next step now that this is in is to add a "Refresh" link so users can manually update the view via AJAX if they want to do so.
If you experience problems related to this patch, please open a new issue in the relevant location (most likely the FBSS queue) as the problem directly addressed in this issue (the "form in form" bug) no longer exists. However if you feel that it is relevant to this thread, feel free to post a link from this issue to the one you open.
Comment #22
pribeh commentedHi Ice,
I downloaded the latest dev, added the files in #16, then uploaded it, ran update.php, cleared caches for both the site and browser. I still can't get it to work as expected. I've attached a version of the fb_status_ahah.js from testing.londonfuse.ca/sites/all/modules/facebook_status. Perhaps I'm not using the right copy.
I'm excited to get this working since I love the possibility of having status refreshable view (or block) outside of the form. Thanks.
Comment #23
icecreamyou commentedOh, whoops. It looks like I forgot to commit that change to facebook_status_ahah.js. I just committed it now though so it will be in the next dev or you can grab it from CVS.
Comment #24
pribeh commentedWicked, I'm glad I'm not that dumb. I'll test out the changes tomorrow.
Comment #25
baff commentedTo me it seems to work. I tested IE, Firefox and Opera. Yipiehhhhhh !!!!!!!!!
Very good work IceCreamYou!
Comment #26
pribeh commentedSeems to work perfectly over here Ice. I'm going to run some more tests but I don't seem to experience any conflicts with Activity comments either.
Comment #27
icecreamyou commentedExcellent, I'm very glad to hear that. Maybe I can finally add FBSSC to the demo site then. ;)
Comment #28
hugafish commentedI would like to test this out on my live site. Backup first yes! so to get this working I will need to go to the dev version of facebook style statuses correct? then the dev version of the FBSSC module, is this all I will need? and one other question, I currently have an action to send email via triggers module for the regular blog and audio post comments to the content author. Does this module work with that or is another trigger/action need to be set up for FBSSC? Thanks
Eric
Comment #29
icecreamyou commentedYes, you can test this on your site using the dev version of Facebook-style Statuses and FBSSC.
Unfortunately I haven't yet had time to write Trigger integration for FBSSC at all, although I will do so eventually. Even so, however, FBSSC will never work with the trigger you currently have set up because it does not use the Comment module. As it says on the project page, I will release a beta of FBSSC when I have written important integrations with other modules.
Comment #30
hugafish commentedVery good info, I will be setting this up for testing hopefully by this weekend and I will let you know if I encounter any strange related errors or behaviours with this module. Thanks for the help IceCreamYou,
Eric
Comment #31
icecreamyou commentedEric, no problem -- however please keep this thread on topic. If you have other troubles feel free to open a new issue.
To all: I just committed changes to FBSS dev that should fix the excess calls to Drupal.ahah.prototype.success(). Also in dev is a new "Refresh" link added to the relevant refreshable content. I've also documented the new hook that lets you magically refresh any part of the page when a status is submitted.