hi, i am using panels and placed statuses form onto a panel. Form submission works with ajax, but list of messages just under the form is not updated, its done only after full page reload.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

IceCreamYou’s picture

Category: bug » support
Status: Active » Fixed

In the Statuses block settings you should enable showing a view with the status update form instead of placing the view into the panel separately. Alternatively you can edit the context advanced settings at e.g. admin/statuses/contexts/user and specify the DOM path of the view you want to update.

tribsel’s picture

thanks for your response:) unfortunately, i steps you mentioned did not help. I placed block in the panels and view with statuses is not refreshed. then added div.view-statuses-stream into Refreshable DOM selectors, but it did not help either.

G Gavitt’s picture

I am having the same issue. I have a user panel page and a status block setup set to enable showing a view, But the status section will not update on the panel. Normal pages refresh just fine (statuses/share etc.)

Status: Fixed » Closed (fixed)

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

brentratliff’s picture

Status: Closed (fixed) » Active

Sorry to reopen a closed issue. Neither method in #1 resolves the problem. Comments refresh but new statuses do not. I am not using Panels, just placing blocks in a normal path.

IceCreamYou’s picture

Status: Active » Postponed (maintainer needs more info)

Obviously I'm not seeing this, so someone who is seeing this needs to either do some debugging or explain how to reproduce this behavior from a clean installation.

Historically, when people have had problems like this it tends to be from other modules interfering.

brentratliff’s picture

Assigned: Unassigned » brentratliff

I'll throw it in xdebug.

RaulMuroc’s picture

Title: messages are not refreshed after submit » Statuses updated messages are not refreshed through AJAX after submit
RaulMuroc’s picture

Assigned: brentratliff » Unassigned
narongwit12’s picture

subscribed

mathankumarc’s picture

tribsel’s picture

Status: Postponed (maintainer needs more info) » Active

Actually, I still have the same problem as in #3. Statuses on regular node pages update just fine, only statuses at user's profile panel page dont get refreshed. I have to either click on Refresh link or reload page to see updates.

I looked into firebug and on regular node pages there is POST request (statuses/ajax) and GET request (node). On user's panel page there is only post. And i dont get any js errors.

additionaly, there is nothing else on the panel - only statuses and im using omega theme.

tribsel’s picture

omg, i just found the cause. Statuses on user panel pages dont get refreshed when "Show the status stream on the default user profiles" settings at /admin/config/statuses/settings/advanced is checked! Once you turn this off, statuses are being refreshed properly.

RaulMuroc’s picture

Ye that's the problem :D!! olé, really good @tribsel, these kind of troubles are the most difficult to guess. Anway, to me is working half half (weirdly), If I write a new statuses, they then disappear all, but when I write another one then yes they appear again all including the last two. So it looks like if first attempt to refresh fails but second works nice.

brentratliff’s picture

I don't think that's the root cause. My instance does not have that checked. I am, however, using a custom alter hook to move local menu tasks around on the profiles. This is similar to how Panels controls user profiles. The issue may be related to that. I have a "Wall" tab with the Statuses block that is not refreshing unless you click the refresh link on the stream. In this case, the AHAH works. I have not had time to debug it further. I used this technique as well as Panels in the D6 version and did not have these issues.

IceCreamYou’s picture

I suppose it's possible that if Drupal tries to render multiple status update forms on the same page the JS settings for each one could conflict with each other. (I think that when using Panels to override user profile pages, the "original" user profile still gets computed, then discarded.) Needs investigation.

klucid’s picture

In my case, I had to turn off AJAX on the view that I wanted refreshed. Not sure if that solves the problem for everybody. I would, however, prefer to have an AJAX pager on this view if possible.

Good luck!

Edit: #13 did not work for me.

eidoscom’s picture

Solution in #13 works for me!! @tribsel you rocks!!! thanks a lot.

brentratliff’s picture

Confirmed #17 was my issue as well. I toggled off AJAX in the non-overridden Statuses stream block and it is now refreshing properly.

Elin Yordanov’s picture

After a long search, tries and fails, I found the problem in my case. It was: Heartbeat Comments
(a sub-module from Heartbeat). After I disabled this module and clear the caches, it worked like a charm.
I don't know though what the actual reason is, but it seems like there are some conflicts between heartbeat and statuses.

IceCreamYou’s picture

Heartbeat Comments

