Well, while I can not access the actual forum of course, the script loading does appear to be clean and without error.

The message you are getting is actually coming from your server. In effect it means the server failed to make the save but has not returned a standard error code so SP is unable to determine why it happened.

I am not sure what error message might be returned but it might be worth asking your host if the php ‘tmp’ folder is available, writeable and not full up with dead files.

The other question, of course, is what has changed? This is not a new installation is it? And if not – and it worked before – then something must have changed somewhere to cause it…

I was notified by my client after upgrading to SP v5.5. That is the only change I recall. I also upgraded whatever plugins were necessary at that time.

The host asked if you’re referring to a test (tmp) folder for different php version?

Omar Jordan said
I was notified by my client after upgrading to SP v5.5. That is the only change I recall. I also upgraded whatever plugins were necessary at that time.

Well – it is not an SP 5.5.0 problem as such. You are the only one reporting this. As I said – it is first and foremost a server issue as I understand it.

The host asked if you’re referring to a test (tmp) folder for different php version?

They are asking what? Do they really not understand what the php tmp folder is? This is pretty basic stuff. It is the default location on the server where php will store files temporarily while they are being processed. Uploads will always use the tmp file location as an interim location during uploading. Under some circumstances, the tmp folder has been known to become full., It should not but it may happen.

I found the tmp folder and doesn’t seem full. I was instructed on how to target it in the wp-config.php file. Is there something specific I should be looking for? 

As per the original question:

Check if the php ‘tmp’ folder is available, writeable and not full up with dead files.

After that then I would check the php error log to see if it reported anything specific on the issue.

The tmp folder is writable (755) and does not appear to be full. I have attached a screenshot

The most recent errors are the following:

"WordPress database error Duplicate entry '0*group' for key 'PRIMARY' for query INSERT INTO wp_sfcache(cache_id, cache_out, cache)"

"WordPress database error Duplicate entry '312*group' for key 'PRIMARY' for query INSERT INTO wp_sfcache(cache_id, cache_out, cache)"

those are not errors, per se…  and have nothing to do with image uploading…

out of curiosity, how big is the image you are uploading? did you ever check the php memory as the error in post #1 says?

the problem is php uploads the image and then we wait via ajax for a response that it was properly uploaded… in this case, your server never responds…  something killed the ajax/script…  hence the 999 unknown message because the server never responded…

with the server in present config, ie no plugins, are any errors reported in the browser console? also, when you upload, you will see an ajax response in the console… can you expand it and see what is reported for the headers and response?

The file is 21K. The PHP memory is 32M.

There has never been an ajax response in the browser console that I recall. But I never checked specifically for that. However, the host dropped the PHP version from 5.3 to 5.2 to “get rid of” the errors. So, I’m actually getting NO errors in the console. I’m thinking that was not wise.

In the past, I have fiddled with the php.ini file. Would that cause an issue?

I am not looking for any errors but the ajax response…  what browser is this?   in most browsers, in the console, when you initiate an ajax response, you will see something added to the console, but not an error… example below

if you expand the little notice (see plus sign in upper left) you will get more info about the ajax response…  see 2nd image:

only issue with php.ini might be if you changed the max upload size in the php settings…

I was using Chrome (Mac). But then I tried using Firefox with Firebug activated and it froze the website. None of the buttons or links were clickable and when I reload the website, it hangs. Absolutely nothing in the console. When I deactivate Firebug, the website is functional. Nothing shows up in the regular console (in Firefox) either.

Are you sure you have the option under the console to display XMLHttpRequests? Nothing will show up if not.

Yes, that option is enabled.

next step is to contact your host… if you get no ajax response at all, the server doesnt even respond to the request…  see if they can track where its going and why the server does not respond…

I have also recently experienced the, Unexpected token prompt, followed by error 999, when trying to upload files.  I contacted my provider and was given the following message (please note I am not nearly as technically savvy as the moderators or the original poster, so I have no idea what the provider is trying to say.).

Hello,

Thank you for contacting HostGator. I’m sorry to hear that you’ve been experiencing problems with your upload functionality provided by the ‘simple-press’ plugin. I’ve investigated the issue and found that the files actually do get uploaded successfully, but there is a coding issue with the plugin which triggers the ‘Unexpected token <‘ error.

I ran a stack trace against the PHP process while uploading a file and found it was uploaded, then moved successfully:

09:27:31 open(“/problem-with-post-edit-buttonome3/advocate/public_html/wp-content/sp-resources/forum-file-uploads/johndurham/2014/07/”, O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 5

09:27:31 getdents(5, /* 7 entries */, 32768) = 224

09:27:31 rename(“/problem-with-post-edit-buttonome3/advocate/public_html/wp-content/sp-resources/forum-file-uploads/johndurham/2014/07/testfile-2.txt_”, “/problem-with-post-edit-buttonome3/advocate/public_html/wp-content/sp-resources/forum-file-uploads/johndurham/2014/07/testfile-2.txt”) = 0

Shortly after that, it writes out a success message:

09:27:31 write(1, “{“jsonrpc” : “2.0”, “error” : {“code”: “0”, “message”: “File successfully uploaded”}, “type” : “file”, “file” : “testfile-2.txt”, “size” : “13”, “width” : “”, “height” : “”}”, 173) = 173

However, the ‘unexpected token’ error is making the upload form believe that the file did not get successfully uploaded. You’ll need to get in touch with the developer of this plugin for an update, or a fix to the coding issue. Please let us know if you have any further questions or issues and we’ll be happy to assist.

I hope this information is helpful.  I look forward to your assistance.

lol.. yeah, not really helpful…  if they feel their is a coding error, and there could of course be one, they should provide just a bit more info…

the fact that the file uploaded is inconclusive…  The server must still respond back to the upload request with success or some sort of message…  So while php and the server may upload the file, there was not any kind of server response to the request so we have no way of knowing if the upload completed properly or not…  hence the unknown 999 response…

the json reponse they indicate there is from the php tring to send out the response… but it never gets to (for whatever reason) the js script that stated the whole process…

or perhaps we are seeing the case of another plugin polluting the response itself with globally inserted data… we have seen some plugins doing this previously, though never on the file uploader response…

so next step would be check at the file uploader js script and see if it receives the response and if the json response if valid, polluted or other…