Pickleburp

Are you using default values for the fields in your testing? In other words, did you hand-type in values or just leave them with the default values?

I was having a very similar issue but I managed to get it working by copying my value out (on the “Edit Page” view in the Dashboard), pasting it back in the same box, and hitting “update.” For some reason, that fixed all of the fields.

I should add that my form validates, sends, and is received successfully. It just won’t process anything from “Additional Settings” on CF7.

I’m having a similar issue with a client’s site. It’s running CF7 3.0.1 on WP 3.1 (haven’t made the upgrade yet).

I’ve tried putting *anything* in the additional settings dialogue and no luck. I’ve tried “location = ,” “location.replace,” and even just a simple alert – on_sent_ok: "alert('Bananas!');" Not even that functions.

Page validates, no JS errors visible in Firebug or Web Developer toolbar. Ultimately I’d actually like to run a little jQuery that will show a built-in “Thank you!” box instead of the form with the thank you message at the bottom, but I need to figure out why its not accepting the script I’m putting in first.

Browsers: Firefox 8, Chrome 15, IE9 tested so far.

Any suggestions are appreciated.

RESOLVED

Finally got this resolved. It turned out to be a problem with the WordPress database.

This morning as I was debugging, I checked the value of the hidden input field for post_ID in a developer copy of the site (on another server) that is running correctly and the version of the live site, and noticed that the field populated with the next incremental value from the DB table wp_posts, while the “broken” version returned zero.

I did some digging around and narrowed down where the incorrect value could be passed in. Firebug was showing that the site was hitting the database and getting a normal response (no “invalid username”, etc.), but it was returning “0” for the post_ID rather than what it should have been, 5746.

I went into /wp-admin/includes/post.php down to the function get_default_post_to_edit on line 403, then commented out line 423 where it grabs the post_ID from the DB and sets it. Instead, I put in $post_id = "5746" and forced it to recognize the next incremental value.

At first, it didn’t seem to do much good, but after refreshing the page a few times and trying to force it to accept, the database stored the value and allowed me to save the post with that ID.

After that I removed all of my comments and echoes and tried making a few new posts from scratch, using Firebug to track the incremental post_ID value in the hidden form input, and everything works perfectly. It allows us to save to draft, publish, and all other new post functions as normal.

As to what caused this exactly, I don’t know. I’m guessing it was some type of data “hiccup” in the database system. At least now if we ever run into this again, we know how to fix it.

Hopefully this can help someone else in the future as well.

Update #2:

So we figure the only reason the theme swap should matter are the template functions included. Since this is a business-to-business site and traffic is low on the weekends, I swapped the theme to Twenty-Eleven this morning. No luck. Even with that theme active, we still go the same error message.

The hosting company assures me that there are no corruption issues with the DB and they claim that everything looks normal. They said there were a few minor errors in the DB a few days ago, but they figured they existed before the issue arose and they went through and cleaned them up.

Very, very frustrating and confusing.

Last night the hosting company had their graveyard tech wipe the site entirely and restore it from a backup version from what we think was before the problem started showing up. Obviously this didn’t fix it or I would have just been updating on that. :\

Anyone? Bueller?

I guess my question is, why would the front-end theme even matter anyway? The problem isn’t in getting posts to display on the site; they display just fine. If it’s a PHP-related issue (again, no errors in the log but I need to enable E_NOTICE in the admin section) then since the PHP files are in /wp-admin/ and /wp-includes/, how could files in /wp-content/themes/ even affect a user’s ability to create a new post?

Maybe I’m overlooking something but I don’t see how they’re related.

Thanks t-p, we’ll have to try it late at night when traffic dies down.

I found a fix.

Go to https://blog.elliotcondon.com/news/advanced-custom-fields-v3-beta/ and download at least v. 3.0.0 beta 2, then overwrite the files in your existing folder (/wp-content/plugins/advanced-custom-fields/), back up your existing files into a separate folder, and then overwrite the existing files on your server with the newly downloaded version.

Note: If you have paid for and downloaded Repeater fields and are currently using them on your site, the beta will fix previously known issues with fields disappearing, not being able to save data to posts, etc., *HOWEVER* any repeater data entered in the old system will no longer save to the database using the same methods, meaning it will no longer associate the data in the repeater fields with your posts.

For example, we have data associated with certain templates using the repeater fields on a new site. We couldn’t change the fields in the repeater field because it would empty the existing data. Using the update, we fixed that issue, but then I had to export the database, find the old fields, and re-enter each of them on the associated pages.

A little bit of a hassle, but its fixed. Looking at the code, it looks like it should be a more permanent fix so we won’t have to do this again in the future.

To geir and anyone else, it appears that the author of the plugin (Elliot Condon) has made a fix in the official version of the plugin more recently. Line 63 has been updated to $data['id'] = (int) $field['id'];, and the “instructions” column has been added to wp_acf_fields in the DB.

I’m still seeing the same issue, however. We built and tested this site extensively on one server, then moved it to a different server for deployment. The odd thing is, it worked fine before but now in a live environment it appears to delete the field when you save it (including Repeater Fields). I’m looking into the database right now but I believe it’s either taking the data out entirely *or* its somehow disassociating the rows so that the DB is looking in the wrong place for the wrong fields?

We also had to do the hack of commenting out line 78 in input_save.php from the core dir in order to save fields on the new server once we got it transferred.

Anyone else come up with a solution or still seeing this issue?

Sorry, didn’t realize this was posting to the general forum, it was meant for the plugin author in question.