Problemi nell'Importare un DB di un sito web già esistenze per crearne uno nuovo

8 contenuti / 0 new
Ultimo contenuto
Problemi nell'Importare un DB di un sito web già esistenze per crearne uno nuovo

Ciao,
mi si pone un problema che non mi era ancora capitato.

Io in genere per creare un sito nuovo, prendo l'esport di un DB di un sito già pienamente funzionante, sostituisco i prefissi delle tabelle con un "sed" e lo importo nel nuovo database.

sed -i 's/pippo_/ciccio_/g' pippodatabase.sql

una volta che il DB così fatto è importato ed ho creato la nuova directory sites/nomesito e impostato correttamente settings.php, lancio il sito dal browser e di norma si >apre< con tutte le vecchie impostazioni. A quel punto faccio le modifiche alle vecchie impostazioni, in particolare i nomi delle directory, poi i riferimenti del sito, il file della lingua e infine il tema, elimino tutti i nodi del sito da cui proveniene il db che qui non servono più tramite le funzioni del modulo "delete all" e riciomincio subito con nuovo tema e nuovi contenuti.

Faccio così perchè in tal modo non devo riconfigurarmi le impostazioni che ci sono in tutta la moltitudine di moduli utilizzati.

Questa volta però mi ritrovo che una volta importato il DB, la pagina web non si apre affatto, mi da SOLO una pagina bianca e non so come risolvere questa cosa.

Ho bisogno necessariamente di una soluzione, perchè reinserie a mano tutte le impostazioni dei moduli, partendo da una nuova installazione di drupal, diventa un lavoro logorante che può richiedere giorni e giorni.

aggiungo qui l'elenco tabelle presenti, potrebbe essere che al momento, avendo molti + moduli rispetto al passato alcuni di questi possano essere causa del problema, come il fatto di fare questa operazione su un nuovo core di Drupal, mette le volte che le ho fatte in passato avevo core + vecchi.

healthyflavors_access
healthyflavors_accesslog
healthyflavors_actions
healthyflavors_actions_aid
healthyflavors_advanced_help_index
healthyflavors_aggregator_category
healthyflavors_aggregator_category_feed
healthyflavors_aggregator_category_item
healthyflavors_aggregator_feed
healthyflavors_aggregator_item
healthyflavors_authmap
healthyflavors_batch
healthyflavors_blocks
healthyflavors_blocks_roles
healthyflavors_boxes
healthyflavors_browscap
healthyflavors_browscap_statistics
healthyflavors_cache
healthyflavors_cache_block
healthyflavors_cache_browscap
healthyflavors_cache_filter
healthyflavors_cache_form
healthyflavors_cache_menu
healthyflavors_cache_nodewords
healthyflavors_cache_page
healthyflavors_cache_update
healthyflavors_cache_views
healthyflavors_cache_views_data
healthyflavors_captcha_points
healthyflavors_captcha_sessions
healthyflavors_comments
healthyflavors_comment_notify
healthyflavors_comment_notify_user_settings
healthyflavors_fbconnect_profile
healthyflavors_fbconnect_users
healthyflavors_fckeditor_role
healthyflavors_fckeditor_settings
healthyflavors_feedburner
healthyflavors_files
healthyflavors_filters
healthyflavors_filter_formats
healthyflavors_fivestar_comment
healthyflavors_flood
healthyflavors_history
healthyflavors_languages
healthyflavors_locales_source
healthyflavors_locales_target
healthyflavors_masquerade
healthyflavors_masquerade_users
healthyflavors_menu_custom
healthyflavors_menu_links
healthyflavors_menu_router
healthyflavors_node
healthyflavors_nodewords
healthyflavors_nodewords_custom
healthyflavors_node_access
healthyflavors_node_comment_statistics
healthyflavors_node_counter
healthyflavors_node_revisions
healthyflavors_node_type
healthyflavors_permission
healthyflavors_profile_fields
healthyflavors_profile_values
healthyflavors_role
healthyflavors_scheduler
healthyflavors_search_dataset
healthyflavors_search_index
healthyflavors_search_node_links
healthyflavors_search_total
healthyflavors_sessions
healthyflavors_system
healthyflavors_taxonomy_manager_merge
healthyflavors_technorati
healthyflavors_term_data
healthyflavors_term_hierarchy
healthyflavors_term_node
healthyflavors_term_relation
healthyflavors_term_synonym
healthyflavors_upload
healthyflavors_url_alias
healthyflavors_users
healthyflavors_users_roles
healthyflavors_variable
healthyflavors_views_display
healthyflavors_views_object_cache
healthyflavors_views_view
healthyflavors_vocabulary
healthyflavors_vocabulary_node_types
healthyflavors_votingapi_cache
healthyflavors_votingapi_vote
healthyflavors_watchdog
healthyflavors_webform
healthyflavors_webform_component
healthyflavors_webform_roles
healthyflavors_webform_submissions
healthyflavors_webform_submitted_data
healthyflavors_xmlsitemap
healthyflavors_xmlsitemap_node
healthyflavors_xmlsitemap_taxonomy
healthyflavors_xmlsitemap_user
healthyflavors_xmlsitemap_user_role

