There you go. Currently, the installer has this markup for the clean URL field:
<input class="install" type="hidden" name="clean_url" value="0" />
The JS code that attempts to set this hidden field to 1 if clean URLs are detected to work is the following:
$('#edit-clean-url').attr('value', 1);
This will not work since the hidden field does not have an ID at all, let alone the specified ID. So all Drupal 7 installs on the UI will end up without clean URLs. I tried adding an '#id' on the hidden field, but that is apparently not supported on this field type, and I'd like to fix this bug instead of escalating into extending support for various things in fieldAPI.
So I just edited this line to reference the element by other identification means.
Note that there is code above in the system.js file that similarly references clean url fields. That one is clearly designed to work on both the installer and actual admin config pages, so I'm not 100% clear on how to fix it without breaking the reusability. It looks certain that #edit-clean-url.install in that portion will not match any time either, since the install class is only used on the install element, which will not get the ID.
It is definitely possible that this signifies a major underlying issue where hidden elements will not get IDs generated, but the attached patch fixed the issue for me while more investigation happens.
| Comment | File | Size | Author |
|---|---|---|---|
| #9 | 927652-9-clean-url.patch | 696 bytes | carlos8f |
| installer-clean-url.patch | 584 bytes | gábor hojtsy |
Comments
Comment #1
ksenzeeGábor, do you have any idea when this broke? I'm curious why it used to work and now doesn't.
Comment #2
damien tournoud commentedAlso, could we make this degradable? When you install without javascript, there is no way to enable clean-URLs during the installation.
Comment #3
markabur commentedTested patch in Safari and Firefox, works fine.
Comment #4
carlos8f commentedYes, let's make sure it's not a larger regression with id attributes. That would certainly be bad :P
Comment #5
webchickSomeone with git bisect able to come to the rescue here?
Comment #6
carlos8f commented#168722: Hidden input elements contain invalid characters in ID attributes: auto-generated #id was removed from hidden fields as of last week. Just means we have to specify our own id or use a different targeting method, like the patch in OP. I'm not sure which method would be more kosher here.
Comment #7
carlos8f commentedThe issue linked above also means you have to use #attributes -> id since #id is no longer rendered in theme_hidden(). I'm not sure if I like that change so much, as @Gabor experienced it's confusing when #id isn't supported like that.
Comment #8
moshe weitzman commentedIMO, we should just set #attributes = array('id' => foo) and be done with this critical. No need to re-debate #168722: Hidden input elements contain invalid characters in ID attributes.
Comment #9
carlos8f commentedUsing the #attributes -> id approach.
Comment #10
moshe weitzman commentedclears up the critical. folks who want to change FAPI can do so in a non critical issue.
Comment #11
webchickI guess there's not really a reliable way to add a test for this. Hmmm.
Ok, committed to HEAD.
Comment #12
gábor hojtsyGreat. I was also wondering what else broke, whether other hidden field IDs were relied on is JS, but did not look. We should consider this fixed, so no reason to reopen, just noting.