A ‘fatal error’ should definitely put an entry in your php error log. Can you take a look and see if you can find it? And if you are referring to the latest update being 5.5.10 then changes were really minimal.

I’ve determined the problem isn’t just with SP after all. it seems a bigger issue than that, I know they were talking about blocking access to xmlrpc.php but I’m not sure they went ahead and did that… waiting to hear back from them.

there are wp plugins for disabling xmlrpc.php…  not sure what they were doing…

please let us know what you hear…

I don’t think it’s related to this issue because I’m still having trouble without SP even installed but FYI this is a msg my host sent me earlier.

We also found some errors on your PHP log file:

Aug 28 13:37:27 castle.wsynth.net ool www: PHP Warning – fopen(): http:// wrapper is disabled in the server configuration by allow_url_fopen=0 – file: /mysite.net/wp-content/sp-resources/forum-plugins/plupload/library/sp-plupload-components.php – line: 936 – function: fopen
Aug 28 13:37:27 castle.wsynth.net ool www: PHP Warning – fopen(http://mysite.net/wp-content/forumuploads/peelingtheonion/2014/12/Feggin-Snow-2.gif): failed to open stream: no suitable wrapper could be found – file: /mysite.net/wp-content/sp-resources/forum-plugins/plupload/library/sp-plupload-components.php – line: 936 – function: fopen
Aug 28 13:37:27 castle.wsynth.net ool www: PHP Warning – fopen(http://mysite.net/wp-content/forumuploads/peelingtheonion/2014/12/Feggin-Snow-2.gif): failed to open stream: no suitable wrapper could be found – file: /mysite.net/wp-content/sp-resources/forum-plugins/plupload/library/sp-plupload-components.php – line: 936 – function: spHandleShutdown

Those errors could be contributing to these issues you’re experiencing and would be a good approach to fix them all as soon as possible.

You will want to verify with the plugin author that it does not require the exec() / exec.php or url_fopen functions, as both of those have been disabled on Synthesis hosting for security reasons.

We do support CURL as an alternative to url_fopen. Your plugin author should know if they are using these functions or not.

we typically dont use fopen() because a few hosts do disable it…  looks like the fopen() was added to file uploader recently when a check was added for animated gifs…   but wont impact what you are doing…

have to get with @yellow-swordfish and see if we can change that..

So your hoisting company has suddenly decided to turn off url_fopen support? That suggests this is the case.

And that is a first! While I sort of understand why they might want to do that I haven’t come across any other host doing so and especially have not come across any host just turning stuff off without giving notice that it would happen so people can remove the calls.

We are going to have talk this over this end…

@mr-papa – I’ve not come across a host doing that as I said above. But actually that is just one use. There are others. The uploader one is easy enough to just remove as a temporary fix.

I don’t know that they suddenly turned it off… it might have been done a while ago, I have no idea.

No – it must be sudden or that error would have triggered before. Curiously – it is actually coded so that any error should be ignored and things move on but that seems to have not happened here.

I can give you a quick fix to stop it being called of you can handle a small code edit?

the error in the email the host sent me may well have been there before but I wouldn’t have seen it, as I said, I don’t think it’s related to the issue I mentioned in my original post because the email from the host with that info was a day or two before I had the issues I’m having now.

While I appreciate it, giving me a quick fix for that now isn’t going to help when I can’t even activate the forums (or a bunch of other plugins) right now. I have NO idea wht’s causing the problem and host hasn’t replied in a couple of hours

Actually – looking back you are quite right. Those are warnings not errors so they would not have stopped the processing.

Have you looked in the error log yourself to see if there is anything?

I don’t have access to error logs

hmm… I guess the error log is labeled  “Server Info” .. just found this.

8/29/2015 8:16:21 PM – www: PHP Fatal error: Allowed memory size of 268435456 bytes exhausted (tried to allocate 18349999 bytes) in /var/www/MYSITE.net/wp-includes/wp-db.php on line 1092

but I have no idea what that’s about

It means that while using the database code library WordPress ran out of php memory. There is no way of being able to know what it was trying to do at the time. Personally I would reboot the server and try again. And if that results in the same issue I would be asking my host if they can increase the php memory allotment.

Bit you are using up 256 MB of php memory there. SP alone did not have anything in 5.5.10 to change it’s memory requirements. Have you added new plugins or anything lately that might have tipped the scales?