[Resolved] Does Toolset update existing files in CRED form if the files are not changed?

[Author]

Posts

[matthewS-9]

1. We have a custom field "File Upload" with "Allow multiple instances of this field" selected (i.e. "wpcf-file-upload").

2. We have 2 cred forms: one is for adding this field values, the other is for editing this field values.
Both forms are identical except that one is "Add new content" type and the other is "Edit existing content " type.

3. We accessed the "add new" form, uploaded 2 files, and submitted the form. Everything was fine.

4. Then we moved these 2 files to a new folder (i.e. from /uploads to /uploads/protected), then we updated the corresponding URLs using

$attachments = get_post_meta($post_id, 'wpcf-file-upload', false);

delete_post_meta($post_id, 'wpcf-file-upload');

foreach ( $attachments as $attachment ) {
$new_url = str_replace("/uploads", "/uploads/protected", $attachment);
add_post_meta($post_id, 'wpcf-file-upload', $new_url);
}

Everything was still fine. We could download the files from the new URLs.

5. Then we accessed the "edit" form and submit the form. We just submitted the form with 2 existing files. Nothing was changed.

6. Then the URL of the first file still contained the "/protected" string. The URL of the second file was always reverted back to the original URL (i.e. without "/protected" string).

We expect that the URLs should not be changed if we do not change the files.
The strange thing is that only one file is affected.

Could you please advise if this is a bug of Toolset?

[Christian Cox]

Hello, I would not expect the URLs to change between steps 5 and 6 as you described. Assuming the URL for both images was correct when you load the edit form (step 5), and you submitted the Form without changing those URLs, then I do not understand why the URL would be different in step 6.

- Is this problem replicable, or was it a one-time issue? If it's replicable, can I log in and see the same problem occur?
- Were the images moved manually, like with FTP, or was there an automatic process involved?
- How did you trigger the code in step 4 - was there some event hook used like a save_post hook, or cred_save_data, etc?

[matthewS-9]

Hello Christian,

This issue can be reproduced. Please

1. Go to hidden link and log in with the credentials below

- login credentials removed by admin -

2. Then go to hidden link

3. Click "Upload or select file" and select the "Force.com_Multitenancy_WP_101508.pdf". (This file has the issue.)

4. Click "Update", click "Continue", click "Edit Application".

5. We can access the file using hidden link well.

6. Then just click "Update" again (Nothing needs to be changed), click "Continue", click "Edit Application".

7. Now the link becomes invalid (without _pda).

8. If we click "Replace file" and select the "Force.com_Multitenancy_WP_101508.pdf" again, and click "Update" again. Then everything is fine again.

9. Then we repeat the 4th, 5th and 6th step and the links becomes invalid (without "_pda") again.

We moved the file using by activating the custom code "update_download_links_on_cred_submit_complete" at hidden link > Custom Code. It's where we changed the file name too. The problem still persists after we disable this custom code.

The same process is fine with the "1809.08370v1.pdf" and "2008.00623v2" file that are in the "_pda" folder too.

Please advise.

[Christian Cox]

Thanks, I'm trying to run tests now but the site keeps timing out. I'll have to come back to this in a few minutes to try again later, hopefully it's just a temporary server issue.

[matthewS-9]

We are sorry. The website should be accessible now.

[Christian Cox]

Okay thanks for the update, I was able to log in today and run some tests. Unfortunately I don't see anything obviously wrong. I can see in the Post Editor that the file URL correctly includes the /_pda/ directory, but when editing the post on the front-end the file URL does NOT contain the /_pda/ directory. I'm not sure offhand why this would be happening, so I temporarily switched to the parent theme and temporarily deactivated the Prevent Direct Access plugins, but that does not seem to solve the problem. I also tried disabling the WordPress Media Library management of uploads in this Form's settings, but that does not seem to solve the problem either. At this point I think it makes sense for me to make a clone of the site so I can install it on my local environment and monitor the database directly. Let me know if you approve, and I will install the All-in-One WP Migration plugin, make that site clone, and run some further tests.

