Un utente ha chiesto informazioni su Pods - Custom Content Types and Fields di Wordpress

Importare le relazioni

Un utente ha chiesto 👇

Ciao. Sto costruendo un sito Web WordPress da contenuti già organizzati (in una tabella CSV / XML) che voglio importare in tipi di post personalizzati.

Sono riuscito a importare campi personalizzati e tassonomie (utilizzando Ultimate CSV Importer e ho anche provato WP All Import), ma ho un problema nell’importazione delle relazioni: non riesco a farlo funzionare. Potete fornire alcune informazioni su come questo può essere fatto?

PS: ho letto in una delle tue risposte che le persone usavano il plugin CIO Pro (uno che non sviluppi tu) ma non ho trovato nessun tutorial su questo argomento sul web. Non volevo acquistare un plug-in aggiuntivo, prova a scoprire che non è possibile. Se puoi fornire ulteriori informazioni su come importare con successo le relazioni in PODS, te ne sarei molto grato!

E grazie per aver sviluppato un plugin così eccezionale: voi ragazzi siete i migliori! Stai davvero consentendo la creazione di un sito Web in WordPress – in modo gratuito e aperto! Grazie mille.

Questo argomento è stato modificato 2 anni, 1 mese fa da. Questo argomento è stato modificato 2 anni, 1 mese fa da.

Lanciatore di thread

(@ mark500)

2 anni, 1 mese fa

Ho trovato alcune istruzioni sul Web sulla combinazione del plug-in WP All import e CIO Custom Fields Importer, ma Non riesco ancora a farlo funzionare:
https://vipp.com.au/cio-custom-fields-importer/how-to-match-and-import-relationship-fields-into-pods/

Fornisce questo esempio di importazione di relazioni nei pod:

—————————————————

Esempio 3, campo personalizzato relativo al campo personalizzato che utilizza l’archiviazione della tabella dei pod

Ad esempio, se disponi di un campo personalizzato relativo al campo “traduzione” di un tipo di post “libro” personalizzato e hai creato il tipo di “libro” di post personalizzato utilizzando un repository di tabelle pod, tabella wp_postmeta). Hai un file sorgente CSV e le traduzioni sono memorizzate in una colonna chiamata “Translations_available”. La virgola è separata dalle traduzioni effettive.

Quando importi, puoi scrivere nel modello di importazione:

MATCH in PODS TABLE (traduzione: {translate_available[1]})

o

MATCH per l’ID articolo nella TABELLA PODS, dalle traduzioni delle colonne (traduzioni: {Translations_available[1]})

——————————————————

Questo “modello di importazione” è considerato il campo nel plugin WP All import? L’ho provato, ma non sembra funzionare …

Qualsiasi aiuto?

Questa risposta è stata modificata 2 anni, un mese fa da. Questa risposta è stata modificata 2 anni, un mese fa da. Autore del plugin

(@jimtrue)

2 anni, 1 mese fa

Se non utilizzi la versione premium di CIO Custom Fields, puoi eseguire le seguenti operazioni solo con la versione gratuita:

La versione gratuita supporta singoli campi di relazione selezionati con ID elemento riconoscibili. La versione pro gestisce più campi a scelta e elementi di corrispondenza automatica su un sito live.

L’impostazione di tale configurazione per l’importazione significa che non è necessario che il file di importazione abbia l’ID lavoro del record “corrispondente” nella colonna del campo di relazione. Una volta creata questa metodologia, ho esportato quel tipo di post dopo l’importazione in modo da avere gli ID dei post e quindi ho usato Excel per VLookup quella tabella con un post-id per gli ID che corrispondono alle posizioni nella tabella successiva per la relazione. Se non avessi troppe relazioni, potresti farlo manualmente penso, ma questo è il metodo che devi fare mentre usi la versione gratuita. Devi utilizzare un id id effettivo dal tipo di post personalizzato correlato nella colonna per importare le tue relazioni e, come mostrato sopra, funzionerà solo per le tue relazioni individuali selezionate.

L’unico modo in cui funziona la modalità “match” è se hai acquistato e stai utilizzando la versione pro. Non forniamo tutorial per questa versione, perché non supportiamo questa versione. Forniscono istruzioni sul loro sito web (a cui hai fatto riferimento)

