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

darius’s picture

darius commented

Strange, 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

kbahey’s picture

kbahey commented

You mean updates from the admin/settings page work for you?

darius’s picture

darius commented

Yes, updates in /admin/settings work for me. I tried site_slogan in particular.

Darius

kbahey’s picture

kbahey commented

I 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?

darius’s picture

darius commented

Mine 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

darius’s picture

darius commented

P.S.: I always do a direct CVS checkout (cvs update -r HEAD -dP)

Darius

kbahey’s picture

kbahey commented

I re-checked out everything, and recreated the database ...

Same result. I am using FireFox.

Can anyone verify this?

chx’s picture

chx commented

file.inc has a form_set_error if your files 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?

kbahey’s picture

kbahey commented

I 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.

chx’s picture

chx commented
Status: Active » Fixed

This was fixed in the first batch of fixes.

Anonymous’s picture

(not verified) commented
Status: Fixed » Closed (fixed)