i noticed these two problems happen with my drupal 6.3:

  1. the update.php script does not work (see description below)
  2. the Views module's ajax features do not work (see description below)
  3. we have struggled with these problems for weeks now in Drupal 6, and have had no solution. however, i have managed to narrow it down a little. (i also tested this with a fresh installation to verify, as well). i noticed that these two problems only happen in the following situation:

    suppose i have a multi-site drupal installation / site serving out 2 or more "sites", such as

(i'm just using made-up names for this example -- not the real names i'm developing on.)

All "sites" are really just aliases for one site, since they're using the same drupal database (so that we can share news and events across departments, etc.), and all sites have virtual host entries in my apache httpd.conf. They are all being served off the same machine [this is on a linux (fedora 8) box, with drupal 6.3, and the development versions of the following modules: Views, CCK, Calendar, Date, Nice Menus, and TinyMCE, as well as current release version of the Advanced Help module. if you need more info on these, let me know.]

the first site stores its settings in /var/www/dru/sites/default/settings.php. The other 3 sites are all located in, for instance:

  • /var/www/dru/sites/department2.com
  • /var/www/dru/sites/department3.com
  • /var/www/dru/sites/department4.com

and each site of course has its own settings.php.

the 2 problems listed above will happen when accessing this site from any of the sites with entries in /var/www/dru/sites/* (that is, departments 2 through 4), but will NOT happen when accessing the first site.

i have an idea that this has something to do with ajax, or with jQuery, and how they find their base url info. But it's just a thought, and since I'm new to drupal, i really don't know where to go from there to find the bug.

for now, during development, i can get along with using only the "default" site for these activities, but for production, i'll need all sites to be able to use these features successfully.

furthermore, there may be other drupal functionality depending on ajax/jQuery (besides these 2 areas) which is also affected in a multi-site installations, so it would be nice to track this one down.

let me know if there is any info i've left out, or anything else i can provide.

Description of the behaviors

1. update.php script does not work

Screenshot 1 shows what it looks like. The update.php script just appears to hang on the "Run updates" step (e.g., http://department2.com/update.php?op=start&id=61), although, in my firebug, it generates two errors (which I've also tried to capture in the screenshot).

when i view page source for this updating page, i see what looks like a mis-placed error message which is echo'ing out in the middle of a script declaration, like the following:

<link type="text/css" rel="stylesheet" media="print" href="/themes/garland/print.css?I" />
    <script type="text/javascript" src="/misc/jquery.js?I"></script>
<script type="text/javascript" src="/misc/drupal.js?I"></script>
<script type="text/javascript" src="/misc/progress.js?1217432582"></script>
<script type="text/javascript" src="/misc/batch.js?1217432582"></script>
<script type="text/javascript">jQuery.extend(Drupal.settings, { "basePath": "/", "batch": { "errorMessage": "An unrecoverable error has occurred. You can find the error message below. It is advised to copy it to the clipboard for reference.\x3cbr/\x3ePlease continue to \x3ca href="http://webdevfh.ss.uci.edu/update.php?id=60\x26amp;op=finished"\x3ethe error page\x3c/a\x3e", "initMessage": "Starting updates\x3cbr/\x3e\x26nbsp;", "uri": "http://webdevfh.ss.uci.edu/update.php?id=60" } });</script>
    <!--[if lt IE 7]>
      <link type="text/css" rel="stylesheet" media="all" href="/themes/garland/fix-ie.css" />    <![endif]-->
  </head>
  <body class="sidebar-left">

<!-- Layout -->
  <div id="header-region" class="clear-block"></div>
...

notice that the key line is this one:

<script type="text/javascript">jQuery.extend(Drupal.settings, { "basePath": "/", "batch": { "errorMessage": "An unrecoverable error has occurred. You can find the error message below. It is advised to copy it to the clipboard for reference.\x3cbr/\x3ePlease continue to \x3ca href="http://webdevfh.ss.uci.edu/update.php?id=60\x26amp;op=finished"\x3ethe error page\x3c/a\x3e", "initMessage": "Starting updates\x3cbr/\x3e\x26nbsp;", "uri": "http://webdevfh.ss.uci.edu/update.php?id=60" } });</script>

which appears to be coming from jQuery. when i try to read through this message (decoding the html entities in my head), i am guessing that this message was originally intended to be shown on in the browser, but never got there (since it's outputting in the section). looking closer, i notice that the URL is the same, just with the "op" parameter changed to "finished". so, in an attempt to reconstruct the originally intended behavior of giving me some kind of meaningful error message page, i replace "op=start" with "op=finished" in the URL, and go there. a few seconds later i get Screenshot 2.

following the advice of the error message in Screenshot 2, i check the recent log entries (/admin/reports/dblog). there appear to be 3.

1st says:

array_map() [<a href='function.array-map'>function.array-map</a>]: Argument #2 should be an array in /var/www/dru/modules/system/system.module on line 975.

2nd says:

array_keys() [<a href='function.array-keys'>function.array-keys</a>]: The first argument should be an array in /var/www/dru/includes/theme.inc on line 1720.

3rd says:

Invalid argument supplied for foreach() in /var/www/dru/includes/theme.inc on line 1720.

This is as far as i can get with it. Again, the problem does NOT happen with the default site. Only with the sites specified in their own directories in /var/www/dru/sites/*.

2. the Views module's ajax features do not work

i actually describe this ill behavior in my posts in another issue, #266157: missing "this" in the file ajax.js. i did not post that original issue, but if you look at my postings (starting with comment #6), you should be able to get a fairly accurate description of the Views ajax problem i am experiencing.

Again, the problem does NOT happen with the default site. Only with the sites specified in their own directories in /var/www/dru/sites/*.

Comments

damien tournoud’s picture

Thanks for your detailed bug report. Can you give us your exact <VirtualHost> configuration for all four sites?

jastern’s picture

sure, and thanks for responding so quickly, Damien.

since you asked for the exact VirtualHost configuration, I'll give it to you, but the site names for our actual machines are different. so "webdevjs.ss.uci.edu" is the default (i.e., "department1.com") site, and has its settings specified in /var/www/dru/default/settings.php. all the others (including the webdevfh.ss.uci.edu which i was testing from) are specified in /var/www/dru/sites/*

the following is the virtual host additions i made to the end of our httpd.conf Apache config file:

NameVirtualHost *:80

<VirtualHost *:80>
  ServerName webdev.ss.uci.edu
  DocumentRoot "/var/www/html"
</VirtualHost>

<VirtualHost *:80>
  ServerName webdevbt.ss.uci.edu
  DocumentRoot "/var/www/dru"
</VirtualHost>

<VirtualHost *:80>
  ServerName webdevfh.ss.uci.edu
  DocumentRoot "/var/www/dru"
</VirtualHost>

<VirtualHost *:80>
  ServerName webdevgl.ss.uci.edu
  DocumentRoot "/var/www/dru"
</VirtualHost>

<VirtualHost *:80>
  ServerName webdevjk.ss.uci.edu
  DocumentRoot "/var/www/dru"
</VirtualHost>

<VirtualHost *:80>
  ServerName webdevjm.ss.uci.edu
  DocumentRoot "/var/www/dru"
</VirtualHost>

<VirtualHost *:80>
  ServerName webdevjm01.ss.uci.edu
  DocumentRoot "/var/www/dru"
</VirtualHost>

<VirtualHost *:80>
  ServerName webdevjm02.ss.uci.edu
  DocumentRoot "/var/www/dru"
</VirtualHost>

<VirtualHost *:80>
  ServerName webdevjm03.ss.uci.edu
  DocumentRoot "/var/www/dru"
</VirtualHost>

<VirtualHost *:80>
  ServerName webdevjm04.ss.uci.edu
  DocumentRoot "/var/www/dru"
</VirtualHost>

<VirtualHost *:80>
  ServerName webdevjm05.ss.uci.edu
  DocumentRoot "/var/www/dru"
</VirtualHost>

<VirtualHost *:80>
  ServerName webdevjs.ss.uci.edu
  DocumentRoot "/var/www/dru"
</VirtualHost>
damien tournoud’s picture

Ok, so all virtual hosts look perfectly identical.

What seems to happen in your case is that the JSON exporter do not properly encode double quotes in strings:

"Please continue to \x3ca href="http://webdevfh.ss.uci.edu/update.php?id=60\x26amp;op=finished"\x3ethe error page\x3c/a\x3e"

should be:

"Please continue to \x3ca href=\"http://webdevfh.ss.uci.edu/update.php?id=60\x26amp;op=finished\"\x3ethe error page\x3c/a\x3e"

I can't understand why this is happening, or why you see a different behavior between the default site and the others...

jastern’s picture

hey, damien,

>What seems to happen in your case is that the JSON exporter do not properly encode double quotes in strings:

ahah! THANK YOU!!!

your noticing the quotes made me remember that on our system we have our php.ini set up for

magic_quotes_gpc     1
magic_quotes_sybase  1

since we have a sybase-type database (interbase) which we access from the same machine via php, but for non-drupal stuff, which uses a different escaping mechanism for single quote characters. the result of having these 2 php.ini directives both turned on is that *only* single quotes will be escaped, and the way they are escaped is with a second single quote (i.e., O'Reilly becomes O''Reilly). Double quotes, backslashes and NUL's will remain untouched and unescaped. this is the way we need it to access our database.

i noticed in /var/www/dru/.htaccess, the magic_quotes_gpc is turned BACK OFF in the 3 sections below:

# Override PHP settings. More in sites/default/settings.php
# but the following cannot be changed at runtime.

# PHP 4, Apache 1.
<IfModule mod_php4.c>
  php_value magic_quotes_gpc                0
  php_value register_globals                0
  php_value session.auto_start              0
  php_value mbstring.http_input             pass
  php_value mbstring.http_output            pass
  php_value mbstring.encoding_translation   0
</IfModule>

# PHP 4, Apache 2.
<IfModule sapi_apache2.c>
  php_value magic_quotes_gpc                0
  php_value register_globals                0
  php_value session.auto_start              0
  php_value mbstring.http_input             pass
  php_value mbstring.http_output            pass
  php_value mbstring.encoding_translation   0
</IfModule>

# PHP 5, Apache 1 and 2.
<IfModule mod_php5.c>
  php_value magic_quotes_gpc                0
  php_value register_globals                0
  php_value session.auto_start              0
  php_value mbstring.http_input             pass
  php_value mbstring.http_output            pass
  php_value mbstring.encoding_translation   0
</IfModule>

BUT there is no magic_quotes_sybase value set there. so, that means that with my current installation of drupal, magic_quotes_gpc is off (0) but magic_quotes_sybase was still on. so, taking your observation, i added this line:

  php_value magic_quotes_sybase             0

to each of these 3 sections, so the result is of course:

# Override PHP settings. More in sites/default/settings.php
# but the following cannot be changed at runtime.

# PHP 4, Apache 1.
<IfModule mod_php4.c>
  php_value magic_quotes_gpc                0
  php_value magic_quotes_sybase             0
  php_value register_globals                0
  php_value session.auto_start              0
  php_value mbstring.http_input             pass
  php_value mbstring.http_output            pass
  php_value mbstring.encoding_translation   0
</IfModule>

# PHP 4, Apache 2.
<IfModule sapi_apache2.c>
  php_value magic_quotes_gpc                0
  php_value magic_quotes_sybase             0
  php_value register_globals                0
  php_value session.auto_start              0
  php_value mbstring.http_input             pass
  php_value mbstring.http_output            pass
  php_value mbstring.encoding_translation   0
</IfModule>

# PHP 5, Apache 1 and 2.
<IfModule mod_php5.c>
  php_value magic_quotes_gpc                0
  php_value magic_quotes_sybase             0
  php_value register_globals                0
  php_value session.auto_start              0
  php_value mbstring.http_input             pass
  php_value mbstring.http_output            pass
  php_value mbstring.encoding_translation   0
</IfModule>

now magic_quotes_sybase is turned off, and the ajax features work for all sites, including the ones set in /var/www/dru/sites/*

as to your second statement,

> I can't understand ... why you see a different behavior between the default site and the others..

i found that there was a magic_quotes_sybase set to 0 (off) in the /var/www/dru/default.settings.php file. (and thus also the /var/www/dru/settings.php file which i made by copying it):

**
 * PHP settings:
 *
 * To see what PHP settings are possible, including whether they can
 * be set at runtime (ie., when ini_set() occurs), read the PHP
 * documentation at http://www.php.net/manual/en/ini.php#ini.list
 * and take a look at the .htaccess file to see which non-runtime
 * settings are used there. Settings defined here should not be
 * duplicated there so as to avoid conflict issues.
 */
