I am trying to:
Save and edit posts from the front end, with a featured image.
Link to a page where the issue can be seen:
I need a private area in which to provide access details
I expected to see:
The featured image being saved to the post when the form is submitted
Instead, I got:
No saved featured image. In fact, If I submit the post from the front end, the featured image is not saved with the post. If I then go and add the image in wp-admin, it works with the post. If I then attempt to edit the post from the front end - even if I don't remove or change the image - as soon as I submit the edit form, the featured image is removed.
I have never experienced this with Toolset before. Please help.
Christian was dealing with this. You have a major security flaw. You just sent by email a transcript of our chat, which has all of the username and password data in for accessing my site as an admin. Email is not secure for this data!!
Okay here's where I am at now. I was able to replicate the problem locally on my copy of your site, even after removing all other plugins and themes completely. I tested by selecting ava-4.jpg and ava-3.jpg existing images from your Media Library, and both failed to save in the new posts. However, the 300x200.png image I uploaded previously does work. So then I copied the ava-4.jpg image from the Media Library and renamed it, then re-uploaded it. The renamed image can be selected and saved successfully from the Media Library. So I'm not sure what could be causing the problem here and I've asked my 2nd tier team to investigate. I will keep you posted here as I receive more information.
Thank you. Do you know how soon they'll be able to get back to me please?
I really appreciate your help.
very best wishes,
Andrew.
I'm not sure, but my day here lasts about another half hour so it will most likely be tomorrow before I can get back to you with details. The second tier staff generally works an earlier schedule because they are in earlier timezones, so hopefully I will have some additional information early in the morning.
Okay thanks for your patience, I have some additional feedback. The problem here is an issue in our software that compares the image 'guid' field from the database against the current domain of the site. In this case it appears that at least some of the images in the database have guid's that are from a different domain, e.g. hidden link. New image uploads contain guids at the test site domain, so the problem does not occur for any of those images. Our developers are working on a fix for this issue so that image guids from other domains will work as expected here. If the site is going to eventually live at the URL used in the guid of these images, you shouldn't have any problems in production. The issue would only occur at a domain other than hidden link. I will be glad to keep you posted as I receive updates about the status of this issue.
This is fabulous news!
So, am I right in concluding that this is something I don't need to worry about, is the cause won't exist on the live site?
Very best wishes,
Andrew.
So, am I right in concluding that this is something I don't need to worry about, is the cause won't exist on the live site?
Maybe, with these two caveats:
1. If the live site domain is indeed hidden link, then you are correct. However, if it's anything even slightly different, like without the "www" for instance, the problem will continue to occur.
2. If you upload new Media Library images in staging and plan to migrate everything from staging to production, then it depends on your migration script whether or not those images would be usable as featured images in Forms. If the migration script will modify the guid values to match the live site, that would be fine. If the script does not modify them and the images continue to use the staging site's guid, that would cause the same problem to occur. Different migration scripts work in different ways, so I can't say for sure whether or not this will be an issue. If you're not migrating, then there's nothing to worry about for this caveat.
Excellent, thank you. In that case I should be fine.
This staging site is literally a sandbox, to test approaches. We won't be migrating this back to live, but once we have figured out if we're happy with a plan, then creating a new instance on the live site, gradually.
Once other point I raised above yesterday:
“You have a major security flaw. You just sent by email a transcript of our chat, which has all of the username and password data in for accessing my site as an admin. Email is not secure for this data!!”
Can you address this please, as I was concerned to see all of this secure supposedly information being passed over email.
Thanks for your excellent support on this, by the way. I've really appreciated it.
Very best wishes,
Andrew.
Yes, thanks for the report. Two things about that:
1. I should have made sure you are aware there are private reply fields below the main chat window where private login credentials can be shared, outside the thread that is emailed as a transcript. Once the information was in the chat, I had no way to remove it.
2. We are testing an update to the system that allows supporters to modify chat messages before the summary is created, so if sensitive information is included in the message thread we can remove that manually before the transcript is sent.
Okay. Does this mean any time I add information in a private area, there's a chance it could go out by email? This is a serious concern.
The chat message threads are emailed in a transcript by default. If you put anything sensitive in those chat message threads, it will be sent out in a transcript unless the supporter removes it manually before the chat is marked resolved. The private reply fields used to share login credentials and FTP info are not part of that transcript, and will never be included in the transcript. I hope that clarifies.
My issue is resolved now. Thank you!
Hi, this issue should have been resolved in the latest release of Forms 2.5.1.
