Sito live vuoto in frontend o continua a caricare e non caricare mai

Sto affrontando il problema più strano di sempre in Magento. stiamo usando la versione 1.9.0.

negli ultimi 2 mesi, il nostro sito live è "vuoto" o "continua a caricare" per i browser usati. Significa che in questo browser abbiamo visitato il sito molte volte.

in alcuni browser, funziona bene. in alcuni mostrano in bianco.

ma il backend funziona bene in tutti i browser.

stiamo riscontrando problemi in Chrome, Mozilla, Opera e tutti gli altri browser.

1) Se cancelliamo la cronologia del browser [cache e cookie], che funziona.

2) Se apriamo lo stesso sito in una finestra privata, funziona.

3) Se apriamo il sito con browser appena installati, funziona da tempo. di nuovo vuoto dopo che abbiamo utilizzato il sito.

4) Se cancelliamo la cartella var / session, allora inizierà a funzionare per tutti i browser per qualche tempo. di nuovo sito vuoto.

5) a volte il sito continuerà a caricarsi e non verrà mai caricato ....

Ho controllato system.log & exception.log . ma sembra che non ci siano errori relativi a questo. stiamo usando https per pagine sicure . anche noi abbiamo l' app Andriod live per questo sito. a volte avremo errori fatali:

**Fatal error**: Allowed memory size of 536870912 bytes exhausted (tried to allocate 85 bytes) in /lib/Zend/Db/Statement/Pdo.php or lib/Varien/Object.php or /lib/Varien/Db/Select.php or app/code/core/Mage/Core/Model/Config.php

impostiamo memory_limit = 1512 Mb in php.ini

in .htaccess abbiamo i seguenti file.

php_value memory_limit 1512M php_value max_execution_time 18000

abbiamo commentato questo:

ini_set('display_errors', 1);

ma nessun errore visualizzato nel frontend. Questo è il log degli errori di Apache :

child pid 23845 segnale di uscita Errore di segmentazione (11), possibile coredump in / etc / apache2

Lottando davvero per risolvere questo problema. Questo problema è correlato al nostro codice o è relativo al lato server?

è il cookie del browser il problema principale? In tal caso, cosa è necessario fare per risolvere questo problema relativo ai cookie per tutti i browser. perché ha iniziato a funzionare una volta cancellata la cartella della sessione?

affrontiamo questi problemi durante la navigazione del nostro sito.

Per prima cosa abilita la modalità sviluppatore nel tuo .htaccessfile, aggiungi quanto segue alla fine del file:

SetEnv MAGE_IS_DEVELOPER_MODE "true"

Quindi modifica index.phpe decommenta la riga:

#ini_set('display_errors', 1);

Riga di riferimento:

• https://github.com/OpenMage/magento-mirror/blob/magento-1.9/index.php#L73

Successivamente accedi tramite SSH e cerca un file di dump principale /tmpcome errore di segmento menzionato. A volte può essere anche nella radice /o nella directory principale del sito stesso, ad esempio: /var/www/html/videomergerapp/.

Se non riesci a individuare alcun file di dump principale, potresti voler aggiungere alcune direttive aggiuntive a PHP / Apache.

Dai un'occhiata qui:

• /server/470407/how-to-get-a-core-dump-from-apache-when-segfaulting
• http://www.cyberciti.biz/tips/configure-apache-web-server-for-core-dump.html

Una volta che hai i file core di dump, puoi usare gdb(se --enable-debug) è stato usato quando è stato configurato PHP. È possibile effettuare questa determinazione emettendo quanto segue dalla riga di comando:

php -i | grep debugo semplicemente creando un file di script php nel tuo root del server web con: <?php phpinfo(); ?>nei suoi contenuti e visualizza il file tramite browser web per vedere i valori di configurazione di PHP.

• https://bugs.php.net/bugs-generating-backtrace.php

Se non è stato abilitato, non sarai in grado di ottenere un backtrace completo in PHP stesso ma solo chiamate di sistema di livello superiore e / o backtrace di apache:

Se hai accesso al file di dump principale che emette qualcosa di simile al seguente ti darà una backtrace per aiutarti a trovare il punto di errore:

gdb /usr/local/apache2/bin/httpd /tmp/core.2027