That's entirely possible actually. Also would explain why I haven't reproduced it so far. Anyone else experiencing this?

deanflory’s picture

Kinda seems familiar though I haven't yet gotten to testing this on the site I'm currently devoted to, but rings a bell with some others in recent history. I do have both statuses and heartbeat/heartbeat comments enabled.

barry6575’s picture

I tried everything that I've seen here and I haven't found a fix as of yet. It works when I use the core profile; however, it doesn't work with panels. Any more suggestions??

brentratliff’s picture

Are you sending the page arguments to the panes?

pinguinland’s picture

It doesn't work... I tried everything so far..
No refresh at all...
It's a clean install of Drupal with statuses and only the necessary modules to work....
Not even #13 or #17 worked for me....

barry6575’s picture

Yes, I did.

IceCreamYou’s picture

Status: Active » Postponed (maintainer needs more info)

For people using Heartbeat, the commit in #1820844: Default view not getting refreshed because of js break. may resolve things for you.

This issue would be dramatically sped up if someone who is actually experiencing this problem could figure out how to reliably reproduce it.

pinguinland’s picture

i have no heartbeat but i can provide u the admin account to see it in action that is not working at a test site that i have....

ehalber’s picture

I am having the same issue.

When adding the statuses block to user profile panels, the expected auto refresh behavior does not occur. I have tried #13 and #17 solution with no luck. I did a fresh install with minimal modules and still no joy. Any help here would be greatly appreciated! :)

RaulMuroc’s picture

#13 was my issue... but:

The first status I need to click F5 and refresh whole page that it appears. Once this is done then is refreshing through AHAH automatically.

gandalf12’s picture

Hi All,

Clean Drupal install and I cannot get the AHAH refresh of the statuses on the page I want it to.
Tried #13, #17 & #30- no luck
Tried using the AJAX refresh as well as AHAH - no luck
I set to show on default user profiles, and it works yay!! boooo - can't get the stream to refresh on the page I want it to refresh on being the Front Page.

After a lot of experimenting, including loosing all the stream altogether, it appears that the AHAH refresh only works on the profile page, at least in my build.

Does anyone know of a work around? I remember trashing the whole status stream earlier back in mid 2011 due to the same problems.

Cheers

Grant

ehalber’s picture

@Icecreamyou,

What can I do to help you out here? This is still not working for user profiles being overridden by panels. I noticed that responding to comments in the user profile stream refresh through AHAH as expected. It's only when posting new content that it doesn't work.

I've checked the XHR profiler in Chrome and there are no AJAX errors, I also can't find any error in my apache logs.

I've tried adding the statuses block as both a block and a view...no refresh.

ehalber’s picture

Category: support » bug
Status: Postponed (maintainer needs more info) » Active

I'm happy to put a minimal d7 install online that reproduces this behavior.

IceCreamYou’s picture

Thanks for offering to help. If the root cause of this issue is that Statuses doesn't work out of the box with Panels, that's what we need to know in order to set up an environment where we can debug this problem.

Setting up this environment is not hard, but debugging it could be time-consuming, and I just don't have the time at the moment. @mathankumarc is the other maintainer and I don't know what his situation is.

mathankumarc’s picture

Status: Active » Needs review
FileSize
4.45 KB

Here is patch for ajax refresh using core ajax system and views.

However still it needs cross-browser and other testing. Testers are welcome.

With this patch #1685454: Views AJAX pagers don't change pages using AJAX after saving a status via AJAX and #1786438: Comments on AJAX inserted status doesn't submit using AJAX both are working fine.

Thought of doing something for new year, mission accomplished now :)

Happy new year to all :)

RaulMuroc’s picture

Uau nice work @mathankumar!

happy new year.

IceCreamYou’s picture

Status: Needs review » Needs work

Very nice -- thanks mathankumarc. Haven't tested yet but it looks like it should work. One problem: the patch in #36 looks like it breaks the ability to update any section of the page, regardless of whether it's a view. Should be possible to adjust though.

jienckebd’s picture

IceCreamYou -- have you had any luck fixing the problem you mention in #38 about the patch breaking the ability to update any section of the page?

mathankumarc’s picture

@Isaac could explain issue little more, that would help me to fix this :)

IceCreamYou’s picture

