I have not seen that exact behavior, so I am not sure why that would happen, but I have a guess. I don’t want to take the time to go walk through the code to figure out exactly what happens, so this will be a little vague & possibly slightly incorrect, but it’s roughly accurate:
When you view the page with the EBD shortcode for the very first time, it will put some information in the database related to the download(s) you have included in the shortcode. This information includes stuff like some of the IDs and possibly the filename and other attributes, including whether or not it has been downloaded. If you are flipping around settings, making new pages with the same ID, etc. it won’t actually store a new row in the DB, instead using the one from before. I believe that that can cause issues sometimes — that is why I usually have people make a brand new file with a filename they have never used before, upload it to Download Monitor (ensuring a new download ID), and make a new CF7 form (ensuring a new ID), when they are having trouble. This eliminates any problem of leftover data in the DB somehow messing things up. That troubleshooting step usually works out for folks. In your case, my guess is that when you mark it as an attachment, that the database is updated to indicate you downloaded the file as soon as the email is sent. The act of marking the file downloaded somehow changes the behavior such that when you then go turn off attachments off & try again, things work. That’s just a guess though – I could be wrong. It may not be the has_downloaded field (or whatever it’s called) that is the bit that flips to “reset” things for you … it could just be the logic path in the code for attachments does something else in the database to “reset” you. You could probably achieve the same “reset” without turning on attachments by uploading a new file (with a name you’ve never uploaded before) and making a new shortcode with that new download_id I suspect.
Sorry that’s vague, but hopefully it helps.
