carbon-fields
carbon-fields copied to clipboard
Field Type "file" Not Saved in Nexted Complex Arrangement, Returns Empty JSON Response
Version
- Carbon Fields: 3.6.0
- WordPress: 6.3.2
- PHP: 8.1
Expected Behavior
Attachment is not assigned to file upload, only on certain pages/cases.
Actual Behavior
When calling: https://www.example.com/wp-json/carbon-fields/v1/attachment?type=id&value=1785 upon hitting "Update" on the page, the files are not being saved properly. The result after Update is no effect (the current files, names, tabs are unchanged).
The JSON response is empty from that 1785 attachment mentioned above:
{"id":0,"thumb_url":"","file_type":"","file_name":""}
There are roughly 20 total files as horizontal tabs in a nested "complex" setup. A few other "files" also return an empty JSON response, while most return correctly.
It appears nothing is being saved from this particular page upon page Update. I was able to add a new top-level tab as a test, but it cannot be deleted.
Container definition
/* File Fields */
$fileFields = [];
$fileFields[] = Field::make( 'complex', 'page_tabs', __( 'File Sections' ) )
->set_layout( 'tabbed-horizontal' )
->add_fields( [
Field::make( 'checkbox', 'section_hide', __( 'Hide Section' ) )
->set_option_value( 'hide' ),
Field::make( 'text', 'section_title', __( 'Section Title' ) ),
Field::make( 'complex', 'page_files', __( 'Files' ) )
->set_layout( 'tabbed-vertical' )
->add_fields( [
Field::make( 'text', 'file_title', __( 'File Title' ) )
->set_help_text( __( 'If left blank, file name will be used instead.') ),
Field::make( 'text', 'file_url', __( 'File URL' ) )
->set_attribute( 'type', 'url' )
->set_help_text( __( 'Will take precedence over file upload, if not blank.') ),
Field::make( 'file', 'file_document', __( 'File Upload' ) )
] )
// https://docs.carbonfields.net/learn/fields/complex.html#config-methods-2
->set_header_template( '
<% if (file_title) { %>
<%- $_index + 1 %>. <%- file_title %>
<% } %>
' )
] )
->set_header_template( '
<% if (section_title) { %>
<%- $_index + 1 %>. <%- section_title %>
<% } %>
' );
/* All Pages, except specials */
Container::make( 'post_meta', __( 'Page Options' ) )
->where( 'post_type', '=', 'page' )
->add_tab( __('File System'), $fileFields);
Steps to Reproduce the Problem
- Attach file to "file upload"
- Click "Update" on page
Comments
No server error logs of any kind to help troubleshoot. The only plugin on this site is Classic Editor.
This only started happening recently. Any steps or ideas to start troubleshooting would be highly appreciated.
Thank you.
EDIT:
With further testing by creating a brand new page with no files initially, this issue is actually global to the site.
I can create top-level horizontal tabs, but attempting to delete the tabs will not work. Same with the nested vertical tabs. Attaching a file is "flaky" where sometimes it works. I cannot delete the vertical file tabs once they're created.
I tried rolling back to WP 6.2, but still experienced the same issues.
Image attached for visual reference.
The complete POST request is below:
{
"_wpnonce": "4cd8b7b2c4",
"_wp_http_referer": [
"/wp-admin/post.php?post=2251&action=edit&message=1",
"/wp-admin/post.php?post=2251&action=edit&message=1"
],
"user_ID": "1",
"action": "editpost",
"originalaction": "editpost",
"post_author": "1",
"post_type": "page",
"original_post_status": "publish",
"referredby": "https://www.example.com/wp-admin/post.php?post=2251&action=edit",
"_wp_original_http_referer": "https://www.example.com/wp-admin/post.php?post=2251&action=edit",
"post_ID": "2251",
"meta-box-order-nonce": "6ea638fb1e",
"closedpostboxesnonce": "a81ae73c6d",
"post_title": "TEST+PAGE",
"samplepermalinknonce": "7eec8e9312",
"content": "",
"wp-preview": "",
"hidden_post_status": "publish",
"post_status": "publish",
"hidden_post_password": "",
"hidden_post_visibility": "public",
"visibility": "public",
"post_password": "",
"mm": "11",
"jj": "05",
"aa": "2023",
"hh": "06",
"mn": "45",
"ss": "00",
"hidden_mm": "11",
"cur_mm": "11",
"hidden_jj": "05",
"cur_jj": "05",
"hidden_aa": "2023",
"cur_aa": "2023",
"hidden_hh": "06",
"cur_hh": "06",
"hidden_mn": "45",
"cur_mn": "51",
"original_publish": "Update",
"save": "Update",
"parent_id": "",
"page_template": "default",
"menu_order": "0",
"carbon_fields_container_page_options_nonce": "0a2c8820ea",
"carbon_fields_compact_input[_page_box_heading]": [
"",
""
],
"carbon_fields_compact_input[_page_box]": [
"",
""
],
"carbon_fields_compact_input[_page_tabs][0][value]": [
"_",
"_"
],
"carbon_fields_compact_input[_page_tabs][0][_section_title]": [
"TEST",
"TEST"
],
"carbon_fields_compact_input[_page_tabs][0][_page_files][0][value]": [
"_",
"_"
],
"carbon_fields_compact_input[_page_tabs][0][_page_files][0][_file_title]": [
"FILE",
"FILE"
],
"carbon_fields_compact_input[_page_tabs][0][_page_files][0][_file_url]": [
"",
""
],
"carbon_fields_compact_input[_page_tabs][0][_page_files][0][_file_document]": [
"2204",
"2204"
],
"carbon_fields_compact_input[_page_tabs][0][_page_files][1][value]": [
"_",
"_"
],
"carbon_fields_compact_input[_page_tabs][0][_page_files][1][_file_title]": [
"FILE+2",
"FILE+2"
],
"carbon_fields_compact_input[_page_tabs][0][_page_files][1][_file_url]": [
"",
""
],
"carbon_fields_compact_input[_page_tabs][0][_page_files][1][_file_document]": [
"2020",
"2020"
],
"carbon_fields_compact_input[_page_tabs][1][value]": [
"_",
"_"
],
"carbon_fields_compact_input[_page_tabs][1][_section_title]": [
"NEXT",
"NEXT"
],
"carbon_fields_container_page_options1_nonce": "68bbb6b75d",
"carbon_fields_container_page_options2_nonce": "b8113d5e79",
"excerpt": "",
"metakeyinput": "",
"metavalue": "",
"_ajax_nonce-add-meta": "6dccf98b25",
"advanced_view": "1",
"add_comment_nonce": "4b765f88cf",
"_ajax_fetch_list_nonce": "1d8b9ac7df",
"post_name": "test-page",
"post_author_override": "1"
}
EDIT: Downgrading WP to branch 6.0.6 allows everything to work again, as expected.
Please let me know what the issue could be on the latest WP branches, so that we can bring our client current again.
Upgraded to 3.6.3 to see if this issue is still there, and it is.
I can imagine the team is busy. However, a response would be great, as I opened this issue back in November.
We will rollback to WP 6.0.6 in the meantime. Many thanks!
@zadro Any update on this issue ?
@midkoukou Client is still on 6.0.6 -- still waiting for any insights from others
@zadro removing ->set_attribute( 'type', 'url' ) fixed the bug for me .
@midkoukou Upgrading to WP 6.4.3 and commenting out that line had no effect, unfortunately. The issue remains, and I have once again reverted back to 6.0.6 -- there are no error logs as to why this isn't working.
It seems the owner of this library is not responding to requests. I opened another issue here: https://github.com/htmlburger/carbon-fields/issues/1221 and haven't heard anything there either.
At least make an announcement this plugin/library is not longer supported, so that we can find other solutions.
Very disappointing, as this was my go-to "fields" library for many years and a solid project.
This is an open source project and anyone can try and fix it, not only the "owners" (actually called contributors). They are doing this in their free time, so please show some patience or pay someone to fix your problem if you can't do it yourself. This is how opensource works. Wordpress has had some issues opened for years, but no one calls it an abandoned project.
@gresakg repos do have ownership, which you can read more about here: https://docs.github.com/en/repositories/creating-and-managing-repositories/about-repositories
And, with no response (or commits) in over 6 months, a response on knowing whether the project will continue to be maintained/supported seems a reasonable ask.
@zadro
I've tested with the container definition you provided and the WP and CF versions you mentioned and I could not reproduce the flaky upload problem (also with classic editor plugin).
Regarding the REST API - if you're trying to get fields from the container definition you provided, you need to query the posts route wp-json/carbon-fields/v1/posts/<id>
, where <id>
is the page id, not the attachment route with the attachment id. You also need to allow the field to be visible from the REST API since it isn't visible by default. In your case you'd need to add ->set_visible_in_rest_api( true )
to the outer most complex field.
@atanas-vasilev-dev, thank you so much for replying! I'm not utilizing REST APIs—that is just one of the many endpoints shown in dev tools when clicking update on a POST or PAGE. Per my other issue posted, this issue is ongoing for WP beyond 6.1.5. Also, there are no error logs, so it's very difficult to troubleshoot. We have updated to PHP 8.2, and the issue persists. Maybe I can stage a site and provide login details? Any additional help troubleshooting would be appreciated. Thanks again.