Facebook-style Statuses - 6.x-2.0
It happens in stream block on advanced profile
Error Message: field is required.
diabling status comment module - and working again

Comments

icecreamyou’s picture

Category: bug » support
Status: Active » Fixed

As the module's page and the download notes clearly say,

This module should only be used with the latest dev of FBSS or a version released after 4 February 2010!

Your problem may also be related to #709996: Status entries disappear when fbssc is enabled.

Also see the Troubleshooting guide here

Gyt’s picture

Title: When module is active status does not work anymore for "normal" users » When module is active statuses does not add anymore
Category: support » bug
Priority: Normal » Critical
Status: Fixed » Active
StatusFileSize
new17.36 KB
new11.87 KB

I 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.

baff’s picture

>> 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 ...

icecreamyou’s picture

I 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.

Gyt’s picture

It'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.

milktin’s picture

Same problem;
yes, only in Internet Explorer. (no problem in FireFox)

icecreamyou’s picture

Ah, 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.

icecreamyou’s picture

Marked #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.

icecreamyou’s picture

Title: When module is active statuses does not add anymore » "Form in form" problem causes status updates to fail

Changing title to something more descriptive.

pribeh’s picture

Thanks 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

icecreamyou’s picture

An 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.

icecreamyou’s picture

Assigned: Unassigned » icecreamyou

Another 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.

hugafish’s picture

subscribing

icecreamyou’s picture

Status: Active » Needs work
StatusFileSize
new8.87 KB

The 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.

pribeh’s picture

Hi Ice,

I've attempted the patch and received the following

Hunk #2 FAILED at 48.
1 out of 2 hunks FAILED -- saving rejects to file facebook_status.js.rej

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

icecreamyou’s picture

StatusFileSize
new79.12 KB
new4.93 KB

Hmm. 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.

pribeh’s picture

Hi 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.

icecreamyou’s picture

pribeh 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.

pribeh’s picture

Hi 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

icecreamyou’s picture

You 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.

icecreamyou’s picture

Status: Needs work » Fixed

It 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.

pribeh’s picture

StatusFileSize
new2.46 KB

Hi 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.

icecreamyou’s picture

Oh, 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.

pribeh’s picture

Wicked, I'm glad I'm not that dumb. I'll test out the changes tomorrow.

baff’s picture

To me it seems to work. I tested IE, Firefox and Opera. Yipiehhhhhh !!!!!!!!!
Very good work IceCreamYou!

pribeh’s picture

Seems 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.

icecreamyou’s picture

Excellent, I'm very glad to hear that. Maybe I can finally add FBSSC to the demo site then. ;)

hugafish’s picture

I 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

icecreamyou’s picture

Yes, 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.

hugafish’s picture

Very 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

icecreamyou’s picture

Eric, 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.

Status: Fixed » Closed (fixed)

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