PluginUs.Net - Business Tools for WooCommerce and WordPress

[realize your idea - make your dreams come true]
Botoscope is currently in early access

Support Forum

You need to log-in to create request (topic) to the support

Errore JSON nella paginazione AJAX del catalogo — "Unexpected token '<'"

The support doesn work on Saturdays and Sundays, so some Friday requests can be answered on Monday. If you have problems with registration ask help on contact us page please
If you not got email within 24~36 business hours, firstly check your spam box, and if no any email from the support there - back to the forum and read answer here. DO NOT ANSWER ON EMAILS [noreply@pluginus.net] FROM THE FORUM!! Emails are just for your info, all answers should be published only here.
The support doesn work on Saturdays and Sundays, so some Friday requests can be answered on Monday.

Salve,

Sto riscontrando un problema intermittente con la paginazione AJAX del catalogo prodotti (funzione woof_draw_products) sul mio sito WordPress/WooCommerce.

Comportamento riscontrato:
Quando mi trovo sull'ultima pagina di una categoria prodotto (es. pagina 3 di 3) e provo a navigare verso un'altra pagina (sia precedente che pagina 1), la richiesta AJAX parte correttamente ma non sempre va a buon fine. Il contenuto resta bloccato sulla pagina corrente, mostrando indefinitamente un indicatore di caricamento.

Errore JavaScript catturato in console nel momento esatto del blocco:

Uncaught SyntaxError: Unexpected token '<',"...<div id="w"..." is not valid JSON

Questo indica che la risposta AJAX, che dovrebbe essere JSON valido, contiene invece un frammento di codice HTML (che inizia con <div id="w"...), corrompendo il parsing lato client.

Cosa ho già verificato ed escluso:

  • Non è un problema di cache: ho confermato che admin-ajax.php è correttamente escluso dalla cache tramite WP Super Cache (regola wp-.*\.php attiva)
  • Il problema si presenta in modo intermittente, non sistematico, anche a parità di configurazione
  • Non sembra collegato a personalizzazioni CSS/JS proprie che ho aggiunto al sito (testato disattivandole)

URL di esempio dove riprodurlo:
https://desmacustom.it/categoria-prodotto/promozionale/felpe/page/3/

Potreste verificare se c'è un warning/notice PHP che viene stampato prima della risposta JSON nella funzione woof_draw_products, corrompendone l'output?

Grazie,
Gennaro Sansone
Desma Custom (desmacustom.it)

Hello Gennaro

Two findings from our side.

First, the URL you gave us does not exist:

https://desmacustom.it/categoria-prodotto/promozionale/felpe/ (Questa pagina non sembra esistere.)

The felpe category returns nothing there. We tested the pagination on https://desmacustom.it/categoria-prodotto/promozionale/ instead, applied a filter (alto), and clicked back and forth through the pages repeatedly. Everything worked, no error, no hanging loader. Please confirm the exact URL where the problem happens.

About the cause, this is our opinion rather than a conclusion. Your site is heavily cached. We can see a Redis object cache running, plus WP Super Cache, and you also mentioned that admin-ajax.php is excluded from page caching. With several caching layers stacked on top of each other, they can fall out of sync with one another. One layer serves something the other layer no longer expects, and the result reaches the browser as HTML where JSON was expected. The fact that the failure is intermittent rather than systematic fits that picture. A code defect would fail every time under the same conditions.

Second, a separate problem we found on https://desmacustom.it/promozionale-donna/. The browser console shows:

Uncaught ReferenceError: woof_husky_txt is not defined

The file ext/by_text/assets/js/front.js is loaded on that page, but the small inline block that defines the woof_husky_txt object is missing from the page source. WordPress normally prints that block immediately before the file. The script runs before its data exists, throws, and everything the plugin binds after that point is never initialized.

The file present but its inline data gone is what happens when JavaScript optimization is pushed too far: combining scripts into one bundle, deferring or delaying them, or stripping inline blocks. Our advice:

Identify which plugin or feature performs JavaScript optimization on your site and switch it off completely, then purge every cache and reload the page. If the error disappears, that confirms the cause.

Then turn it back on, but exclude the plugin scripts from optimization. Most optimization plugins have an exclusion list. Add woocommerce-products-filter to it, so that nothing under wp-content/plugins/woocommerce-products-filter/ is combined, deferred or delayed.

 

Salve,

Due aggiornamenti da parte nostra.

1. URL della categoria — ci scusiamo per la confusione: lo slug della categoria è stato rinominato da"felpe" a"felpa" nel frattempo, subito dopo avervi inviato l'URL originale, per questo restituiva un 404. Ora dovrebbe risolversi correttamente con il nuovo slug.