[matthewS-9]

Thanks for your investigation.

Unfortunately due to our security agreement with the government website's owner we are not allowed to make a clone of the website locally.

However we are able to replicate the issue with just a fresh install of WordPress and Toolset locally.
We just need to
1. Upload a file using Toolset form, then
2. Move the file to a "_pda" folder manually, and change the file metadata manually in database, and
3. Update the file using Toolset form (without changing anything).

(Therefore we suspect that it is a bug of Toolset form).

Could you please try it?

[Christian Cox]

Unfortunately due to our security agreement with the government website's owner we are not allowed to make a clone of the website locally.
That's fine, I am able to replicate similar behavior in my own environment. In my local tests, can see that the image field URL value is not identical to the custom field value when editing the post with Forms if I manually change the field value in the postmeta table. Forms seems to be relying on the attachment post's GUID instead of the filepath stored in postmeta. I'm not exactly sure why that is happening, if it's expected, if it's expected that the attachment post's GUID should be modified when you move the image, if Forms simply does not work with non-standard upload paths, etc. Let me ask my 2nd tier support team for some additional information and I'll give you some feedback.

[Christian Cox]

After a discussion with my 2nd tier support team, they have confirmed the behavior I described earlier and note that the file attachment post's GUID value is used for the file field's value instead of the postmeta field value when an Edit Post Form is displayed. If you are using a custom process to change the postmeta field value and the file path, it probably makes the most sense to update the file attachment post's GUID value as well to point to the correct file path.

[matthewS-9]

Thanks, Christian.

If we use this code to change a file upload field value.

$attachments = get_post_meta($post_id, 'wpcf-file-upload', false);

delete_post_meta($post_id, 'wpcf-file-upload');

foreach ( $attachments as $attachment ) {
$new_url = str_replace("/uploads", "/uploads/_pda", $attachment);
add_post_meta($post_id, 'wpcf-file-upload', $new_url);
}

then to which value should we update the file attachment post's GUID value or what else should we do to make the Toolset edit form work correctly.

Actually we don't think that this relates to the file attachment post's GUID value that should be unique and unchanged.

We suspect that this is a bug of Toolset forms when pulling and updating an existing file upload field value.

Could you please contact the developer who is responsible for maintaining the Toolset EDIT forms code to clarify this?

[Christian Cox]

then to which value should we update the file attachment post's GUID value or what else should we do to make the Toolset edit form work correctly.
In my local tests, you must update the GUID value in the posts table for the row that corresponds to the file attachment post. See the screenshots here.

Actually we don't think that this relates to the file attachment post's GUID value that should be unique and unchanged.
We suspect that this is a bug of Toolset forms when pulling and updating an existing file upload field value.
Could you please contact the developer who is responsible for maintaining the Toolset EDIT forms code to clarify this?

Whether or not it "should" be related to the GUID is definitely a good question, but whether or not it is in actual practice, not so much. It's definitely related, you can see field values updating when I modify the guid directly in the database. See the screenshots here. I've asked my 2nd tier team to take a closer look at this, and I'm waiting for some additional feedback. It does seem odd that the GUID is used instead of the postmeta entry value, and I understand that modifying GUIDs is considered bad practice. In this case if the site is migrated to a new server and the GUID values were not updated during migration, all these file paths would all be wrong when editing the post with Forms...and if modifying GUIDs is considered bad practice then we have a problem here.

Side note - I've noticed your cred_submit_complete hook update_download_links has no conditionals in place that target a specific Form submission. Without a Form ID-based conditional in place, the code in update_download_links will be triggered for ALL Form submissions. I'm not sure if you are aware of the potential impact of having unrestricted callbacks like this, so I wanted to bring it to your attention.

[matthewS-9]

Thanks so much for your help, Christian.

