URL-ből
Ezt csak úgy tudod megoldani, ha az URL-ben átadod az aktuálisan megtekintett galéria nevét:
http://www.honlapneve.hu/galeria_1/kep_1
http://www.holapneve.hu/galeria_2/kep_23
Mindkét link ugyanarra a képre mutat, az előző-következő linkek célpontjait pedig az URL-ből kiszedett galeria_x alapján készíted.
A gond az, hogy ugyanaz a kép több URL-en is elérhető lesz, amit a Google nem szeret, hogy finoman fogalmazzunk.
Egyébként előző-következő linkek készítésére a Custom Pagers modul való, érdemes elolvasni a dokumentációt is, hátha találsz benne valami érdekeset ($nav_array['full_list'] például indexoldal készítésére)... Általában én inkább CCK-val és Views-zal készítek galériát, jóval nagyobb rugalmasságot ad, mint a hagyományos taxonómia.
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
alapcsomag
2. Regisztrációs űrlap beküldése után barátságos üzenet kiírása
A Drupal által kiírt üzenet (angol verzió):
Thank you for applying for an account. Your account is currently pending approval by the site administrator.
In the meantime, your password and further instructions have been sent to your e-mail address.
Ha nem tetszik, a nyelvi beállítások oldalán le lehet cserélni a szöveg magyar fordítását tetszőleges szövegre. Az üdvözlő email szövegét az admin/user/settings oldalon lehet beállítani.
3. Felhasználó értesítése az adminisztrátori jóváhagyásról
User status change notifications modul
Szeretném hangsúlyozni, hogy nem azzal van a gond, ha valaki kérdez – erre való a fórum. A gond az, ha valaki először kezd Drupallal foglalkozni, elkezd építeni egy honlapot, és minden egyes lépésnél ideszalad megkérdezni, hogy ezt vagy azt hogyan kell csinálni. Előbb kapcsoljuk be az alapcsomagban található összes modult, próbálgassuk végig a lehetőségeket, ismerjük meg a rendszert.
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
nem gyenge, másra való
Méltatlanul gyenge a Drupal egészéhez képest. A modul konfigurálhatósága, a lehetőségei, az admin lehetőségei, mind-mind olyan, mintha életében nem fórumozott volna aki írta.
Már nagyon sokszor leírtuk, hogy a Drupal alapcsomagban található fórum modul az olyan típusú fórumok kiszolgálására lett tervezve, mint a Drupal.org vagy a Drupal.hu. Feltesz valaki egy kérdést, és arra néhány körön belül megszületik a válasz, ezzel a szál lezárul. Ha később egy másik felhasználó rákeres a témára, akkor egy rövid, gyorsan áttekinthető oldalon megtalálja a megoldást. Ezért is kérjük, hogy úgy kérdésnek nyissanak a fórumozók új témát, mert egy többszáz hozzászólásos, végenincs, kanyargó szálból nehéz kibányászni a hasznos információt.
Másik műfaj a csevegős fórum, ott időnként több ezer, tízezer hozzászólás is érkezik a témaindítókhoz. Ott nem az a cél, hogy egy konkrét problémára, kérdésre választ kapjon aki a kérdést feltette, vagy aki később rákeres a témára, hanem az, hogy mindenki kifejthesse a véleményét. Az ilyen a fórumokon a szálak soha nem zárulnak le, legfeljebb érdeklődés hiányában elhalnak. Efféle fórum működtetésére valóban lehetnek jobb megoldások, mint a Drupal fórum.
1 profi mindenképpen kell
Ajánlom ezt a cikket.
A konkrét kérdésekhez pár szempont:
1. Teljesítmény
Mekkora forgalomra számítotok? Mekkora részét tudjátok cache-ből kiszolgálni? (Ehhez persze ismerni kell a Drupal cache mechanizmusait.) Errefelé közmondásos az "iwiw-klón", amit még a legelvakultabb drupalos sem tenne Drupalra :)
2. Szavazás
Az alapmotorba beépített szavazás csak bejelentkezett felhasználók számára működik. Ha névtelen látogatóknak is engedélyezni akarjátok, akkor fel kell áldozni a page cache-t, vagy írni egy saját (ajaxos) megoldást.
3. Kereső
A beépített kereső professzionális célokra nem alkalmas. Nagyobb webhelyeken az Apache Solr-t (JAVA alapú) használják sikerrel. Hamarosan fizetős kereső is lesz az Acquián keresztül. Vagy Google Custom Search.
A többi funkció nagyjából megvalósíthatónak tűnik, de ahogy a belinkelt cikkben is írják, az alábbi hozzáállásból nagy hasraesések lehetnek:
Drupal is a PHP application, and we're a PHP shop, so we can do Drupal
Legalább 1 profi Drupal fejlesztő kell a csapatba. Főleg ha a határidő < 3 hónap.
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
Friss telepítésen kipróbáltam
Jó ötlet volt a próba az új telepítéssel. Köszönöm! Kipróbáltam egy frissen telepített D10-en és ott nem jött elő a hiba. Azért aggasztó, hogy ilyen hibák bármikor előjöhetnek a további fejlesztéseknél akkor is ha úgy érzed, hogy nem követtél el semmi hibát és mindent jól csináltál és nem tudod a valódi okát. Úgy lehetne biztosra menni, hogy módosítok valamit az oldalon és utána ellenőrizzek le minden funkciót, nem történt-e valamilyen hiba és minden úgy működik-e, ahogy kell? Így nagyon hosszú ideig tart a a fejlesztés. Főleg ha vissza kell állni korábbi állapotokra, mert valami nem úgy működik, ahogy kell. Az is fennáll, hogy olyan hiba keletkezik amit nem veszek észre csak később és rengeteg munka kárba veszik. Arra sincs semmi garancia ha a mostani friss telepítéses próbát tovább folytatom abba az irányba, ahogy az előző verziót, nem áll-e elő ugyanez a hiba?
Valakinek van esetleg valami jó ötlete, tanácsa arra, hogy legközelebb ne vagy kisebb eséllyel futhassak (esetleg mások) bele ilyen hibákba?
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
Spam robotok és Spam emberek
Csak egy élő példa arra, hogy nem csak a robotok érik el az oldalt:
Nemrég teszteltem online környezetben egy Drupal Commerce webáruházat. Ha jól emlékszem, akkor a PayPal-tól kapott Developer fiók (test, seller/buyer, email, stb) miatt kellett, hogy online legyen, mert csak így tudtam tesztelni rendesen a checkout-ot.
Szóval az történt, hogy beüzemeltem egy Captcha-t és miközpben pár napig teszteltem a vásárlás menetét, 10 új vásárló jelentkezett be és regisztrált a weblapra. Mondanom sem kell, hogy mindegyik hamis adatokat adott meg úgyhogy nem volt nehéz kiszúrni ezeket.
Ekkor merült fel bennem a kérdés, hogy kell-e nekem ezzel foglalkoznom és az időm/energiám 20%-át azzal töltenem, hogy kiszűrjem a saját online boltomból az ilyen férgeket?
Több más tényezőt is figyelembe vettem és arra az álláspontra jutottam, hogy a Commerce helyett egy külső szolgáltatót bízok meg azzal, hogy közvetítsen a digitális termékek eladásában.
Köszi a tippet, a hasznos könyvjelzők közé mentettem a Honeypot modult!
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
kákán a hurok
Egyrészt -szerintem- a leírt információ kevés ill. nem értem, hogy amikor a linkelésről beszél az elején, akkor miért az ls parancsot írja, másrészt a logikája szerint a joe/includes fake könyvtárban nemcsak a módosított nevű, hanem az eredeti conf.php másolata is ott csücsülne.
Harmadrészt, ha tényleg azt akarjuk, hogy a joe saját könyvtárában levő config állomány másolatot módosítani tudja, akkor semmiképpen sem lágylinkkel készítünk másolatot a fájlról.
Ezek mind apróságnak tűnnek, de a Linux alatt nincsenek apróságok :oD
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
Köszönet + kérdések
Köszi a hírt meg a munkát. Többek között én is kerestem az a dolgot. És hát valóban csinál érdekes dolgokat. :-]
Lenne is rögtön két kérdésem:
1. A letöltött tgz-ben az install.txt azt írja, hogy patcheljem meg a common.inc-et. De nincs ehez való patch fájl a tgz-ben. Kimaradt volna?
2. A drupal roadmap listájában TODO jelöléssel szerepel az i18n. Ez azt jelenti, hogy biztosan benne lesz, vagy azt, hogy szeretnék ha benne lenne?
--------------------------------
Miles
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
elvetemült gazember vagyok :)
Én akkor elvetelmült gazember lennék, mert a weblabor sminkjében például lekérdezem a kategóriákat, hiszen valamiért nem minden esetben kapja meg a smink függvény az infót... Illetve ez így volt 4.4-el, aztán most megörökölte az új smink is ezt a viselkedést. Meg egyéb elvetemültségek is vannak benne. Ezért nem feltételezem, hogy a node smink függvény minden esetben tényleg csak a szöveget írja ki egy fejléccel. Különben már a fejléc több mint ami az alap honlap (bár a ATamás konkrét követelményeit még mindig nem ismerem).
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
Views Summary nézet
Views modul lesz a barátod, ott tudsz összesítő nézeteket készíteni (lásd a Summary kezdetű opciókat az Argumentumok résznél). A nézet a végén valahogy így néz ki:
A zárójelben azt mutatja, hogy az adott évben hány node-ot vittek fel, bár gondolom ezt valahogy le lehet tiltani, ha nem kell. Ezt a nézetet beteszed egy blokkba, és úgy sminkeled, hogy menünek látszódjon. Hogy pontosan hogyan kell a nézetet beállítani azt sajnos nem tudom, mert még nem dolgoztam a CCK dátum mezőjével. Az biztos, hogy lehet legördülő listás megoldást is készíteni, ahol a látogató maga választhatja ki, hogy melyik év node-jaira kíváncsi. (Lehet, hogy ez a Calendar-ba be is van építve?)
Az más kérdés, hogy érdemes-e ilyen menüt készíteni. Minden egyes oldallekéréskor végig kell néznie az összes dátum mezős CCK node tartalmat, és azokból összesítő listát kell generálnia. Elég erőforrásigényes megoldásnak tűnik. Persze körülményektől függ...