I am trying to: Attach images to a custom field
Link to a page where the issue can be seen: n/a
I expected to see: image attached
Instead, I got: Error: "Please enter a valid URL address pointing to the image file."
The error is occurring when the image is in a folder with a space in the folder name. This wasn't a problem before a recent update to the Toolset plugin as we've been working with this folder structure without problem for some weeks. There is no problem using these folders/images in other areas, e.g. as a Feature Image. We are using Media Library Folders Pro plugin but deactivating this and using the standard Media Library makes no difference.
We have hundreds of images within this folder structure (which is a copy from the previous version of the website). Renaming the folders will break most of the content in the new site that references these images. Can this change be reversed or can you suggest how we go about amending the existing folder structure and content with minimal effort?
Thanks
Richard
Hi, a recent change was made to help fix a problem where the image name had URL parameters. My guess is you are experiencing a side effect of this change. As a temporary workaround, try adding %20 in place of spaces in the URL, like this:
<em><u>hidden link</u></em>
Does this modification allow you to save the post successfully? Is the image displayed successfully on the front-end of the site?
Please let me know the results so I can report this to our developers.
Hi Christian
Yes, escaping the spaces with %20 worked. The post saved and the image appeared in the front end. I can use that as a temporary workaround but would like to see that automated if possible. One odd thing I experienced was that the left/right arrows keys worked in reverse in the text box containing the filename.
Thanks
Richard
Okay thanks, I'm able to replicate the same issue and it looks like it began to behave this way in Version 3.2. Let me ask my 2nd tier team for clarification on this and I'll give you some feedback shortly.
Hi, I've been trying to replicate this to show my 2nd tier support team but I can't seem to figure out how to get image paths with spaces to save in the custom field values. Can you explain how you were able to get these image paths to pass validation? Did you import the image field values from another site, or manually manipulate database values? I've tested as far back as Views 2.3.5, and spaces in the image paths produce validation errors. Can you provide any additional information on this?
Hi Christian
Apologies for the late reply. Because of the large number of images, these were imported to this draft website from the live site (on the same server) by copying the folder directly on the server. The site uses the Media Library Folders Pro which has a facility to sync images that are manually added, which adds them to the database. I would think that it's this sync process which has effectively bypassed validation. However, looking at the attachment posts created, these do have %20s rather than spaces, so I don't know where the spaces are coming from.
Richard
Okay so let me try to clarify the history here. You mentioned that you're working on a development or draft site based on a live site. Does this mean you are trying to recreate, with Toolset, a live site that was not built using Toolset? Or was the live site initially built with Toolset as well? If it was built with Toolset, are you saying that the custom field images with spaces in their directory paths were working correctly on the original site? I'm trying to understand how the custom field images were originally inserted, and when the spaces were introduced in the file paths. Either the custom field images were initially inserted on the staging sited, or the custom field values were originally set in the live site and then transferred to the staging site somehow. If there was an import process for custom fields, please provide some more detail about that process.
Hi again. The old site was not built with Toolset, it was a bespoke PHP app. This had allowed images to be uploaded with URLs that would not pass validation in WordPress. However, MLF Pro did tidy the URLs when importing the images from the copied directories on the server.
The original gallery content was imported using a bespoke import routine which read the original image URL from the old site, which might contain parentheses, multiple hyphens and spaces, tidy it up in order to match it to the correct attachment post (as created by MLF Pro) and then add the matching attachment post's ID to the Toolset gallery custom field, attached to correct post of course.
I hope that makes sense. Richard
...and then add the matching attachment post's ID to the Toolset gallery custom field, attached to correct post of course.
Actually Toolset custom image fields store a full image URL value, not a reference via attachment ID. This could be one reason why you are not having the same problem in featured images - those are stored against a post using an attachment ID reference in postmeta, not a full URL. The main issue here is that Toolset requires full URLs for custom image field values, and those URLs must not include spaces. Even though the fields may be displayed correctly when spaces exist in the URLs, this format is incorrect and must be fixed. Any import process you use must respect the formatting rules, or you'll experience these problems related to custom field validation in wp-admin.
Hi Christian
I've checked and the import routine does create post_meta records containing the full URL, tidied up and containing no spaces.
E.g.:
.../wp-content/uploads/storage/CLIENTS%20A-F/Birmingham%20Botanical%20Gardens/p3150116-002-1488202963.jpg
The guid in wp_posts attachment record also contains no spaces but the image selector returns the URL with spaces and then can't be saved until they are manually replaced with %20.
Thanks, Richard
Okay so your assertion is that the image selector is working incorrectly because it doesn't replace the spaces in folder names with %20 automatically? I'm trying to understand what you expect from Toolset.
Hi Christian
From what I can see the only place there is a space is in the actual folder on the server. That space is replaced by %20 wherever the image URL is stored in the database. So what appears to be happening in that when an image is selected, either MLF Pro or Toolset replaces the %20 with spaces which then have to be manually changed back again to %20 in order to validate. Given that the selection of the same image as the Featured Image works OK, I'd suggest that it is Toolset that isn't taking the spaces into account.
I accept that it would be impossible to create folder names with spaces in using MLF Pro, and that MLF will change spaces in filenames to hyphens on upload, so the problem is dependent on the way the images have been added to the new site but it would certainly help if Toolset could take this into account. The alternative is for me to manually replace all the spaces with hyphens on the server and then update all the values in the database to match which, given the volume of image files involved, is likely to be prone to error, and the site is now live.
Thanks again.
Richard
I see, and it seems there is not a simple solution here. You would like Toolset to accept spaces in custom field image directory paths, but spaces in directory names are not currently supported. It's not a bug where the system once allowed spaces in folder names but suddenly stopped allowing them - the system never was designed to support the type of data that was imported. If you'd like to see the system start accepting spaces in image paths, then I encourage you to submit your request here: https://toolset.com/home/contact-us/suggest-a-new-feature-for-toolset/
Until that is implemented, unfortunately there's no quick fix I can offer. Manual intervention is required to adjust the data. You must remove spaces from folder names and update the image paths in the database to match the new folder structure reactively, or modify the import process and repeat the import using modified directory names.
Hi Christian
Fair enough. I'd thought it was working earlier but perhaps not. I'll work on sorting this at the server and db level.
Thanks for your help
Richard
Closing per user comments.
