No automatic refresh... [#175254]

Comment	File	Size	Author
#26	chatroom-no-refresh.patch	696 bytes	oriol_e9g
#25	chatroom-chatroomread.patch	586 bytes	sjovanig

Comment #1

McGo commented 13 September 2007 at 18:39

Category:

bug

» support

The same setup works fine under another URL / directory setup. So the question ist, what URL / directory depending settings can cause the failure?!?

Log in or register to post comments

Comment #2

McGo commented 13 September 2007 at 19:39

So i figured out that one of the two pages (stable) doesn't send any XMLHttpRequests and therefore can't read the cachefile and update the chat content. Firebug gives me an error:

document.getElementById("chatroom-user-alert") has no properties
chatroomAddEvents()chatroom.js (line 24)
e()jquery.js (line 2)
[Break on this error] document.getElementById('chatroom-user-alert').onclick = function() {

On the other site (beta) the error doesn't appear. The weird thing is, that the beta site is the working one and has the same module and core-code basis (Updated from SVN via cron-jobs!)... I even checked the file permissions and the .htaccess file... Any further ideas ?!?

Log in or register to post comments

Comment #3

ArchDoomBringer commented 13 September 2007 at 23:29

Id dearly love to find a solution as well.
I have been trying to get this working for a week now and i still cant see messages.
I have read through the previous posts and nothing helps.

Log in or register to post comments

Comment #4

mperabo commented 16 September 2007 at 15:13

Hi.

Had the same problem before. Here's how I brought it to work, maybe it helps someone else also:

I accidentaly installed the chatroom to /modules instead of sites/all/modules. One I moved it to the sites/... folder, it worked pretty fine.

Log in or register to post comments

Comment #5

McGo commented 16 September 2007 at 16:38

mperabo,

on both sites the module is installed outside the webroot in a directory that is updated outof svn via cronjob. Under /sites/all there are two symlinks that point to that svn directory. So it is already installed in /sites/all/modules. This configuration is the same between the beta and the productive site.

Hoping for further ideas,
McGo

Log in or register to post comments

Comment #6

McGo commented 17 September 2007 at 09:46

Oh sh...

I got it. I had to enable a block (Chat on-line list). By enabling that block, Drupal automatically loads additional javascript stuff that is needed by the chatroom-module.

So for me it works now...
McGo

Log in or register to post comments

Comment #7

McGo commented 17 September 2007 at 11:54

Assigned:	Unassigned	» McGo
Status:	Active	» Closed (fixed)

Log in or register to post comments

Comment #8

M3 commented 25 September 2007 at 04:14

Status:

Closed (fixed)

» Postponed (maintainer needs more info)

I'm having the same problem with the chat area not refreshing until the user enters a message or toggles away, except I've tried the module in various locations (/sites/all/modules, /modules, etc) and the "Chat on-line list" is enabled. I did also replace the JavaScript to enable the chats to show at all in 5.x (documented somewhere). Any ideas?

Log in or register to post comments

Comment #9

darren oh

English

Lakeland, Florida

commented 25 September 2007 at 11:42

Status:

Postponed (maintainer needs more info)

» Closed (fixed)

Drupal 5.2 is not compatible with current releases of Chat Room. A new release will be made shortly.

Log in or register to post comments

Comment #10

manimal commented 7 October 2007 at 08:29

I'm experiencing this with latest dev release (also on any version I try as well). Darren Oh stated in another thread that it was compatible with 5.2.. so I'm confused. The online block is enabled (all the chatroom blocks are enabled).

not sure what the mentioned javascript replace thing was..

Log in or register to post comments

Comment #11

darren oh

English

Lakeland, Florida

commented 7 October 2007 at 14:43

manimal, try clearing out your temp directory.

Log in or register to post comments

Comment #12

manimal commented 7 October 2007 at 16:19

okay, I tried that, and it still does the same thing.. tried updating the database after clearing the directory, creating a new chatroom, and still no messages appear until after I submit a new message, or set my status to away or back..

Log in or register to post comments

Comment #13

darren oh

English

Lakeland, Florida

commented 7 October 2007 at 17:17

I don't have any information that enables me to reproduce the problem. Contact me directly if you would like me to test it on your site.

Log in or register to post comments

Comment #14

manimal commented 8 October 2007 at 04:53

okay, it must be something on my site, or database that causing the problem. I'll have to look at this later when I can meet up with the other guys working on my site with me.

thanks for the advice (and ofcoarse the efforts towards the drupal community!)

Log in or register to post comments

Comment #15

evans-pj commented 12 October 2007 at 08:34

does chatroom work with drupal 5.2?

Log in or register to post comments

Comment #16

darren oh

English

Lakeland, Florida

commented 12 October 2007 at 12:56

The development version should. Please test it and let me know.

Log in or register to post comments

Comment #17

Red_Beard commented 5 September 2008 at 17:34

Was this ever resolved? I am experiencing the same problem.

Log in or register to post comments

Comment #18

benhammond commented 16 September 2008 at 22:46

I think I have the same problem; chat works brilliantly on my home machine but fails to asynchronously update when running on the public website.

After a little digging around I reckon that this is because the ajax calls to chatroomread.php are passed with a timestamp of FALSE
I assume this means that my hosting provider has disabled PHP calls to filemtime.

Would it be so terrible to tolerate missing timestamps (I guess I would have to discard the 'quiet response' functionality); is there another reason why this would be a Bad Idea.

Would it be better to change my hosting provider?

Log in or register to post comments

Comment #19

Desi Raaj commented 18 June 2010 at 06:28

Version:

5.x-1.x-dev

» 6.x-2.9

i have this problem too here is what i found in the logs
page not found 06/17/2010 - 23:24 chatroom/chat/get/latest/messages

Log in or register to post comments

Comment #20

asb commented 27 March 2011 at 13:16

Version:	6.x-2.9	» 6.x-2.14
Category:	support	» bug
Status:	Closed (fixed)	» Active

Similar issue with the current release. Changing category to "bug report" as it doesn't work as it should according to the project page.

The additional block mentioned in #6 ("Chat on-line list") seems not to exist anymore. I have only two blocks (
Active chat rooms, Active chats) which are both enabled.

Thanks & greetings, -asb

Log in or register to post comments

Comment #21

oriol_e9g

Catalan

Barcelona

commented 28 March 2011 at 08:22

Same problem with chatroom-6.x-2.14

Log in or register to post comments

Comment #22

asb commented 28 March 2011 at 12:15

Priority:

Normal

» Major

Hi,

I tried a second installation on a different site; in both cases, the site is located on a subdomain (subdomain.domain.tld), and in both cases Drupal is running in the root (not installed in a subfolder).

In one case, not even the own message is echoed on the screen. In the other installation, that works fine; however, messages from the chat partner do only show up when the chat page is reloaded manually. With this behaviour, this is no chat (not interaction!), but some weird Shoutbox/Tribune like feature.

Log in or register to post comments

Comment #23

oriol_e9g

Catalan

Barcelona

commented 28 March 2011 at 12:45

Component:	User interface	» Code
Assigned:	McGo	» Unassigned

I can confirm that i have this problems with a multi-site site in a subdomain installation. No apparent mistakes (chatroomread in root directory, chatroom module installed in sites/all/modules).

I don't know it it's a bug report or a support request.

Log in or register to post comments

Comment #24

sjovanig commented 30 March 2011 at 09:04

I had this same problem.

The guilty is file 'chatroomread.php', that it should be in site root.

To do the trick you have to change about line 57:

drupal_bootstrap(DRUPAL_BOOTSTRAP_CONFIGURATION)

to

drupal_bootstrap(DRUPAL_BOOTSTRAP_FULL);

You can confirm this solution works!

Log in or register to post comments

Comment #25

sjovanig commented 30 March 2011 at 09:32

Status	File	Size
new	chatroom-chatroomread.patch	586 bytes

Related #24

Attaching patch

Log in or register to post comments

Comment #26

oriol_e9g

Catalan

Barcelona

commented 30 March 2011 at 09:33

Status	File	Size
new	chatroom-no-refresh.patch	696 bytes

patch attached with comments change

Log in or register to post comments

Comment #27

oriol_e9g

Catalan

Barcelona

commented 30 March 2011 at 09:36

Status:

Active

» Needs review

Log in or register to post comments

Comment #28

asb commented 30 March 2011 at 14:18

Status:

Needs review

» Reviewed & tested by the community

When running from the site's root directory (the folder where chatroomread.php is), the patch from #26 applies cleanly and fixes the issue for me. Now this thing seems to work as it is supposed to!

Thanks!

Log in or register to post comments

Comment #29

Anonymous (not verified) commented 5 April 2011 at 04:56

Status:

Reviewed & tested by the community

» Needs work

this patch will not be applied, as it defeats the purpose of chatroomread.php entirely.

i'm keeping this open, but we need to find the underlying problem.

Log in or register to post comments

Comment #30

AlexisWilke commented 5 April 2011 at 07:25

If the FULL version is necessary in some cases, then it should be loaded only when required. Otherwise, optimization wise, it is really bad (as Justin is pointing out!)

Now, you guys may want to try the patch I posted on this issue: #869682: Chat messages don't appear when clicking chat button or pressing enter

It fixed my problem with variables being deleted by the bootstrap process. If that fixes your problem too, then we're there. Now that would not explain why setting the initialization to FULL would help in any way... but you may have some conflicts with other modules that require such to work.

Thank you.
Alexis