ini_set('arg_separator.output',     '&amp;');
ini_set('magic_quotes_runtime',     0);
ini_set('magic_quotes_sybase',      0);
ini_set('session.cache_expire',     200000);
ini_set('session.cache_limiter',    'none');
ini_set('session.cookie_lifetime',  2000000);
ini_set('session.gc_maxlifetime',   200000);
ini_set('session.save_handler',     'user');
ini_set('session.use_only_cookies', 1);
ini_set('session.use_trans_sid',    0);
ini_set('url_rewriter.tags',        '');

but this file's settings only affected the default site, not the other multi-sites i have in /var/www/dru/sites/*. this is because --- as suggested in the "multisite configuration" section of the INSTALL.txt file --- i had copied over the sites/default/default.settings.php file to sites/default.settings.php, and changed only what i needed to. but i had NOT done this for the other, non-default sites. instead, i had just created a new settings.php file for each site, from scratch, adding only the few lines i thought i needed, for brevity and speed, and thinking that these other sites would "inherit" the settings from the default settings.php -- which they don't -- and overwrite only what they change. but it does not work this way, apparently. the default settings.php is not understood by drupal as "the default settings for all sites (unless overridden)" instead, it is understood as "the settings for ONLY the default site".

and, after all, the INSTALL.txt did say clearly to copy over the file and make changes.

