Previous Events button does not work (REST: error 400 “missing parameters”)

An update:

After hours of investigation far outside my competence, I was able to find a workaround for this, and perhaps it could help others.

Using Postman, i tried to find out excactly what was treated different by the two servers, and finally found that the difference was in the server side handling of the Request Header “accept: undefined”.

Checking the plugin source code, I found that the ajax request is set up in obj.getAjaxSettings with accepts: ‘html’, but that this does not affect the headers actually sent by the XHR request. In order to set the header explicitly, I added a line to obj.ajaxBeforeSend telling it to set the request header like jqXHR.setRequestHeader(“Accept”, “*/*”) or jqXHR.setRequestHeader(“Accept”, “text/html”) – the main thing seems to be that the slash needs to be present. So, in context, ?I amended /src/resources/js/views/manager.js (line 531) like this:

obj.ajaxBeforeSend = function( jqXHR, settings ) {
               var $container = this;
               var $loader = $container.find( obj.selectors.loader );

               jqXHR.setRequestHeader("Accept", "*/*");
               $container.trigger( 'beforeAjaxBeforeSend.tribeEvents', [ jqXHR, settings ] );

               if ( $loader.length ) {
                       $loader.removeClass( obj.selectors.hiddenElement.className() );
                       var $loaderText = $loader.find( obj.selectors.loaderText );
                       $loaderText.text( $loaderText.text() );
               }
               $container.attr( 'aria-busy', 'true' );

               $container.trigger( 'afterAjaxBeforeSend.tribeEvents', [ jqXHR, settings ] );
       };

Voilà, it works! So, I guess there must be some kind of bug here, either in the plugin or in jquery itself, that is only triggered by some server setups being stricter about the format of the accept header. I also noticed that this code in manager.js (line 499 emphasized):

obj.getAjaxSettings = function( $container ) {
 var ajaxSettings = {
  url: $container.data( 'view-rest-url' ),
  accepts: 'html',
  dataType: 'html',
  method: $container.data( 'view-rest-method' ) || 'POST',
  'async': true, // async is keyword
  beforeSend: obj.ajaxBeforeSend,
  complete: obj.ajaxComplete,
  success: obj.ajaxSuccess,
  error: obj.ajaxError,
  context: $container,
};

… counterintuitively does nothing to set the actual header. For reference, I am running the newest Chrome 110.0.5481.100 on Linux, but tested also in modern Edge and Konqueror, with the bug consistent in both and also being reported by users on other platforms. The server reports Server API LiteSpeed V8.0.1 Cloudlinux 1.3.

So with this line added, it works for me, for now. But any feedfack is welcome as to whether my fix is the correct one. Thanks in advance!

One more update to the update. Even though my hack worked, reading jquery documentation I suspect I found the root cause of the issue.
The accepts: in obj.getAjaxSettings is not actually necessary, because it depends on the dataType. So, just deleting/commenting out the line “accepts:'html'” (manager.js line 499) actually fixes the issue, because the Accept header will be correct by datatype default.
Alternatively, if the accepts for some reason should be explicit, it would need to be specified as follows, which would give the same result as deleting the line:

accepts: {
   'html': 'text/html'
    },
dataType: 'html',

Hi there!

I’m sorry for the delay, but I am glad you have a workaround for this. Our developers are already working on some improvements to our REST API calls. We have had feedback from other users regarding the jQuery ajax settings object value being invalid and are working on testing some solutions at the moment.

I’ll share this with the team and we will keep you posted.

Thanks,
Gladys

Thank you very much for the update!

Hi @rangoy

Thank you for patiently waiting.

I wanted to give you an update on this issue. We already created an internal ticket for this and the fix should be available on the next release.

I have added your case to our internal ticket. While we don’t have an ETA, you’ll get notified once there is an update and fix.

Regards,
Darian
—-
Internal Bug Ticket: BTRIA-1695

Hello @rangoy !

We released a fix for the issue that you’re facing.
Please update the plugin to the latest version and try again.

Let us know any feedback that you may have

Cheers,

Hi @rangoy

We haven’t heard from you in a while, so I’m going to mark this as resolved. Feel free to start a new thread if you have any more questions.