Hello,

Noticed some quirks with the D7 port. I didn't have the time to create proper patches, but here are the solutions:

1. chatblock.php () - $_chatblock_cache_path is improperly set
I don't know if this is only my installation's problem, but this variable points to a completely false location, which results in an empty output from the callback script, rendering ajax updates quadriplegic.

Modified to: $_chatblock_cache_path = dirname(__FILE__) . '/sites/all/modules/chatblock/cache';

2. Unable to disable smart port feature by setting step width to 0

This was more tricky to find out. I wanted to implement continous polling, but it just didn't want to work. By debugging chatblock.js, I noticed that:

2.1
at line #232
The if statement will always evaluate to TRUE, because smartPollStepWidth is string zero (aka "0"), which evaluates to true in JS world.

Solution:
in chatblock.module at line #859 add an (int) cast to the initialization of the variable:

(int) variable_get('chatblock_smart_poll_stepwidth', 0)

Also changed its default value to zero, but that is just personal preference.

2.2
at line #281, Drupal.chatblock.pollRate will not be set, so calling setPollInterval will do nothing.

Solution: added the following line just before the call to setPollInterval:
Drupal.chatblock.pollRate = Drupal.settings.chatblock.pollRateDefault;

Hope this helps, and I hope to see this included in the next release.

Regards,
Adam

Comments

doitDave’s picture

doitDave commented
Assigned: Unassigned » doitDave
doitDave’s picture

doitDave commented
Version: 7.x-1.2 » 7.x-1.x-dev
Status: Active » Postponed (maintainer needs more info)

I have now had some time to check your findings.

Regarding $_chatblock_cache_path, it is not as easy as your suggestion, as the module might not be in sites/all (respect multisite environments!). However, the current logic assumes chatblock.php sticking in your drupal root, just like index.php. So when being called, the relative path would have to work (as sites is always below drupal_root) and I wonder why it doesn't. Thus, before making changes/fixes on this, I would really like to learn something about your setup and why it didn't lead to the right folder anyway? Can you say something about your PHP version and server software and probably caching modules etc. that you are using?

Then for the typecasting: I have fixed this in dev, so it will be in the next release. Thanks!

In the last item you are wrong, because pollRate actually does get set. See adjustPollrate.

Looking forward to your report on #1!

adam.t’s picture

adam.t commented

I appreciate your reply!

1.
You are right about the multisite part, as I'm using a single-site environment, I just didn't deal with it.

I found that the source of the problem is the $_POST['mp'] variable, which contains invalid subpath info (it contains a subpath that is not relative to my Drupal root, as it contains directories several levels "above" the Drupal root). I didn't track this further.

Environment: ISP Config shared hosting env. with apache + PHP FPM, with Drupal running in the docroot. I have had no problems with other modules so far.

2.
Cool, thanks.

3.
I have to defend this one, but let me clarify things further (also, please keep in my that my use case was to implement continuous polling, with a fixed poll rate, like in every 5 seconds).

In the js function adjustPollRate: if you take the last, outermost "else" branch (where you get when you disable the smart polling feature, which was my case), you will see that pollRate is just not set at that point. You then call setPollIntervall there, which checks the existence of the pollRate variable, and will do nothing if it is empty.

Hope that helps.

doitDave’s picture

doitDave commented

Oh, now I see that you are right about the missing initial pollRate setting. Indeed your fix helps it. I have added it now, thank you!

$_POST['mp'] actually contains the site slug. Which, in a standard install, is "all" and otherwise e.g. "mysite". It is resolved to either sites/all/modules or sites/mysite/modules. So what does it contain in your case? Since you have a single site setup, it should be "all" - so what is the actual value making you figure it invalid?

doitDave’s picture

doitDave commented
Status: Postponed (maintainer needs more info) » Active
adam.t’s picture

adam.t commented

Dave,

In my case $_POST['mp'] contains the following: "26/web/sites/all"
I don't understand where it gets the "26" from. /web is the directory name of my document root.

Thanks for the rest of the fixes!

doitDave’s picture

doitDave commented

What I just recalled when reviewing the code: An invalid path never should be passed to chatblock.php, because unless a counter-check on the cache path validates, chatblock.php is not chosen as a callback path (instead, js/chatblock/view is, rendering the cache path irrelevant for the rest).

However, as the recent path determination might have opened some other flaws (e.g. backslashes, multibyte issues or improper directory separators), I have now implemented a slightly different approach. I would appreciate your testing it tomorrow (you need to wait until the packaging script has added it to the dev package), especially the path issue, and getting back to me. Thanks in advance!

doitDave’s picture

doitDave commented
Status: Active » Needs review
doitDave’s picture

doitDave commented
Status: Needs review » Fixed

As there is no more reaction, I consider this solved.

Status: Fixed » Closed (fixed)

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