Support

Account

Register Login

Home › Forums › ACF PRO › Submitted images not retrieved in acf_form

Solved

Submitted images not retrieved in acf_form

  • I have an acf_form to submit and edit posts which works without a hitch.
    It has several fields on several tabs, including 2 image fields.
    The first is a simple image field, to show a profile photo.
    The second is a gallery field to create a gallery.

    If I submit a new post with images, they get stored. When I then edit the post again (in the front-end) no images show. They do show on the site and they do show in the back-end so the values are getting stored, but they’re not shown on the front-end form.

    Do I have to include something to make these fields show the stored values ?

  • Hi @beee

    Could you please make sure that you use the acf_form() function on the newly created post template (single.php)? If you don’t use it there, could you please make sure that you set the post_id option with the newly created post ID like this:

    acf_form(array(
    'post_id' => 99,
));

    Where ’99’ is the newly created post ID.

    If you have done it but still have the issue, could you please make sure that you have added the acf_form_head() function on top of your header?

    If still no joy, could you please share the JSON or XML export file of your field group and the code you used to show the forms so I can test it out on my installation?

    Thanks 🙂

  • My acf_form is on a page. By adding a variable I ‘feed’ the proper post ID into the form. Like so: http://dvp.dev/edit-advertentie/?id=492
    And yes it’s on there 🙂

    I use twig so I can’t place php in files, so I created a shortcode which echoes the acf_form and takes the posted variabale into account as the post_id.

    This is the shortcode code: http://pastebin.com/dDANWavf

    This is the code I use to display the form: http://pastebin.com/rFL7mEWF.
    As I said it’s Twig, but basically on line 18 it checks if the user has an id.
    If so, he’s logged in. If no id = provided in the url then no post ID is passed to the form. If an id is passed (like in the URL above), then that post values are loaded into the form. Works on all fields, except the images.

    I’ll send the JSON export in a private post after this.

  • This reply has been marked as private.

  • Hi @beee

    Please keep in mind that you are not supposed to return acf_form(). If you need to return acf_form(), you need to put it in a variable first by using the output buffering feature. This page should give you more idea about it: http://php.net/manual/en/function.ob-get-contents.php.

    Could you please fix it and see how it goes?

    Thanks 🙂

  • I removed both returns from the shortcode, but nothing changed.

    Not quite sure what you mean with by putting it into a variable.

  • This reply has been marked as private.
  • This reply has been marked as private.

  • Hi @beee

    I’ve just checked your site and it seems the front end form doesn’t load the proper data. Could you please try to set one of the custom post type ID to the form’s post_id option like the following?

    acf_form(array(
    'post_id'           => '99',
    'submit_value'      => $submit_button,
    'updated_message'   => $updated_message
));

    Where ’99’ is the custom post ID. If it shows the correct data, then there’s something wrong with how you get the post ID.

    WordPress shortcode needs you to return the string you want to show on the front end. But because acf_form() doesn’t return anything (it just prints the form immediately), you can’t return it. This is where output buffering is used. Instead of printing the form right away, by using ob_start() and ob_get_contents() you can put the string (the form) in a variable first and then later return it from the shortcode. If you don’t know how this works, kindly visit PHP community.

    Also, could you please upload the files that have long content instead of copying it to your reply? Because copying it makes the thread hard to read.

    Thanks 🙂

  • You were right….
    When I changed $post_ID to a hardcoded post ID (which had images), the images showed right away on the front-end.

    I fiddled around with ob_start but I didn’t quite know how/what… So I started to retest everything from the beginning and I think there might have been an incorrect var on line 37, because I have managed to get the form up and running without the use of ob_start.

    Will need to do some more testing but first signals look good. I also need to rewrite the code, because my code is not written DRY, so I need to delete the 2nd instance of the acf_form (but that’s not perse necessary for it to work).

    PS didn’t think I could upload files here, so hence why the long json export in private and pastebin. You may delete them since we don’t need them anymore.

  • Ok, now I have the form working, it brings another question.
    I haven’t looked for it yet, but is it possible to ‘disable’ the photo editor for users on the front-end ?

    I don’t want them to change the image title/description etc.

  • Sorry have another question 🙂

    The image upload seems to be working for administrators. If I use a lower user role, I get an error, saying an error has occurred. But no specification what type of error.

    Only limitations I have is minimum size (dimensions) and max file size.
    I had a file type limitation but took it out for a test. Doesn’t work with/without.

    Do users need a custom capability to upload images ?
    Thought the form took care of it.

    Note: all user roles have the cap upload_files

    Edit: I tested all user roles (with the wp uploader), none works except administrator… All end in error, without specifying what the error is.

    More edit: I noticed it only occurs when using the wp uploader. I set it to basic and now the (single) photo uploader works. But the gallery still uses the wp uploader.

  • Hi @beee

    Yes, to be able to upload the images using wp uploader, the user role should have at least the upload_files capability. Sometimes, they also need to have the create_posts, delete_posts, and edit_posts capabilities.

    If you don’t want to use the wp-uploader, you can always use the basic uploader like what you have done. But I’m afraid it won’t work for the gallery field.

    As a workaround, you can try to use the repeater field instead. That way, you can create a repeater with an image field as the subfield and your visitor can upload the images one by one. If you want to, you can also convert the data from repeater field to gallery field by using acf/save_post action.

    I hope this helps 🙂

  • I added the caps which weren’t added (create_posts) but this didn’t change a thing…

    I find it weird only admins can add images but other roles can’t. I looked through all my code to see if there was something related to current_user_can() but nothing.

    The basic uploader is not what I want, because that way images don’t seem to be linked to a post and some of my functions get bypassed.

    It really frustrates me, been working on this whole day and can’t find the solution (or even a hint) to why users can’t upload.

    I deactivated a whole bunch of plugins but nothing 🙁

    Edit: just switched to twentytwelve and it does work there, so it is something theme related, since that was the only difference. I didn’t deactivate any plugins during this test.

    I tried eliminating a whole bunch of template functions but I can’t get it to work yet.

  • This reply has been marked as private.

  • Hi @beee

    If it’s a theme related issue, I suggest you get in touch with the theme author instead. That’s because the theme author can add anything to the theme that can cause issues with ACF (it can be the PHP or JS code).

    Also, could you please check the JS console of your browser’s developer tools for any error messages with the gallery field?

    Thanks 🙂

  • I am the author, well co-author 🙂 it’s a theme which is written entirely from scratch between colleagues and I.

    I deactivated almost all plugins and a ton of features in functions.php but I can’t pinpoint it yet which annoys the hell out of me, because the images are a main feature of the site.

    Since only admins have the right to upload, I tried looking for current_user_can statements but I checked all of them but no luck.

    There are no console errors, only the console.logs I built in to check if certain stuff is loaded… And no errors appear.

  • Hi @beee

    I’m afraid I can’t help you much with this kind of issue. I’m sorry about that.

    Another thing you can do is assigning all of the capabilities to your custom role and see if you can upload images on the front end form. If you can do it, then you can disable the capabilities one by one to see which ones that are required. After that, you can search them in your template.

    Hope this helps 🙂

  • LOL… are we telepathically in sync or so 🙂

    I just did that and wanted to ‘report’ that it does work when all capabilities are turned on… so will investigate further…

    Edit: I killed caps 1 by 1 until I got to manage_options which seems to be the trigger.

    I then looked throughout the entire template but I can’t find any indication where this would be set. I only have 5 functions which check if current_user_can and non indicate that it could be related.

    I might know a workaround, by adding the capability manage_options to this user role and then extend all if current_user_can('manage_options') queries with specific roles.

    The most important one being to redirect any user who has no business in the admin.

    It’s not ideal, I’m the first one to agree, but I don’t see any way right now… I don’t know where to look anymore.

  • Hi @beee

    That’s sure weird. I’m not sure if you have seen this, but there’s a snippet that I think will help you: https://github.com/WebDevStudios/CMB2/issues/283.

    I’m really sorry that I can’t help you much further 🙁

    Thanks 🙂

  • It appears this piece of code does basically what I suggested above, but in a different way. The snippet does it by code, I did it by adding a cap through user role editor.

    In the post you linked, they filter the user upload, but this is already taken care of by ACF so I don’t need that.

    Do you see any caveats in the way I described to solve it ???

    In a private post above you received the ftp details.
    Would you have some time to d/l the template and search in the files for current_user_can and verify that these are not related to this issue ?
    It’s only 5 or so, so shouldn’t be that much work. Appreciated if you can, too bad if not.

    This so frustrates me like you won’t believe 🙂

  • Hi @beee

    I’ve just checked your theme but couldn’t figure out what’s wrong with it. There are several places where the manage_options capability is mentioned, though:

    dvp/functions.php:141:
