Sziasztok!
Adott egy oldal, ahol meglehetősen gyakran frissülnek a tartalmak és a frissítés dátuma szerint kellene listázni azokat. Gondoltam a node verzió (revision/version) segít majd rajtam, de tévedtem.
A node module új verzió létrehozásakor a node_revision táblában szépen eltárolja az aktuális node azonosítóját (nid) és az új verzió azonosítáját (vid), valamint az aktuális időpontot. Ezzel minden rendben van, amíg módosításra nem kerül az adott node, mert ilyenkor frissül a node_revision táblában is az időpont. Így pl. ha nyelvtani elírást módosítunk, frissül a verzió "létrehozás" dátuma és ha a views-ban a "Node revision: Created date" szerint listáznánk, akkor természetesen nem azt kapjuk amit akarunk. Ez utóbbi már inkább views szűrő elnevezés hiba (itt is említik: http://drupal.org/node/679740), de az alap probléma, hogy a verzió létrehozási dátumát nem tárolja a drupal.
Találkozott már vki ezzel a problémával? Milyen megoldást ismertek, ajánlotok?
Én írtam egy egyszerű module-t, ami új node verzió készítésekor (nodeapi) saját táblában tárolja a verzió létrehozás dátumát. Vmint írtam ehhez views szűrő támogatást, hogy e szerint lehessen rendezni a tartalmak listáját.
Ez a module valójában a node_revision kiegészítése "created" időponttal. Telepítéskor leellenőrzi, hogy az adott node-hoz tartozik-e új verzió (nid, vid azonos-e) és e szerint inicializálja a verzió létrehozás dátumát - ha azonos, akkor a node létrehozás dátumát tárolja, ellenkező esetben pedig a node_revision dátumát. Nagyobb site-ok esetében batch használata lenne talán még előnyös, hogy ne fusson ki a php az időből.
Ez miért is probléma? A
Ez miért is probléma? A node-ot vagy verzió kezeled, vagy nem. Ha verziókezeled, akkor a verzió módosításának dátuma megegyezik a létrehozásának dátumával. Ha meg nem verziókezeled akkor értelmetlen a kérdés.
nid és a vid azonosság meg kb. addig működik amíg egyetlen egy verzió létre nem jön a rendszerbe, mivel attól fogva mindig más lesz. Ha már kifacsarod a működést akkor facsard ki rendesen és a node_revision táblában található összes verzióhoz hozz létre ilyen értékeket.
Az egy jó megoldás amúgy amit csináltál, mert ez nem egy hiba/probléma, hanem egy új feature, funkcionalitás és ehhez új modul dukál. :D
pp
Palócz István
https://palocz.hu | https://tanarurkerem.hu
Azért probléma, mert...
Így van ameddig nem kívánsz egy nyelvtani elírást javítani (tehát nem akarsz új verziót, mert nem verzió változik, hanem u.a. a verziót "javítod") onnantól kezdve nem a verzió létrehozási dátumát adja vissza/tárolja a node_revision, hanem a módosítás dátumát - azaz felülírja a node_revision-ben.
Értem én amit írsz, de nekem akkor is fura, hogy ha vki használni akarja a verzió kezelést, akkor onnantól minden egyes módosításnál (node szerkesztés) új verziót kell létrehoznia, amennyiben használni akarja a verzió létrehozás időpontját. Ha ezt az utat választottam volna, akkor is kell egy form_alter, ami automatikusan bepipálja az "új verzió készítése"-t, mert szinte biztos hogy akad olyan szerkesztő aki elfelejti majd. Ráadásul minden szerkesztőnek ki kell adni a verziókezelés jogot. Nekem ez nem nagyon tetszik :)
Ahogy írtam, a module-om
Azaz minden node_revision bejegyzéshez létrehoz egy bejegyzést, annyi módosítással, hogy amennyiben a nid vid egyezik, a node táblából veszem a node létrehozási dátumát és nem a node_revision-ből, mert ott a node "changed" érték szerepel.
Nem értelek továbbra sem.
Nem értelek továbbra sem. Miért tekinted problémásnak a teljesen evidens működést. :D
Ha egy node-nál bekapcsolom egyszer az új verzió készítését attól fogva az mindig be lesz pipálva. Ráadásul akinek nincs joga a verziók kezeléséhez az ezt ki se tudja kapcsolni.
Az meg, hogy mikor készüljön új verzió az egy vicc ugye? Ha valamit változtatok legyen az bármilyen kicsi változtatás is az egy új verzió és kész.
Továbbra is azt mondom, hogy a nid és vid értékeknek egymáshoz semmi közük! Abból, hogy egyezik-e vagy sem semmilyen következtetést nem tudsz levonni azon kívül, hogy ha egyezik akkor soha senki nem hozott létre még új verziót egyetlen egy node-ból sem és ha nem akkor már igen. Ennél többet nem.
Mondjuk usability szempontból el lehetne gondolkodni azon, hogy a verzió kezelést csak bekapcsolni lehessen és ki már ne. :D
pp
Palócz István
https://palocz.hu | https://tanarurkerem.hu
Tényleg úgy működik?
Akkor az én Drupal verziómmal (6.16) van a gond? Ha egy node-hoz létrehoztam már új verziót, és azt szerkesztem, nincs automatikusan bejelölve az új verzió létrehozása.
Ui:feldobtam egy új Drupal-t és ott sem úgy működik ahogy írod.
Tartalomtipus beallitasok?
A tartalomtipusnal kivalasztod, a verziokezelest, es az uj tartalom felvitelenel alapbol bent van a pipa, ha egy meglevo tartalmat nezel ott valoszinu nem lesz bepipalva.
---
http://drupalaton.hu
Jogos.
Jogos.
Konklúzió
Tehát ha verzió kezelem a tartalmakat, akkor nincs módom rá, hogy kiszűrjem a nyelvtani elírásokat, azaz bármilyen módosítást végzek, új verzió jön létre = a lista elején fog megjelenni (ha e szerint rendezek) a módosított tartalom és nem tudom megmondani a drupalnak, hogy ez u.a. tartalom, ne tárold külön, mert csak egy betű elírás volt.
Szerintem akkor lenne ez korrekt, ha nem lehetne node szerkesztéskor új verziót létrehozni, ha a tartalomtípusnál ez nincs engedélyezve, ill. node szerkesztéskor kikapcsolni az új verziót, ha az a tartalomtípusnál be van kapcsolva. Így tényleg minden változtatás új verzió lenne, és ehhez tárolva lenne az időpont is. Mert engem továbbra is zavar, hogy ki-be kapcsolható az új verzió létrehozása, de kikapcsolás esetben is eltárolja a node_revision-be a módosítás időpontját. Tehát a módosítás időpontja szerintem duplikálva van - ott van a node táblában "changed" néven, és a node_revisions-ben "timestamp" alatt. Rosszul gondolom? Miért nem elég a node táblában a changed és a revisions-ben pedig a létrehozásé? Tud vki gyakorlati példát arra, hogy miért van így? Vagy magyarázatot :)
nem igazan ertem az egesz problemat
ha a node letrehozasa alapjan akarsz rendezni, akkor miert nem az alapjan rendezel es kesz. nem ertem hogy jonnek ide a verziok.
ha te a tartalom tipusban uj verzio letrehozasat alapertelmezesnek allitod be, akkor nem fogja tudni azt kikapcsolni senki, csak akinek van joga verziok kezelesere.
gyakorlati pelda:
egy rontott verziorol visszaterek egy korabbi verziora... akkor maris nem ugyan az a node changed es a revision timestamp.
-
clear: both;
Nem a létrehozás, hanem a
Nem a létrehozás, hanem a frissítés dátuma szerint szeretnék rendezni. Azaz van egy tartalmam, hozzákerül pl. egy fotógaléria, vagy bármi más fontos információ (új verziót hozok létre) és egy frissítés szerinti listát szeretnék. Azaz egy friss node-ok listát. Viszont nem akarom hogy előre kerüljön egy száz éve létrehozott node, amit a napokban vki javít elírás miatt.
A gyakorlati példát nem teljesen értem, mert ha visszalépsz egy verzióra, akkor tudtommal új verzió jön létre - új bejegyzés, új timestamp. A régi verzió timestamp-je megmarad és a node changed szintén az aktuális timestamp-et kapja.
tovabbra se ertem, hogy minek ez a kavaras a revisionbe
a viewsban van egy tracker nezet, te pont egy olyat akarsz. kapcsold be es lesd meg hogy van beallitva vagy klonozzad. elore szolok, hogy nem a revision date -et hasznalja, hanem a node updated date -et.
amit csinalni akarsz, (modositas datuma szerinti rendezes) annak semmi koze a node verziozashoz, nem kell hozza verziozni, anelkul is megy.
masik gyakorlati pelda akkor:
letrehozok uj verziot, de miutan mentettem eszre veszek egy hibat. ujra szerkesztem, de most mar nem akarok uj verziot letrehozni... akkor changed valtozik, de a revision datuma nem.
-
clear: both;
Nem telejsen azt akarom :)
Ahogy írtam: nem akarom, hogy ha pl. nyelvtani elírást javítok (szerkesztem a tartalmat = a node changed frissül) előre kerüljön a listában. Tehát a node updated nem megfelelő.
hogy mikor keszitesz uj verziot es mikor nem, az rajtad all
alapertelmezett az, hogy jojjon letre uj verzio. ezt csak az tudja felulirni akinek van ra joga. ha te eppen egy minimalis elgepelest javitasz, kezedben a dontes joga, hogy jojjon e letre uj verzio vagy sem. ha nem jon letre uj verzio nem kerul elore, ha letrejon uj verzio elore kerul.
nem ertem mi a problema.
itt a forumba is szamtalanszor javitunk bele forumtemakba, van hogy uj verziot hozunk letre, van hogy csak egy elgepelt cimet javitunk, akkor mondjuk nem hozunk letre uj verziot.
ennyi. tokeletesen mukodik ez, nem tudom minek bonyolitod. :) ha nem akarod elore hozni, nem hozol letre uj verziot, csak belejavitasz es mented. mi ezzel a problema? :)
-
clear: both;
A probléma az, hogy ha a
A probléma az, hogy ha a node-ot javítod (elírást), annak ellenére hogy nem hoztál létre új verziót, de módosítottad a node-t, a node táblába a "changed"-hez bekerül az aktuális timestamp (ez ok), de a node_revisions-be is bekerül az aktuális timestamp, azaz a módosítás dátuma fog szerepelni a node_revisions-ben. Tehát akkor mi alapján rendezed a listát? node_revisions timestamp alapján nem lehet, mert nyelvtani korrekció után előre kerül. Node posted szerint szintén nem, mert új verzió esetében a node nem fog előrekerülni.
végigzongoráztam az egészet lerő fee, meg feerő le,
bosszantó, de a felvetés úgy tűnik jogos. :)
sehol nem találtam olyan issuet, ami erre panaszkodna vagy foltot adna erre, ezen lepődtem meg igazán.
nem tűnik túl logikusnak ez a működés, ha nem pipálom be, hogy új verzió, akkor az lenne a logikus (nekem), hogy csak a node->changed -et uppoljuk a pillanatnyi timestampre, de a revision created az marad ami volt.
ezt egy elég egyszerű patchel el lehetne intézni, kíváncsi lennék, ha elkészítesz egy ilyet és nyitsz neki egy issuet, ahol szépen elmagyarázzuk, hogy mi a helyzet és miért gondoljuk, hogy ennek emígy kéne működnie, akkor mik lennének az ellenérvek (ha lennének egyátalán) és mikor kerülne be ez a coreba.
csinálsz ilyen patchet? ha nem, csinálok én, csak azért kérdezem. :)
előbb egy patchel próbálkoznék és ha elutasító a nép, akkor írnék csak modult rá.
-
clear: both;
Nekem is először a patch
Nekem is először a patch jutott eszembe, de 1000%, hogy visszadobják, lásd, amit lentebb írtam. Szerintem nem fogják ezért felborítani a node_revision táblát. És szvsz ennek a hátterében a "fejlesztői logika" áll, beleértve a verziókezelést programozói szinten. Ha változás van, akkor az új commit, és mindegy, hogy csak helyesírási hiba van. Kb, amit pp írt az elején.
Azért kíváncsi vagyok, mi lesz az eredmény.
----
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.
nade ember...
miért kéne felborítani a revisions táblát? :)
ha nincs "create new revision" akkor a query ne nyúljon a revision.created -hez, ennyi a történet. :) nem kell új mező, meg semmi kavarás, a legútóbbi változtatás időpontja amúgy is ott van a node.changed -ben.
egy helyen kell a node modulba nyúlni és egyetlen queryt átírni, hogy update node_revision ne legyen, ha nincs új revision. sluszpasz. minden más ettől ugyan úgy fog működni, még a views handler is.
ilyen hozzáállással meg kb soha ne küldj semmilyen patchet, úgyis visszadobják. :)
-
clear: both;
Holnap megbeszéljük...
a DUG után ;)
rossz erzesem van
Azt hiszem te nem arra akarod hasznalni a reviziot amire szantak.
Jo lenne tudni konkretan mit is szeretnel, talan konnyebben tudunk segiteni.
---
http://drupalaton.hu
Kellett egy nap, amíg
Kellett egy nap, amíg megemésztettem ezt a témát, kb mostanra esett le, hogy mi a gond. Érdekes, amit írsz, de érthető oka van. Ahogy írtad, a node revision táblában mindössze timestamp mező van, nincs created/updated. Ha végiggondolod, teljesen jogos, hogy a timestamp frissül, ha nincs új verzió, hiszen a legutóbbi verzió akkor készül, amikor utoljára megnyomod a save-t.
Például.
Node verzió 13:45 elmented. 13:55-kor beleírod, hogy "habsili", és elmented. Ha a node revision táblában a timstamp 13:45 maradna, az hazugság lenne, mert a 13:45 kori állapothoz képest már hozzá került a "habsili".
Amit írtál, teljesen jó megoldás, a saját táblában kezelése a dolognak. Amúgy akár meg is oszthatnád, hátha másnak is jól jön majd.
----
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.
Örülök :)
Kösz, hogy szántál időt az emésztésre :), és a példát is. Nem is azt állítottam, hogy rossz az egész drupal úgy ahogy van :), de boldogabb lennék, ha a node_revisions-ben lenne egy "created" mező is. Szerintem a verziókezelés sem borulna meg ettől csak kiegészülne.
A module-t megosztom, amint megírtam a batch részét.