Qualcuno mi sa aiutare? Oppure c'è un modo per esportare solo le impostazioni di TUTTA l'installazione completa di DRUPAL moduli compresi e dopo aver installato il DB CORE di drupal basta solo caricare il file delle impostazioni che automaticamente abilita tutti i moduli e tutte le varie impostazioni?

Fatemi sapere xkè configurarmi tutti i moduli a mano da zero è un massacro.
Io mi aspetta diverti problemi (i soliti) ma non mi aspettavo che il browser non riuscisse ad aprire il sito.

Questo problemino mi ha bloccato tutti i piani di lavoro di questo week end.. e non me lo aspettavo proprio.

L'idea è buona, ma un pò pericoloso. Dato che hai importato le tabella di sistema (system, variable, ecc) povero Drupal pensa che tutti i moduli nella vecchio install sono presente, mentre magari non ci sono. Il risultato è il famoso 'white screen of death'. Comunque, qualcosa si può fare. Nella mia esperienza /user è quasi sempre disponibile, ache quando l'home page va in palla. Dopodichè con un pò di fortuna sarà possibile vedere, e modificare la pagina dei moduli. Controlla che non hai un modulo 'abilitato' che invece non hai nella istanza nuova di Drupal.

Questo mechanismo di 'prendere in prestito' un db funziona solo se il nuovo sito usa gli stessi moduli del vecchio. Se non, bisogna disabilitare i moduli nella vecchia che non ci saranno nella nuova prima di clonare il db.

Se conosci bene le tabelle, forse backup and migrate è un tool da provare.

HTH

John

Più imparo, più dubito.

John!..
.. mi fai un po sprovveduto in materia.

Questa che ti ho mostrato è per me una prassi usuale ;-). La chiave di volta del processo di installazione di ogni mio nuovo progetto. Altrimenti impazzirei.

Ti posso assicurare che i moduli ci sono TUTTI, anche perchè io utilizzo una sola root di drupal sul filesystems per gestire TUTTI i progetti. Lavoro su multisiti SEMPRE.

Replicare il DB non implica in questo caso alcuna carenza di moduli.
Backup e Migrate è il mio tools di sicurezza per il backup anche SE adesso inizia a starmi stretto, molto stretto!!!

In ogni caso non posso certo disabilitare tutti i moduli per replicare il DB di un sito di produzione con i moduli non attivi.

Cmq sia cercherò di entrare un po + nel dettaglio con i moduli da disabilitare anche se i moduli installati nel sito originario sono gli stessi, uguali e identici che servono nel nuovo sito.

Però, un test che avevo fatto per sicurezza era quello di disabilitare XML Sitemap e importare il db, ma senza risultato.

Cmq, posso dirti che /user o /?q=user non va.

Altre idee?

Una cosa utile, se c'è qualcuno esperto in materia, potrebbe essere capire quali tabelle SVUOTARE o su cui fare UPDATE e in quali campi, per poter far funzionare sempre operazioni del genere. Questa potrebbe essere una via, come anche quella di avere un tool che consenta di esportare tutte le impostazioni - TUTTE - del core drupal e dei moduli e reimportarle poi in una e pulita installazione del core di DRUPAL e che auto abiliti anche i moduli e così via.

Ragazzi DEVO assolutamente risolvere questa cosa... mi si è bloccato TUTTO il lavoro sui nuovi progetti.

Scusa, non avevo letto bene la tua richiesta...

jscm wrote:
Ti posso assicurare che i moduli ci sono TUTTI, anche perchè io utilizzo una sola root di drupal sul filesystems per gestire TUTTI i progetti. Lavoro su multisiti SEMPRE.

