Install breaks without Javascript enabled if you have has_js cookie set

See http://drupal.org/node/517688?page=1#comment-2168750 for screenshot and original thoughts.

I think this might be a duplicate of #313606: menu_router error during install, although it's hard to tell for sure since that issue is a bit muddy.

As a temporary workaround, you can manually replace "op=start" with "op=do_nojs" in the URL and it will install fine.

Not sure if this is the same problem here, but the error is similar.

I just installed D7 on xampp and got the an error at this url during the install (url http://localhost/drupal7/install.php?profile=default&locale=en )

Fatal error: Class 'DrupalQueue' not found in F:\www\drupal7\modules\update\update.install on line 13

If you try to install without javascript, please make sure that you clean your "has_js" cookie. The Batch API currently need that cookie and outputs different HTML based on it.

Sorry, i'm an idiot.

My problem had nothing to do with Javascript, but that I had not set enough php memory as the requirements suggest. Slap on the hand, and next time I will read the requirements.

I experienced this problem — trying to install without javscript enabled resulted in total fail.

With javascript enabled, everything was fine. When I disabled Javascript (and forgot I had) installation didn't work. I just froze on the screen where installation should happen... and nothing was moving forward. I waited a while to see if it would work anyway, thinking maybe only the animation was missing and the install would finish anyway, but the install never completed. This was not a php memory need.

Damien Tournoud said:

If you try to install without javascript, please make sure that you clean your "has_js" cookie. The Batch API currently need that cookie and outputs different HTML based on it.

In my opinion, requiring someone who doesn't have javascript to "clean your has_js cookie" isn't a solution. The install needs to simply work, even without javascript. Everything needs to work without javascript. It won't be as pretty, but it needs to work.

Just to confirm this issue. Trying to install without JavaScript resulted in a a screen that looked like the screenshot above (but in the seven theme). No message, no progress indicator, no text on screen to tell me what was happening... I ended up pressing the back button, at which point it proceeded to tell me that installation was successful, shortly followed by an error message mentioning 'DrupalQueue' as per the original post.

This is definitely a problem, and quite a major one I'd say. There is no way to guarantee that users have JavaScript enabled, and you certainly can't tell them to make sure their 'has_js' cookie is cleaned!

The has_js cookie is set by Drupal. So you only get this if you have js enabled, then disable it, then try to install Drupal - which mainly happens to people testing the installer, not actual people trying to install Drupal in the wild, who either have js enabled or they don't.

I agree with catch that this is unlikely to affect regular users — I also ran into this issue when testing an install profile. This seems to be a known problem (#229825: backport "$_COOKIE['has_js'] must die" patch to 7.x)

For example, in authorize.inc

      // If the user switches from JS to non-JS, Drupal (and Batch API) will
      // barf. This is a known bug: http://drupal.org/node/229825.
      setcookie('has_js', '', time() - 3600, '/');
      unset($_COOKIE['has_js']);

So a solution could be to clear the has_js cookie early on in the installation process?

Yeah reading back through this morning, I realized I'm an idiot for not seeing what the has_js cookie is. If the installer works for people who truly do not use javascript, and not just people who had it a moment ago and just now turned it off — then we are fine. That's a non-issue.

Yes, so Drupal is not web accessible if Drupal required JavaScript, see WCAG/BITV 6.3 [1].

[1] http://www.w3.org/TR/WAI-WEBCONTENT-TECHS/#tech-scripts

I just tested this and can confirm the issue. The patch deletes the has_js cookie at the start of the installation process. This does not cover for a user that disables javascript half way through the installation process, but that seems very unlikely.

Commit to 8.x and backport?

rerolled to HEAD

Moving back to Drupal 7, since the 'has_js' cookie is no longer in Drupal 8 so I assume this is no longer an issue there.

I confirm it is not reproducible in Drupal 8. Patch needs to be rerolled for D7.

Rerolled my original patch from #12 so it can be applied with patch -p1.

#229825: backport "$_COOKIE['has_js'] must die" patch to 7.x prevents this bug to happen on initial conditions (no has_js cookie set) but doesn't fix this bug once has_js is already set.

So this patch should be committed independently of 229825 is accepted or not for D7.

Patches #17 and #18 are the same, cross-patched :)

Indeed. But #17 is preferable since the merit is yours :)

Basing on comment #18, I take this issue isn't yet fixed, when the cookie is already set.

(The image used in the IS isn't available anymore. I am changing input format since not all users can post comments when the format is Full HTML.)

Thanks @apaderno, also for the point about #18. I was thinking about comments in #229825 (written two years ago), that the batch operations are working regardless of JS enabled/disabled status. So it is possible that the patch is the mentioned issue changed until it was commited (the last comment here is 9 years ago and the patch was commited 6 months ago).

But I will try to test it and report if this issue is still relevant a causing problems.

I have tested the D7 installation process with has_js cookie (enable with $conf['set_has_js_cookie'] = TRUE;) and javascript disabled. The installation completed successfully without any errors.

Can someone else confirm if this issue is still present, as it does not seems to be. Thanks.

There are no additional comments, so it seems like that the issue: #229825: backport "$_COOKIE['has_js'] must die" patch to 7.x fixed also this issue. Therefore closing this as outdated. Feel free to reopen if someone finds a scenario, which is still not working. Thanks!