Adding fields to content types no longer works

I encountered this too. It appears that the value of $edit['ctype_id'] is lost before the database insert occurs.

Is there something about the call to flexinode_field_select() near line 377 that fails to set $ctype_id in the called function?

The $ctype_id variable is not always supplied in the function arguments. This patch grabs it from $_POST in those cases.

Doesn't work.

I'm having the same problem. It seems that I had this problem before and found a fix for it somewhere on this site but cannot find it again.

This post dealt with the same issue, but was marked fixed (because it was fixed, at the time).

It seems it's raised it's ugly head again. I'm re-opening the other post and am cross-referencing both posts here but will let someone else decide which is the duplicate of which.

Possible duplicate of node/49279

Hello all,
I have other sites where flexinode is working fine. I noticed this problem as I am developing a new site and trying to create some flexinode forms. So others can look at this and confirm I have created a user "test" with the password "test" with admin privelidges so that you can see this for yourselves. This site is running under the latest cvs version of Drupal so something has changed since 4.7b6 that makes flexinode no longer able to add fields. Hope this helps. I don't consider myself a competent enough programmer to find the problem although I have tried.

Here is my test site: www.newsite.kolacnymusic.com

Feel free to log in and try to add flexinode fields. Please don't change anything else. :) I'll leave it open for a few hours.

The above patch does resolve this problem for me. I am using the latest CVS version of flexinode and Drupal.

I am sorry but I disagree. This patch most certainly does NOT fix the problem.

Try applying this patch and then adding a dropdown menu (select field) to one of your flexinode content types. Where's the input box for your select items?

We need a universal fix for this. I'm sorry but this is not it.

Follow up... Flexinode is adding fields to the database. They are just not being displayed.

More follow up.
You are on the right path. Flexinode is adding fields to the database but is not setting ctype_id. I can manually set this from the database and the fields appear. I'm going to keep looking but I hope someone who is more of a savy programmer can find where it is breaking.

All I can say is that it works for me. I am now able to add drop down menus, text fields, images, and other fields to my flexinode content types. If I revert the patch, the problem returns.

The patch is fairly simple and should not be susceptible to changes in hosting environments. What else could be different between what you and I are using?

This is a patch for the latest CVS version of flexinode, which is intended for the latest CVS version of Drupal. I updated both today. What versions are you using?

It certainly is weird then, because I too am using the latest versions of both flexinode and Drupal. Perhaps one of us should send the other all the files in their flexinode directory (as a start point) to do a file-compare?

Good idea. Here are my modified flexinode files.

Is it possible that page caches are obscuring the matter?

This is really wierd.
When I first read your post, I tried the patch and it still did not work. I've been playing around with different code tweaks on the flexinode module and couldn't get anything to work. After reading your last post, I decided to try the patch again. Voila, it works.
I don't know what I am doing different that I wasn't doing before.

I was thinking that cacheing might be the thing too. At some point I turned it off just to make sure that everything was refreshing. Everything is working like it is supposed to now cache or not.

This piece of debugging code, when placed at the top flexinode_field_form(), could help us chase this bug.

  ob_start();
  print_r($_POST['edit']);
  drupal_set_message('$_POST[edit] = '. ob_get_contents() .'');
  drupal_set_message('$field_id = '. $field_id);
  drupal_set_message('$ctype_id = '. $ctype_id);
  ob_end_clean();

This will show up twice: when defining a term and when submitting the new term.

Patch works perfectly for me. Running up-to-date cvs versions of both Drupal and Flexinode (3.30.06).

Patch worked for me as well.

njivy, can you send in a patch instead of a tarball, so that we can see quickly what you changed, and then identify the problem easier?

Bèr

Just wanted to confirm that the patch worked for me.

One thing that I did was to start with a clean flexinode_field table (emptied it). I didn't want the previously entered flexinode fields to cause any problems.

Patch worked for me by hand, ++

although I had trouble applying it
(version out of synch with todays CVS? Maybe just me)

Can we get this applied please? it's making flexinode unusable at the moment.

I tested the patch against a freshly-downloaded CVS version of flexinode. It worked for me.

This patch works just fine. What's the holdup on getting it committed? I'd say this is pretty critical. ;-)

I am not the maintainer, and I don't have a "contributions" CVS tree installed. So we are waiting for someone with either of those attributes.

I have the same bug -- would love to see this committed if it solves the problem.

Well, that took long enough.

I haven't done exhaustive testing on this yet, but I'm getting an error when attempting to add a new URL field, using njivy's files with 4.7rc2. Maybe I'm doing something wrong...?

I am kindof the unoficial maintainer.

1) I did not see any good reviews, only a lot of fuzzy talk about places where the patch worked and where not. In addition, I got a tarball that added more chaos.

2) Unless I see a clear explanation of the problem the solution, AND a clear review with a short note on how the review was done and how patching solved the issue, I have nothing to confirm a patch does what it should do.

3) Apparently (#29) I was right with my hesitation to commit this. We now have a new bug. should I revert the commit? Can anyone confirm and possibly re-close this issue?

Ber,

Personally I can't confirm or deny anything one way or the other - I am now running a hacked, patched, botched, altered and heavily customised version of flexinode which works for me.

Why haven't I posted it? Because I've put patches in there that nobody seems to have confirmed are wanted or are likely to make it into CVS.

IMO, there have been so many threads on flexinode - not just on the module file but on all the .inc files too. There has been patch after patch after patch and (yes, I'm probably exagerrating now) it seems as though every one of them has somebody for whom it doesn't work.

Flexinode needs sorting out - it needs a FULL-TIME maintainer (that's not intended as a dig, Bers) and it needs ONE up-to-date reliable version of each file that's included in it.

We have 13 pages of active issues on this module - how did we get this into such a mess?

I will summarize to the best of my memory.

Problem:
After defining a field and clicking "Submit", the user is redirected to the list of content types. The system shows a successful status message, but the new field is missing from the list.

An inspection of the database revealed that the value of ctype_id was missing. The newly added field existed in the database, but it was not associated with any content type.

Solution:
See the patch in #3 above.

(Bèr, the tarball you mentioned twice is relevant only to the preceding discussion between Patrick and myself. See #12 and #13.)

Review:
I am able to add urls, emails, images, textareas, textfields, drop-down menus, and numbers. I skipped some field types because they are not 4.7-compatible.

It is possible that the original problem could be solved a better way. I am still learning to wield the new form API. But the evidence suggested that the patch worked and that the patch was needed. So I submitted it. I perceived no active maintainer.

It's your decision, Bèr. Revert, re-code, or close.

For what it's worth, the patch works for me, AFAIK. And I can add urls, too, no problem. Thanks everyone for all the hard work here.

if any runs into newly introduced issues, please open a new issue.

thanks for all your time!

I just DL'd the most recent version from CVS and it seems to be working.