facebook app azonosító
Korábban működött? Mert most nincs benne az oldal forráskódjában a Facebook azonosító, ami alapján összeköti az FB a honlapot az FB oldallal. Ha korábban ment a dolog, akkor kérd meg a fejlesztőt, hogy vegye fel az FB felhasználódat App adminisztrátornak, utána pedig az App felületen látható azonosítót be kell tenni a page.tpl.php-ben a body után, valahogy így:
<body> <div id="fb-root"></div> <script>(function(d, s, id) { var js, fjs = d.getElementsByTagName(s)[0]; if (d.getElementById(id)) return; js = d.createElement(s); js.id = id; js.src = "//connect.facebook.net/hu_HU/all.js#xfbml=1&appId=egy-hosszú-szám-ami-az-app-azonosító"; fjs.parentNode.insertBefore(js, fjs); }(document, 'script', 'facebook-jssdk'));</script> ... </body>
Ha ez megvan, akkor a https://developers.facebook.com/tools/comments?view=queue oldalon látod az új kommenteket. Én arról nem tudok, hogy az FB falra is ki lehetne ezeket tenni, de nem látom át az FB szolgáltatásait teljesen. (Ha van ilyen szolgáltatása az FB-nek, akkor valószínű van rá Drupal modul is.)
Tehát ez csak arra jó, hogy értesülj róla, ha valaki kommentelt a honlapon.
(Nagyon jó képek egyébként, bookmarkoltam az oldalt. Lehet tudni, ki tervezte a lakást? Írd meg légyszi magánban. Köszönöm szépen. :))
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
String Overrides
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
külön tartalomtípus
Hozz létre egy írók tartalomtípust, majd vegyél fel a cikk tartalomtípusodhoz egy szerző reference mezőt, ami az írók tartalmakat kínálja fel.
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
most van ennyi?
Kérdés, hogy már most megvan a 20.000 felhasználó, több millió cikk, vagy csak ennyit szeretnél? :) Mert ha 20.000 regisztrált felhasználó rázúdul egy több millió cikket tartalmazó honlapra, az elég komoly előzetes tervezést igényel (gyorstárazási stratégia, keresőindexelés, stb.)
De ha ez egy induló honlap, akkor jó a Drupal. Később, ha nőnek az igények, lehet hangolni rajta, vagy akár más rendszerre migrálni.
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
én nem ezzel kezdeném
Miért? Ez egy kis kiegészítő szolgáltatás a Panelshez. (Nem csak a $page['content']-et panelesíti, hanem az egész page.tpl.php-t kiváltja.) Én nagyobb webhelyekre mindig felteszem, hátha kell majd alapon, de szinte soha nem használjuk.
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
nem biztos, hogy megéri
A Contextet nem ismerem, a Panels esetén a régi Block felület teljesen elfelejthető, csak egy helyen kell mindent állítani.
Az égvilágon mindent meg lehet csinálni vele, épp csak kávét nem főz, viszont idő a megtanulása, a sok kattintgatás egy idő után elég fárasztó, kód szinten meg szinte átláthatatlanul komplex. A Block-kal ellentétben az ügyfél a Panels felületet egyáltalán nem tudja kezelni.
Csak olyan webhelyre javaslom, ahol nagyon sok blokk van, amelyeket nagyon sokféle feltételtől függően kell kirakni, környezeti változókat átadni nekik, stb. Egy átlag céges webhelyen nem éri meg használni.
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
saját layoutok
önmagában a panels modul szerintem nem sokat ér.
Hát ez egy elég húzós kijelentés. :)
Ha biztos vagyok benne, hogy a „körítés” (fejléc, lábléc) soha nem változik, akkor ami a kettő között van, arra elég a Panels, saját layoutokkal. A Panels Everywhere akkor jó, ha kell pl. a webhelyen belül egy microsite-szerűséget csinálni, ahol teljesen más a layout, mint a webhely normál részein.
„pláne nem tudja önmagában kiváltani a blokkrendszert”
A blokkrendszer összes szolgáltatása elérhető a Panels felületen keresztül. Meg mellette még mindenféle extrák: változók átadása, megjelenítési szabályozás, CSS #id és .class beállítási lehetőség, stb. Egy Panels webhelyen az ember jellemzően soha nem jár az admin/structure/block oldalakon.
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
külön panelek
Ahogy írtam, a Context-et nem ismerem, nincs összehasonlítási alapom.
A Panels tökéletesen megfelel arra, amit írtál. Hogy megéri-e, az csak utólag fog kiderülni. :) De legrosszabb esetben majd a következő projektnél fogod hasznosítani a megismerésére fordított időt.
A Mini panels arra jó, hogy több blokkot összefoghatsz egy csokorba, és a csokrot teszed ki egyik vagy másik panelbe egy meghatározott helyre. Egy-egy blokk tetszőleges számú csokorba bekerülhet. De nem muszáj a Mini panels-t használni, ez is csak egy kényelmi szolgáltatás, hogy kevesebbet kelljen kattintgatni. Például ha A, B, és C útvonalon külön-külön paneljeid vannak, de mindhárom esetben ki kell tenni az Aktív fórumtémák és az Új munkaajánlatok blokkot, akkor ezekből csinálsz egy minipanelt, és a minipanelt teszed ki a három panelbe.
A súlyokat az áthúzós felületen áthúzással állítjuk. :) Ha X útvonalon a blokknak z helyen kell lennie, Y útvonalon pedig w helyen, akkor két külön panelt készítünk, felvesszük a blokkot a megfelelő helyekre, és beállítjuk, hogy az első panel X útvonalon jelenjen meg, a második pedig Y útvonalon. (De persze lehet PHP kóddal és még sokféle megoldással operálni. Tényleg csak kávét nem...)
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
lehet mindent egy helyen
Igen, a Panels egyik hátránya a széttöredezett UI. Elvileg lehetséges, hogy nem töröd szét az admin felületet, hanem mindent egy helyen csinálsz, és PHP-kóddal szabályozod az egyes oldalelemek láthatóságát, mikor melyik változót kapják meg, mikor melyik layoutot használják, stb. De akkor meg felesleges a Panels, írj egy modult és kész.
Általános probléma, hogy ha van egy 10 különböző layoutot használó, 50-100 blokkot mozgató webhelyed, akkor nem tudod jól átlátni. Akár Panels-szel dolgozol, akár saját kóddal. Erre én saját kis chartokat, Excel táblázatokat és efféléket szoktam készíteni magamnak, de azokat naprakészen tartani megint csak plusz munka.
Drupal 8-ban az egyik fő fejlesztési irány a blokk rendszer kiváltása, de nem teljesen Panels irányba ment el a fejlesztés. Lehet, hogy már van valami kísérleti modul, én sajnos nem tudtam követni a fejleményeket az utóbbi időben.
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
status = 0
1. Ha a modulok adminisztrációs oldala nem elérhető, akkor az adatbázisban (pl. PHPMyAdmin segítségével) a system táblában megkeresni a Variable translation modult és átállítani a státuszt 0-ra, gyorstárat üríteni.
2. A Variable store és Variable realm modulokat külön-külön a kért verzióra frissíteni a szokásos módon. Ha itt fatal error-t kapsz, akkor a projekt hibajelentések közt érdemes szétnézni, hogy másnál is előfordult-e. Bár nem hinném, hogy stabil kiadás bekapcsolhatatlan lenne.
3. Variable translation modult bekapcsolni, update-et lefuttatni.
Tehát a lényeg, hogy előbb az alapmodult frissítem, és ha az problémamentes, akkor utána a függő modult. Ha pedig beleszaladtam egy ilyen csapdába, akkor kikapcsolgatni a problémás modulokat, és egyenként frissíteni őket, a függőségi sorrendben visszafelé (előbb azt, amitől valami függ, utána a függőt).