2. woof_husky_txt is not defined su /promozionale-donna/

Abbiamo verificato la vostra ipotesi sulla cache ed escluso questa causa. Per contesto: non abbiamo alcun plugin di minificazione/combinazione/defer JS installato (verificato l'elenco completo dei plugin attivi — nessun Autoptimize, WP Rocket, W3TC o simili), e le impostazioni Prestazioni di Elementor Pro su questa installazione coprono solo CSS/font/immagini, non JS.

Abbiamo poi testato direttamente la cache:

  • Svuotato completamente WP Super Cache (cache di pagina) — confermate 0 pagine in cache — ricaricata la pagina: errore identico.
  • Svuotato anche Redis Object Cache — ricaricata la pagina: errore identico.

Quindi non si tratta di un problema di sincronizzazione tra livelli di cache. Guardando direttamente il sorgente della pagina: il blocco di script inline che dovrebbe definire var woof_husky_txt = {...} (normalmente stampato tramite wp_localize_script subito prima di ext/by_text/assets/js/front.js) è completamente assente dall'HTML — non rimosso da un livello di ottimizzazione, semplicemente mai stampato, su questa specifica pagina/categoria, indipendentemente dallo stato della cache.

Potete verificare lato vostro sotto quale condizione la funzione di enqueue/localize del modulo by_text decide di non stampare quel blocco? Vorremmo capire se dipende da impostazioni specifiche del widget filtro su questa pagina.

Grazie!

Hello Gennaro

Thank you for the detailed testing, that saved us time. We went through the plugin code for this specific case, and we want to share what we found.

About the pagination issue: thank you for clarifying the slug change. We will retest on the correct URL. Please confirm the exact address where the loader hangs, and also tell us the plugin version you are running and whether it is the free version from WordPress.org or the premium one. You have not mentioned it yet and the two lines behave differently.

About woof_husky_txt is not defined.

We looked for a condition inside the by_text module that would skip printing that block, as you asked. There is none. Here is how it works internally.

The by_text extension registers two things in the same method, at the same moment. It hooks its own script loader to wp_enqueue_scripts, and it registers front.js in the plugin include list. The inline block you are missing is produced by wp_localize_script attached to the handle of another file, husky.js, which is enqueued in that same method with no conditions around it. There is no setting, no widget option, no page type and no category that can turn one of them on and the other one off. They are printed together or not at all.

We also confirmed that the by_text extension is marked as a system extension, so it cannot even be deactivated in the plugin settings. It always loads.

This is why we cannot reproduce the state you describe from our side, and why we believe the file arriving without its data block is caused by something outside the plugin that removes or reorders that script after our code has produced it. The two scripts have different handles, so anything that touches one of them will not touch the other, and the result is exactly what you see.

There are more candidates than the ones we mentioned before, and importantly they are not minification or defer tools, so your check would not have caught them.

First, per page asset managers. Plugins such as Asset CleanUp, Perfmatters, Freesoul Deactivate Plugins or Plugin Organizer let you unload a specific script handle or a whole plugin on a specific URL. That produces precisely this symptom on one page while the rest of the site is fine.

Second, optimization above WordPress. Cloudflare Rocket Loader, a LiteSpeed cache module at server level, or an optimization layer offered by your hosting provider. None of these appear in your plugin list because they are not plugins.

Third, the theme itself, or a page builder. If this page is built with Elementor, its rendering path differs from a normal category template, and a theme or builder can interfere with what is printed in the head.

One quick check that would narrow this down immediately. Open the page source with view-source, not the Elements tab of DevTools, and search for husky.js.

If the husky.js script tag is not there at all, something is unloading our script on that page, or the plugin is not initializing there.

If the husky.js tag is present but the var woof_husky_txt block before it is not, then something is stripping inline scripts from the output.

To isolate it properly, we suggest the following on a staging copy of the site, on a test subdomain, so your live shop is not affected.

Clone the site to the subdomain and confirm the error still happens there.

Switch to a default WordPress theme, for example Storefront or Twenty Twenty Four, and reload the page. If the error disappears, the theme is involved.

Then deactivate all plugins except WooCommerce and our filter. Keep Elementor active only if the page cannot be rendered without it. Reload the page.

If the error is gone at that point, activate the remaining plugins one by one, checking the page after each activation. The plugin that brings the error back is the source.

Please also check two settings on the plugin options page, Advanced tab: the field named Init plugin on the next site pages only, and the force extension disable field. If anything is filled there, it may exclude this page from plugin initialization.

Send us the results of these steps and we will continue from there.