Hi,

When I enter text into any of the fields I've created and hit save, the fields are cleared and nothing is saved.

Any help would be greatly appreciated.

Thanks.

Comments

gjbuzz’s picture

I'm having the same problem but only on the admin profile. I can save other user profiles fine. Is this something in my permissions or just a cck error?

ericbroder’s picture

Priority: Major » Normal

I'm unable to replicate this bug. I can save text fields fine with 7.x-1.0-beta1. Not sure exactly what "the admin profile" refers to, but I successfully saved text values on the Main Profile for my admin user (uid 1).

wrybread, gjbuzz, are there any specific steps you can share that will replicate this issue? What is the configuration that leads to this problem?

Jerome F’s picture

Usual fields are saved all right.
I also experience same problem I can't save some infos in fields from contributed modules like Location http://drupal.org/project/location and office hours http://drupal.org/project/office_hours.

I created a related issue in Office Hours:
http://drupal.org/node/1126386
There is already an issue in Location module :
http://drupal.org/node/1064666

Using Profile 2 7.x-1.0-beta2
Office Hours 7.x-1.x-dev (2011-Apr-10)
Location 7.x-3.x-dev (2011-Apr-06)

If I get #1 well it means when you edit the user profile as drupal root admin. But I tried to set the correct permissions, to log in with a test user and to save changes from there but that's no help, for me even the user himself can't save his location.

Jerome F’s picture

Title: won't save new info » Contributed modules widget fields data not saved in Profile2
Priority: Normal » Major

Changing title to a more specific description and priority as there is currently no workaround nor alternative module.

joachim’s picture

Component: User interface » Documentation
Category: support » bug
Priority: Major » Critical
Issue tags: -can't save

I'd go as far as saying this is critical, since without fields you can't do anything useful with this module.

Have you tried the latest dev release?

Jerome F’s picture

Version: 7.x-1.0-beta1 » 7.x-1.x-dev

@joachim: Thank you for your quick answer.
I tried beta2 / last git and last dev today - same behavior with each of them.

The location data saving problem is more a location issue, that's why I assume you marked this as documentation. So if somebody needs to be redirected to the location issue this matter is discussed here: http://drupal.org/node/1064666 - http://drupal.org/node/1061266 apparently everything is not fields API in 7.3.x and the plan is to port content profile to 7.3.x and add more substantial support to D7 new features in the 7.4.x branch.

The patch in http://drupal.org/node/1064666#comment-4297472 temporarilly solves the problem with Profile2.

I use location 7.3.x and also tried Location 7.4.x but it's still unstable.

Jerome F’s picture

Title: Contributed modules widget fields data not saved in Profile2 » Contributed modules widget fields issues in Profile2 (data not saved, API issues...)

Changed title to be more accurate - this issue turns out to point to several issues in core and contributed field widget modules.

This issue is in Profile2 queue because theses issues don't exist in a regular content type and just show up in Profile2 (Though it's likely to happen in other new D7 entities. Yet I didn't experience that anywhere else for the moment.)

I don't know if any of the issues discussed here are directly related to Profile2, your better judge than me regarding that, but at least I think it could be usefull for people using Profile2 and its maintainers to be aware that these issues exist.

I also created a separate issue regarding image field, which seems to be an ajax issue more specific to Profile2: http://drupal.org/node/1127256

joachim’s picture

I'm about to go on holiday so I don't have any time to push this forward.

But there are two possible breakage points:

1. Profile2 relies on the user categories system provided by core -- in effect, a profile2 form is really a special type of user form. That may cause problems with things not getting triggered in FieldAPI.
2. Profile2 is built on EntityAPI module, which may have problems of its own,

Happy bug-hunting! :)

ericbroder’s picture

Status: Active » Closed (duplicate)

I think it might be best to archive this issue as a duplicate. Here's what I'm seeing so far:

Original Post and #1: can't replicate, not enough info.

#3:
- Office Hours issue: #1126386: Add more hours link not displayed in Profile2
- Location issue: #1064666: Location CCK not saving for entities other than nodes

#6: Location issue: #1064666: Location CCK not saving for entities other than nodes

#7: Profile2/Image issue: #1127256: image field "Add a new file" doesn't appear when an image is uploaded in Profile2 when field translation module is active

So I'm having trouble finding anything new that needs work in this issue here. Seems like mostly a compilation of feature requests and bug reports that are already documented elsewhere.

For example, from the Location project page:

Important: Location 7.x-3.x is a direct port of the drupal 6 version (6.x-3.x) and so it still uses node locations and user locations etc. as before instead of properly using the field API. This means that the location field the location CCK module provides will only work for nodes, not users, taxonomy or anything else.

Jerome F’s picture

@Joachim : thank you this makes things clearer.

@ericbroder : Thanks nice sum up. You're right to close this issue as a duplicate.

The purpose of this issue is to document other issues to help people find them easily, and to help understanding why these issues appears specifically in Profile2 and not in a regular content type. I think wrybread who opened it had that kind of problem at the begining, although we don't have any feedback from wrybread since then.

ericbroder’s picture

Thanks Jerome F, good teamwork :-)

kleinmp’s picture

Status: Closed (duplicate) » Active

I am having the exact same issue as the poster where the profile simply won't save. I tracked it down to the point where it's failing and found that the submit handlers are never being called.

I have 6 profile types setup and I am also using og which seems to hook into the same user profile form.

Anyway, when the form is being processed, it gets to a point in drupal_process_form where it checks some values to determine whether it should call the submit handlers.
Currently, line 827:

if ($form_state['submitted'] && !form_get_errors() && !$form_state['rebuild']) {
  // Execute form submit handlers.
  form_execute_handlers('submit', $form, $form_state);

I've found that the value in $form_state['rebuild'] is TRUE for me. I fixed it by adding another validation handler that runs last and set the rebuild value to FALSE. That's as far as I've gone, so I'm not sure where this rebuild value is going wrong.

Taxoman’s picture

Subscribing

Taxoman’s picture

Version: 7.x-1.x-dev » 7.x-1.0

This issue was re-opened the day after version 1.0 was released... Would like to get a confirmation from the people who have experienced this if it is still a problem in 1.0.

fago’s picture

Status: Active » Closed (duplicate)

Looks like this are issues caused by the contributed modules, see #9. Also, we already have a postponed location issue in the queue. Setting this back to duplicate.

If you ran over other issues, please open separate issues for that.