Search functions on localhost, but not on a remote server

[metacodez]

First of all I love this Theme! I upgraded lately from an old version of the Theme to the newest one basically by setting up everything as described. All looks very fine locally.

When I start JEKYLL_ENV=production bundle exec jekyll build and upload the site to my server on http://www.refcodes.org, the search fails: No search results are schown. The Firefox Console states:

Loading failed for the <script> with source “http://www.refcodes.org/assets/js/search-data.json”.

When I run the site locally via bundle exec jekyll serve the search functions all fine.

I tested in Arch Linux using the following brosers and on some Android phones:
Firefox 64.0.2, Chromium Version 71.0.3578.98.

Seems the the Browser has problems loading search-data.json, though when targeting the URL http://www.refcodes.org/assets/js/search-data.json its all there.

I am not sure whether this is a theme issue or located in one of the external dependencies, mayby some one else had a similar issue.

Any help is appreciated, thanks beforehand and best regards,
Siegfried

[mmistakes]

Not a theme issue. Your search-data.json has an issue which it can't be parsed, that's why search isn't working.

If you browse to http://www.refcodes.org/assets/js/search-data.json
You'll see the following errors:

SyntaxError: JSON.parse: unexpected character at line 1 column 1 of the JSON data
Content Security Policy: The page’s settings blocked the loading of a resource at http://www.refcodes.org/favicon.ico (“default-src”).

CORS errors are almost always related to your hosting server. This is why it's working for you locally and not on your production server. I've only ever used Apache servers and you can fix these sorts of things with a .htaccess file. You'll probably have to search around for the actual fix, but I'm fairly confident the theme is working as intended.

[metacodez]

Seems to be a problem with a JavaScript being loaded by the site with the file-suffix json and not js. This addresses the file search-data.json included as script in the lunr-search-scripts.html file (inside the _includes folder).

I modified the lunr-search-scripts.html to load search-data.js instead of search-data.json and made loading all of the scripts relative to the site and not absolute: This way the scripts are always loaded from the hosting server, even if the site is reverse-proxied. After site-generation, I post-proces the _site folder to rename search-data.json to search-data.js. Yes, this renaming-part is hackish :-( Now the search data loads fine.

The reason is that my browser refuses to load a file with a suffix json using a <script> tag which actually is no JSON but moreover a JavaScript file:

The search-data.json is actually JavaScript, having an assignment operator inside, and therefore it is no static data structure such as JSON any more. The browser thinks this is a security issue and blocks the "JSON" from being executed,

Original lunr-search-scripts.html before my modifications:

  <script src="{{ '/assets/js/lunr/lunr.min.js' | absolute_url }}"></script>
  <script src="{{ '/assets/js/search-data.json' | absolute_url }}"></script>
  {%- unless lang == "en" -%}
    <script src="{{ '/assets/js/lunr/lunr.stemmer.support.min.js' | absolute_url }}"></script>
    <script src="{{ '/assets/js/lunr/lunr.' | append: lang | append: '.min.js' | absolute_url }}"></script>
  {%- endunless %}

I changed it as follows:

Modified lunr-search-scripts.html:

  <script src="{{ '/assets/js/lunr/lunr.min.js' }}"></script>
  <script src="{{ '/assets/js/search-data.js' }}"></script>
  {%- unless lang == "en" -%}
    <script src="{{ '/assets/js/lunr/lunr.stemmer.support.min.js' }}"></script>
    <script src="{{ '/assets/js/lunr/lunr.' | append: lang | append: '.min.js' }}"></script>
  {%- endunless %}

It looks more like a linar-search issue and my solution is a bad hack...

[mmistakes]

Check your server config. This 100% seems like the issue. It could be sending the wrong MIME type and headers for .json files.

[mmistakes]

https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP

[metacodez]

This can very much be the case, before the workaround it also occured directly on the bitbucket hosted website at https://refcodes.bitbucket.io as well as on the reverse-proxied http://www.refcodes.org counterpart. I close this ticket as being solved.