Currently fbss_refreshIDs holds a list of DOM paths. These DOM paths could represent any section of the page, not just a view; users can specify other sections of the page in context advanced settings or via hook_statuses_refresh_selectors() / hook_statuses_refresh_selectors_alter(). The refreshing is done by re-loading the current page silently in the background and replacing the relevant section of the page with the corresponding section from the new copy. (That is the only way to do it generically for any content. #847802: Content loaded on the page via AJAX can't be automatically refreshed when a status is submitted discusses another method where modules could define specific callbacks for replacements.)

The patch in #36 is problematic because it restricts the areas of the page that can be updated to only views, then specifically looks at the list of views and calls their own AJAX update functions. First of all this looks like it would only work if AJAX is enabled for that specific view, but also it won't work if something other than a view needs to be updated, like the block of popular tags provided by the Tags submodule.

On the other hand, maybe it's reasonable to decide that in 99% of cases the only thing anyone will ever want to update when a status is submitted is a view, and just run with that. That's fine if we decide to do that (as long as we think carefully about potential use cases we are eliminating) but it is a regression, and we'd need to change the UI on the context advanced settings pages too.

mathankumarc’s picture

Currently fbss_refreshIDs holds a list of DOM paths. These DOM paths could represent any section of the page, not just a view; users can specify other sections of the page in context advanced settings or via hook_statuses_refresh_selectors() / hook_statuses_refresh_selectors_alter(). The refreshing is done by re-loading the current page silently in the background and replacing the relevant section of the page with the corresponding section from the new copy.

If we are going to avoid reloading the page again, then we can remove both hook_statuses_refresh_selectors() and hook_statuses_refresh_selectors_alter().

The patch in #36 is problematic because it restricts the areas of the page that can be updated to only views, then specifically looks at the list of views and calls their own AJAX update functions. First of all this looks like it would only work if AJAX is enabled for that specific view

Yes.

but also it won't work if something other than a view needs to be updated, like the block of popular tags provided by the Tags submodule.

I think we can trigger an event in statuses.js when a statuses form is submitted and other modules can listen for it and update the relevant content accordingly.

IceCreamYou’s picture

I think we can trigger an event in statuses.js when a statuses form is submitted and other modules can listen for it and update the relevant content accordingly.

This is not something I expect other modules to want to implement, as it is usually site-specific, with the exception discussed in #847802: Content loaded on the page via AJAX can't be automatically refreshed when a status is submitted. This is a regression from what we currently do and would require site administrators to write fairly substantial code in order to refresh other parts of their page. In fact they already *can* do this, if they can write code.

That said, I think I'm okay with this in principle, as long as we document it; but it requires changes to the context advanced settings form, the way the Refresh IDs setting is used, the hooks you mentioned, and the upgrade path, in addition to the JS changes you've already made.

GolDRoger’s picture

OMG, I LOVE YOU XD

Spent one day trying to understand why statuses was not refreshed and it was only an option to disable :D

THANK YOU :)

barry6575’s picture

Any luck with fixing this??

mathankumarc’s picture

Currently we need to support the following possibilities when the new status is submitted using AJAX,

  • Updating the views page/block
  • Updating custom block
  • Updating custom container

To cover up the above scenarios I would suggest the following method,

Rather than just returning the selectors list in hook_statuses_refresh_selectors() , we can modify it to return the values like following,

  • For view,
    array(
      'type' => 'view',
      'display_id' => 'page_1', // Or 'block_1'
      'selector' => '#selector',
    )
  • For custom block,
    array(
      'type' => 'block'
      'name' => 'custom_block_1',
       'selector' => '#selector',
    )
  • For custom content,
    array(
      'type' => 'custom',
      'path' => '/custom/content/path', // Path to fetch the custom content or We can allow them to specify the callback to fetch the custom content
     'selector' => '#selector',
    )

So with the above information, We can easily make AJAX request for each one when user submits the new status.
Something like below,

For views
We can add new callback in statuses which will execute the necessary view and return the results for the AJAX request
For custom block
Same like above, in the same callback we can return the specified block contents
For custom content
If we are going to ask the user to enter the path, then its upto the user to specify the right path. If we are going to ask the user to enter the callback name, then like previous implementation we can call that callback in our custom callback

This way we can support all the scenarios and as you mentioned in 43 this will require minimal coding from site administrator.

This just my suggestion and this will result major changes in hook_statuses_refresh_selectors() and hook_statuses_refresh_selectors_alter(). Let me know your thoughts.

