Egy olyan problémába futottam bele, hogy egy általam létrehozott tartalomtípust szeretnék címkékkel ellátni. Van, ahol több, mint 1000 különböző címkét is használok!!! Tömegesen exportálom, és importálom ezeket a tartalmakat, minden működik is, egészen addig, amíg magát a tartalmat meg nem nyitom. Ott ugyanis nem engedi elmenteni, mert csak 1024 karaktert enged beírni a címkék számára fenntartott mezőbe.
Kérdésem: ki lehet-e kapcsolni ezt a korlátozást valahol? Van egy olyan megérzésem, hogy ez az ajax általi lekérdezés korlátozása. Ennél a tartalomtípusnál nincs is rá szükségem, hogy felkínálja a már meglévő címkéket, mivel összesen ~28000 címkét használok. Teljesen használhatatlan ebben az esetben.
Tulajdonképpen ez egy cikkszám. És képeket szeretnék ezekkel a cikkszámokkal ellátni, hogy bármelyik terméknél ne a termékhez kelljen újra, meg újra feltölteni ugyanazt a képet, hanem egy kép-tartalomtípust létrehozni a képekkel, és beírva a cikkszámot, a terméknél már meg is jelenik.
(Nem szeretnék komplex webshop motort beüzemelni, mert jelen esetben a képek kategorizálása a feladat csak belső használatra. És az általam átgondolt struktúra alkalmas is rá, ha nem lenne ez az 1024 karakteres limitáció. A képek 99%-hoz még elég is lenne, de itt későbbi bővítés, vagy módosítás miatt jó lenne, ha a maradék 1% is működne rendesen.)
Hogyis van ez?
Nekem nem teljsen világos, hogy milyen tartalom típusaid vannak. Ha jól értem akkor neked van 2 tartalom típusod és 1 taxonómia szótárad.
Cikkszámok
Taxonómia szótár.
Valószínűleg nincsenek extra mezői, mert a $term->name tárolja a cikkszámot.
Képek
Ez egy node típus.
Mezők:
Termék
Ez egy node típus.
Mezők:
Szerkesztői folyamat
Ha nem export/import-tal kezelnéd a tartalmakat, akkor az alábbi lenne a kézi tartalom kezelés.
A 3. pont nem világos nekem.
Mivel a termék hivatkozik a cikkszámra (taxonómia), ezért adminisztrátori hibából előfordulhat az, hogy több termék is ugyan arra a cikkszámra hivatkozik. Vagy a kiválasztott cikkszám nem szerepel a kiválasztott képnél a "Cikkszámok" listában.
A cikkszámok (term) külön is adminisztrálhatóak, tehát lehet hogy törölnek egy használatban lévő cikkszámot.
A jelenlegi szerkezetnél nagyon sok helyre kell ellenőrzést beépíteni, hogy az adatok konzisztensek maradjanak.
Egyszer ki kell választani a cikkszám hivatkozást (taxonómia), aztán ki kell választani a képre a hivatkozást, amit nem tudok elképzelni, hogy milyen widget-tel történik (select, radio, autocomplete, views_explorer).
Észrevételek
Amennyiben a cikkszám egyedi minden terméknél akkor egy kicsit fura nekem, hogy a cikkszámot nem közvetlenül a termék tárolja, hanem egy referencián keresztül érhető el.
Van rá több módszer is, hogy egy feltöltött kép újra használható legyen több nodenál (field item-ben) is.
https://www.drupal.org/project/file_entity
https://www.drupal.org/project/entityreference_view_widget
media
scald
Entity vagy Term reference mezőben ~1000 értéket tárolni nem túl szerencsés, mert könnyen performance problémákhoz vezethet. Vannak olyan esetek amikor az összes hivatkozott entity-t be kell tölteni egyszerre. Ez lassú lehet és sok memóriát igényel.
1024-es korlát feloldása
Nagyon kell vigyázni mert az autocomplete widget-tel új cikkszámok is létrehozhatóak!
Az is lehet, hogy 1 darab új cikkszám jön létre, 7000 karakteres névvel. Vagy legalábbis szeretne létrejönni, de mivel egy taxonómia kifejezés neve 255 karakterre van korlátozva ez a próbálkozás hibához fog vezetni.
Vonatkoztassunk el a cikkszámtól
Az általad írt 3. pont most nem lényeges. Nem kellett volna belekevernem a cikkszámot, mert elvitte egy termékkarton irányba a gondolatodat.
Jelenlegi tartalomtípusaim: cikkszám, kép és fájl(PDF) tartalomtípusaim vannak. Azért különböztetem meg őket, mert később másfajta feldolgozást igényelnek. Egy tartalom CSAK EGY képet, vagy CSAk EGY PDF fájlt tartalmaz.
És egy term_reference mezőt. Ez utóbbi okoz fejtörést. Lehet, hogy nem is ezt kéne használnom, mert egyes esetekben túl sok egyedi azonosítót kellene ide bevinni.
Tehát más megközelítésben képzeld el, hogy van egy nagyon nagy létszámú 28000 tagú csoport. Fényképeket, dokumentumokat kell feltölteni. Mondjuk beküldök egy képet, és beírom a képen szereplő személyeket, akik mind egyedi névvel rendelkeznek. De a képen szerepelhet 1000 különböző ember is.
Keresésnél beírom ezt az egyedi nevet, és kilistázza azokat a képeket, amelyiken szerepel. Ez most működik is, ahogyan elképzeltem, de csak úgy, hogy importálom a tartalmat.
Ha máshogy küldöm be a képet, akkor az általad is említett autocomplete mezőt használom. A radio és select típust nem tudom elképzelni a sok címke miatt.
A views_explorert meg fogom nézni.
Meg fogom még nézni az általad említett file_entity, és entityreference_view_widget modulokat is. A Scald modult túl összetettnek találtam esetemben, bár nagyon tetszett. Próbálom minél kevesebb modullal megoldani, mert tényleg csak ennyi a cél. Kép és PDF katalogizálás (meg néhány egyéb fájl, de azokban nem kell indexelni). Tesztelés céljából már be is üzemeltem egy virtuális SOLR szervert is a dokumentumok indexeléséhez. Megy is szépen. De amíg nem áll össze maga a keretrendszer, addig ez nem téma.
Hogy miért akarom ezt létrehozni Drupallal?
Vannak erre windowson programjaim, de csoportmunkára nem alkalmasak, és azokat szeretném most kiváltani. A legfontosabb szempont, hogy lehessen exportálni és importálni az adatokat, mivel már több 10000 adat megvan. Van, amelyik terméknél 6-8 kép és doksi, vagy grafikai fájl. Tervezem az ImageMagick beállítását is alá, hogy a PSD fájlokat az általam kíván formátumra konvertálja, de ez a jövő zenéje. Most egy ilyen minimális kép és dokumentum katalogizálót szeretnék összekalapálni, amiben csak a lényeg van.
Néztem az OpenKM és Alfresco webes dokumentum menedzsment rendszereket is, de a feladatomhoz azok túl összetettek, bár készen vannak. És a címkézés ott sem olyan, amilyennek szeretném. Azért gondoltam, hogy Drupal-lal próbálkozom, mert alapszinten ismerem, és elég jól bővíthető rendszernek tartom. Ha valaki tud Drupalra készült kész rendszert, ami kép és dokumentumkezelést végez, azt megköszönném.