assortedchips

Yes, there is an error with the content returned back from the draw.io server. I have reported the bug and will let you know when it has been fixed. Thanks for the report.

With the current version of the plugin, no it can’t do that. I’m considering this as a potential future feature of the plugin, but you’ll have to wait a while for that to happen (sorry). First I’ll have to evaluate the idea more and consider how to address the many security-related repercussions that would accompany such a feature (e.g., what you describe by not requiring logging in would basically be giving any user/hacker a way to inject unsafe content into your site by replacing and mimicking the connection to the draw.io website with their own malicious backend).

It still might be worthwhile to go down this route, I’m just not sure yet. I think any potential security issues can be addressed appropriately. I’ll keep this topic open until I decide for sure what to do. But what you are suggesting represents quite a bit of extra work, so don’t expect this anytime soon.

Not sure if your colophon updates its download links automatically when new plugin versions are released. If not, then you should update the link for DrawIt to download version 1.0.12 – the older version 1.0.10 breaks some installations that use an older version of php. Thanks.

I added an option for choosing wp-content/uploads/drawit_temp/ instead of the default location. Can you update to 1.0.10 and give this a try? Thanks.

So basically you have completely disabled all php temp files on your server? That seems very limiting.

I think the most reasonable solution here is to have an option in the plugin settings page that allows the user to save temp files per the current behavior, or to choose to save temp files to wp-content instead. That should cover just about any configuration and desired behavior that might be encountered. I’ll put this option in the next release.

Maybe you can enlighten me on this topic. I don’t see why saving a temporary file to a directory intended for temporary files should be avoided. This follows the very basic behavior that every web file-submission <form> uses – saving the uploaded file to a temporary directory during upload, then moving it to its final location immediately afterward. In fact, I’m using WordPress’s get_temp_dir() function to determine the temp directory in which to save the temp file, then using WordPress’s media_handle_sideload() function to move it to the wp-content/uploads directory. This is all in the same manner that WordPress does such things. This seems acceptable and standardized to me. I would rather not dirty up wp-content with a custom temp folder that a user might get confused about. I would never want custom temp folders to end up being part of someone’s site backup, for example.

It might work out to provide an option in the plugin’s settings page to allow a user to specify a custom temp directory location, but I hesitate to add settings like that that generally wouldn’t get changed and might make things just look more cluttered.

OK, I see. We were using different ipad images from their menus.

If I use the same one you’re using, then I have the same problem. In is not the foreignObject tag – these cliparts don’t use that. However, I the problem appears to be that the SVG image only provides a source reference to the clipart on a web-based clipart content delivery network (CDN). So in other words, the image isn’t actually contained within the SVG, the SVG loads it from another location anytime the SVG is viewed.

I think if you did the export directly from the draw.io website, then uploaded that SVG image to your WordPress media library, you would have the same problem. Is that correct?

Most browsers don’t allow cross-domain loading for certain types of media, often including SVG images. At least when the image is part of a page’s content – as you pointed out, if you go to the image directly, it displays it just fine.

This can be brought up with the draw.io team – I’m not sure if there is any way for them to grab the actual image data and embed it in the SVG source (it is possible, but I’m not sure what licensing agreements, if any, that they might have for the various clipart).

I should put a warning about this in the settings page in the next version of the plugin, at least until a solution can be reached.

Thanks for the report!