oh well, lesson learned. i will copy over that default settings.php now to each site and adjust the appropriate lines.

however, as far as drupal code is concerned, i guess it comes down to the following choices?..

1) since having magic_quotes_sybase On seems to cause so many problems for ajax features globally, we should make the same changes to the .htaccess file in CVS that i did on my own installation, so that, just for safety, in future versions of drupal 6, this setting is by default turned off for all sites,

OR

2) some sites do need to have magic_quotes_sybase set to On. this is why it is being left as a settings.php option. so, some de-bugging needs to be done on the ajax features and how they are affected by this setting.

jastern’s picture

StatusFileSize
new604 bytes
new929 bytes

okay, i haven't seen any answer to this in a while, so i'm just going to go ahead and post some patches for the .htaccess file. i'm not exactly sure how Drupal's branches work, and what the latest HEAD is really pointing to (version 7?) so i'm just going to submit two patch files: one against the DRUPAL-6 branch version of the .htaccess file, and a second one against the current HEAD version of the .htaccess file.

i'll leave it up to the developers to decide whether magic_quotes_sybase set to 0/Off should be included or not, and whether to apply these patches. it seems that it should (certainly on my system), but i just don't know for everyone else.

let me know if there's anything else you need.

jastern’s picture

Version: 6.3 » 6.x-dev

