The https/http protocol + domain name are missing, so it will trigger the warning message you mentioned above:
Logo Please enter a valid URL address pointing to the image file.
Images Please enter a valid URL address pointing to the image file.
And if you are using CRED form to create the post and setup the image field values, CRED form should not produce such kind of URLs you mentioned above, if the problem still persists, please check the compatibility problem:
Deactivate other plugins and switch to wordpress default theme, and test again
Relevant Documentation:
This support ticket is created 6 years, 9 months ago. There's a good chance that you are reading advice that it now obsolete.
This is the technical support forum for Toolset - a suite of plugins for developing WordPress sites without writing PHP.
Everyone can read this forum, but only Toolset clients can post in it. Toolset support works 6 days per week, 19 hours per day.
I have a cred form on my local dev server that uploads images in two different places. When i try to save the form i get this error message below. The images are shown in the form after i upload them
I'm wondering if it is because of the tld i use for local sites which is .dev.cc
The post was not saved because of the following 2 problems:
Logo Please enter a valid URL address pointing to the image file.
Images Please enter a valid URL address pointing to the image file.
Hello. Thank you for contacting the Toolset support.
Yes - Types checks for the valid URL for image upload and it will try to find the valid URL while validating the image field.
It will try to search for a valid domain in the URL. so we can't save the post due to this security query for the URL.
Currently the valid and supported URLs are the ones starting from hidden link and hidden link or remove the URL validation for your custom field for your localhost environment by editing your custom field and remove url validation.
Minesh thanks very much could you explain how to remove the URL validation of the image field to me - it doesnt appear to be something i can do within CRED
Thanks Minesh- this is a cred Add New Content front end form. The fields are not required and the patch didnt make any difference.
I notice also now that if i create the post directly in the backend. I get the same warning- though it appears to be because the url is relative. If i then complete the url including the .dev.cc domain tld. The post will save However the url (after saving it) is rewritten as a relative URL- See screen shot below.
I have other sites the use cred forms to upload images and the paths are all absolute. So perhaps this is the issue. Im not aware of any setting in wordpress or the types suite that toggles path between relative and absolute. Is there such a thing im unaware of someplace.
BTW Im using serverpress as my lamp stack here - which is somewhat new to me- just in case that might ring a bell
In custom image field created with Types plugin, it accepts only the complete URL format as the field value, for example:
<em><u>hidden link</u></em>
With the https/http protocol + domain name + path + file name, but in your screenshot: hidden link
The https/http protocol + domain name are missing, so it will trigger the warning message you mentioned above:
Logo Please enter a valid URL address pointing to the image file.
Images Please enter a valid URL address pointing to the image file.
And if you are using CRED form to create the post and setup the image field values, CRED form should not produce such kind of URLs you mentioned above, if the problem still persists, please check the compatibility problem:
Deactivate other plugins and switch to wordpress default theme, and test again
Thanks Luo- the screen capture i sent was made after i first fixed the url to be complete which allowed me to save the record. After the record was saved the image path was re-written to be relative.
In any case if figured it out this am. I use Serverpress as my local test environment and they recently added NGROK Integration via a plugin. I turned it off and all the urls became absolute again and the issue resolved.