Extremely sorry for my inactivity over past four months. Due to my official and personal work I'm not able to participate regularly, however hereafter I will put minimum of 5 hours per week for Statuses regularly:)

IceCreamYou’s picture

This way we can support all the scenarios

That is actually very similar to what I had in mind with #847802: Content loaded on the page via AJAX can't be automatically refreshed when a status is submitted.

Ideally, we would make it so the current DOM-path-based system would work and add additional support for custom callbacks (the views and block cases are just special cases of custom callbacks anyway). But if there's no way the DOM-path-based system will work then the approach you're suggesting is fine too. Anyway it should be possible to add support for custom callbacks in one patch, and potentially remove the existing system in a future patch.

Due to my official and personal work I'm not able to participate regularly, however hereafter I will put minimum of 5 hours per week for Statuses regularly:)

That's quite good news! :)

RaulMuroc’s picture

Status: Needs work » Active

To put light over #30 that AHAH begins to refresh once you have an existing status (minimum 1).

I have to pass in :admin/config/statuses/contexts the DOM path and currently I pass at the general section: div.view-statuses-stream and to the specific for profile: td.views-field

And the point is: Is logic does not refresh the FIRST STATUS because the DOM Path does not exist at all. It creates after first status and that's why YES it refreshes once the DOM Path exists.

So we should modify code that by default creates the div (DOM PATH) where status_stream is shown but with hidden condition which becomse shown when it has one or more status. This should solve it.

I would do that but I do not know where is the code what creates this and I am really out oft ime to go through.

thanks.

IceCreamYou’s picture

statuses.js line 147 is where the code finds the area to replace:

            var element = $(val);

If element.length === 0 then there is nothing on the page that can be replaced yet. However we can't just insert something because we don't know where to put it. Maybe we could have a second path for a parent wrapper or something.

The rest of this thread seems to be about a conflict with Panels, which is a different different issue on the surface, but it's possible it could be resolved the same way.

barry6575’s picture

I found a way around this for the time being. Go to the Status block and in Status Settings click 'show a view on this block.' This will show the view that is associated (Status Context). This solves the issue as Statuses are refreshed after submitted.

Also, you will need to adjust your visibility settings within panels to accommodate your use case. In addition, you may need to create a view (Content Pane) to show status messages for anonymous users if that don't have permission to post statuses.

****Note: Once enabled the the gear icon, in panels, that allows you to add/change content will disable. You must click the Status Settings off to regain the ability to add content to panels.

Hope this helps.

Update: Just read #1 and the fix was stated there (unbelievable almost a year later). I don't think I clearly understood where to go in the past. I know my way around Drupal much better now. Just to be clear, I went to Blocks then found the Status block and Status Settings was found there.

RaulMuroc’s picture

To me latest solution doesn't solve me anything :S

Indeed I get same results with or without 'show a view on this block.' option enabled/disabled. I point out that I have ticked in statuses module settings the option of 'refresh through AHAH', I don't know if that affects.

The funny of the thing is that FIRST MESSAGE, and only first, doesn't refresh but second and towards they perfectly refresh.

RaulMuroc’s picture

Some advance on this?

Trying all alternatives here and works 90% effectively.

When a user doesn't have any statuses message and he writes the first statuses, it needs to be refreshed with F5 (reloading page). Once the user has one statuses message, for the following messages is just working cool and automatically refreshing.

RaulMuroc’s picture

Issue summary: View changes
FileSize
4.33 KB

Latest patch refactored because it did not apply. Needs review.

RaulMuroc’s picture

Status: Active » Needs review
thirdender’s picture

I just ran into this problem, although it was largely my own stupidity :-p

The selector I was trying to refresh on form submit was .statuses-update + .view-statuses-stream. During AHAH update, a progress throbber DIV was added between .statuses-update and .view-statuses-stream. The JS was looking for the exact same CSS selector after the content had been loaded, and with the throbber between the two elements the selector wasn't matching anything.

Posting this here in hopes it saves someone some time and effort. The module works great after I changed the selector by removing the offending +

Thanks for the great module!

RaulMuroc’s picture

@thirdender, thanks but that was a particular situation ;)

Anyway made your changes it does not completely works. Two situations:

1) Through CDN
Doesn't refresh AJAX at all. HAve to referesh whole page.

2) Without CDN
The first time you make a statuses doesn't refresh. From second forward it works nicely.

I don't why it behaves that way....

RaulMuroc’s picture

