Mint ahogyan fent is leírták a kérdésedre a válasz az, hogy:
fájlokat másol, adatbázist másol: kész.

Nyílván Te azt szeretnéd, hogy ebbe a topikba minden felmerülő problémára meglelje a választ az aki ilyenbe vág. Mi meg azt szeretnénk, hogy minden felmerülő probléma külön szál legyen. Ne legyenek hosszú szálak csak rövidek. Egy konkrét problémára konkrét válasz. pl.:

Van egy ilyen-és-ilyen verziójú Drupal oldalam ilyen-és-ilyen modulokkal amit innen-ide-költöztettem. A költöztetés során ezt-és-ezt csináltam. Ezt a hibaüzenetet kaptam. Ezt-és-ezt próbáltam, itt-és-itt találtam valamit de ezek nem oldották meg a problémámat. Merre induljak tovább/mit tenne ön az adott szituációban?

Erre aztán jönnek a válaszok egy pici pontosítás után.

Kérdezhetnéd, ez miért jobb mint ha egy topicba meglelhető lenne a megoldás az összes felmerülő problémára. Hát most figyelj! Egy információt kétféleképpen lehet elrejteni:
1. korlátozzuk a hozzáférést
2. engedjük a hozzáférést, de felhígítjuk egyéb relevánsnak tűnő információval.

A te megoldásod sajnos a második esethez fog vezetni. Ha nem is azonnal idővel biztosan. Ezt mi nem szeretnénk.

Ennek persze megvan az a hátulütője, hogy a kérdezőnek energiát kell fektetnie a kérdés feltevésébe. Nem is keveset. A drága idejét rá kell áldoznia, hogy a problémáját megoldja. ;) Ez van, ezt nem lehet kikerülni.

Az meg, hogy egy topic elhal az itt nem probléma, hanem erény. Erény mert jó volt a kérdés és jöttek rá jó megoldások.

Persze én megértem, hogy nem akar valaki energiát fektetni a kérdésébe, csak azt szeretné, hogy meglelje a választ. Ezt is megadhatjuk:

42

pp

Én saját modullal oldanám meg a következő módon:
1. a modulomban kialakítanám a form-ot úgy, ahogy írtad: név, tárgy, üzenet.
2. hook_nodeapival odaragasztanám a kommentezhető tartalomtípus view nézetének($op = view) végére a formomat(drupal_get_form)
3. a formban lenne egy hidden típusú mező is: ez tárolná a kommentezett tartalom NID-jét
4. ez a rejtett mező a NID-et az URL-ből szedné, mint default value (hisz az adott node oldalán áll amikor kommentezni tud)
5. a komment elmentésénél (form submit) elmentésre kerülne minden adat, és a NID, hogy melyik tartalomhoz lett írva
6. szintén hook_nodeapival az adott tartalomtípus view nézeténél beépíteném a kommentek listázását (NID alapján)
Valamerre erre indulnék, de ez csak ötlet, nem teljesen kidoglozott, és nem biztos hogy pontról pontra jó megoldás.

Ha nem akarod ennyire bonyolítani, akkor meg valahogy úgy csinálhatnád, hogy létrehozol egy tartalomtípust az újfajtas kommenthez, kialakítod CCK-val amilyenre akarod, plusz CCK-val kialakítod a NID mezőt is, írsz egy hook_form_alter függgvényt, ami kitölti a NID mezőt URL-ből szedett NID-del. És ha mindez megvan, a kommentezhető tartalomtípus linkjei($link) közé beépítesz egy új linket, ami erre az új tartalomtípusra mutat, mellette egy GET változóval, benne a NID-del (node/add/sajatkomment?nid=x).
Így persze kattint a node alatt a linkre, és át lesz dobva egy új oldalra, ahol kommentet írhat, és ha megírta, akkor majd átdobja az elkészült komment view oldalára (bár ez is lekezelhető a form_alterben) - szóval az első irány jobb szerintem.

Első körben el kell döntened, hogy mi az amit szeretnél szinkronizálni a fejlesztői rendszerről az élesre.

Azután fel kell dolgoznod egy rossz hírt:

Nincs adatbázis tartalomra verzió kezelés. (az adatbázis sémára vannak kezdeményezések, de az adatokra nincsenek)

Ebből következik, hogy minden olyan adatot, amit verziókezelés alá akarsz tenni, ki kell tenned kódba. A views, rules, tartalomtípusok, valamint minden olyan aminek van mashine-name-e(általad megadott név), és amibe a felhasználó nem nyúlhat bele, könnyedén kitehetőek. (de pl. ha engeded, hogy a views-t módosítsa, vagy új rule-okat adjon hozzá, vagy belepiszkáljon a tartalom típusokba, akkor gondban leszel)

Azok az elemek, amiknek generált azonosítójuk van (tartalmak, menük, kategóriák stb.) azok mind, mind csak körülményesen tehetőek ki. Általános megoldás, hogy valahogyan generálnak neki egy egyedi azonosítót, ami általában pont attól nem függ amitől szeretnéd, és pont attól függ amitől nem szeretnéd. (mert a készítők aktuális workflow-jába úgy illeszkedett bele.) A másik véglet, amikor annyira általánosra csinálják meg, hogy visszavezettük a problémát az eredetire, mégpedig, hogy nem a felhasználó adja meg az egyedi azonosítót.

Fentiek igazak a nyolcas konfiguráció managemant-re is.

Ilyenkor vagy együtt élsz ezekkel a problémákkal, vagy programozol. (sokat, tesztelsz, programozol)

Kezdetben javaslom a Features és Strongarm modulokat felrakni.

2011-ben többek között erről beszéltem a Drupal Hétvégén: http://videotorium.hu/hu/recordings/details/3692,Instant_Drupal

Git-hez ajánlom még Nevergone videóit és a tanarurkerem.hu tanfolyamát(x) tagsággal tudod csak megnézni.