changing version to 6.x-dev in the hopes that it helps to catch someone's eye to this issue

jastern’s picture

Status: Active » Needs review

hello!? is anyone there?

i submitted this patch back in september, but as of december, 3 months later, i see that versions 6.6, 6.7, and 6.8 have been released without this patch applied. and this bug is still "unassigned"..

i really don't know what i'm doing wrong to get someone's attention on this.. it's really just a simple one-liner, but i'd like to see it get included in the next (6.9) distribution if possible?

whom do i contact to get their attention? any help would be appreciated.. thanks.

damien tournoud’s picture

Status: Needs review » Needs work

Ok, this should probably be moved somewhere else... for example in drupal_initialize() or something like this. We should remove all critical PHP settings from both .htaccess (which applies only to Apache) and default.settings.php (which force users to manually update their settings.php files...).

gábor hojtsy’s picture

Version: 6.x-dev » 7.x-dev
Status: Needs work » Needs review

Sounds like a good improvement to me, at least in line with our current workflows. Not sure what Damien tries to envision here, but refactoring of where we do these settings can be done in a later patch after this issue is resolved. Based on the discussion above, I support this change for Drupal 7 and will commit a backport to Drupal 6 once in Drupal 7.

damien tournoud’s picture

Title: ajax features not working from a non-default multi-site site » Add magic_quotes_sybase = 0 to .htaccess (was: ajax features not working from a non-default multi-site site)
Status: Needs review » Reviewed & tested by the community
Issue tags: +Quick fix

