|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.1.4 is now available. This release contains an important compatibility fix for WordPress 4.5 to allow correct detection of the taxonomy term editing screen. Without this fix, any custom fields you have attached to custom taxonomies will not be shown at all in the editing form. Note also that MasterPress will still detect the edit screen correctly in…