-1

I'm using some simple AJAX page transition on a Craft CMS site, very similar to these instructions: https://designbycosmic.com/journal/craft-cms-ajax-page-transitions-with-history-pushstate

The basic structure of my code is this:

$.ajax({
  type: 'POST',
  url: href,
  data: {},
  success: function(result){
    // hide old content, load new content, fade in new content
  },
  error: function(){
    console.log("ajax error");
  }
});

"href" is the link to new page to load.

I'm always getting a 400 (Bad Request) error.

I'm using this exact same method for a similar site on the exact same hosting environment and it works fine, so I'm banging my head as to why this would be acting differently.

All of the other answers on this subject seem to be for when "data" is not formatted correctly, but none address the issue when you're simply loading a URL, with no other data.

In this case, what would cause a 400 error?


UPDATE

OK here's the live site for anyone who is kind enough to help further investigate: http://mearch.nz/

Still very incomplete and under development. You should be able to navigate between Home, Projects, and and then any project detail page linked from the Projects index. You'll see that the loading indicator just gets stuck there and the new page never arrives because the AJAX fails.

If you reload any of those pages they work fine. Nothing wrong with the URL. For some reason it's just not accepted as proper data for the AJAX POST.

Now for comparison, here's another website on the same web host, using the same AJAX functions, and same CMS, and it works fine: http://benek.nz/

Benek Lisefski
  • 159
  • 1
  • 3
  • 13
  • 1
    You're doing a POST request but not sending any data? Have you checked the Chrome DevTools to see if the response contains any other information? – Maria Ines Parnisari May 31 '17 at 01:56
  • 1
    the reason you get a 400 response is because the **server** is saying that the request is bad (hence Bad Request) - client side code is rarely going to tell you why the server is responding as it is - you need to fix the server, or if you don't control the server, you need to understand what the server expects, and make your request fit the servers requirements – Jaromanda X May 31 '17 at 01:56
  • @JaromandaX and that is why this is so frustrating for me. It's on the same server environment as another site with almost identical code which works fine. So as far as I know this should be what the server expects. – Benek Lisefski May 31 '17 at 05:10
  • @MariaInesParnisari Chrome DevTools is not telling me anything more than 400 (Bad Request). Where would I look for additional info? – Benek Lisefski May 31 '17 at 05:11
  • Almost ... that may be the key. But you have not provided server side code in the question – Jaromanda X May 31 '17 at 05:12
  • @JaromandaX I've just edited question with link to live site and additional info. – Benek Lisefski May 31 '17 at 22:00
  • How does that help @BenekLisefski? Can't see server code – Jaromanda X May 31 '17 at 22:54

1 Answers1

1

http:// mearch.nz/projects/ does not reference http:// mearch.nz/js/init.js. But init.js needs to be loaded since it contains your javascript-code! In contrast http://benek.nz does reference init.js and therefore it works.

Looks like you use minmee on http:// mearch.nz and therefore it is a bit difficult to debug your issue.

It seems that your request has an CSRF-issue. This normally happens if javascript sends a request to a web-server, which is different to where the javascript comes from.

This is what I did to reproduce your issue:

  • navigated to http://mearch.nz/projects/
  • clicked on link "projects"
  • In Google Chrome: the console window writes "... 400 (Bad Request)"
  • In Google Chrome in the network tab under response I see the server also sent HTML containin text "Bad Request" and "The CSRF token could not be verified."
Aedvald Tseh
  • 1,757
  • 16
  • 31
  • No issue with init.js as on this new site it's just part of the minimee compressed file. The CSRF issue was the problem! Looks like Craft has changed the default - CSRF used to be disabled by default but now on a newer update of the CMS install files it's enabled. So that explains why it was behaving differently on this site as compared to the other. Thank you so much for you help - that clue was enough for me to sort it out. – Benek Lisefski Jun 01 '17 at 01:26