|traversal||# Posted on June 27, 2013 at 9:03 am|
Hey Bart, unfortunately the image fields do rely on the fact that the files are hosted inside the same WordPress installation – you can’t really point at images hosted at another location.
While this may sound strange, we can’t do a lot of the magic with images without being able to access the files locally in PHP. In the dashboard for example, even if you’re not resizing them, we still need to resize them for display. Also, when we build a tag, we access the locally to be able to get the width and height, and so on.
On the front-end, I imagine you’d be able to display the images still if you manually build tags and just use the raw value, but that obviously takes away the convenience of not needing to do that in our API.
I think the only way for now is to run a separate DB / content folder for dev. Not ideal I know, but I don’t see a way around it.
There is potential to modify this handling a little and try to pull down an image (for resizing etc whenever the image isn’t found in the installation, but this change is not trivial. Your use-case is not unusual of course, so we might need to address this somehow.
Masterpress 1.3.6 is a compatibility release. It resolves an edge case with shared fieldsets not working for MySQL 8 when the fieldset is limited to more than 1 post type or taxonomy or excluding any post types or taxonomies.