Agreed. Patch applies with offset on HEAD.

webchick’s picture

Version: 7.x-dev » 6.x-dev

Ok, committed to HEAD, per Gabor.

Moving back to 6.x.

webchick’s picture

Priority: Critical » Normal

Also, this is among the edgiest of edge cases I've ever seen in my life (sybase magic quotes AND a "custom" settings.php file), so definitely not critical. ;)

gpk’s picture

Version: 6.x-dev » 7.x-dev
Status: Reviewed & tested by the community » Needs work

Note that magic_quotes_sybase is ini_set() to 0 in default.settings.php in all 6.x versions.
http://cvs.drupal.org/viewvc.py/drupal/drupal/sites/default/default.sett...
Therefore there is nothing to fix in 6.x AFAICS.

This line was removed from default.settings.php in HEAD by #303154: Document ini_set() calls in default.settings.php on the basis that it was redundant. However the logic (http://drupal.org/node/303154#comment-1163968) assumed that magic_quotes_gpc is always turned off by .htaccess; but this is not the case if PHP is running as CGI (in that case, http://api.drupal.org/api/function/fix_gpc_magic/6 does a workaround). Probably the .htaccess change should be reverted, and the ini_set() of magic_quotes_sybase should be restored, but in http://api.drupal.org/api/function/drupal_initialize_variables/7 instead of in default.settings.php.

damien tournoud’s picture

Let's get this into 6.x first (add php_value magic_quotes_sybase 0 in .htaccess where there is already a php_value magic_quotes_gpc 0, it can't hurt and it's good for consistency).

After that we will implement the plan I outlined in #8: move all critical ini_set() settings to drupal_initialize_variables().

gpk’s picture

Version: 7.x-dev » 6.x-dev
Status: Needs work » Reviewed & tested by the community

.htaccess attempts to set magic_quotes_gpc because it can't be set at runtime.

magic_quotes_sybase can be, which it is why it is already in default.settings.php.

I think the original problem was caused by the fact (#4) that jastern created new settings.php files that omitted most of the (usually required) stuff. If he had copied default.settings.php, or even his modified settings.php file, he would have been OK.

gábor hojtsy’s picture

Version: 6.x-dev » 7.x-dev
Status: Reviewed & tested by the community » Needs review

As per #15, this is not relevant for Drupal 6.

damien tournoud’s picture

Status: Needs review » Fixed

Ok, let's close this for D7, then.

Reworking the ini_set() is way out of the scope of this issue.

Status: Fixed » Closed (fixed)
Issue tags: -Quick fix

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