So yeah, any ideas why?
Yes – the shortcode wasn’t written with that in mind. (That’s the short answer – long answer to follow…)
Image/file upload is a relatively new feature in the plugin. Like many of the plugin’s features, it was added due to overwhelming user request.
Likewise, the shortcode to directly display a field value was added for the same reason (although it was added long before the upload functions).
When things get added, they are generally added based on what users are asking for and while I try to think through possible scenarios, there are tons of possible ways the plugin ends up being used, so I don’t usually think of everything. If it’s not something that was thought of, then it doesn’t come up until someone uses it in a way other people aren’t using it and then asks a question about it.
When files are uploaded, they are given an attachment (a WordPress post type) ID. That’s what is saved in the meta data for the user. From that post ID, we can create links or gather information about the attachment.
So the numbers you are seeing are the actual value of the stored field.
The shortcode only does what it is programmed to do, which currently is to display the value that is saved for a user for a given field. So in this case, it is displaying exactly what is saved in meta for that user for that field.
Recently (last update) the shortcode was updated to better accommodate fields that use a different saved value than their displayed value (dropdowns, multiple select/checkbox, radios). We can certainly add functionality to accommodate images and files as well.
There are a lot of possibilities with this. I’ll introduce it in the next update (which I expect to be released soon, and there is a beta version on github). In this case, it may be subject to (slight) change. I have to think through the process a little bit.
My initial thought is to just have [wpmem_field field=some_field] display an image if it is an image and a link if it is a file. But I still want to accommodate things that may require custom handling, so I would want to offer the opportunity to display the raw value (which is the post ID) for use in some other capacity.
I’ll need to decide which one of those is the default and which one can be generated by additional attributes. I’d lean toward displaying the image as the default and getting the ID by attribute since that seems like it would be more intuitive for the average user.
Also, I’ll need to work on attributes for display size. Images are automatically resized into some additional sizes. I’ll probably default here to the actual image and use an optional attribute to select a different size.
For now, the beta mentioned above has the update to display image. (Note: that’s subject to change prior to official release based on some of the items mentioned above.)