Infatti, se tutti i moduli sono in sites/all/modules e tutte le teme in sites/all/themes allora ti do ragione.

jscm wrote:
Cmq, posso dirti che /user o /?q=user non va.

Aaia. Questo non è un buon segno.

jscm wrote:
Altre idee?

Si. Prova usare Drush per accedere al sito problematico. Presumo che sei in localhost. Drush non è un modulo, ma un script PHP che carica Drupal come una specie di 'mega' script. Dato che funziona dal command line, è più che probabile che da qualche indicazione di dove sta il problema (almeno dovrà dare un errore sul CLI). Dato che stai usando multisite, puoi provare usare l'opzione -l o --uri per specificare il sito. Magari prova con un sito che funziona prima per 'prendere la mano'. Prova con il commando 'status' o 'statusmodules' per esempio...

jscm wrote:
Una cosa utile, se c'è qualcuno esperto in materia, potrebbe essere capire quali tabelle SVUOTARE o su cui fare UPDATE e in quali campi, per poter far funzionare sempre operazioni del genere. Questa potrebbe essere una via, come anche quella di avere un tool che consenta di esportare tutte le impostazioni - TUTTE - del core drupal e dei moduli e reimportarle poi in una e pulita installazione del core di DRUPAL e che auto abiliti anche i moduli e così via.

Hmm. Credo che Patterns sta seguendo quest'idea. Ma non so se è arrivato fino in fondo...

HTH

John

Più imparo, più dubito.

Ciao tramite drush usando i comando che dicevi: status e statusmodules sono giusto a questo risultato

1 - moduli sono attiviti tutti quelli giusti
2 - status mi mostra:

  Drupal version    : 6.14
  Site Path         : sites/healthyflavors.ejarvis.eu
  Site URI          : http://healthyflavors.ejarvis.eu
  Database Driver   : mysqli
  Database          : Connected
  Drupal Bootstrap  : Successful
  Drupal User       : Anonimo

fin qui tutto bene, ma fatto questo vado a dare un occhiata al watchdog generato...
ed ottengo alcuni errori di questi tipo:

mysqli_real_escape_string() expects parameter 1 to be mysqli, null g[...quindi manca il resto della stringa... ]

ma a parte questo niente d'altro.

in ogni caso ho fatto un bel di po di prove, ho imparato i comandi... ma errori appositi niente.

Potrei provare a disabilitare i moduli tramite drush visto che mi consente di farlo... e vedere fare tentativi finchè non trovo quello che non mi fa funzionare il sito... ammesso ovviamente che si tratti di un modulo.

Al primo tentativo ..ho trovato il problema o meglio i moduli che creavano il casino.

ho disabilitato questi 2 moduli che provengono dallo stesso produttore:

- PostLift (postlift_causestyle)
- LinkLift (causestyle)

Praticamente sono 2 moduli che servono per utilizzare i servizi text link e post link provenienti da LinkLift.
Questi 2 moduli NON provengolo da sito Drupal.org, ma vengono forniti direttamente da LinkLift, quindi magari non sono proprio scritti in maniera appropriata.

Non so quale dei due sia quello che ha creato il problema però appena li no notati cercando quale disabilitare li ho disabilitati tutti e 2 subito e come primo tentativo.

Di conseguenza, il metodo di importare l'export di un DB di un sito pienamente configurato e fuzionante, in un altro database in modo da creare subito un nuovo sito altrettanto funzionante e con tutte i moduli già configurati resta più che valida, rapida ed efficace ma NON sufficiente. Questa è una procedura che a scanso di particolari rari problemi FUNZIONA SEMPRE.

E' FONDAMENTALE intervenire per modificare i campi legati alle directory (PRIMA COSA da FARE SUBITISSIMO, se no finisce che scriverete DATI nelle directory del sito a cui apparteneva l'export che è stato importato), modificare tutti i campi legati alle informazioni e alle caselle email, le impostazioni di backup_migrate e così via.

Grazie John per avermi suggerito Drush, molto utile per alcune cose.

saluti

jerry

Ho risolto :D

erano 2 moduli non provenienti dal sito drupal.org, ma utilizzati per i servizi di LinkLift e forniti da loro.

li ho disabilitati con drush e il sito è stato caricato al primo colpo ;-).