Risposte nei forum create

Stai visualizzando 15 risposte - dal 1 al 15 (di 212 totali)
  • È un bug. Lo correggeranno appena possono.

    tizz

    (@tizz)

    Sono contenta, grazie a te per il riscontro.

    tizz

    (@tizz)

    Mi sembra molto chiaro che la follia non si riferisce in nessun modo all’utente, ma esclusivamente a chi nel supporto ufficiale del suo tema gli consiglia di rimuovere quella riga di define nel wp-config.php.

    Io la ritengo una cosa folle – o una “sciocchezza madornale” se è più bon ton – che, non uno qualsiasi che passava da lì, ma coloro che si suppone siano se non gli autori del tema perlomeno chi li rappresenta, dicano una cosa del genere non sapendo cosa sia la riga define(‘DB_NAME’, ‘xxxx’) nel wp-config e, quindi, gli suggeriscano di rimuoverla.

    Come dovrebbe reagire l’utente, scusa? O prende atto che coloro che stanno dietro il suo tema sono degli incapaci, e lo cambia, oppure ne prende atto ma continua a usarlo lo stesso perché gli va così.
    Mi sfugge cosa ti preoccupa, e lo dico sinceramente.
    Se pensi che il termine sia troppo “forte” e pensi che possa offendere non so chi, boh, censuralo, oscuralo, o mettici un francesismo al suo posto.

    Io mi ritengo libera di criticare apertamente ciò che si legge nel web – perché la questione è solo questa – e di avvertire un utente che è venuto qui a chiedere supporto del rischio che corre in certe mani.
    Ma per il resto, sono d’accordo, qui non sono a casa mia e, se proprio ambite a vincere il premio del supporto più politically correct del web ;), allora ditemelo… e me ne starò zitta.

    tizz

    (@tizz)

    Il file wp-config.php è il file di configurazione e serve a WordPress per comunicare con il database, non c’entra quindi niente con i contenuti del sito.

    tizz

    (@tizz)

    Ho visto ora che nel supporto di siteorigin.com dove hai chiesto aiuto hai pubblicato il define con il nome del DB. Non si pubblicano mai le credenziali, né parti di esse! Chiedi quindi subito che quella riga sia rimossa dal forum pubblico.
    La cosa più preoccupante però è che il tizio (che dichiara di essere uno del supporto ufficiale del tema) dica di non sapere cosa sia quella costante – chiunque installi WP sa o deve sapere cosa sia quel define: è il nome del DB, com’è chiaro – ma addirittura ti consigli di cancellare quella riga, senza poi che l’altro del supporto intervenga.
    È pura follia, io fossi in te cambierei tema.

    tizz

    (@tizz)

    Io sul tuo sito attualmente vedo QUESTI errori:

    Warning: include(1): failed to open stream: No such file or directory in /wp-config.php on line 30
    Warning: include(): Failed opening ‘1’ for inclusion (include_path=’.:/php7.1/lib/php/’) in config.php on line 30

    Che normalmente stanno a significare che mancano dei file.
    In ogni caso, prima di tentare un nuovo aggiornamento manuale, credo che ora tu debba sistemare il wp-config.php, perché se c’è quella roba alla riga 14 può esserci anche altro di sbagliato alla riga 30 proprio a livello del percorso.
    Non è certamente normale – all’apparenza sembrerebbe un attacco hacker, ma potresti anche esser stato/a tu ad aver copiato e mischiato pezzi a caso: parti mancanti o aggiunte relative alla configurazione del file mischiate con le chiavi di salatura.
    Se ci fosse un errore sul nome del database WP non comunicherebbe con il database e il sito non si vedrebbe, quindi credo che le credenziali ci siano comunque prima o dopo quel poccio.

    Devi quindi fare backup di quel wp-config e metterlo da parte. Poi compili correttamente un nuovo wp-config partendo dal sample fornito nel pacchetto di WordPress, usando Notepad++ e seguendo questa guida, senza aggiungere nient’altro e facendo attenzione che le credenziali del DB siano giuste.
    Poi elimini quello vecchio (via FTP dal server) e carichi subito quello nuovo.

    PS: comunque, a lato, non dovevi aggiornare a PHP 7.1 senza prima informarti che tutti i plugin e il tema in uso fossero compatibili, né farlo in concomitanza con altri aggiornamenti.

    tizz

    (@tizz)

    Usare un tema responsive. Se il tema dichiara di esserlo ma in effetti non lo è, rivolgiti al supporto del tema.
    Se il tema è responsive ma tu l’hai modificato, allora ripristina le condizioni di default.

    tizz

    (@tizz)

    tizz

    (@tizz)

    @valeazzi, è buona prassi non consigliare plugin non aggiornati da anni.
    In questo caso, stiamo parlando di ben 6 anni. Inoltre se dai un’occhiata al suo supporto, si vede chiaramente che aveva dei problemi già 4 anni fa.
    Consiglio @sergiopinnaprato di non usarlo. Ce ne sono altri tra cui puoi scegliere.

    tizz

    (@tizz)

    Allora, diciamo che il redirect automatico di WordPress si comporta in modo tale che è difficile dare per scontato ciò che farà o non farà, e come lo farà (a parte quei casi che ti dicevo prima, default>postname, eccetera), in presenza di tanti e diversi URL da gestire, quali quelli che si possono trovare in una struttura complessa di permalink come la tua e nella variabile di tanti post/pagine/categorie/magari custom post types e chissà che altro.
    Quindi a mio parere, ma mi posso sbagliare, direi che no, il caso singolo di quell’URL non prova da solo che WP gestirà tutti i redirect in modo corretto. Ma, ripeto, posso sbagliarmi e sono pronta a smentite, che credo si dovranno basare su esperienze e test diretti.

    Perché allora quel vecchio link funziona? Perché quando WordPress trova quello che sarebbe un 404 esegue una ricerca sullo slug (diciamo, su un frammento) dell’URL e cerca un post o una pagina con quello stesso frammento. Se ne trova uno, usa la funzione wp_redirect() e reindirizza a quello che gli sembra l’URL corretto.
    Avendo quindi tu “postname” sia nel vecchio che nel nuovo URL, è probabile che WordPress si sia “attaccato” a quello per il redirect.
    Lo farà anche per tutti gli altri? Non lo so.
    Può darsi, ma se stiamo parlando di un sito ben avviato e consolidato da anni con migliaia di post, io non mi fiderei fino in fondo. Un test serio non si può basare su una singola prova, quale che sia il test e quale che sia la prova.
    Poi, c’è il discorso che ho già fatto: WP per fare quel redirect usa una funzione PHP, non so quindi cosa può succedere a livello di prestazioni in un sito con 2.000 post con magari un traffico quotidiano notevole.

    Da qua, non potendo andare a fondo alla questione, potrei dirti allo stesso modo, in buona fede, ritenendo entrambi i consigli validi: no, non fare un cambiamento così importante su un sito grande già indicizzato!, oppure: fallo, basta che il redirect 301 sia fatto bene e ne vale la pena.
    Magari potresti affiancarti a un professionista per fare questa operazione che è comunque delicata, dato il volume del sito.

    …(nonché per indicizzare i nomi delle categorie rispettive).

    I nomi delle categorie apparirebbero comunque, e sarebbero inviati ai motori nella sitemap delle categorie come in ogni altro caso, solo che invece d’essere /categoria/nome della categoria/ sarebbero /nome della categoria/ e basta.

    • Questa risposta è stata modificata 6 anni fa da tizz.
    tizz

    (@tizz)

    No, WordPress non fa redirect automatici se si cambia l’intera struttura dei permalink, a meno che non si passi dalla struttura predefinita a postname, o in altri casi semplici, tipo da day and name a month and name e viceversa. Oppure li fa da vecchi slug a nuovi slug, in pratica quando cambi URL di post individuali.

    È quindi altamente consigliato approntare un redirect 301, meglio se nell’.htaccess e non via PHP soprattutto in presenza di molti articoli e pagine come nel tuo caso.
    Se lo fai per motivi SEO, prendi in considerazione il cambio al semplice /postname, invece che /category/postname, se non hai motivo di confusione tra i titoli o altro che giustifichi la presenza di /category/. Se scegli l’opzione /postname, puoi sfruttare un tool di Yoast che crea automaticamente il redirect 301 da inserire nell’.htaccess.

    Oppure, in ogni caso, puoi usare questo plugin, che non conosco personalmente ma nella cui pagina leggo che “di default gestisce tutti i redirect usando WordPress” (significa che li fa via PHP), ma che “si può configurare in modo che i redirect siano salvati sul file .htaccess e gestiti da Apache stesso” (se il tuo server è Apache), e nel tuo caso sarebbe meglio dato che passare per WordPress rallenterebbe il sito, meglio quindi che il redirect avvenga sul server prima. Da quanto si legge, dovrebbe esser possibile farlo anche su un server Nginx.

    I redirect 301 sono necessari al fine di reindirizzare tutti i link esterni da altri siti e i contenuti indicizzati, e subito dopo dovrai provvedere a creare una nuova sitemap da inoltrare ai motori di ricerca.
    Per quanto riguarda i link interni, se reindirizzi non è strettamente necessario un search and replace, ma te lo consiglio comunque per evitare altri redirect anche se gli eventuali ritardi fossero minimali.

    tizz

    (@tizz)

    Non è strano che tu l’abbia rilevato dopo una settimana (anzi, avresti anche potuto notare il problema dopo più tempo) per vari motivi ora insondabili, a partire da una cache persistente, all’aver visto il sito da logged-out, da altro browser o da altro dispositivo (appunto, mobile), da una minificazione non effettuata per una qualsiasi causa, o perché i file interessati non erano stati ancora richiesti, oppure per certi conflitti non ancora manifestati, tipo con quell’altro plugin di ottimizzazione, con file già minificati di altri plugin o temi che vanno in contrasto se si usa la minimizzazione automatica, eccetera.

    W3TC è un plugin che richiede un’attenta (e non immediata) configurazione, da rivedere e mettere a punto nel tempo.

    Come già detto sopra, ribadisco: con W3TC (e probabilmente altri plugin di cache) occorre un’osservazione nel tempo da rinnovare sull’onda dei vari aggiornamenti, propri e di altri plugin/temi/WP. È un plugin che può dare molte soddisfazioni, ma NON è configurabile e perfettamente funzionante in un giorno o in una settimana, né dall’utente senza esperienza in merito, sebbene sia gratuito e disponibile a tutti.

    Controlla di averlo disinstallato completamente, perché non basta disattivarlo e cancellarlo, occorre prima svuotare la cache e poi una volta cancellato eliminare tutti i file relativi sul server (quelli creati dal plugin e che si trovano al di fuori della sua propria cartella) e controllare che l’.htaccess sia stato ripulito; ci sono guide nel web che spiegano come disinstallarlo correttamente.

    Tra i plugin gratuiti di cache è tuttora il migliore per quantità e qualità di prestazioni che offre, anche se ultimamente è più aggressivo di un tempo e come minimo occorre fare una minificazione manuale e tenere disattivate alcune opzioni, personalmente non so cos’altro consigliarti anche perché bisogna conoscere tutta l’installazione a fondo e non sarebbe neppure serio provarci da un forum, e in presenza di un altro plugin di cache e/o di ottimizzazione come quello che dici di avere è molto difficile che ci sia compatibilità.

    tizz

    (@tizz)

    In quella sezione vedi il traffico di ciò che (gli account de)gli autori hanno generato. In altre parole, dato che il tuo sito è mono-autore, quel numero dovrebbe corrispondere alle statistiche delle pagine visitate, se controlli.

    Se ci fossero altri autori, vedresti chiaramente sotto ogni autore il traffico generato dai loro articoli/pagine.
    È la “freccetta” la chiave della comprensione:
    Infatti, se guardi bene, vedi *la freccetta* puntata verso il basso alla sinistra del tuo nome che, se cliccata, apre la finestra sotto, che giustamente ha la freccetta per rientrare: significa che quelle visite sono strettamente legate al tuo account, perché sono pagine che hai scritto tu.

    tizz

    (@tizz)

    Disattivare tutti i plugin per debug in caso di problemi è sempre un ottimo consiglio, io stessa è sempre il primo che do, e l’utente dovrebbe o potrebbe senz’altro provare anche questa strada, ma W3TC può dare ogni genere di problemi di visualizzazione se non ben configurato, soprattutto utilizzando la funzione di minimizzazione automatica.
    In questo caso credo si trattasse proprio di un problema relativo alla minimizzazione di W3TC, anche se non l’ho visto e quindi naturalmente parlo solo su base empirica o intuitiva (e ciò potrebbe lasciare il tempo che trova).
    Inoltre mi sembra d’aver capito, da ciò che @giuliaguarrera ha detto, che il problema è sparito eliminando W3TC.

    tizz

    (@tizz)

    W3TC è un plugin che richiede un’attenta (e non immediata) configurazione, da rivedere e mettere a punto nel tempo.

Stai visualizzando 15 risposte - dal 1 al 15 (di 212 totali)