Vanishing .json files

[TheCellar]

As far as I'm aware I haven't changed anything to cause this, but as of last night my product categories (but only the filtered ones) have suffered from an infinite loading time. Refreshing the page twice (once is insufficient, twice always does it) loads it properly, and from then on it will behave normally until the next 'Publish to Web' takes place.

According to the Chrome console, the error is that "AjaxProductList_XXX_XXX.json" and "AjaxProductDetails_XXX_XXX.json" are not found (404) when the page is first loaded. Once each category has been observed, these files exist, and the site behaves as intended. The effect occurs across browsers (Safari, Firefox, Chrome), and observing the page with one browser fixes the issue for all browsers on any computer.

Where are these files going, and why are they not being built automatically? Everything was working perfectly well yesterday afternoon.

(haslemerecellar.co.uk, site still (massively) in progress. Sellerdeck 2013 Business 12.0.2.0.0.0.NVGA)

[peblaco]

Json files for filtering are generated when you visit the page. Check your network settings to make sure all links include www. If not it causes the cart to empty and filtering to fail. P.S. Your Google Analytics code on the home page fails, see fix here.

[TheCellar]

Google analytics code, fixed, thank you.
I corrected the network settings, and now have a sort of inversion of the problem - http://www.haslemerecellar.co.uk/aca...Chile_169.html works fine, but http://haslemerecellar.co.uk/acatalo...Chile_169.html throws a [SyntaxError: parseJSON] (by the looks of it, it's calling www.(etc) from .(etc) and is having the cross-site access disallowed.)

[peblaco]

You should pick one or the other. Your Google listing includes www and that is what most websites use. You can set up a .htaccess redirect file on your server to redirect users and search engines.

[TheCellar]

Ah, I see the issue - thank you. I hadn't realised .htaccess didn't exist by default!

The JSON files are, as you say, still being created on the fly (whose idea was that?), but now everything is being redirected to the WWW prefix they seem to be also loading at the same time. Problem solved, I think - it certainly seems to work.

Thanks!

[TheCellar]

I really ought to have noticed that I needed separate entries for the homepage and 'everywhere else'. Cheers, you've been exceptionally helpful!

[TheCellar]

Fixed! I was overcomplicating things tremendously. Thank you for all your help - this has also fixed the original issue which caused me to notice the missing JSON files, which was slight incompatibility with Chrome, and complete incompatibility with Safari!

[peblaco]

I was discussing json files with SellerDeck support and they sent the below which I thought may be useful to share as it explains the concern posted above:
"It is Working As Designed because if no one has ever visited the page before, the JSON file does not exist. Visiting the page causes the server to run a script that produces the file, the browser then downloads it, if it didn't the filtering wouldn't work. If the same user visits the page again, they will use the browser cached copy, in fact this can be seen in FireBug, the JSON files will appear as ' 304 Not Modified'. Now, if you clear the browser history to simulate a new customer, you will see the json file marked as '200' ok. This is because the browser downloaded the file, but as it already existed the server was not forced to run a script to produce it, so it makes things faster. If you publish to web, and rinse and repeat you will see that the file is missing again, and the server needs to recreate another one allowing for potential new product / changes to existing. In short, New customer, JSON file does not exist, visiting page causes server to run a script, once script produced browser downloads JSON. Same customer revisists page, merchant has not done an upload so nothing has changed, browser uses cached JSON, very fast. New customer visits a page that has been previously visited by a previous customer, JSON file exists so browser downloads it. This saves the server having to run a script."

[Hugh Gibson]

The JSON files are, as you say, still being created on the fly (whose idea was that?)

Mine

Reducing server load and speeding up filtering was the aim.

Note that the emergency release of SD2013 (now in beta) changes the extension of the filter cache files from .json to .js as some shared IIS servers can't easily be configured to allow download of .json files (ticket ref SD-2582).