'capability'    => 'manage_options',

dvp/inc/admin-columns.php:111:
if ( !current_user_can('manage_options') ) {

dvp/inc/acf.php:172:
if ( !current_user_can('manage_options') ) {

dvp/templates/profile.php:11:
if ( current_user_can('manage_options') ) {

dvp/page.php:28:
if ( current_user_can('manage_options') ) {

    Maybe you can check them again.

    I think setting manage_options to the user role can create issues in the future, especially for plugins that don’t check the role, but only the capabilities.

    Maybe you can add manage_options as a temporary capability when someone is visiting the page. I’m not sure how it works, but I found something related here: http://wordpress.stackexchange.com/questions/53230/temporary-capability-for-current-user-can.

    Because this topic is more related to WordPress, I suggest you visit WordPress community instead because they know better about the core functions than we are.

    Thanks 🙂

  • I understand what you mean, but for the time being I don’t see another way then to add manage_options as a cap for the role(s) in question and expand these current_user_can statements.

    All statements have been checked, double checked, triple checked and disabled.
    Nothing worked.

    in functions.php: capability for adding acf_options_page
    in acf.php: doing nothing now (empty statement), but will be a check if a user needs to get an email or not
    in admin-columns.php: unset yoast stuff
    in page.php: check if an error image should be shown or not
    in profile.php: check to see if user can ‘view’ other profiles. This one needs to be extended, so users can’t view other users’ profile (like I can).

    So nothing I see which is related to ACF’s image/media upload.

    The link you gave looks interesting but have to look into it later if it’s something for me.

  • On a side note… You overlooked another question I asked somewhere in this topic.

    Is it possible to ‘disable’ the photo editor for users on the front-end ?

    Now I have the possibility to let users upload images, I prefer to have them not be able to edit the title/alt/description since I don’t use them. I generate them in a different way.

  • Hi @beee

    I’m afraid this is not possible because ACF uses WordPress attachment modal box, and the editor comes with it as default. There are some threads on the internet with the same question, but the only solution, for now, is to hide it using CSS code.

    I hope this makes sense 🙂

Viewing 25 posts - 1 through 25 (of 27 total)
1 2

The topic ‘Submitted images not retrieved in acf_form’ is closed to new replies.