i noticed these two problems happen with my drupal 6.3:
- the update.php script does not work (see description below)
- the Views module's ajax features do not work (see description below)
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/*.
| Comment | File | Size | Author |
|---|---|---|---|
| #5 | htaccess_DRUPAL-6.patch | 929 bytes | jastern |
| #5 | htaccess_HEAD.patch | 604 bytes | jastern |
| Screenshot2.png | 53.92 KB | jastern | |
| Screenshot1.png | 75.45 KB | jastern |
Comments
Comment #1
damien tournoud commentedThanks for your detailed bug report. Can you give us your exact
<VirtualHost>configuration for all four sites?Comment #2
jastern commentedsure, 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:
Comment #3
damien tournoud commentedOk, 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:
should be:
I can't understand why this is happening, or why you see a different behavior between the default site and the others...
Comment #4
jastern commentedhey, 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
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:
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:
to each of these 3 sections, so the result is of course:
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):
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.
Comment #5
jastern commentedokay, 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.
Comment #6
jastern commentedchanging version to 6.x-dev in the hopes that it helps to catch someone's eye to this issue
Comment #7
jastern commentedhello!? 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.
Comment #8
damien tournoud commentedOk, 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...).
Comment #9
gábor hojtsySounds 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.
Comment #10
damien tournoud commentedAgreed. Patch applies with offset on HEAD.
Comment #11
webchickOk, committed to HEAD, per Gabor.
Moving back to 6.x.
Comment #12
webchickAlso, 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. ;)
Comment #13
gpk commentedNote 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.
Comment #14
damien tournoud commentedLet's get this into 6.x first (add
php_value magic_quotes_sybase 0in .htaccess where there is already aphp_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().
Comment #15
gpk commented.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.
Comment #16
gábor hojtsyAs per #15, this is not relevant for Drupal 6.
Comment #17
damien tournoud commentedOk, let's close this for D7, then.
Reworking the ini_set() is way out of the scope of this issue.