Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
After upgrading to latest HEAD with the new form API, changing anything in admin/settings does not get reflected in the variable table.
Something is broken in the new from API.
To reproduce:
- Upgrade to HEAD
- Go to admin/settings
- Change site name or slogan
- Go to the variable table and verify that the changes are not saved
Comments
Comment #1
darius CreditAttribution: darius commentedStrange, I cannot reproduce it (I did check the variable table). I just updated to the latest CVS version. The reason I looked at this report is because I have other problems after the update, and I suspect they might be related. For example, in the dba (database administration) module, "empty table" stopped working -- it achieves no effect.
Darius
Comment #2
kbahey CreditAttribution: kbahey commentedYou mean updates from the admin/settings page work for you?
Comment #3
darius CreditAttribution: darius commentedYes, updates in /admin/settings work for me. I tried site_slogan in particular.
Darius
Comment #4
kbahey CreditAttribution: kbahey commentedI just checked out a fresh copy from cvs (not download a cvs tarball), and the problem is there.
Check the top of system.module. Mine says:
// $Id: system.module,v 1.236 2005/10/07 06:09:13 dries Exp $
What does yours say?
Comment #5
darius CreditAttribution: darius commentedMine says
// $Id: system.module,v 1.236 2005/10/07 06:09:13 dries Exp $
too. I guess we really need a third person to verify this problem.
Darius
Comment #6
darius CreditAttribution: darius commentedP.S.: I always do a direct CVS checkout (cvs update -r HEAD -dP)
Darius
Comment #7
kbahey CreditAttribution: kbahey commentedI re-checked out everything, and recreated the database ...
Same result. I am using FireFox.
Can anyone verify this?
Comment #8
chx CreditAttribution: chx commentedfile.inc has a
form_set_error
if yourfiles
directory is not writeable and as forms API is a generic mechanism it does not know that such an error is not the end of the world and because there is a form error, it won't execute the form.So darius had a files, kbahey had not.
I feel inclined to change status to by design but I can understand that this is a bit confusing. Do we change the error message to
drupal_set_message
? Do we check for form errors in system settings form and write out a message that your settings are not saved?Comment #9
kbahey CreditAttribution: kbahey commentedI can verify that what chx said is correct: I did not have a files directory, and Apache could not create it because of permissions. Once I created that manually, the form was able to save the data successfully.
Comment #10
chx CreditAttribution: chx commentedThis was fixed in the first batch of fixes.
Comment #11
(not verified) CreditAttribution: commented