Se si verificano solo problemi casuali sul frontend e mai sul backend, la maggior parte dei segni indica un possibile problema con la codifica del modello. Quando si verificano le pagine vuote (e / o viene visualizzato l'errore se è stata abilitata la modalità sviluppatore e la visualizzazione dell'errore). Accedi al tuo amministratore e disabilita tutte le cache e svuota tutte le cache e gli archivi di cache.

Quindi andare su app/etc/local.xmle impostare i moduli locali di disabilitazione su true.

<disable_local_modules>true</disable_local_modules>

Ciò disattiverà il caricatore automatico dal caricamento di qualsiasi modulo app/code/local.

Per disabilitare i moduli della comunità è più semplice esaminare ciascuno dei file di definizione dei moduli trovati app/etc/modulese disabilitati impostando il nodo attivo su false in questo modo:

<active>false</active>

In questo modo puoi aiutare a escludere se un modulo di terze parti sta causando la fonte del problema attraverso il processo di eliminazione. NOTA: non puoi disable_local_modulese semplicemente passare attraverso tutti i tuoi moduli NON-CORE (qualsiasi cosa Mage_ * ignori!).

Se i problemi persistono, proverei temporaneamente un pacchetto di modelli predefinito andando su Sistema> Progettazione e definendo un nuovo design di qualcosa come default o base. Se i pacchetti di modelli stock funzionano, saprai che la causa dell'errore risiede nei file di progettazione del modello (.phtml).

Molti modelli in cui mi imbatto sono pessimi nell'utilizzare i Mage::getModel()->load()cicli foreach poiché questa è una cattiva pratica e alla fine può consumare grandi quantità di memoria e risorse del server.

Magento ha uno strumento di analisi del codice che può aiutarti a scansionare i tuoi file modello per determinare se c'è una di queste cattive parti di codice:

• https://github.com/magento-ecg/magniffer

Ulteriori letture:

• Fondamenti per il debug di un negozio Magento

Inoltre, può essere utile per tutti in quale cache e spazio di archiviazione della sessione si sta utilizzando app/etc/local.xml.

Spero che sia di aiuto!

Suppongo che ci sia una ricorsione nel tuo codice. Modifica il file lib/Varien/Db/Adapter/Pdo/Mysql.phpe imposta $_debuge $_logCallStacksu true. Questo dovrebbe registrare lo stack di chiamate in un var/debug/pdo_mysql.logfile che dovrebbe darti un'idea se c'è una ricorsione nel tuo codice quando impiegherà un'eternità a caricarsi. Nota che questo file continuerà a crescere molto rapidamente, quindi abilitalo idealmente quando pensi che il problema sia iniziato sul posto.

L'altro modo è disabilitare i moduli / le estensioni con errori che si ritiene possano causare questo. Questa potrebbe essere anche la tua semplice estensione dei prezzi configurabile, prova a disabilitarla temporaneamente e vedi se aiuta a prevenire il problema.

Ho avuto lo stesso problema nel sito Web di un cliente. Controlla il tuo Magento per malware.

Questo è uno scenario ben noto, di solito si tratta di un walware che reindirizza il contenuto dei messaggi dell'utente a un sito Web esterno.

Inizia a controllare index.php, di solito lo hackerano. Scorri il codice fino alla fine, controlla anche a destra e tra le righe commentate nell'intestazione della licenza. Gli hacker vengono utilizzati per nascondere il codice in questo modo.

Hai il "caricamento per sempre" perché tenta di contattare i siti Web bloccati dal tuo ISP.

Dovrebbe essere abbastanza facile trovare il malware, cercare le stringhe "base64", "eval", "mcrypt".

Ho avuto un comportamento simile su un Magento che aveva due siti Web. Il sito si stava caricando bene per alcune pagine e poi si caricava per sempre.

La configurazione degli URL di base era errata. L'impostazione dell'URL di base protetta è stata impostata sul sito Web errato mentre l'URL di base non protetta è stata impostata correttamente.

Quindi, per risolvere questo problema se l'amministratore non funziona nemmeno correttamente, i valori devono essere modificati nella tabella core_config_data per il sito Web giusto, ovvero impostare l'URL giusto con "http: //" e una barra finale nel campo valore corrispondente a il percorso "web / unsecure / base_url" e "web / secure / base_url" per l'ambito_id corretto che rappresenta l'ID del sito Web.

Si noti che l'URL sicuro è http solo perché era un sito Web demo.