HI there, could it be that your code is not compatible with PHP7? Just tested it with PHP 5.6.3 and there it’s working fine.
Hey @nonverbla,
Thanks for your support! 😀
There has been a couple of reports about this. I will check again with PHP7 to see if it’s that. But will be looking into it and providing a fix asap.
Wow, what a response time! 🤠
OK, looking forward to the fix.
I just checked on my local machine.. it’s using PHP7.
I’m almost certain it is to do with some of the new features in version 3+ of the plugin. I have been in hospital after a snowboarding accident so haven’t been able to put much time into this lately, but will be as soon as possible.
I’ll keep you posted.
Oh my, I hope you are better! In Germany we have a saying: „Sport ist Mord“, which means “Sports is Murder/Death” 😉
Thanks for looking into it.
Luckily it wasn’t quite death 🙂 Healing up well, lots of broken bones, so it’s a long road, but this week saw me being able to use the computer almost as normal, so I will get more development time in now.
Hey, check if this works for you:
You can test by going to your admin dashboard > plugins > editor, then pick SVG Support, find the file ‘svg-support/functions/attachment-modal.php’ and modify the lines:
$svg_path = get_attached_file( $attachment->ID );
$dimensions = bodhi_svgs_get_dimensions( $svg_path );
with this:
$svg_path = get_attached_file( $attachment->ID );
if ( ! file_exists( $svg_path ) ) {
$svg_path = $response[ 'url' ];
}
$dimensions = bodhi_svgs_get_dimensions( $svg_path );
Reference thread: https://ww.wp.xz.cn/support/topic/500-internal-server-error-523/
-
This reply was modified 9 years, 3 months ago by
Benbodhi.
Just checked it – this changes the 500 Error to just a never-ending request.
I am talking about the admin-ajax.php call that gets executed on both the media panel as well as inside of Advanced Custom Fields image uploads, for example.
-
This reply was modified 9 years, 3 months ago by
Rasso Hilber.
Ok, no problem, I’ll keep digging, was worth a shot.
I can’t reproduce to test on my end unfortunately.
The plugin Query Monitor might be able to provide some valuable insight
I don’t know how to inspect an ajax call with Query Monitor…
Maybe some more information helps: I have my attachments stored remotely on the production server, replacing the attachment_url with the remote host (like if it would be a CDN) in my development environment. Could this be causing the issue?
So… it definitely has to do with the file being not present on my system! The weird thing is that the file_exists call takes ages to complete on my machine.
Oh yeh, you definitely need the the SVG files in the same domain, no subdirectory or externals. This has been the case since the beginning, so I don’t know why these errors are only just popping up now.
Thank you for your time troubleshooting this! Much appreciated.
Ah – good to know, thank you! Actually, it seems like is_file is a bit faster then file_exists.
@benbodhi – I came across this error when working on a site locally that didn’t have all the uploads synchronised (normally I just redirect/proxy any missing uploads to the production server via a rewrite rule).
Although I understand the need for the file to be present, I think at the very least, a missing file should be handled more gracefully. In the snippet you provided above, it doesn’t seem to handle a file that is simply missing. To do this, it should check if the file exists inside the bodhi_svgs_get_dimensions function, where it tries to load the file as XML.
I haven’t had time to look for a proper solution but a start would be something like this in the first line of the bodhi_svgs_get_dimensions function:
if (! is_file($svg) ) return (object) array( 'width' => 0 , 'height' => 0 );
Then at least it won’t try to load a non-existent file, leading to the fatal error when trying to access properties that are not set… If the file really doesn’t exist, it’s impossible to know the dimensions so that’s why I set width and height to zero. What do you think?
Get well soon 🙂
