Sziasztok!
Van egy szótáram, amit eredetileg azért hoztam létre, hogy folyókat, patakokat lehessen hozzárendelni egy-egy adott node-hoz term reference-ként. Az igények időközbeni módosulása miatt azonban ezeket a kifejezéseket szeretném átültetni node-okra, mindenféle fieldjükkel együtt.
Ez a szótár most hasraütésszerűen kb. 300 elemet tartalmaz.
Az eredeti elképzelés jónak tűnt, időközben a megrendelő kérése alapján ezeket a folyókat (magukat a term-eket) viszont elkezdtük kibővíteni mindenféle fieldekkel (sok-sok adat): több képgalériával (Image fieldek, külön-külön), szövegmezőkkel, integerekkel, stb.
Aztán az volt a kérés, hogy ne legyenek alatta egyáltalán listázva a hozzákapcsolt node-ok, mert azok feleslegesek, meg csúnyán néznek ki. Na, akkor ezt hook_preprocess_page()-ben, egy csúf kis unset()-tel eltüntettem, de ekkor merült fel igazán, hogy azért a taxonomy nem ilyesmire való. Meg a taxonomy termek szerkesztésére vonatkozó jogok nem annyira szofisztikáltak a core-ban, külső modulok nélkül, pl. sajnos alapból aki megkapja a taxonómiaszótárak szerkesztésére a jogot, az látja a "Manage display" fület is (volt is erről egy issue, meg itt egy kérdés: http://drupal.stackexchange.com/questions/22533/how-to-hide-manage-field...), meg hasonlók.
A kérdésem:
hogyan lehetne átmozgatni/átmásolni/átalakítani node-okká ezeket a taxonómia-kifejezéseket minden fieldjükkel, fordításukkal együtt? Például a képek átmásolása tűnik igazán problémásnak, az hogyan történne? (rengeteg kép van már feltöltve a kifejezésekhez)
Biztos nem egy egyszerű feladat, főleg ennyi fieldnél, de talán van valami ötletetek. Előre is köszi!
átmásolás lenne a legjobb
Igazából az összes adat átmeneti átmásolása lenne a legjobb, így lehetne csekkolni az esetleges különbségeket. Meg mondjuk ahogy észrevettem, ha pl. a Media widget használata esetén A content type egyik mezőjénél egy B-ben feltöltött képet választok ki, és B-nél törlöm a képet, akkor A-nál is törlődik. (Pedig azt hittem, van csekkolás arra vonatkozóan, hogy máshol nincs-e használva, és akkor megmarad attól még a fájl, amíg van rá hivatkozás, ha már entitás a fájl.)
Létrehozol egy tartalomtípust
Létrehozol egy tartalomtípust mondjuk FOLYO névvel.
A term field-eket a "Létező mező hozzáadása" lehetőséggel add hozzá a tartalomtípusodhoz.
Migrate vagy Feeds modullal migráld be a term neveidet FOLYO tartalomtípusú node-okká, de csak a neveit.
Most az adatbázisban a term és a node field értékek közt csak annyi a különbség, hogy a term sorban a entity_type = taxonomy_term a bundle = SZÓTÁRNEVED illetve az entity_id és revision_id.
Vagyis ha egy ügyes php scriptben betöltöd a szótárad term-jeit, majd végiglépteted. A term neva alapján rákeresel a node névre, így van egy tid és node id-d amit ugye meg kell feletetni.
A fildjeid adtbázis táblájában az tid=entity_id sorban a entity_type = taxonomy_term helyett node, a bundle = SZÓTÁRNEVED helyett FOLYO, a entity_id és revision_id pedig a nid értéke.
Így leírva kicsit komplikált. Rövidebben:
Ha van egy tid=11 és egy nid=11 szótárelemed és tartalmad, és mindkettőnek van field_akarmi mezője. Akkor az adatbázisban a két entitás úgy különül el, hogy a entity_type = taxonomy_term illetve node a bundle = SZÓTÁRNEVED vagy TARTALOMTÍPUSOD neve.
Vagyis ha a két egyforma entity_id-jű sor entity_type és a bundle értékét felcseréled, akkor az adatok felcserélődnek :)))
És ez tényleg működik mert ki is próbáltam.
Mindezt a Migrate modulban is meg lehet csinálni, de abban van néhány homályos pont amire kapásból nem tudnék megoldást mondani.
Azt azért hozzáteszem, hogy csak nagyon óvatosan az ilyen direkt módosítással, mert alaposan el lehet rontani sok mindent. De megfontoltan és okosan meg lehet csinálni.
...mit tudok: http://web.termuves.hu
wow, köszi! Nem gondoltam volna, hogy ez így működhet!
Köszi szépen az alapos választ!! Ez nagyon hasznos volt!
Szóval az ügyes PHP-script már a Drupal hatókörén kívül működne. :)
Ha jól értem, akkor például ki kellene gyűjtenem a fieldek machine name-jeit szépen egy tömbbe, valamint meg kellene feleltetnem a Migrate vagy Feeds modul segítségével legenerált ÚJ node id-kat és RÉGI term id-kat egymással, hogy egyértelmű legyen, konkrétan melyik nid-hoz szeretném végül is kapcsolni az adott fieldek tartalmait.
Például a taxonomy szótárhoz kapcsolt fieldem machine name-je ilyen:
field_ez_az_en_kepfieldemakkor az adatbázisban a
field_data_field_ez_az_en_kepfieldemtáblában kellene az "entity_type" mezőt a "taxonomy_term" értékről átállítom "node" értékre, a "bundle" mezőt pedig az új bundle-névre (példádban FOLYO).A problémás viszont az entity_id és revision_id értékének megfeleltetése lehet, ahol lehet hibázni, hogy megfeleljen egy az egyben a taxonomy term az ÚJ, Migrate vagy Feeds modullal generált node-ok id-jainak. Gondolom ez esetben például konkrét cím alapján kéne egyeztetni, hogy mik felelnek meg egymásnak, vagy ilyesmi... habár ezen még agyalnom kéne, mi lenne a megfeleltetés legjobb módja.
Erre ötlet?
És tényleg nem ragaszkodik a field bármi más módon magához a korábbi entitáshoz? Tehát annyi, hogy akkor ezentúl a taxonomy termeknek egyszerűen nem lesz meg a korábbi fieldjük, mert át lettek állítva más bundle-höz? Nincs valami egyéb kapcsolat is? Úgy értem, amikor a UI-on keresztül adunk hozzá egy fieldet, akkor csak ezeket a kapcsolatokat építi fel, csak ezekbe a mezőkbe írogat a Drupal, máshova nem menti a kapcsolatot (például hogy mi jelenik meg a Manage Display-nél, Manage Fields-nél)?
Ez tényleg ilyen "egyszerű" lenne? :)
Már csak pironkodva kérdezem meg, hogy példakódod nincs rá? :))
Persze itt megpróbálom publikálni, ha jutok valamire (már ha szalonképes a kód, próbálom úgy megírni), csak kérdezem, hátha meg tudsz spórolni nekem mondjuk egy-két órát a saját korábbi próbáddal (már ha megvan még egyáltalán, és ha nem gáz a kér(d)és - vagy csak egy-két dologra tesztelted?).
A próba abból állt, hogy egy
A próba abból állt, hogy egy node-term párosnál kézzel átírtam...
Ha szépen akarod csinálni, akkor migrate modullal csinálod meg, de ugye ehhez meg kell ismerni a migrate-ot is. Ez azért is szebb, mert a mentés részt rábízod a modulra és ő úgy fogja elmenteni és az eredeti term field tartalom kapcsolatok is megmaradnak.
A saját php script egyszerűbb (de nem szép, csak hasznos), mert kimarad a migrate...
...mit tudok: http://web.termuves.hu
"Nincs valami egyéb kapcsolat
"Nincs valami egyéb kapcsolat is?"
Ezt a saját php kódos dolgot szvsz nyugodtan ugord, 100%, hogy kárt teszel. Egy példa, ami core, és tuti szétvágja: file_usage, ez már biztosan inkonzisztens lesz. De százszám vannak olyan modulok, amik entity type alapján dolgoznak, pl a userpoints soha nem lesz képes megfelelően kiszámolni az aggregált dolgait, de ott a subscriptions, flag ésatöbbi, de ha neadjisten a file_entity_paths még megy az oldaladon, akkor.. Khmm.. Hát elképzelésem sincs, mit csinálna, de valszeg simán elkezdené átnevezni a fileokat, mivel nem lesz matching config + tele lesz false adatokkal az egyik tábla, mert nincs aki megmondja neki, hogy hello, én már node vagyok.
Vagy migrate, vagy feeds, ez utóbbi lehet klikk-klikk, egy csv file http://drupal.org/project/views_data_export -al, egy feeds importer hozzá és kész.
----
Rájöttem, miért kérdezek olyan ritkán a drupal.hu-n. Amíg szedem össze az infokat a kérdéshez, mindig rájövök a megoldásra.
Azért abban vitába szállnék,
Azért abban vitába szállnék, hogy "100% hogy kárt teszel", de mivel pusztán elvi síkon tudnánk róla vitázni nincs sok értelme...
Az viszont biztos, hogy körültekintő módon kell eljárni.
De a Migrate jó választás...
...mit tudok: http://web.termuves.hu
Akkor asszem Migrate
Köszi a választ neked is! Tartottam tőle, hogy valami egyéb kapcsolat is lehet, amit tönkrevághat a sima mezőátírás.
Egyelőre sajna klikk-klikkről videót nem találtam, bár azzal már van tapasztalatom, hogy lehet Feeds-zel sok node-ot létrehozni, és mondjuk taxonómiakategóriát hozzárendelni, de azzal nincs, hogy például rendes képmező-tartalmakat hogyan lehet migrálni.
A Views data export okés, hogy készít egy CSV-t mondjuk a textfieldek tartalmaiból, meg ilyesmikből, de mit kezd a képekkel?
Van esetleg példa valahol ilyenre is, amit én szeretnék? Én még nem találtam, bár sanszos, hogy nem néztem körül rendesen.
És köszi még egyszer!
képek
Képeknek elég az URL-t átadni a Feeds-nek és megy szépen.
Választ szeretnél? - Új kérdés, új téma - Tesztoldal - Trollkezelés - Frissítés
Na, az nem rossz. És azt is
Na, az nem rossz. És azt is lehet mappelni valahogy, hogy automatikusan szedje ki a kép konkrét URL-jét (valahogy biztos, nyilván nem kézzel kell belekalapálni)? A szokásos
public://"sémák" szerint kell megadni?Amúgy ilyesmivel próbálkoztatok már?
Most megint kérdés lett számomra, a Migrate vagy a Feeds modullal érdemes próbálkozni. :D
Igazából konkrétan ilyesmihez nem találtam még leírást, ha tudtok ilyenről, ne tartsátok magatokban. :)
Migrate modul
A migrate modul pont ezt csinálja, ami neked kell. Kell írni egy egyedi migrálás class-t és futtatni.
--
Szabó Dénes - Internode.hu - Munkára fogott weblapok
Példa ilyesmire van valahol?
Köszi szépen a választ!
Eddig képmező tartalmainak más content type-ba mozgatására nem találtam Migrate-es példát, csak taxonomy és egyebek átmozgatására, importálására, Te esetleg tudsz ilyenről?
Köszi!
hogy kerested?
ezt írtam be: how to migrate file fields migrate module drupal
3. találat volt (első kettő d.o link volt)
http://civicactions.com/blog/2009/oct/27/migrate_module_file_handling
persze kétezer kilences. biztos lehet találni újabbat is.
szerk.: túlkombináltam, most azt írtam be, drupal migrate file example:
https://www.acquia.com/blog/file-import-improvements-migrate-24
-
clear: both;
Köszönöm szépen, elolvastam,
Köszönöm szépen, elolvastam, így már a teljes homályból legalább valamennyi eloszlott, bár itt is picit más az alapvetés: "In this example, the source files are mounted at /mnt/files and the image_filename source field is a file path relative to that directory."
Konkrétan arra még nem találtam részletes példát, hogy egyik Drupal bundle-ből másik Drupal-bundle-be (nem másik CMS-ből, nem fizikai elérési útvonalakról, hanem Drupal-útvonalakról) hogyan költöztetem át az adatokat.
Mindenesetre a Migrate dokumentációja a drupal.org-on elég hosszadalmas:
http://drupal.org/migrate
szóval nem úszom meg, hogy elolvassam az egészet, hogy kitisztuljon a kép: ami még mindig homályos, hogy hogyan illik implementálni az osztályokat, hogy is néz ki az egész, kell-e ciklus, vagy csak átadom a taxonómiatáblából a teljes db_select-et, aztán megfeleltetek elemeket neki mondjuk egy hook_migrate_destination_prepare_node() implementálásával, hookokkal dolgozom vagy osztály-implementációkkal, egyelőre homály a működése, egyrészt mert túl keveset olvastam a témában, és nem futottam át egészen részletesen a gyári példákat, másrészt mert az eddigi példák, amiket láttam, csak részt mutattak be az egészből (sajna az általad mutatottak is), nem vitték végig a példát, csak leszűkítették egy konkrét részére.
De megpróbálok akkor tájékozódni még.