It is clear that a Toolset edit form should pull the meta value and use it when updating the file upload field value because we are changing the field value, not the field guid.

Instead it assumes that the field value is identical to the guid, and pulls the guid, and uses the guid for updating the file field value.

Therefore we believe that this is a Toolset forms bug.

[Christian Cox]

Okay our 2nd tier team has submitted a ticket to the Forms team to change the behavior here so that the Edit Form pulls the information from the postmeta table rather than using the GUID of the attachment, but in all likelihood a custom code solution will be required for the near future. I don't think this will be changed quickly because according to the team, the GUID is used throughout the Forms plugin and assumed to be the URL of the attachment. In other words, it's not a simple change in one location that can easily be swapped out. We'll need to run a substantial amount of testing to be sure changing this does not break the software in other locations, and other priorities are already lined up for the next couple of release cycles. For now, we recommend changing the GUID to match the new attachment directory path as mentioned before in our discussion. I'll keep you posted here as I receive updates, but as I said I don't expect this will be changed in the near future.

[Nigel]

Hi there

Let me comment directly to share a solution.

If a Form is submitted containing a file field, and upon submission the value of the field is immediately changed via manual intervention such that it is not equal to the attachment guid, then that is unexpected, and likely to have unexpected consequences.

The normal WordPress practice of defining a custom uploads directory by setting the UPLOADS constant in wp-config.php doesn’t run into any such issues and everything continues to work as expected.

But in the case where you want to move just certain files—those submitted using a form—into a custom directory, it will be necessary to update not only the custom field value (the file URL), but also the attachment post guid as well as a custom caching table maintained by Toolset. Although the guid should not ordinarily be changed, that is because of issues that can develop further down the line, and in this case you will be changing the guid immediately when the attachment post is created, so that it matches the custom URL you define for the file field.

An example of how to do that appears below. This code moves the files to a subfolder of the /uploads directory, and then updates the various fields as required, and it can be adapted to your needs if using 3rd party code to manage the files. It works both on add new post forms, and also edit forms, if you add additional files when editing the post.

Meanwhile I am creating an internal ticket for the developers to suggest they review the plugin code to remove references to the guid as a source for the URL. As Christian said, that may take some time, so hopefully this solution will serve you in the meantime.

/**
 * Move files uploaded by Forms to other directory
 */
add_action('cred_save_data', 'tssupp_form_submit', 10, 2);
function tssupp_form_submit($post_id, $form_data)
{
    if (in_array($form_data['id'], array(8, 9))) { // Add Post and Edit Post forms

        $meta_key = 'wpcf-pdf';
        $folder = 'protected';

        $current_urls = get_post_meta( $post_id, $meta_key, false );
        foreach ($current_urls as $current_url) {

            if ( !strstr( $current_url, $folder ) )
            {
                $attachment_id = attachment_url_to_postid( $current_url );
                $current_path = get_attached_file( $attachment_id );
                
                $path_info = pathinfo( $current_path );
                
                // move the file to protected folder
                $moved = rename( $current_path, $path_info['dirname']."/protected/".$path_info['basename'] );
                
                // update post_meta with new URL
                $new_url = str_replace( '/uploads', '/uploads/'.$folder, $current_url );
                update_post_meta( $post_id, $meta_key, $new_url, $current_url );
                
                // update guid with new URL
                global $wpdb;
                $data = array( 'guid' => $new_url );
                $where = array( 'ID' => (int)$attachment_id );
                $wpdb->update($wpdb->posts, $data, $where );
                
                // update toolset guid cache with new URL
                global $table_prefix;
                $data = array( 'guid' => $new_url );
                $where = array( 'post_id' => (int)$attachment_id );
                $wpdb->update( $table_prefix.'toolset_post_guid_id', $data, $where );
            }

        }
    }
}

[matthewS-9]

Thanks, Nigel.

We did use a trick to overcome this Toolset forms issue without changing the guid.

When there is a reliable fix please let us know.