Oké
Oké, jogos, csak egy kicsit lehidaltam hirtelen. Bár megfogadtam, hogy idén csak jobb minőségű, tartalmasabb hozzászólásokat gyártok, most el is buktam kicsit. :)
Szóval ez még nem a Drupal 8, ezért itt még nincs olyan az alaprendszerben, hogy egy adat „csak úgy jön” valahonnan. Minden adat az adatbázisban tárolódik, vagyis igen, mindkét esetben az adatbázisban tárolódik a tartalomtípus és onnan kerül feldolgozásra.
Én úgy gondolom, hogy a node_type_save() elment egy tartalomtípust, mint pl. amikor modulból létrehozunk egy tartalmat vagy bármit. A hook_node_info() pedig definiál egy olyant, ami a modul működéséhez feltétlenül szükséges.
Érdemes megnézni ezt a listát:
http://drupalcontrib.org/api/drupal/drupal!modules!node!node.api.php/fun...
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
CKEditor Link Filter
Ha mégis úgy döntenél, hogy CKEditort használsz, akkor ahhoz érdemes felrakni a CKEditor Link modult is, az tartalmaz egy "CKEditor Link Filter" nevű szűrőt (ami beállítható az admin/config/content/formats/filtered_html, admin/config/content/formats/full_html stb. oldalakon), ami pont az általad említett problémát oldja meg, a belső node/123 jellegű linkeket lecseréli a szövegben a keresőbarát URL aliasra.
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
aboros hozzászólását látva
aboros hozzászólását látva lehet, hogy én értettem félre a kérdést (mellesleg szerintem félreérthető is volt), mert azt feltételeztem, az IS a célod, hogy magában a node body-ban lévő node/id-s linkek automatikusan cserélődjenek a keresőbarát URL aliasra.
Ezek szerint nem ez az elsődleges célod, hanem inkább csak az, hogy a node/id-s címet beírva irányítódjon át a júzer a keresőbarát URL aliasos címre.
Végül is ha a Global Redirect 301-gyel irányít át minden esetben a keresőbarát URL aliasra, akkor a node body-ban lévő linkek cseréjére nem biztos, hogy mindenképp szükség van (bár SZERINTEM érdemes lenne ettől még), mert akkor a keresőrobotnak is elmondja a 301-es kód, hogy a cím végleg elköltözött a másikra, tehát elvileg a keresőrobot a másikat (tehát a keresőbarát URL aliason található tartalmat, ami ugyanaz, mint a megfelelő node/id-s cím) fogja feltérképezni, nyilvántartani.
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
A placeholder nem zárja ki a labelek használatát, csak kiegészít
Úgy látszik, ez a téma sajnos duplikálódott:
http://drupal.hu/forum/weform-placeholder-modul/17481
Szerintem maga a placeholder attribútum tök jól megfér a label mellett, értelmesen felhasználva MÉG egyértelműbbé teheti a form használatát. Az általad linkelt cikkben teljesen jogos szempontokat vetnek fel, megemlítik, hogy ne akarjuk a label helyettesítőjeként használni a placeholdert. Ez így is van, de arról a pozitív hatásáról viszont kevésbé tesznek említést ezek a cikkek, hogy milyen jó lehet a placeholder abban az esetben, ha van egy label az adott mezőhöz (abban akár lehet hint is!), ÉS még emellé mutat egy példát a használatra a placeholder (nyilván ezt ízlésesen kell megoldani, hogy ne nézzen ki úgy egy űrlap, mintha tele lenne hányva túl sok infóval); így még biztosabb lehet, hogy a júzer a megfelelő mezőbe a megfelelő szöveget írja.
Szóval szerintem nem ördögtől való a placeholder attribútum használata, ha jól használják.
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
Én annyira nyugodt szívvel
Én annyira nyugodt szívvel azért nem törölném.. Próbáltam keresni olyan upgrademet, amit még nem ganéztam ki táblailag, de nem találtam, viszont a content* táblák manuális törlése egyáltalán nem rémlik. Sőt, ezeket elvileg a migrációs folyamat elintézi, de nem magától, a cck mezőket külön kell kezelni: http://drupal.org/node/1144136
A d6_upgrade filterre nekem az volt koncepció, hogy 1 hónap zavartalan működés után ment a levesbe.
Az imagecache dolgai törölhetők, ha már megcsináltad az image styleokat.
A nodewordst némi (sok) szenvedéssel fel lehet rugdosni d7-re a Meta Tags modulhoz, fix update path nincs, csak ötletelés: http://drupal.org/node/1281138
Amúgy ha már minden adatod a helyén, és azt látod d7en amit kell, és nem derül ki semmi miújság pár hónapig, a schema modul segítségevel szépen össze lehet szedni, hogy mi törölhető.
----
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.
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
eddig jutottam
Próbáltam az alábbi módszereket, de nem működik:
http://drupal.org/project/metatag
http://drupal.org/project/auto_opengraph
Próbáltam hozzáadni a meta elemeket, az alábbi cikkek alapján:
http://kahthong.com/comment/7294
Próbáltam a template.tpl.php-be hozzáadni, megmondani neki:
http://rickmanelius.com/article/tell-facebook-which-image-share
De mindegyik megoldás ugyanaz: egyszerre több képet is enged megosztani.
A field mezőm neve [kepecske], 1 db képet lehet feltölteni, ezt szeretném megosztani, és csak ezt az egy választást szeretném engedélyezni.
Ha valakinek van tapasztalata még, kérem ossza meg velem, mert már nem tudom milyen irányba is mehetnék tovább.
Próbáltam egy csomó modult megosztásra:
Addtoany
Sharethis
Facebookshare
Próbáltam saját kóddal, de semmi...
Köszönöm!
mini
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
táblák megosztása
Drupal szájtok között megoszthatók táblák - így közös használatba kerülhetnek pl a user-ek is, elég nekik egyik szájton regelni,
az ehhez kapcsolódó útmutatót itt találod:
http://drupal.org/node/22267
(nem ajánlott, de működik, készítettem már user megosztást, de mindjárt a telepítésnél és nem már működő weboldalaknál - itt sokkal bonyolultabb, mert a már regisztrált felhasználókat össze kell fésülni egy táblába-, a közösen használandó táblába)
- mindenképpen teszt oldalakkal - ha lehetséges az eredeti webshopok másolatával - dolgozz, ments, visszaállítható legyen a forrás és az adatbázisok is, a settings.php!
egy másik kérdés, hogy elegendő-e a userek megosztása neked
(a közös user használathoz a fenti leírás mutatja milyen táblákat kell megosztanod)
...webshop-t nem adtad meg,
kérdéses onnét mit kell és mit tudsz megosztani,
pl a rendeléseket is jó lenne egy helyen tárolni és látnia a vevőnek...
ha próbáltad kérlek, írd meg mire mentél vele, köszönöm
Geva
----- Számítások - Kalkulátorok
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
Ő arról beszélt, hogy
Ő arról beszélt, hogy felveszi _ugyanazt_ mezőt kétszer, és a képstílusokkal játszik a pagerben. Szinte teljesen biztos vagyok benne, hogy két _különböző mezővel ez nem működik. A views_slideshowban ugyanis a result egy sorában lévő eredménnyel lehet sakkozni, ez viszont nem egy sor lesz.
Továbbá amit írtál, az architect fail. A kis kép struktúrálisan a nagyképhez kapcsolódik. Ha két külön mezőt veszel fel neki, egy totál bizonytalan indexértéken kívül az égvilágon semmi nem köti össze a mezőket. Akkor most képzeld el, hogy van vagy 30 kép egy ajtóhoz! Elég átrendezni a sorrendet az egyikben, a jóisten nem fogja tudni lekövetni a másikban. A kaszkádolt törlésről ne is beszéljünk..
Nálam több helyen van mezőzött file, a kutyát nem zavarja, hogy a formon van még egy mező, arról nem is beszélve, hogy pár sor form_alter ezt a kérdést lekezelni. De még mindig ott van a lehetőség saját file bundle-re, egy saját _file_presave-en vagy validateen kívül nem hiszem, hogy sokkal bonyolultabb lenne megoldani a mimetype issuet - ha van egyáltalán.
----
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.
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
Majdnem jó
Nos kipróbáltam.
Annyi a bajom vele, hogy a profil függéseknél csak az első profil csoportot látja.
Ugye Profile 2-t használok és ha létrehozok egy új csoportot, akkor sem a csoportra sem pedig annak mezőire nem lehet hivatkozni.
A Profile2 install után ugye 1 profil csoportot találunk (main), ezt lehet átírni bármire, ill. lehet több más csoportot is létrehozni.
A conditional_fields modul ugyan kezel profil függőségeket, de:
1., Csak mező szinten, tehát egy egész mező csoportra nem lehet hivatkozni
2., Csak az első (main) csoport mezőit látja, tehát a 2. létrehozott csoport mezőire már nem lehet hivatkozni.
Mindebből következik, hogy nincs Profile2 integrációja.
Ez csak annyiban gond, hogy jobban örültem volna, ha a profile 2-vel szépen tagolt mező csoportokat egyszerre tudom adott függőség szerint megjeleníteni vagy eltüntetni.
Rengeteg profil mezőről van szó ugyanis.
Így most ömlesztve kell az összeset egy csoportban tárolni és egyesével beállítani minden mezőre a függőségeket.
Persze a semminél azért ez is jóval több.
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
alkönyvtár
Egy saját tapasztalatot mesélek el:
Fut egy oldal a fő-domainen (pl. http://example.com/). Mindegy, hogy éles- vagy tesztoldal-e, Mancika, a titkárnő lelkesen tölti fel tartalommal, amelyek linkje így a http://example.com/node/1 -hez hasonló lesz, a feltöltött fájlok pedig a http://example.com/sites/default/files/ linkről érhetőek el.
Aztán kitalálják, hogy a Drupal kerüljön a „kiscica” nevű alkönyvtárba. Ezért a linkek módosulnak http://example.com/kiscica/node/1 címre és a fájlok elérése pedig http://example.com/kiscica/sites/default/files/ lesz.
Viszont Mancika mindenhova az első változattal adta meg a linkeket, amelyek az alkönyvtárba helyezés után nem működnek.
Az alkönyvtárral kapcsolatos megjegyzésem erről a történetről szól.
Választ szeretnél? - Új kérdés, új téma - Tesztoldal - Trollkezelés - Frissítés