Először is ne legyél
Először is ne legyél write-only ;)
Aztán ha elolvasod az első két találatot amit mutattam az imént rájössz sok dologra:
- a drupal 6-os verzióját már nem nagyon szeretnék felkészíteni a php5.3-ra
- ugyanakkor lelkes programozók írtak egy patchet amit ha felraksz akkor elvileg működik, és ráadásul van egy másik megoldás is.
- a drupal 7-es verziója már működni fog az emlegetett php verzióval tuti, de az még nem stabil és nem jöttek hozzá ki a modulok mert még mindig aktív fejlesztési fázisban van.
A módosításokat nem javaslom, mert kitudja milyen problémákba fogsz még belefutni, és mint tudjuk drupal core-t nem hackelünk.
Ha saját gépeden szeretnéd feltenni, akkor telepíts egy régebbi verziójú php-t ha pedig szerveren akkor kérd meg az adminisztrátort, hogy tegye fel neked az utolsó kiadást a php 5.2-ből.
---
Tévedni mindenkinek szabad, csak a mérnöknek észre kell vennie.
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
Webes gondolkodás
Bocs, hogy közbeszólok, nem értek a dologhoz ilyen mélységekben, de Csonka Gergely hozzászólásában szerintem nagy tuttiság van.
A weben több "nyelv", több rendszer dolgozik együtt. Amikor "kitalálták" nem tudhatták, mi lesz belőle. Tákolás folyik. Egy C, C++, vagy Java programot valaki(k) megír(nak) (persze mások által megírt függvény- és objektumkönyvtárakból építkezve) és az kész lesz. Ezek az eszközök a webhez képest sokkal szűkebb környezeti feltételekhez lettek kitalálva (a Java OP rendszer függetlensége sokkal erőforrás igényesebb, mint egy C program). Olyan szintű "forradalom", mint a procedurális (struktúrált) kontra objektumorientált paradigma, a weben sokkal gyakoribb, az igények gyorsabban változnak és sokkal több paraméter szűk keresztmetszetének figyelembe vételével kell megoldani a dolgokat. Mivel túl nagy a diverzitás, csak atomi szinten lehet sztenderdizálni. Szerintem a Drupal nem lehet a webes gondolkodás alap mintája, legfeljebb egy igen jó eszköz lehet az olyan alap minták gyakorlati interpretálásához, mint az XML, vagy az RDF.
Egy örök zöldfülű
Fox Mulder
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
több megoldás is lehetséges (milyen meglepő:)
használod az organic groups modult. ezzel létrehozol egy 'lakossági' csoportot, azokat a tartalmakat amik a lakossági oldalhoz tartoznak, ebbe a csoportba küldöd be. a csoportnak beállíthatsz saját sminket (eltérő háttérszén pipa), a blokkokat pedig ugye sminkenként helyezed el az oldaladon, tehát a 'lakossági' sminkbe nem rakod ki a belépés blokkot és kész.
ugyanezt megoldhatod domain access -el is, az némileg összetetteb, de sokkal többet tud. (mondjuk nem is pont ugyan az a célja, mint az organic groupsnak. attól függ a döntés, mennyire akarod külön kezelni a két 'oldalt')
leggyalogabb megoldás, bármiféle contrib modul nélkül, hogy beleraksz egy sima on-off checkboxot minden tartalom típusodba, 'ez a tartalom lakossági' és ez alapján a template_preprocess_page -ben extra osztályt pakolsz a body tagbe, ez alapján más lehet a komplett színkészlet. a blokk konfigurációnál pedig php kódot választasz, argumentumokkal figyeled, hogy node/% oldalon vagy e, ha igen betöltöd a node (node_load()), és ha van értéke a checkboxodnak, akkor nem rakod ki a belépés blokkot.)
elsőre talán az organic groupsot javaslom. próbáld ki, ha valami nem megy, kérdezz konkrétat. (új téma lesz valszeg)
-
clear: both;
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
Na így már más a leányzó
Na így már más a leányzó fekvése..
Akkor sorban: Olyan nincs, hogy a blokk nézete nem látja az argumentumot, ott valami mást beállítás nem jó a blokk nézeténél. Hogy állítottad be az argumentumot? Previewnél kézzel beírva az UID-t kapsz vissza valamit?
aloszünleg mert nem adhatok meg neki megintcsak nevek utvonalat
Van egy érzésem, hogy nem blokk nézetet csináltál, annak ugyanis nem kell útvonal.
z első nézetnek pedig nem lehet blokknézete mert azt nem tudom modositani hogy az ne tartalomra hanem felhasználóra szürjön
Már hogyne lehetne. A mezők hozzáadásánál a Felhasználók csoporton belül az összes profil adat elérhető még akkor is, ha tartalom a nézet alapbeállítása.
De itt egy másik megoldás:
1. Csinálsz egy user alapú nézetet.
2. Beállítod az argumentumot >> UID from URL
3. Csinálsz egy kapcsolatot: "Felhasználó: Nodes authored"
Ezek után csinálsz egy page alnézetet a tartalmakkal és egy block alnézetet a felhasználó adataival.
----
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
vegkepp eltorolni
sok modulnak nincs uninstall fuggvenye, de a guestbook 6.x-1.1 es a 6.x.-2.x-nek is van..
az az erzesem, hogy a modules konyvtarban van egy regebbi guestbook modul..
rendszer tisztitas:
1. siman torlod a questbook modul konyvtarat mindenhol ahol megtalalod. (vagy ha csak questbook.modul (vagy.info) fajlt talalsz konyvtar nelkul, azt is)
2. kitorlod a {system} tablabol a "guestbook" sort
3. meglatogatod az admin/build/modules oldalt
4. ellenorzod a {system} tablat. Ha megint talalsz benne questbook sort akkor valahol meg ott van a modul, ugyhogy elolrol az elso pontra
5. bemasolod a kivant verziot a sites/all/modules konyvtarba
6. bekapcsolod a modult (valoszinuleg hibauzenetet kapsz)
7. kikapcsolod a modult
8. admin/build/modules/uninstall oldalon uninstallalod
ezutan mar tiszta a rendszered (a guestbook modultol)..
masodik tipp: ha a schema_version oszlop erteke a {system} tablaban -1, az azt jelenti, hogy a modul meg nem volt bekapcsolva (vagy sikertelen volt a bekapcsolas). Ilyenkor sem jelenik meg a modul az uninstall oldalon..