Non forniamo supporto per la versione premium poiché viene gestito sul sito Web CIO quando acquisti la versione premium (https://vipp.com.au/cio-custom-fields-importer/contact-us/)

Spero che aiuti.

Lanciatore di thread

(@ mark500)

2 anni, 1 mese fa

Sì, aiuta! Grazie per avermelo spiegato.

Ho contattato il supporto dei CIO e mi stanno aiutando a capire come ottenere questo risultato.

PS: nella nota a margine, hanno scritto:

A proposito, a causa di un bug nelle relazioni a due vie, alcuni clienti hanno problemi nell’importazione di aree di relazione a due vie. I problemi sono scomparsi quando i campi sono stati modificati in relazioni unidirezionali. Potresti considerare l’utilizzo di una relazione unidirezionale (faccia a faccia o faccia a faccia) e utilizzare un modello / richiesta personalizzato per elencare gli elementi correlati. I domini di relazione a due vie scrivono l’indice POD due volte, sono inefficaci e diventa difficile ridimensionarli quando i dati si accumulano.

Sai di cosa stanno parlando, forse si tratta di un bug nuovo o già risolto?

Autore del plugin

(@jimtrue)

2 anni, 1 mese fa

Non saremmo davvero d’accordo sul fatto che le relazioni bilaterali non siano “efficaci o difficili da scalare quando i dati si accumulano”.

Ciò significa che quando configuri la tua relazione, ad esempio da Libri ad Autori, hai una serie di relazioni in “Autori” da Libri denominate “Related_Author”. Questa è una relazione unidirezionale e lui scrive il collegamento “una volta”. Supportiamo anche le relazioni bidirezionali, il che significa che puoi avere una serie di relazioni da “Autori” a “Libri” chiamate “Libri_relativi” e utilizzare l’altra relazione per rendere automaticamente valido l’altro collegamento.

Sì, se ne avessi uno con centinaia di collegamenti, potrei vedere dove potrebbe essere inefficace, ma di solito in quel caso, probabilmente useresti comunque il nostro Table Storage e senza dubbio lo sarebbe.

Dovrebbero fornire maggiori dettagli sul motivo per cui considerano questo un “bug”. Puoi inviarci un’e-mail a support@pods.io e mi assicurerò di verificarlo.

Grazie!

Autore del plugin

(@ sc0ttkclark)

2 anni, 1 mese fa

Volevo solo saltare qui e notare che, a livello tecnico, Pods memorizza le relazioni bilaterali su due livelli nella nostra tabella delle relazioni. Questo è probabilmente ciò a cui si riferiscono. Lo facciamo perché interroga i dati indicizzati nella tabella in modo più efficiente, invece di scrivere logica che controlla più colonne in SQL JOIN della tabella delle relazioni. Non ci occupiamo solo di relazioni, permettiamo alle persone di mettere in discussione le relazioni e incrociarle. Non c’è modo di archiviarli di seguito senza creare domande inefficaci, quindi abbiamo optato per un interrogatorio quotidiano più efficiente.

(@visualdata)

2 anni, 1 mese fa

Ciao, sono lo sviluppatore del plug-in importatore di campi personalizzati CIO. Ho notato che l’email di cui sopra si trova in questo forum pubblico, che a mio parere era una conversazione privata per affrontare un particolare caso d’uso. Nel caso in cui qualcuno leggendo questo thread in futuro fraintende l’email citata per il suo contesto, ecco la frase di revisione per una relazione a due vie

I campi di relazione bidirezionale scrivono due volte l’indice PODS, non sono adatti per l’importazione batch e sono difficili da scalare quando i dati si accumulano.

Il commento di Scott sopra ha fornito una panoramica a livello tecnico. L’applicazione corrente dei campi di relazione a due vie utilizza due record per rappresentare una relazione, invece di cercare lo stesso record in due modi diversi. Questo duplica il lavoro durante la scrittura su un database. Se un autore ha 10 libri, otterrai 20 record per un’area di relazioni bilaterali (invece di 10 record che utilizzano relazioni unidirezionali). Ora un autore produttivo ha probabilmente 50 libri, o hai 5 aree di relazione simili (ciascuna che coinvolge 10 elementi), quando un post viene creato / aggiornato, il server del database deve occuparsi di 100 record (invece di 50 record). Raggiungerà un punto al di là di ciò che un server di database può gestire in un breve periodo di tempo, specialmente in un ambiente di hosting condiviso. Ciò farà sì che l’importazione non riesca durante la scrittura ripetuta dei dati ad alta velocità. Il problema peggiorerà con la crescita dei dati.

Nella mia e-mail, volevo dire che hai bisogno di una struttura dati che si adatti alle tue esigenze attuali e future.

Detto questo, a mio parere PODS è ancora il miglior plugin per la gestione di domini personalizzati con un ottimo supporto e un buon potenziale di ridimensionamento. Forniva un altro modo per memorizzare i dati personalizzati in una tabella separata (nota anche come archiviazione di tabelle), oltre a una tabella postmeta. Diversi clienti hanno importato più di 20.000 record con il trio (WP All Import, CIO Pro, PODS) in una volta sola.

Was this helpful?

0 / 0

Lascia un commento 0

Your email address will not be published. Required fields are marked *