This is the console message retrieved from creating a new statuses and click the send button:

XHR finished loading: POST "http://www.whatever.com/statuses/ajax". jquery.js:505
XHR Loaded (ajax - 200 OK - 998.6259937286377ms - 1.981KB)

So theoretically it should load correct and it looks the problem is somehow realted to the call to load the content in the screen. No more info so far (sorry).

IceCreamYou’s picture

I don't remember if there's another issue where this is discussed, and it has obviously been a long time since I've looked at this issue; but as #56 mentions, there are actually two issues at play here. The first is that in many (all?) setups, Statuses doesn't refresh the first time a status is posted. This happens because Statuses tries to replace the view showing the statuses stream after a status is submitted, but since there were no statuses before the first one, there was no stream to start with, and hence there is nothing to replace. The second issue, which seems to be the main thing discussed in this thread, is that under mysterious circumstances the DOM path to the statuses view gets changed, in which case everything works except that Statuses doesn't know where to put the updated view on the page. That part is unclear to me.

  • IceCreamYou committed 6a2bdcf on 7.x-1.x
    Workaround for issue #1547864: Statuses are not refreshed through AJAX...
IceCreamYou’s picture

I just committed a change to dev that causes the page to refresh if Statuses can't figure out where it's supposed to put content it fetched via AJAX. This should at least mitigate the issue of the status form refreshing via AJAX and then nothing appearing on the page. Another possible workaround is to choose broader selectors in the context settings (which does not require any code changes).

ed523’s picture

This is a little different, the block isn't in a panel but was getting the same ajax error. Also I'm using views ticker to display the statuses like a news ticker across the header of the site. with statuses comments turned off. Unchecking the thing in #13 made the error go away, however new statuses make the ticker move down a bunch of pixels partially obscuring them until you hit refresh on the page, then they're in line with the others.

ggevalt’s picture

Hi,

I have updated this post to say that we are getting fully functionality on this. We are using the newest version of the .dev version of the module.

FYI, we have done a custom sub module and with node.js and views.nodejs we've been able to get the statuses to refresh automatically for both the author and anyone looking on the page which gives us the "live" functionality we were seeking. We will be releasing a write up and code of what we did in the near future. If you are interested, contact me.

This is a terrific module. And as we are rolling out our new site for our teen site, we will be interested to see how this changes how the kids connect and react to each other's posts.

Thanks in advance.

geoff

manoj mohanan’s picture

hay,anyone pls help me to find the correct solution for this problem...giv basics.am fresher in drupal7

Ddroid_za’s picture

Hey, Thanks for an awesome module.

I also experience the same issues when adding the statuses block, with its attached view into a panel pane.

The auto refresh works 100% on the status/share page and view for example, just not when embedded in a panel pane. I have tried applying the above patches as best I could against the 7.x-1.0-beta2+18-dev version but non of them apply cleanly.

Anyone else had any luck getting this into a panel and updating?

UPDATE - This solved it for me: #13!!

SocialNicheGuru’s picture

#13 is right:

omg, i just found the cause. Statuses on user panel pages dont get refreshed when "Show the status stream on the default user profiles" settings at /admin/config/statuses/settings/advanced is checked! Once you turn this off, statuses are being refreshed properly.

This works.

SocialNicheGuru’s picture

@ggevalt
could you share the write up? This is exactly what I am looking for.

ggevalt’s picture

Hi, For anyone checking in on this rather old forum string, may I applaud @barry6575 in #50. This works.

So our problem was our set up: We were using panels (remember that was the initial point of this thread) and AHAH did not seem to work. We didn't necessarily care about the use case of the statuses block -- ie., whether it was on a user page or in relation to a node or by itself. IN PANELS, we had set up the related node on the left (the explainer for what a particular statuses page was for -- we use statuses for idea-storming and discussion) and had TWO blocks, Statuses and View: Statuses context stream on the right in a two-column set up. AHAH refresh did not work no matter what we tried.

Then, four years later, we found Barry's post #50 and tried out the most important part of his suggestion: "Go to the Statuses block and in status settings click 'show a view on this block.' " We did that. We then then disabled, in panels, the Views block: statuses context stream to leave only the updated Statuses block.

Bingo. Works perfectly, so that now the AHAH refresh works as expected -- a second after you share your status update, it appears at the top of the stream directly below it.

So thank you, Barry. Sorry I didn't run into this a year and a half ago.

g