Risultati della ricerca per 'Wordpress sql server'
-
-
Buongiorno a tutti. Ho un grosso problema con la visualizzazione dei caratteri speciali che vengono usati nella lingua Rumena. Sono per la maggiore caratteri accentati.
Vengo a problema. Sulla versione locale dove ho la seguente configurazione:Mysql versione 5.7..25
PHP:7.4.2
Wordpress: 5.3.3non ho alcuna problematica di visualizzazione
Sul server remoto ho la seguente configurazione:
Mysql versione 5.1.63
PHP:6.1
Wordpress: 5.3.3Ho problemi. I caratteri speciali sono visualizzati con il ?.
Il settario della collection del DB è Latin1_general_ci
ho dettato anche con una query la codifica a Utf8.Ma il problema persiste.
Chiedevo se era un problema di versione del Mysql o di PHP o di entrambe. Questo perché per aggiornare il serve devo spegnere 5 DB e la cosa non mi diverte.
Ho provato poi a commentare le seguenti line nel file wp-config
//define(‘DB_CHARSET’, ‘utf8’); //define(‘DB_COLLATE’, ”);Adesso i caratteri speciali vengono visualizzati cosi �
successivamente Ho fatto un altra prova.
ho dettato il db e il file wp-conf con la codifica utf8_romanian_ciRisultato adesso alcune lettere accentate le vedo ma altre invece no.
Ad esempio in questo titolo: CÂTEVA INFORMAȚII NUMERICE non riesco a visualizzare la lettera Ț.
Ho notato che il problema inizia gia dal backend del sito. Ovvero io inserisco il testo corretto poi quando “aggiorno” le lettere non codificate compaiono con la ?
Grazie
-
Buongiorno,
sono nuovo della community e un principiante di wordpress, ho comprato uno spazio hosting wordpress e un tema con intenzione di realizzare il sito per la mia piccola societa’ di interior design. Vorrei realizzarlo in autonomia perchè mi darebbe molta soddisfazione anche se per necessità di tempo è rimasto parcheggiato fino ad inizio crisi Coronavirus. In questo periodo di inattività mi sonno messo sotto per completare il sito, ma ieri ho innescato un problema concellando uno dei due utenti del database che ritenevo fosse superfluo (concesso sbellicarvi dalle risate :-)).
Il mio livello terra-terra mi aveva messo nella condizione di pensare che quell’utente in più, (ritenuto superfluo) lo avessi creato io (tempo fa) per errore.
Al sucessivo tentativo di collegamento ecco la risposta:
Error establishing a database connection
Ricreo l’utente del database cancellato dandogli tutti i privilegi, non sapendo quali avesse prima. Ora mi viene anche il dubbio di non avere utilizzato il nome identico. Stessa risposta nel browser nel tentativo di accedere a WordPress.
Apro un ticket con il gestore dell’hosting che mi risponde così:In merito alla questione database si assicuri che i dati tra il file di configurazione wp-config e quelli relativi al DB siano effettivamente corretti, oltre che il collegamento del nuovo utente col db sia stato effettuato fornendo tutti i privilegi.Ad ogni modo come assistenza sistemistica ci occupiamo solo delle problematiche lato server, non assistiamo i clienti nella realizzazione/manutenzione dei siti, essendo questo un lavoro prettamente da web master.Perciò qualora riscontrasse altre difficoltà con la realizzazione del suo sito le suggeriamo di rivolgersi al suo web master di fiducia oppure ad una web agency.
Praticamente…..arrangiati! ed hanno anche ragione,credo.
Mi rimane la voglia di riuscire con le mie mani a ripristinare quanto di buono ero riuscito a fare (mancava poco al completamento del sito).
Ho la sensazione che sistemare il wp-config con le giuste dritte sia alla mia portata ma non so dove andare a parare. Ho visto nella gestione file del cpanel che il file wp-config.php è posizionao nella cartella public_html. Mi si presentano le seguenti domande:
E’ quello il file da sistemare per correggere l’errore?
Da dove si edita il file? dal Cpanel in gestione file?
Ammesso di riuscire ad entrare nell’editing del file, quali le righe di codice da correggere e sopratutto, a quali parametri di accesso devono essere congrue.
Se non ho capito male dovrei fare in modo che in determinate posizioni di quel file, le credenziali di accesso corrispondano a quelle dei due utenti del mio database, coretto?
Due giorni fa, visto che ero a buon puntocon la composizione della pagina, avevo fatto il backup sia dell’home directory sia del database mysql, ho pertanto pensato di tentare con il recupero di questi.
il recupero del mysql mi da questa risposta:
Operazione completata: The system successfully restored the database “jieewdgs_wp17cdk” from the backup file “jieewdgs_wp17cdk.sql.gz”.
Mentre il recupero dell’home directory mi dice:
Errore: TypeError: NetworkError when attempting to fetch resource.
Il problema di connessione come potere vedere voi stessi provando a connettervi a
[link sotto] permane invariato.
Soluzioni? grazie per l’attenzione che potrete offrire al mio problema
un salutoLa pagina su cui ho bisogno di aiuto: [devi essere connesso per vedere il link]
-
Sarà mai pssibile usare WordPress con il database Microsoft SQL Server?
-
Salve a tutti,
ho un dominio [link sotto] su siteground
Dentro essenzialmente ci sono pochi plugin e woocommerce installato con al massimo 6-7 prodotti e qualche pagina informativa oltre la home.Il sito non è più accessibile
Ho aperto un ticket su siteground e la risposta è stata
“CAUSA DEL CONSUMO ELEVATO DI RISORSE:
Abbiamo svolto uno studio approfondito e abbiamo scoperto che WordPress esegue query lente in direzione del suo database, che infine monopolizzano il server. Il server tenta di eseguire le query lente mettendo altri processi in coda fino a quando viene liberata un po’ di memoria. Tuttavia, mentre sono in attesa, i processi si accumulano e causano ulteriori problemi. I motivi per query lente nel database possono essere molteplici, ma i seguenti tre sono i più comuni:”
E continua ancora:
Ecco alcune delle query di database che sono lente e consumano molte risorse del server:
=== Databases Info =========================================================================
Database Label Tables Views InnoDB MyISAM Slow Queries Slowest Query DB Size
————– ————- —— —– —— —— ———— ————- ——-
dbbqkxtgr564py meditashop.it 45 0 45 0 2293 9.538 52.5 MB
——————————————————————————————–=== TOP 10 of 2293 (total) Slow Queries for the past 24 hours ====================================================
1. Executed 9h 54m 51s ago for 17.010839 sec on Database –> dbbqkxtgr564py
Date: 2020-04-10 08:24:21 Query_time: 17.010839 Rows_examined: 1: Rows_sent 0 Lock_time: 0.000209 Query_chars: 415
UPDATE usc_packlink_entity SET type = ‘Configuration’, index_1 = ‘taskRunnerStatus’, index_2 = ‘1’, index_3 = NULL, index_4 = NULL, index_5 = NULL, index_6 = NULL, index_7 = NULL, data = ‘{\”class_name\”:\”Logeecom\\\\Infrastructure\\\\Configuration\\\\ConfigEntity\”,\”id\”:\”1\”,\”name\”:\”taskRunnerStatus\”,\”value\”:{\”guid\”:\”\”,\”timestamp\”:null},\”systemId\”:\”1\”}’ WHERE id = ‘1’;
——————————————————————————————————————-
2. Executed 9h 54m 51s ago for 15.057252 sec on Database –> dbbqkxtgr564py
Date: 2020-04-10 08:24:21 Query_time: 15.057252 Rows_examined: 385: Rows_sent 385 Lock_time: 0.050277 Query_chars: 74
SELECT option_name, option_value FROM usc_options WHERE autoload = ‘yes’;
——————————————————————————————————————-
3. Executed 9h 54m 51s ago for 12.268459 sec on Database –> dbbqkxtgr564py
Date: 2020-04-10 08:24:21 Query_time: 12.268459 Rows_examined: 385: Rows_sent 385 Lock_time: 0.050340 Query_chars: 74
SELECT option_name, option_value FROM usc_options WHERE autoload = ‘yes’;
——————————————————————————————————————-
4. Executed 2h 33m 48s ago for 10.020625 sec on Database –> dbbqkxtgr564py
Date: 2020-04-10 15:45:24 Query_time: 10.020625 Rows_examined: 0: Rows_sent 0 Lock_time: 0.071572 Query_chars: 101
SELECT option_value FROM usc_options WHERE option_name = ‘wc_connect_debug_logging_enabled’ LIMIT 1;
——————————————————————————————————————-
5. Executed 8h 12m 53s ago for 9.538467 sec on Database –> dbbqkxtgr564py
Date: 2020-04-10 10:06:19 Query_time: 9.538467 Rows_examined: 0: Rows_sent 0 Lock_time: 0.000098 Query_chars: 101
SELECT option_value FROM usc_options WHERE option_name = ‘_transient_et_builder_ajax_cache’ LIMIT 1;
——————————————————————————————————————-
6. Executed 8h 12m 53s ago for 9.528367 sec on Database –> dbbqkxtgr564py
Date: 2020-04-10 10:06:19 Query_time: 9.528367 Rows_examined: 0: Rows_sent 0 Lock_time: 0.012888 Query_chars: 104
SELECT option_value FROM usc_options WHERE option_name = ‘jetpack_edit_links_calypso_redirect’ LIMIT 1;
——————————————————————————————————————-
7. Executed 4h 34m 47s ago for 9.108485 sec on Database –> dbbqkxtgr564py
Date: 2020-04-10 13:44:25 Query_time: 9.108485 Rows_examined: 1: Rows_sent 1 Lock_time: 0.050165 Query_chars: 95
SELECT option_value FROM usc_options WHERE option_name = ‘_transient_et_core_version’ LIMIT 1;
——————————————————————————————————————-
8. Executed 7h 8m 5s ago for 7.904073 sec on Database –> dbbqkxtgr564py
Date: 2020-04-10 11:11:07 Query_time: 7.904073 Rows_examined: 362: Rows_sent 181 Lock_time: 0.006090 Query_chars: 214
SELECT usc_posts.* FROM usc_posts WHERE 1=1 AND usc_posts.post_parent = 16 AND usc_posts.post_type = ‘revision’ AND ((usc_posts.post_status = ‘inherit’)) ORDER BY usc_posts.post_date DESC, usc_posts.ID DESC;
——————————————————————————————————————-
9. Executed 7h 3m 57s ago for 7.156883 sec on Database –> dbbqkxtgr564py
Date: 2020-04-10 11:15:15 Query_time: 7.156883 Rows_examined: 362: Rows_sent 181 Lock_time: 0.043920 Query_chars: 214
SELECT usc_posts.* FROM usc_posts WHERE 1=1 AND usc_posts.post_parent = 16 AND usc_posts.post_type = ‘revision’ AND ((usc_posts.post_status = ‘inherit’)) ORDER BY usc_posts.post_date DESC, usc_posts.ID DESC;
——————————————————————————————————————-
10. Executed 4h 30m 7s ago for 6.986377 sec on Database –> dbbqkxtgr564py
Date: 2020-04-10 13:49:05 Query_time: 6.986377 Rows_examined: 0: Rows_sent 0 Lock_time: 0.031671 Query_chars: 101
SELECT option_value FROM usc_options WHERE option_name = ‘wc_connect_debug_logging_enabled’ LIMIT 1;
——————————————————————————————————————-=== Top 3 Similar SQL Queries and their query time =================================================================
Executed: 1814 time for minumum: 1.002449 sec, maximum: 9.538467 sec
SELECT option_value FROM usc_options WHERE option_name = ‘_transient_et_builder_ajax_cache’ LIMIT 1;
——————————————————————————————————————-
Executed: 184 time for minumum: 1.015242 sec, maximum: 6.586253 sec
SELECT * FROM usc_packlink_entity WHERE type = ‘Configuration’ AND ( index_1 = ‘taskRunnerStatus’ AND index_2 = ‘1’) LIMIT 0, 1;
——————————————————————————————————————-
Executed: 70 time for minumum: 1.052578 sec, maximum: 4.332906 sec
SELECT post_id, meta_key, meta_value FROM usc_postmeta WHERE post_id IN (150) ORDER BY meta_id ASC;
——————————————————————————————————————-Dalle query precedenti possiamo concludere che il tuo problema è causato da un script non ben compilati.
Come posso procedere?
Cosa va fatto?Grazie mille
Giovanni
aggiornamento
dovresti contattare uno sviluppatore professionista per controllare le query lente generate dal tuo database come specificato dal mio collega nella risposta precedente perché questo va oltre lo scopo del nostro supporto.La pagina su cui ho bisogno di aiuto: [devi essere connesso per vedere il link]
-
Salve, il mio sito in costruzione ha un problema nel backend. Quando provo ad editare le pagine (solo quelle, articoli e altre cose funzionano) wordpress comincia a diventare lentissimo, impiegando anche diversi minuti per caricare l’editor di Elementor. A volte addirittura non carica e mi spunta questo messaggio:
“MySQL server has gone away in /home/customer/www/digitalclimaroma.it/public_html/wp-includes/wp-db.php on line 2024
Warning: mysqli_query(): Error reading result set’s header in /home/customer/www/digitalclimaroma.it/public_html/wp-includes/wp-db.php on line 2024
Warning: Cannot modify header information – headers already sent by (output started at /home/customer/www/digitalclimaroma.it/public_html/wp-includes/wp-db.php:2024) in /home/customer/www/digitalclimaroma.it/public_html/wp-includes/functions.php on line 6221”
Ho già provato a contattare il mio servizio di hosting, ma non mi hanno voluto aiutare perché va oltre le loro competenze, dicono.
P.S: non sono un programmatoreGrazie a tutti per l’attenzione
-
Buonasera,
oggi ho aggiornato un sito alla versione 5.4-it_IT di WordPress, da quando si è conclusa l’installazione, in ogni pagina o post e per qualsiasi modifica voglia apportare, quando vado per aggiornare e salvare la pagina rimane all’infinito in “salvataggio in corso” senza però mai concludersi.
Il sito permette di aggiornare i plugin ed i temi e le varie configurazioni.
Vi chiedo di aiutarmi cortesemente perchè sono impossibilitata a lavorare.
Ringrazio e auguro un buon lavoro.
Il sito ha una versione del server mysql non attualizzata e stò cercando di farmelo aggiornare.
Qualche idea su comer risolverle il problema? Potrebbe essere che non potendo usare UTF8MB4 si pianta?Vi ringrazio
-
Ho importato una mia tabella personale nel db di wordpress.`
Ora sto provando a recuperare i dati senza successoRicevo tale errore:
Errore sul database di WordPress: [You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near ‘7991’ at line 1]Il file page.php
.... <?php is_page('statistiche'); include_once('inc/statistiche.php'); ?> ....Il file statistiche.php
<?php global $wpdb; $table_name = "mytabella"; $sql=$wpdb->query("SELECT * FROM $table_name"); $result = $wpdb->get_results($sql); foreach ($result as $mt) { echo "<p>" . $mt->id. "</p>"; } ?>
-
Premesso che tutti i passaggi per ripristinare il sito sono stati fatti (ho disabilitato i plugin ed il tema corrente, ho sovrascritto i files di wp con la versione in uso quindi tutti i files nella roote e quelli delle cartelle wp-admin e wp-include) ancora non ho provato con il database perchè quello che ho potrebbe avere lo stesso problema se il problema è nel db. La configurazione che ho è obsoleta perche chi ha in gestione il sito non vuole cambiare anche se tutti i problemi relativi alla sicurezza gli sono stati elencati. La configurazione è la seguente:
wordpress installato, versione 3.5.1 su server linux PHP 5.0 MySQL 5.1.63
Comunque ho abilitato il debug ed il risultato è il seguente:[12-Nov-2019 16:36:49 UTC] PHP Parse error: syntax error, unexpected ‘$supports_permalinks’ (T_VARIABLE) in /var/www/vhosts/vanitycake.it/httpdocs/wp/wp-includes/functions.php on line 3029
Ma la cosa strana è che da quando ho abilitato il debug nel file debug.log ci sono registrati errori a tutte le ore incluso di notte!!!!
Come posso procedere per ripristinare questa situazione???
Grazie, Santino.La pagina su cui ho bisogno di aiuto: [devi essere connesso per vedere il link]
Grazie @luca21 ,
ho letto e riletto nei limiti della mia capacità di comprendere intere pagine di “codex.wordpress.org”, ho seguito tutorial su YouTube e comprato corse su Udemy.
Il risultato è stato pressocché ZERO.
Il fatto che mi sta facendo impazzire è che il nuovo sito da me “costruito” funziona e il problema è solo nell’importare i dati (immagini e testi).
I testi vanno tutti al loro posto ma le immagini no.
Potrei riuscire a sistemarle credo ma questo porterebbe ad avere migliaia di immagini nella stessa cartella anno/mese in wp-content\uploads e non va.
Anche con il contratto professional su serverplan, una cartella di quelle dimensioni non viene gestita.
Qui purtroppo non è possibile postare degli screenshot, ma per me è una vera follia.
Il post si apre perfettamente ed al posto della immagine mostra il solito simbolo di immagine mancante con il nome dell’immagine. Se prendo il link della immagine non mostrata nella pagina, sia usando il DX del mouse e il comando “Open in new tab, sia andando in “modifica” e selezionando l’immagine mancante nei dettagli ritrovo lo stesso link che messo nel browser porta all’immagine corretta (in locale) e in effetti nella cartella h**p://localhost/LioSite.com/wp-content/uploads/2017/08/Tatjana-Bek-Imperfezione.jpg l’immagine esiste.
Ma allora perché nel post non viene visualizzata???
Esiste qualche metodo per esportare testi e immagini dal sito online e reimportarli IDENTICI (stesse date, stesse cartelle) che funzioni?
Non voglio mollare ma mi pare di incasinare sempre di più la situazione.
Ed ogni volta butto tutto, reinstallo un nuovo WordPress, ricreo un nuovo database, ricreo le pagine importando i template che ho preparato, ricreo i CPT, le tassonomie etc, e poi …. nulla.
Mi pare di capire che il database in MySql registri e ricordi ogni tentativo che io faccio di importare le immagini e al secondo tentativo anche se le immagini sono state cancellate, per lui sono presenti e quindi doppioni e quindi mi dice:Failed to import Media “William-Shakespeare-Ma-l’uomo,-l’uomo-orgoglioso”
Failed to import Media “Erri-De-Luca-Gli-insorti-del-ghetto”
Failed to import Media “Julio-Cortázar-Istruzioni-per-salire”or
Media “Chiara” already exists.
Media “Palazzo delle Tuileries” already exists.
Media “Ribelle” already exists.
Media “Insciallah” already exists.etc.
Deve esistere una soluzione, ne sono certa.
Pensavo di non potere essere in grado di creare un sito ed invece a quello sono riuscita ad arrivare in qualche modo, ma non riuscire a trasferire il contenuto del vecchio sito a quello nuovo non pensavo potesse essere un calvario simile.
Ho anche pensato di fare (non so nemmeno esattamente cosa sia, ma nelle mie ricerche ne ho sentito parlare da molte parti) un “Redirect” tra il nuovo sito e il vecchio e poi proseguire con il materiale nuovo sul nuovo sito e man mano manualmente inserire le migliaia di vecchi post.
Ma questo presupporrebbe lavorare live sul sito online e la cosa non mi piace per nulla.
Anni al computer mi hanno ben insegnato a lavorare su copie e backup lasciando sempre integri gli originali, ma qui nn so che fare 🙁
Se avete programmi da consigliare ve ne sarò grata.
E comunque grazie per il tempo dedicatomi.Lio (vecchia stupida)
Ciao normalmente per spostare WordPress da dominio a dominio occorre avere i back-up dei file WordPress (ad esempio segue una lista non esaustiva: file php , JavaScript , CSS , immagini ecc) e mysql e oltre a questo devi modificare i percorsi nel database come indica la guida gentilmente fornita da Cristiano Zanca https://codex.wordpress.org/Moving_WordPress#Changing_Your_Domain_Name_and_URLs
Ciò che non capisco è che versione di WordPress usi in localhost e online? (Se “esattamente” la copia riprodotta allora il link fa già al caso tuo) mentre se sono versioni diverse la faccenda si complica.
Devi possedere i back-up completi file e MySQL https://codex.wordpress.org/Moving_WordPress#Moving_to_a_New_Server come meglio spiegato qui dove spiega che in caso di problemi si può sempre tornare al punto di partenza.
Se non riesci nei back-up di tutto WordPress e del database per favore non toccare nulla goditi il tuo sito e poi ti affiderai a un professionista
Colgo inoltre l’occasione di augurare Buona Pasqua a tutti.
-
Ciao a tutti,
non sono esperta nella gestione di siti quindi scusate se quanto chiederò sarà scontato.
Non so se sto inerendo la mia richiesta nella posizione corretta… portate pazienza
Spero di riuscire a spiegarmi, ho letto qualcosa in rete ma non sono riuscita a risolvere il problema di cui vi scrivo sotto.
Devo migrare il mio sito dal vecchio hosting ad aruba, il dominio rimane lo stesso. Ho in locale sia la cartella contenente i file WP del sito (funzionante sul vecchio hosting) che il file .sql che mi sono stati dati da chi a suo tempo aveva realizzato il sito con WP.
Ho caricato tramite filezilla tutti i file (ad esclusione del file .sql) sull’FTP di aruba ed ho modificato il file wp-config.php nelle sezioni indicate sotto•define(‘DB_NAME’, ‘nuovo_nome _db’)
•define(‘DB_USER’, ‘nuovo_nome_utente_db’)
•define(‘DB_PASSWORD’, ‘nuova_password’)
•define(‘DB_HOST’, ‘nuovo_host’)
Ho poi importato il database e tutto ha funzionato – il database mi compare ha la seguente struttura:
wp_commentmeta
wp_comments
wp_links
wp_logger_ginger
wp_options
wp_postmeta
wp_posts
wp_termmeta
wp_terms
wp_term_relationships
wp_term_taxonomy
wp_usermeta
wp_users
wp_yoast_seo_links
wp_yoast_seo_meta
A questo punto nel pannello di controllo ho scelto Gestione Hosting WordPress, ma prima di farmi fare il login mi è stata chiesta la procedura classica di installazione di Word Press quando si ha un database vuoto.
(…Benvenuto nella famosa installazione di WordPress in cinque minuti! Compila semplicemente le informazioni qua sotto e sarai già sulla strada per utilizzare la piattaforma di pubblicazione più estesa e potente del mondo …)
Ho fatto l’installazione inserendo quanto mi è stato richiesto, in seguito il database che avevo importato prima si presenta con questa struttura:
wp312_commentmeta
wp312_comments
wp312_links
wp312_options
wp312_postmeta
wp312_posts
wp312_termmeta
wp312_terms
wp312_term_relationships
wp312_term_taxonomy
wp312_usermeta
wp312_users
wp_commentmeta
wp_comments
wp_links
wp_logger_ginger
wp_options
wp_postmeta
wp_posts
wp_termmeta
wp_terms
wp_term_relationships
wp_term_taxonomy
wp_usermeta
wp_users
wp_yoast_seo_links
wp_yoast_seo_meta
fatto ciò vedo che il sito praticamente ignora le tabelle importate e si comporta come se fosse un sito creato partendo da un database vuoto… risultato che il vecchio sito pur essendo su FTP ed avendo tutte le tabelle del vecchio database praticamente …. Non esiste….
non so se sia pertinente ma ho notato che il database del vecchio sito riporta quanto segue:
— phpMyAdmin SQL Dump
— version X.X.X
— https://www.phpmyadmin.net/
—
— Host: localhost:XXXX
— Creato il: —————————————-
— Versione del server: XX.X.X-CCCCCCCCCCCCCCC
— Versione PHP: X.X.XSET SQL_MODE = “NO_AUTO_VALUE_ON_ZERO”;
SET AUTOCOMMIT = 0;
START TRANSACTION;
SET time_zone = “+00:00”;/*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */;
/*!40101 SET @OLD_CHARACTER_SET_RESULTS=@@CHARACTER_SET_RESULTS */;
/*!40101 SET @OLD_COLLATION_CONNECTION=@@COLLATION_CONNECTION */;
/*!40101 SET NAMES utf8mb4 */;
—
— Database:VECCHIO NOME DATABASE
—
Mentre se esporto in locale un database creato partendo da uno vuoto trovo:
— phpMyAdmin SQL Dump
— version Y.Y.Y.Y
— http://www.phpmyadmin.net
—
— Host: YY.YY.YYYY.YY
— Generato il: —————————
— Versione del server: Y.Y.YY
— Versione PHP: Y.Y.YSET SQL_MODE=”NO_AUTO_VALUE_ON_ZERO”;
SET time_zone = “+00:00”;/*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */;
/*!40101 SET @OLD_CHARACTER_SET_RESULTS=@@CHARACTER_SET_RESULTS */;
/*!40101 SET @OLD_COLLATION_CONNECTION=@@COLLATION_CONNECTION */;
/*!40101 SET NAMES utf8 */;
—
— Database:NUOVO NOME DATABASE
—
Ho provato a modificare il vecchio file .sql prima di importare (ho sostituito i valori delle versioni ed il nome del database) ma praticamente il risultato rimane lo stesso…
Ho anche visto che WP crea tabelle che hanno come nome wp312_xxxxxxxx mentre il vecchio database crea tabelle con nome wp_xxxxxxxxx
non so se siano una osservazioni pertinenti.
Riuscite ad aiutarmi?
Grazie!!!
-
