Errore di sistema dopo installazione estensione
-
impostazioni standard di php
-
-
C'è qualcosa di sbagliato in quello locale, probabilmente. Quando trasferisci "cozza" con quello che normalmente viene utilizzato.
Onestamente non ho mai capito la necessità di sviluppare in locale
-
Aggiornamento: visto tutto con il sistemista il quale è andato a vedere anche i log di errore di Apache.
Nei log compaiono anche altri errori che, con l'aiuto di AI, abbiamo visto essere relativi ad un conflitto nel file stylequalcosa.php (non ricordo bene il nome del file).
Si tratterebbe del fatto che in quel file un stringa viene vista come "data" (nel senso di dato in inglese) mentre invece l'operazione che faccio cerca un array (o viceversa).
L'AI proponeva un workaround che però impattava la sicurezza sicchè stiamo ancora cercando. -
ma è in un file di helix? Secondo me ti conviene contattare quelli di joomshaper, magari hanno già visto l'errore e sanno già come risolverlo...
-
Non credo sia di Helix, il percorso sono sicuro al 99,9% che fosse:
rootdelsito/administrator/components/com_templates/src/Model/StyleModel.phpCi ho pensato a scrivere JShaper visto che ho anche un account a pagamento ma ultimamente la loro prima risposta è di dargli le credenziali di accesso.
Stasera o domani ci provo, magari questa volta non risponderanno così -
il problema non è in joomshaper, è nella differente impostazione dei due server.
Quello locale utilizza WebServer con interfaccia PHP Apache2handler (mod_php)
"Quando in un pannello (tipo Virtualmin, Plesk, ecc.) vedi “WebServer interfaccia PHP Apache2handler”, significa che PHP viene eseguito direttamente come modulo interno di Apache, cioè con mod_php.
Come funziona
Apache riceve una richiesta per un file .php (es. index.php).
Invece di passarlo a un processo esterno (come avviene con PHP-FPM/FastCGI), Apache lo elabora direttamente con il modulo mod_php.
Il risultato (HTML) viene inviato al browser.
In pratica, Apache e PHP sono “fusi insieme” nello stesso processo.Il server su quale fai la copia è WebServer + interfaccia PHP-FPM/FCGI
Quando un utente apre una pagina PHP (ad esempio un sito Joomla), il web server (Apache, Nginx, LiteSpeed, ecc.) deve “chiamare” il motore PHP per interpretare il codice e restituire la pagina già elaborata al browser.
Questa chiamata può avvenire in vari modi, e uno dei più diffusi è proprio:
PHP-FPM (FastCGI Process Manager) con interfaccia FCGI (FastCGI).I concetti principali
WebServer
È il software che riceve le richieste dal browser.
Esempi: Apache, Nginx, Caddy.PHP-FPM (FastCGI Process Manager)
È un sistema che tiene attivi in memoria diversi processi PHP pronti a rispondere.Gestisce in modo efficiente molte richieste contemporanee.
Permette configurazioni avanzate (limiti di memoria, timeout, numero massimo di processi).
È lo standard moderno per far girare siti dinamici ad alto traffico.
FCGI (FastCGI)
È il “protocollo” di comunicazione tra il WebServer e PHP-FPM.Al contrario di CGI tradizionale (che avviava un nuovo processo PHP per ogni richiesta → molto lento), FastCGI tiene i processi PHP già pronti.
In pratica: il web server passa la richiesta al PHP-FPM attraverso FastCGI, riceve la risposta e la invia al browser.
E' una mia ipotesi, ma probabilmente non puoi fare una semplice copia tra server configurati in maniera differente.
Puoi fare comunque la controprova reinstallando da zero, sul server fast cgi, joomla e i vari componenti che utilizzi.
si ringrazia chatgpt per la descrizione dei due ambienti.
-
Ho fatto altre diverse prove con il sistemista e siamo arrivati alla stessa conclusione di Pietro.
Sono proprio diverse le impostazioni ed evidentemente questo mi inibisce la banale funzionalità per la quale J mi restituisce l'errore (ovvero assegnare ad una sola voce di menu un template diverso dal predefinito).Fare la controprova sarebbe ottimale ma onestamente mi porta via troppo tempo. In fondo ho già importato nel server pubblico sia le pagine che i template e quindi non devo far altro che switchare. Certo, avrei voluto farlo dopo prove su pagine meno trafficate, ma se non è possibile...
Di conseguenza non mi restano che due cose:
- dar ragione e accettare il consiglio di Pietro sulla inutilità di sviluppare in locale, per lo meno se non si hanno server configurati a specchio
- impostare come predefinito il template di helix per tutte le pagine del sito
Grazie a tutti per aver seguito il mio thread
-
Suggerisco un'altra prova banale.
Non vorrei che a generare casino fosse il file .htaccess, che copiato dal vecchio ambiente al nuovo genera casino.
Prova, nella nuova installazione a mettere un file .htaccess standard al posto di quello preso dal sito locale. -
Non volevo dire che sviluppare in locale è inutile. Può essere comodo in alcuni casi, ma se il sistema non è allineato come quello di produzione veramente sono dolori, e tu lo stai provando dal vivo
-
Tra un sistema "a processo unico" e uno "a due processi" potrebbe anche starci che ci sia effettivamente un problema di permessi, per cui uno dei due processi possa non accedere correttamente a qualcosa e dare un errore che nel primo caso non ci sia. Però è una di quelle cose che potrebbe trovare solo un sistemista.
Detto ciò, i server locali dovrebbero avere quasi tutti la possibilità di scegliere se usare il php come modulo o con fstCGI (perlomeno, io uso MAMP su Mac e dà questa possibilità). Onestamente ho sempre lasciato tutto di default, e non ho mai avuto problemi, ma mi sa che d'ora in poi ci starò attento, mettendo anche questa impostazione come poi sarà quella del server del provider. -
@pstrada avevo capito quello che volevi dire.. e infatti sono d'accordo con te: su ambienti allineati ha senso, ma sto sperimentando a mie spese che la condizione opposta dà problemi
-
@emaberg ti ringrazio per la specificazione ma onestamente fare cambiamenti e test mi porterebbe via solo tempo per prove che poi erano "solo" un eccesso di zelo in fondo in fondo.
Però almeno ho un insegnamento: se i server non sono allineati NO sviluppo in locale
