Sziasztok,
a drupalos oldalamon amikor egy felhasználó regisztrálja magát, akkor arról kap egy levelet, illetve én is mint webmaster. Ezután én kézzel aktíválom a felhasználót.
Azt tapasztalom, hogy ennek tényéről nem kap levelet a felhasználó.
Azt szeretném kérdezni, hogy ez csak egy nálam lévő hiba e?
Vagy esetleg valami modult kellene feltenni, vagy valahol a kódba belenyúlni?
várom segítségeteket.
Üdv. Gábor
Hogyan lehet megtudni a NODE, TERM értékét, pl. a címsorban ez van: ?q=taxonomy/term/57.
A $tems-ből és a fenti sorból ki tudom halászni, de nem túl elegáns.
Valamilyen függvénnyel nincs erre, amivel le lehet kérdezni ?
Májusban egy Drupal without modifications című szál kapott erőre a Drupal fejlesztői levelezőlistán, mely arról is szólt, hogy szükséges-e módosításokat végrehajtanunk a Drupal alap kódján ahhoz, hogy a kívánt webhelyet megkapjuk. Ez természetesen azzal a komoly igazsággal zárult, hogy "attól függ". A Drupal.hu kialakításakor például szigorú vezérelv volt, hogy alap telepítést használjunk, csak modulokkal kiegészítve a rendszert. Így ahelyett, hogy varázslatokat művelnénk, a maga valóságában tudjuk bemutatni a Drupal rendszert. A módosítások elkerülése sok esetben működik, de nem minden esetben tartható.
A jelenleg Drupal 4.6 alapú Weblabor.hu esetében például nem tudtunk megoldani néhány dolgot anélkül, hogy a Drupal alapmotor forráskódon változtattunk volna. Minden esetben igyekeztünk átgondolni, hogy szükségünk van-e egy-egy változtatásra, és időről-időre visszatérünk ezekre a kérdésekre. Éppen egy ilyen nemrég megvalósult "visszatérés" ihlette ezt a kis tippet.
Ha mégis módosítanunk kell valamit, minden esetben érdemes a változtatásokat a kódban dokumentálni. Mi erre a célra a +WL: megjegyzés előtagot választottuk, mely jól kereshető a kódban. A több soros változtatásoknál hosszabban írjuk le, hogy miért nyúltunk a kódba, de mindig egy sorba tesszük a megjegyzést, mert így később programozottan is egyszerűen kigyűjthető. Egy valós példa a Weblabor kódból:
// +WL: máshol jelenítjük meg az XML ikont
// $output .= theme('xml_icon', url('taxonomy/term/$tid/0/feed'));
?>
A kód módosításának egyik útja, hogy közvetlenül a meglévő forrást szerkesztjük. Ezt főleg kisebb változtatások esetén alkalmazzuk, amikor csak 1-5 sort kell módosítani, vagy hozzáadni. Néhány érdekes változtatás, amit meg kellett tennünk:
contact.module kódjában a szerkesztőség CC-zésének lehetősége. Pár sor változtatást igényelt.Érdekes, hogy ezek és még számos változtatásunk sokszor az űrlapokat érintik, amik a Drupal 4.7-estől kezdve bevezetett sokkal rugalmasabb tömb alapú megoldással már sokkal kevésbé igénylik majd a kód módosítását.
Számos kifejezetten Weblabor specifikus függvényt kiszerveztünk egy wllib.inc nevű fájlba, melyet a sites/default/settings.php fájlból töltünk be, így elkerülve, hogy emiatt módosítani kelljen a Drupal kódját. Így a módosításainkat kis méretűen tudjuk tartani, legalábbis, amikor további kódot kell hívni.
A fenti rövid kódpélda esetében is érdemes elgondolkodni, hogy egyáltalán bárhol is szükségünk van-e az xml_icon megjelenítésére. Ha nincs, akkor természetesen a theme_xml_icon()-nak megfelelő saját smink függvényünket kell elkészíteni, üres visszatérési értékkel. Ez a Weblabor környezetében az azigazi_xml_icon() nevű függvény lenne. Esetünkben viszont úgy gondoltuk, hogy nem akarjuk teljesen eltávolítani ezt a rendszerből (bár valószínű ez a döntés is megérett a felülvizsgálatra).
Vannak azonban olyan helyzetek, amiket nem lehet egyszerű kód módosítással kezelni, és a smink függvényekhez hasonló felülíró mechanizmust sem kapunk, hanem jobban járunk, ha egy függvényt máshol definiálunk. Így alakult, hogy a drupal_get_path_map(), drupal_get_path_alias(), drupal_get_normal_path(), és a drupal_rebuild_path_map() függvényeket a kódban egyszerűen megjegyzésbe tettük, a +WL: magyarázattal ellátva, és a wllib.inc-ben valósítjuk meg a működésüket. Sajnos eléggé összetett álnév számítási rendszert fejlesztettünk ki, ragaszkodva a lehetőleg magyar webcímek használatához. Ez nagyon komoly teljesítmény problémákat okozott a 4.6-os álnév rendszerbe épüléssel, ezért a tesztjeink arra mutattak, hogy jobban tesszük, ha saját céljainkra optimalizált megvalósítást teszünk a kódba. Ráadásul emiatt több kisebb változtatást is el kellett végeznünk más modulokban is.
Az embernek könnyen "eljár a keze", akár meggondolatlanul is képes változtatásokat vinni a rendszerbe, ha szükségét látja. Sajnos ez gondot okozhat a későbbi frissítéskor, amin a speciális megjegyzések sem segítenek, ha egyszerűen csak felülmásoljuk a kódot. A következő részben azt szeretném leírni, hogy a fenti változtatások megtartása mellett hogyan tudjuk mégis folyamatosan frissíteni a Weblabor mögött működő Drupal rendszert.
Sziasztok,
Egy siteon minden emailes dolog rendesen megy, kivéve az invite modul email küldését (4.7). Valószínűleg utf8 kódolással megy ki a levél, de valamilyen header nincs jól beállítva, ezért a subject és a body (magyar szöveg esetén) olvashatatlan.
Volt ezzel kapcsolatban problémája már valakinek? Van esetleg valamilyen megoldás?
Próbáltam a mail() fügvényben átírni a fejlécet (a modulban: Content-type: text/plain; charset=utf8) de nem lett sokkal jobb :)
Hálás lennék minden tippért.
Sziasztok!
Az szeretnem megtudni, hogy Drupallal lehet-e webshopot kesziteni? Vagyis, letezik-e ilyen modul? Az oldal webshopkent funkcionalna, kiegeszitve egy ket ugyes modullal!
Érdekes módon éppen a változtatásokról szóló tipp-kettős előző részének megjelenése napján vált elérhetővé a Lullabot Podcast tizenhatodik része, melyben Jeff Robins készít interjút Dries Buytaert-tel, a Drupal alapítójával. Ebben hangzik el a következő párbeszéd:
Jeff Robins: Don't hack Drupal, if you are hacking the code, you are doing something wrong.
Dries Buytaert: Either you are doing something wrong, or core needs to be extended.
Jeff Robins: [...] but then some security update comes out, or a new version of Drupal comes out, you can't upgrade, because your hacks will break everything.
Most arra a kérdésre próbálom megadni a választ, hogy mit tehetünk, ha mindenképpen saját módosításokat kell alkalmaznunk, de ezeket a frissítésekkel is meg szeretnénk tartani. A megoldás természetesen nem olyan egyszerű, mint egy klasszikus Drupal frissítés, de aki módosít a kódon, annak ezt vállalnia kell.
Ha a legújabb hibajavításokkal szeretnénk élni, akkor könnyen lehet, hogy elvesztjük a biztos tudatunkat arról, hogy mégis melyik Drupal verziót használjuk. A Weblabor esetében például jelenleg úgy foghatjuk meg a használt verziót, hogy a Drupal 4.6-os ágon valamilyen dátummal bezárólag aktuálisak a fájljaink. A szükség esetén megjelenő 4.6.x-es kiadások követése mellett a folyamatos hibajavításokat is érdemesnek tartjuk alkalmazni, így valószínű, hogy amit használunk, annak nincs is hivatalos verziószáma. Még ha lenne is, akkor sem lehet megállapítani a fájlok alapján, hogy pontosan melyik verzióval állunk szemben (hacsak nem vezetjük következetesen egy jegyzetben, hogy melyik verzióra frissítettünk legutóbb).
Így kell egy eszköz, ami megmondja, hogy milyen dátumból kell kiindulni. Végig kell nézni minden fájlt, amiben a fejlesztői (CVS) verziónak megfelelő információ található, beleértve a Drupal rendszerbeli legutóbbi módosítás dátumát is. Ezt magunk is megtehetjük, de az alábbi saját fejlesztésű szkript automatizálja a feladatot:
// Grab all files with possible CVS Id data
$files = find_drupal_files();
$cvsids = array();
$latest = '';
// Go over the files and collect CVS Id data
foreach ($files as $filename) {
$content = join('', file($filename));
if (preg_match('!\\$Id: ([^\\$]+) Exp \\$!', $content, $found)) {
$cvsids[$filename] = $found[1];
if (preg_match('!\\d{4}/\\d{2}/\\d{2} \\d{2}:\\d{2}:\\d{2}!', $found[1], $date)) {
if (strtotime($date[0]) > strtotime($latest)) {
$latest = $date[0];
}
}
}
else {
$cvsids[$filename] = 'n/a';
}
}
print "LATEST;$latest\n";
foreach($cvsids as $name => $id) {
print substr($name, 2) . ";$id\n";
}
// Recursively go over possible Drupal files
function find_drupal_files($root = '.') {
$folders = glob($root . '/*', GLOB_ONLYDIR);
$files = glob($root . '/*.{php,inc,txt,module,theme,engine,mysql,pgsql,install}', GLOB_BRACE);
if (file_exists($root . '/.htaccess')) {
$files[] = $root . '/.htaccess';
}
foreach($folders as $folder) {
if (!in_array($folder, array('.', '..'))) {
$files = array_merge($files, find_drupal_files($folder));
}
}
return $files;
}
?>
Ezt a Drupal gyökerébe téve, és onnan lefuttatva megkapjuk CSV formában a fájlok verzió azonosítóit, és legutóbbi fejlesztői módosítási dátumait. A szkript megkísérli a legutóbbi dátumot kiválasztani. Ebben azonban nem szabad vakon bízni. Ha kiegészítő modulokat is telepítettünk, érdemes azoktól eltekinteni a legutóbbi dátum megállapításakor. Hiszen valószínű az alaprendszert és a kiegészítőket külön frissítjük, illetve lehet, hogy egy kiegészítő jóval későbbi dátummal rendelkezik, mint amikor az alaprendszert legutóbb frissítettük. Ez indokolja a CSV formátumot, amit így tudunk importálni kedvenc táblázatkezelőnkbe, és szűrhetjük az elemeket, sorrendezhetünk, és könnyedén kiválaszthatjuk a legutóbbi frissítés dátumát.
Így kiderítettük, hogy mikori a Drupal rendszerünk.
Követnünk kell a változtatásainkat. Erre a legkézenfekvőbb eszköz egy saját célra telepített Subversion, CVS vagy más változáskezelő rendszer. Ha eléggé szerencsések vagyunk, hogy egy ilyet az eszköztárunkban tudhatunk, akkor már félig megoldottuk a problémát. Ezzel persze csak a saját módosításainkat követhetjük, illetve a frissítések fájlokra tett hatását ellenőrizhetjük.
Feltételezem viszont, hogy olvasóimnak nincs verziókezelő rendszer a tarsolyában, és szerencsére a változáskövetés esetünkben enélkül is megvalósítható. A Drupal.org CVS szervere ugyanis segítségünkre van mindenben. A megállapított dátumnak megfelelő kódot kell először is letöltenünk a szerverről. Attól függően, hogy milyen CVS klienst használunk, ez más-más módon történik. Én parancssori klienst alkalmaztam. Tegyük fel, hogy a megállapított dátumunk 2005. december 13. és a Drupal 4.6-os kódra van szükségünk. Az alábbi parancs segítségével kaphatjuk meg.
$ cvs -z6 -d:pserver:anonymous:[email protected]:/cvs/drupal co -r DRUPAL-4-6 -D "2005-12-13" drupal
Ezzel kaptunk egy tiszta módosítatlan Drupal forráskódot. Most nincs más dolgunk, mint megállapítani a saját Drupal kódunk, és a tiszta Drupal kód eltéréseit, hogy a változtatásainkat egyértelműen azonosíthassuk. Erre a célra én a Meld nevű programot használtam, de nagyon hasonlóan használható a WinMerge is Windows rendszert alkalmazóknak.
Most hogy tételesen látjuk a változtatásainkat, érdemes egy pillanatra végiggondolni mindegyiknek a létjogosultságát, és amennyiben megtartásuk mellett döntünk, dokumentáljuk mindegyiket az előző részben bemutatott konvenciók szerint. Ez még nagyon meghálálja magát a későbbi kódfrissítéseknél.
A változtatásaink azonosítása számos előnnyel jár, de leginkább azért van rá szükség, hogy megkezdhessük a kódfrissítést. Készítsünk egy másolatot az előbbi tiszta Drupal verzióról az összes extra CVS könyvtárral együtt. Ennek a másolatnak a fájljait írjuk felül a saját módosított fájljainkkal. Ezek után futtassuk le a CVS frissítő parancsát továbbra is a 4.6-os ágon maradva, de kérve a legaktuálisabb fájlokat:
$ cvs update -r DRUPAL-4-6
A megjelenő üzenetek között a C jelű fájlokra kell különösen figyelmet fordítanunk, mert ezekben a saját módosításainkat és a Drupal forráskód módosításait a CVS nem tudta összefésülni, és mindkét verziót berakta a fájlba speciális jelzésekkel. Nyissuk meg ezeket a fájlokat bármilyen szerkesztő programban és eseti jelleggel magunk döntsük el, hogy mi lesz a helyes új kód. Ha minden ilyen konfliktust megoldottuk, futtassunk le még egy ilyen update parancsot, és figyeljük meg, hogy csak M jelű fájlunk maradt-e. Ezek az általunk módosított fájlok, amik a frissítéssel összefésülve megtartották a változtatásainkat.
Mivel a kódfrissítés és összefésülés elkészült, egyszerűen felülírhatnánk a webhelyünk forráskódját az új kóddal. Én azonban azt javaslom, hogy ne siessük el, hanem vegyük elő a fent használt különbség vizsgáló programunkat, és ezúttal a frissült kód és a webhelyünk forráskódja között tekintsük át a változtatásokat. Így látni fogjuk, hogy milyen módosítások kerültek a Drupal rendszerbe. Ezek egyrészt adott esetben sminkünk vagy kiegészítő modulunk működésének javítását is szükségessé tehetik. Másrészt pedig ha valami elromlik a friss kód gyakorlatba ültetése után, akkor több tippünk lesz, hogy mégis mi mehetett tönkre, mi változott egyáltalán.
Végül pedig, mielőtt az új kódot hadrendbe állítanánk, ne felejtsünk el biztonsági mentést készíteni a webhelyünk forráskódjáról és az adatbázisról. Ha valamit elszúrtunk volna, akkor arra még mindig visszatérhetünk.
Szeretnék egy oldalon, egy tablázat cellájában megjeleníteni egy flexinode-dal léterehozott node-ot.
1. léterhozok egy "oldalt" ahol a beviteli forma PHP.
2. van egy táblázat, egy cellája, ahova kellene egy PHP függvényhívás, ami megjeleníti a node-ot ! Melyik ez a függvény. (a node számát tudom).
A node flexinode-val készült és a formázása node-flexinode-1.tpl.php.
Sziasztok!
Szeretnék elkészíteni egy honlapot drupalban. A honlapom bizonyos oldalait mindenki olvashatná, viszont 1-2 oldal csak a regisztrált felhasználók számára lenne hozzáférhető. Pontosabban mindenki látná, de letölteni csak a tagok tudnának.
Ezt, hogyan tudom megoldani?
Nikol
Steven Wittens blogjában néhány órája vázolta a döntés hátterét, mely szerint az egyedi JavaScript megoldásokról valamely kész kódkönyvtár beépítésére tér át a tervek szerint a Drupal a következő kiadásban. Az érdeklődők csoportja által megvitatott kérdések eredményeképpen a jQuery kódra esett a választás. A jQuery fejlesztője John Resig személyesen is a csapat segítségére sietett, hogy a különböző felmerült aggályokra választ adjon. Steven szerint a 4.8-as kiadásra elkészül az JavaScript motor beépítése, bár ez természetesen a tesztelőkön is múlik majd.
Alapvető és állandó probléma nagyobb forgalmú oldalakon, hogy a sok hozzászólás között igen nehéz a különböző szálakba érkezett új hozzászólások követése. A Drupal alapértelmezés szerint az általunk még nem olvasott hozzászólásokat (és tartalmakat) ?új? jelzéssel látja el. Ezt javítottam föl azzal, hogy arra kattintva a következő új hozzászólásra ugorjon.
A megoldás két egyszerű lépésből áll PHPTemplate sminkmotor használata esetén. Az első a template.php kiegészítése. Ez a fájl az adott smink gyökerében helyezhető el, például /sites/all/themes/azensminkem/template.php. Feladata a gyárilag használható .tpl.php fájloknál kevésbé általános finomhangolások végrehajtása, esetünkben a comment.tpl.php-nak küldött változók felülírása. Ez a _phptemplate_variables($hook, $vars) függvénnyel történhet a következő módon:
function _phptemplate_variables($hook, $vars) { switch ($hook) { case 'comment': static $numnew; $numnew=$numnew?$numnew:0; if ($vars['new']) { $vars['numnew'] = ++$numnew; } break; } return $vars; }
Mivel ez a függvény meghívódik minden sablon kiértékelésekor, a hozzászólások megjelenítése előtt meg tudjuk vizsgálni, hogy éppen egy új hozzászólást dolgozunk-e fel. Ha új hozzászólásról van szó, akkor a függvényhívások között megjegyzett értékű (static) $numnew változóban számoljuk, hogy hányadik új hozzászólást találtuk. Az aktuális hozzászólásra vonatkozó $numnew változót megkapja a sablonunk.
A második lépés a hozzászólásoknál a megjelenés testreszabása, a link elhelyezése. Ez a comment.tpl.php, hozzászólások megjelenését szabályozó fájllal oldható meg. Ha nem létezik, létre kell hozni. Drupal 5 használata esetén az alapértelmezése a következő.
<div class="comment<?php print ($comment->new) ? ' comment-new' : ''; print ($comment->status == COMMENT_NOT_PUBLISHED) ? ' comment-unpublished' : ''; ?> clear-block"> <?php print $picture ?> <!-- módosítandó rész eleje --> <?php if ($comment->new) : ?> <a id="new"></a> <span class="new"><?php print $new ?></span> <?php endif; ?> <!-- vége --> <h3><?php print $title ?></h3> <div class="submitted"> <?php print $submitted ?> </div> <div class="content"> <?php print $content ?> </div> <?php print $links ?> </div>
A megjegyzésekkel jelölt részt kell módosítani a következőre.
if ($comment->new) { if ($numnew == 1) { print '<a id="new"></a>'; } print '<span class="new"><a name="new' . $numnew . '" '. 'title="következő olvasatlan hozzászólás" href="#new' . ($numnew+1) . '">' . $new . '</a></span>'; }
Ezzel ha új hozzászólást látunk, és az első új hozzászólásról van szó, akkor a new horgornyt rakjuk le. Különben egy new5 típusú horgonyt, ahol 5 az új hozzászólások közötti sorszám. A következő új hozzászólásra linkeljük a feliratot.
