CUNY Academic Commons

Can you check your browser console when this is happening? It's possible that this is a symptom of the general 502 problem.

Apparently I wasn't capturing a log in my console of past events and haven't been able to replicate the problem in the past few minutes. I'll keep trying and let you know what I get.

This time, when I "refreshed" the page in the browser, it brought up the "another more recent version of this page exists, would you like to restore from backup?" message. I selected "restore from backup" and the revisions that I had made were retained and the "update" button was active.

Thanks for the additional details, Lisa. I'm able to reproduce the SyntaxError console notice, but not the button behavior.

I'm not certain that they're related to each other. The buttons you've listed (Draft, Preview, etc) are disabled during asynchronous save routines, which may be manual (clicking Update, for example) or, more frequently, automatic (autosave). They should be reenabled when WP reports that the autosave has been successful. It's possible that the JS error you've pointed out would prevent the autosave from completing. But, given that the SyntaxError happens on every pageload, but the button issue recurs only irregularly, I'm guessing that they're unrelated to each other.

I spent a little time trying to debug the SyntaxError. But the error comes from a minified script that's hosted on wordpress.com and hoisted into the Commons by Jetpack. It appears (though it's very hard to verify, because the script is obfuscated) that there's a bug in wordpress.com's JavaScript that causes a parse error when wp.com reports a 403 Unauthorized error. This appears to happen when Jetpack is not registered with wordpress.com. As noted above, I doubt that this is directly connected to the button behavior. But, by way of eliminating possibilities, you might consider either: registering your copy of Jetpack with wordpress.com (https://gcdi.commons.gc.cuny.edu/wp-admin/admin.php?page=jetpack) or, if you're not using it, disabling Jetpack altogether.

As for the buttons. My guess is, as before, that there's a network error that's causing the AJAX autosave routine from finishing. On Chrome, this error might not appear in the regular console, but would only show up when viewing the Network tab in the developer tools (click the XHR filter to view only AJAX-related network activity). If you're still able to reproduce, please open that tab and see what activity is recorded when your buttons do not reenable themselves.

We have not experienced the problems in the past week.... I think we should be able to close the ticket. I'll let you know if it crops up again. Thanks!

Boone Gorges wrote:

Hi Lisa! A quick follow-up to see if you've noticed these issues lately. Thanks in advance for any more debugging!

HI Boone,
I just experienced this problem again. Here's the error that I got: {"wp-refresh-post-lock":{"new_lock":"1477586616:7270"},"wp_autosave":{"success":true,"message":"Draft saved at 11:43:36 am."},"wp-auth-check":true,"server_time":1477586616}
<span class="Z3988" title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Adc&rfr_id=info%3Asid%2Focoins.info%3Agenerator&rft.title=GC+Digital+Initiatives+to+Co-Sponsor+%26%238220%3BEnacting+a+Different+STEM%3A+Building+Equitable+Futures+Beyond+%E2%80%9CDiversity%E2%80%9D&rft.aulast=&rft.aufirst=&rft.source=Digital+Initiatives+at+the+Grad+Center&rft.date=2016-10-27&rft.type=blogPost&rft.format=text&rft.identifier=&rft.language=English"></span>

After for of the errors above, then I get this:

{"code":403,"headers":[{"name":"Content-Type","value":"application\/json"}],"body":{"error":"authorization_required","message":"An active access token must be used to retrieve notifications."}}

Thank you for following up, Lisa! It does sound like some weird confluence of JS issues might be cascading to cause failures in unrelated areas.

Can you clarify for me where you've copied these responses from? Is it the full text of the Response tab of an admin-ajax.php request? The span class="Z3988" element in the response looks suspicious to me. It's generated by the COinS Metadata Exposer plugin, and is intended to be appended to post content. To see it appended to a JSON response payload looks quite wrong, and I wonder whether this is causing a parse error and killing JS on the page.

Yes, what I copied into comment #9 was the full text of the Response tab of the admin-ajax.php request.

The error message in comment #10 is the text from the Response tab to another error. The content under the name tab that goes with that error is as follows:

https://public-api.wordpress.com/rest/v1.1/notifications/?http_envelope=1&fields=id%2Ctype%2Cunread%2Cbody%2Csubject%2Ctimestamp%2Cmeta%2Cnote_hash&number=10

Thanks, Lisa.

I'm totally at a loss. On a lark, I forced the heartbeat API call (the admin-ajax.php request) into appending the <span> element to the end, just to see if it would break the page for me. It didn't. So that was a red herring.

Ray, do you have any ideas?