-
IT café
Ajánlott szakirodalmak a teljesség igénye nélkül (a lista még bővülhet):
Új hozzászólás Aktív témák
-
Sk8erPeter
nagyúr
Na, akkor én leszek a második halottidéző.
A válasz pedig röviden az, hogy mindez szerencsére admin-felületen is elintézhető: a megfelelő view-nál a "Fields" résznél kattints az ImageField meződ nevére, ekkor megjelennek az ehhez tartozó beállítások - itt görgess le egészen a legaljáig, a "Format" részhez, itt valószínűleg nálad jelenleg a "Generic files" van beállítva. Ezt változtasd meg úgy, hogy a Lightbox-hoz tartozó formátum jelenjen meg - remélem van is ilyen! Colorbox-nál rengeteg formátumot be lehet állítani, (nekem ezzel van tapasztalatom), így a kép kattintásra egyből a Colorbox-vásznon jelenik meg, plusz szépen együttműködik az ImageCache modullal (ami szerintem kötelező darab). A Colorbox-ot egyébként is nagyon tudom ajánlani, szépen testreszabható. De remélem, Lightbox-szal is meg tudod oldani.
Sk8erPeter
-
Sk8erPeter
nagyúr
Pedig most a kedvedért felraktam a Lightbox2 modult, és nálam működik, átalakítja képpé.
Vegyünk egy példát, végre kicsit konkretizálva:
1.) Először Generic files formátumban: KÉP
2.) Aztán átalakítva: Lightbox2: product_list->product_full formátumra (nálam van két ilyen ImageCache-preset, Ubercart-modulból): KÉP
3.) Ezután Update, és az eredmény: KÉPMást ezenkívül nem is állítottam, tehát nem pipálgattam azokat, amiket említettél.
Szerk.: ja, és a Lightbox2-vásznon jelenik meg az eredmény (mondjuk a Views admin-felületén pont nem, hanem csak ahol a végleges eredményt megmutatom).
Tehát a product_list szerinti ImageCache-preset szerint, kicsinyítve jelenik meg a kép, aztán rákattintva a Lightbox-vásznon már a product_full preset szerint, nagyobb méretben jelenik meg.
Most kipróbáltam, az iframe-mel is a kép jelenik meg...[ Szerkesztve ]
Sk8erPeter
-
Sk8erPeter
nagyúr
Igen.
Az egyébként is szinte kötelező modul 6-oshoz (7-esnél pedig már core része! - ez is bizonyítja, hogy nem kicsit hasznos), amennyiben már képkezelgetés is szóba kerül. Admin-felületen összekattintgatva készíthetsz olyan mintákat, amik segítségével automatikusan átméreteződnek a képeid, vagy elforgatja, kivágja őket, amikor legenerálod, stb. Nagyon hasznos modul.Még saját hook is tartozik hozzá, így adott modul saját ImageCache presetet definiálhat (már próbáltam, nagyon gyorsan meg lehet írni ilyet, pár sor, nézhetsz rá példát pl. az Ubercartban, ha komolyabban érdekel).
Pl. meg tudod csinálni vele, hogy egy kicsinyített, adott méretre korlátozott kép jelenjen meg, ami linkel a nagyobb képre, ami rákattintásra Lightbox-vásznon jelenik meg.
Ha azt szeretnéd, hogy a Lightbox2-vásznon az eredeti, teljes méretű kép jelenjen meg, készíts olyan ImageCache-presetet, ami igazából nem csinál semmit, tehát marad a 100%-os képarány. Meg legyen egy, ami a kicsinyített változatot jeleníti meg.
Ugyanilyen az említett "Lightbox2: product_list->product_full", itt a product_list egy preset, ami a kicsinyített változatot jeleníti meg, ez linkel a teljes méretű képre.[ Szerkesztve ]
Sk8erPeter
-
Speeedfire
nagyúr
Hmmm. Nem is volt ilyen opció, úgy néz ki a legutóbb túlfrissítettem a rendszert...
Ez volt fent... 6.x-2.0
Most visszaraktam ezt 6.x-1.6 és megy.
Asszem ha legközelebb frissítem megnézem, hogy melyik modul, hogy áll épp.Fotóim https://fb.com/toth.szabolcs.art || IG: http://instagram.com/_tothszabolcs_ || Weblapom http://szabolcs-toth.com
-
Sk8erPeter
nagyúr
Nem hook, hanem core-ban lévő függvény segítségével:
drupal_set_title()=====================================
(#36) Speeedfire : amúgy mi a döntés oka, hogy cseréled a Drupalt Yii-alapokra?
Sk8erPeter
-
Siriusb
veterán
Sajnos ez csak a title-t manipulálja és nem a head_title-t, de nem rossz ötlet.
Ellenben találtam egy page title modult.
-
Sk8erPeter
nagyúr
Akkor ezek szerint most nem volt világos, mit is szerettél volna, a drupal_set_title() ezt csinálja - a köv. képen látható Drupal egy teszt gyanánt használt 6-os Drupal, létrehoztam egy Story content type-ot, Test Story címmel:
EREDETICsak teszt gyanánt most létrehoztam egy "pete" nevű modult, itt módosítom a címet:
/**
* Implements hook_nodeapi()
*/
function pete_nodeapi(&$node, $op, $a3 = NULL, $a4 = NULL){
switch($op){
case 'view' :
// var_export_drupal_set_message($node, '$node');
drupal_set_title('Lószar');
break;
}
}Ez pedig a következőt eredményezi: MÓDOSÍTOTT CÍM.
Nem ezt szeretted volna ezek szerint?
Sk8erPeter
-
Sk8erPeter
nagyúr
Jah, oké, már felfogtam.
Bár már találtál rá modult, leírom a megoldást úgy is, ha saját modulból szeretnéd módosítani. A korábbi, "pete" nevű modulnál és a rendkívül fantáziadús módosított címnél maradva (most ki tudtam próbálni, és működik):
/**
* Implements hook_preprocess()
*
* @see http://api.drupal.org/api/drupal/developer!hooks!core.php/function/hook_preprocess/6
*/
function pete_preprocess(&$variables, $hook) {
if($hook == 'page'){
// itt már össze van pakolva a $variables['head_title'], szóval akár a korábbi értékét is fel tudod használni, hogy csak hozzáfűzz valamit - én most az egészet módosítom erre a fantáziadús címre
$variables['head_title'] = 'Lószar (de különleges cím)';
}
}Az eredménye pedig: MÓDOSÍTOTT $head_title.
Remélem erre gondoltál.
Sk8erPeter
-
Sk8erPeter
nagyúr
Szívesen!
Igen, én is így gondolom, meg felesleges teljesítmény-romlással is járhat, ha egy apró módosításért egy alapvetően kihasználatlan, a célhoz képest túl nagy tudású modult felraksz.
A másik, amit ilyenkor szoktam csinálni, ha tudom, hogy egy modul képes arra, ami nekem kell, de csomó minden mást is csinál, amire nekem egyáltalán nem lesz szükségem: megnézem a kódját, és tulajdonképpen kiemelem a szükséges részt a kódból, vagy csak ötletet lopok belőle, hogy mivel is lehetne szépen megoldani a kérdéses problémát."Ugyanis a jquery_ui_add('ui.tabs'); utasítással nem csinál semmit, csak ha drupal_add_jssel hozzáadom a szükséges fájlt."
Szerintem az a baj, hogy nem tömböt adsz át a függvénynek, nézd meg a függvényt: jquery_ui_add().
Tehát a helyes szintaktika ez:jquery_ui_add( array('ui.tabs') );
===
Szerk.: amúgy most kértem, hogy pár hasznos linket tegyenek be az első hozzászólásba, remélem bekerül (remélhetőleg valaki hasznát veszi a linkeknek).
Ha nektek is lenne pár javaslatotok, hogy mi kerüljön az első hsz.-be, ne fogjátok vissza magatokat![ Szerkesztve ]
Sk8erPeter
-
Sk8erPeter
nagyúr
Modulok:
Nem rossz, de a hivatalos honlapon meg telepítések száma alapján is lehet rendezni.jQ UI:
Igazad van, jó, hogy pont én linkeltem, nem néztem meg alaposan...Itt van az a rész, ami tömbbé kasztolja, ha pl. valaki úgy hívja meg, ahogy Te is:
// Convert file to an array if it's not one already, to compensate for
// lazy developers. ;)
if (!is_array($files)) {
$files = array($files);
}Szóval Te egy lazy developer vagy.
Amúgy hol hívod meg a függvényt, melyik hookban?
A source-ban egyáltalán nem jelenik meg a UI tabs pluginje?[ Szerkesztve ]
Sk8erPeter
-
Sk8erPeter
nagyúr
Nincs mit!
A template.php-n belül melyik függvényben hívtad meg?
Egyébként még a korábbira visszatérve, vagyis a $head_title változó módosítására: az if($hook == 'page') ellenőrzés szükségessége helyett még egyszerűbb, és még jobban elkülöníthető megoldás, ha a következőt alkalmazod:
/**
* Implements hook_preprocess_page()
*
* @see http://api.drupal.org/api/drupal/developer%21hooks%21core.php/function/hook_preprocess_HOOK/6
*/
function pete_preprocess_page(&$variables) {
// Modifying $head_title variable's value
$variables['head_title'] = 'Lószar (asdasdasdasd)';
}Egyébként úgy van a sorrend, hogy előbb a moduleName_preprocess() fut le, utána a moduleName_preprocess_hook().
A sorrendről bővebben: [Setting up variables for use in a template (preprocess and process functions)].U.i.: minden programozó lusta.
[ Szerkesztve ]
Sk8erPeter
-
Sk8erPeter
nagyúr
"Csak simán beleraktam a template.php-be, semmi cifrázás."
Az említett jquery_ui_add('ui.tabs'); sort úgy, ahogy van, beledobáltad a template.php-be, és még csak függvénybe sem pakoltad?
Hát akkor ezt a megoldást jó gyorsan felejtsd el. Ne is csodálkozz, ha ilyen módon valami nem az elvárt szerint működik. Használd a Drupalt rendeltetésszerűen, ahogy illik.
Szóval ha a template.php-ben szeretnéd ezt a függvényt meghívni, akkor kotord elő ezt a fájlt, és pakold bele ezt (smink nevét nyilván módosítsd a sajátodra):/**
* Override or insert variables into all templates.
*
* @param $variables
* An array of variables to pass to the theme template.
* @param $hook
* The name of the template being rendered (name of the .tpl.php file.)
*/
function YOURTHEMENAME_preprocess(&$variables, $hook) {
static $jQuery_UI_plugins_included = FALSE;
if (empty($jQuery_UI_plugins_included)) {
jquery_ui_add('ui.tabs');
$jQuery_UI_plugins_included = TRUE;
}
switch ($hook) {
case 'page':
// ....
break;
// ....
}
}Ezt most úgy csináltam meg, hogy minden hook esetén include-olja a jQuery UI plugint.
Ha csak egy adott hooknál kell, akkor értelemszerűen a switch-case-en belülre rakd.
Aztán törölj egy cache-t, és remélhetőleg működni fog (nálam megy).Sk8erPeter
-
Sk8erPeter
nagyúr
Megcsináltad azokat a lépéseket, amik a readme-ben vannak?
Hányas verziójú jQuery UI-t töltötted le hozzá? Hova raktad? Libraries modul fent van? Ezt is érdemes felpakolni.
Valamit lehet, hogy az alábbi lépések közül kihagytál.-- JQUERY UI 1.7 --
The jQuery UI module uses jQuery UI 1.6 because jQuery UI 1.7 requires at least
jQuery 1.3, which is not shipped with Drupal 6. If you absolutely need to move
to jQuery UI 1.7, you can get around this by doing the following:* Download and install the corresponding jQuery Update module from:
http://drupal.org/project/jquery_update
* Download the latest jQuery UI 1.7 release from:
http://code.google.com/p/jquery-ui/downloads/list?q=1.7
* Put the downloaded archive into the directory:
/sites/all/libraries/jquery.ui-1.7.zip
* Extract the archive. This will create the following sub-directory:
/sites/all/libraries/jquery.ui-1.7/
* Rename the sub-directory into "jquery.ui":
/sites/all/libraries/jquery.ui/
so the actual jQuery UI JavaScript files are located in:
/sites/all/libraries/jquery.ui/ui/*.js
* Enable the module at Administer >> Site building >> Modules.
#59:
Nálam bekapcsolt Devel modullal is jól működik.
Szerk.: elvileg a jQuery Update modul nélkül is működnie kell, 1.6-os verzióval.[ Szerkesztve ]
Sk8erPeter
-
Sk8erPeter
nagyúr
Akkor mutasd meg plíz, hogyan adod hozzá drupal_add_js() segítségével - tehát mi az, ami működik.
Valószínű, hogy valami elérési úttal kapcsolatos probléma lesz.Így próbálja megtalálni a jQuery UI elérési útját: jquery_ui_get_path().
Sk8erPeter
-
Sk8erPeter
nagyúr
Pedig ez az elérési út jó.
Na, de hogy sikerüljön kideríteni a probléma okát, vigyük vissza egy kicsit, először is csekkoljuk, hogy belelép-e egyáltalán az itt említett függvénybe, tehát ezt írd be a template.php-be (szerkeszd a meglévő függvényt, ha már megvan):/**
* Override or insert variables into all templates.
*
* @param $variables
* An array of variables to pass to the theme template.
* @param $hook
* The name of the template being rendered (name of the .tpl.php file.)
*/
function YOURTHEMENAME_preprocess(&$variables, $hook) {
static $testOutputReady = FALSE;
if(empty($testOutputReady)){
drupal_set_message('jquery_ui_get_path(): <pre>' . var_export(jquery_ui_get_path(), TRUE) . '</pre><hr />');
$testOutputReady = TRUE;
}
// ..........
}A YOURTHEMENAME helyén nyilván legyen a saját theme-ed neve.
Most ezzel egyrészt meg tudod nézni, mit ad vissza a jQuery UI path-ra, valamint ellenőrizni tudod, hogy jól írtad-e meg, belelép-e egyáltalán a függvénybe.
Ha kiírja a path-t, akkor majd szólj vissza, mit adott eredményül.Szerk.: most kipróbáltam egy tök kezdetleges teszt-Drupalon (6-os), és ott is jól működik.
Ott is fent van a jQuery Update, a Libraries és a jQuery UI.[ Szerkesztve ]
Sk8erPeter
-
Sk8erPeter
nagyúr
Hát akkor a subtheme-ed valahogy nagyon rosszul strukturált, elképzelhető, hogy ezért nem megy. A subtheme-ben is kellene, hogy tudd használni rendesen a megfelelő theme hookokat.
Ez is közrejátszhat a sikertelenségben.
Ennek a megoldása igazából csak azért érdekes, mert ha ez nem megy, lehet, hogy más modulok helyes működése is kérdéses.
Az elérési út pedig jó...Sk8erPeter
-
Sk8erPeter
nagyúr
Nem tom, lehet.
"Annyi a kavarás a subtheme-ben, hogy Views-t használok."
Ezt nem értem. Hogy jön a subtheme-hez a Views module, mi köze a kettőnek egymáshoz?
Vagy most arra célzol, hogy azon az oldalon, ahol meg akarod jeleníteni a jQuery UI-t, ott éppen Views-zal kéred le a tartalmat?
A megfogalmazás így elég zavaros...Sk8erPeter
-
Sk8erPeter
nagyúr
Hogy csináltad a Garland subtheme-et? Valahogy így?
Mondjuk én Zen subtheme-et használok, ott minden theme hook faszán működik (amúgy is ajánlott smink a Zen, ha valaki szereti a rugalmasan kezelhető, jól kommentezett theme-eket).
Arra kéne rájönni előbb, mi az oka, hogy nem működnek a subtheme hookjai.[ Szerkesztve ]
Sk8erPeter
-
Sk8erPeter
nagyúr
Szerintem saját sminket írni tök felesleges, túl sok meló, miközben nagyon faszán testreszabható sminkek vannak, amikből könnyű jól működő subtheme-et gyártani (lásd pl. Zen), és legalább valaki már elvégezte helyetted a piszkos melót.
A Zent egyébként azért szeretem, mert már van egy előre elkészített subtheme, aminek a neve "STARTERKIT", amit csak a saját mappájából ki kell ollózni, berakni külön theme-ként, és átírni a STARTERKIT részt a megfelelő fájlokban a saját névre, amit szeretnél adni a subtheme-nek (template.php, theme-settings.php, valamint a STARTERKIT.info.txt fájlt átnevezni a sajatnev.info-ra), és kész vagy.
Még példákat is mutat a template.php-ben a hookokra.
Arról nem is beszélve, hogy az Internet Explorerrel való kompatibilitásra is gondoltak a CSS-fájlokban is, meg választhatsz előre létrehozott CSS-fájlokból, hogy most fixed vagy fluid layoutot szeretnél.
Aztán ezt megfelelően testreszabod.
Na én ezt nem akarnám megcsinálni mind saját melóval, ha már valaki ezt megosztotta.[ Szerkesztve ]
Sk8erPeter
-
Sk8erPeter
nagyúr
Nincs mit!
Amúgy miután kibontottad a Zen-t, a STARTERKIT könyvtáron belül van egy README.TXT, az tök egyértelműen elmond mindent. De igazából annyi a lényeg, amit előbb leírtam, ha jól csinálod, kb. 5 perc (jó, elsőre 10), és van egy tök jól működő subtheme-ed.Sk8erPeter
-
Sk8erPeter
nagyúr
Jaja, én még nem találtam jobbat a Zennél.
Nagyon logikusan strukturált, jó, hogy vannak példák a template.php-ben az alkalmazható hookokra (még kezdőként nagyon nagy hasznát vettem, sokat segített), rendkívül jól dokumentált (minden fájl elején totál egyértelmű magyarázatokkal van tele, hogy mi mire való, melyik változó használható fel, és annak mi is lesz pontosan a tartalma, stb.), Internet Explorer hülyeségeire is gondoltak, könnyen megvalósítható vele a fixed és a fluid layout is, és persze teljesen valid kódot generál.Szótöredékes keresésre? Hmm, jó kérdés.
Itt nem találsz valami ezzel kapcsolatosat (Apache Solr Search Integration)? Az Apache Solr Search Integration a core search modul lecserélésére, a kereséses extra feature-ökkel való kiegészítésére hivatott.[ Szerkesztve ]
Sk8erPeter
-
Sk8erPeter
nagyúr
Hát én csak részmegoldásokat találtam, pl. kötőjeleket szóelválasztásnak tekint, mint egyfajta szótöredék: [link]
Van egy ilyen, de ezt őszintén szólva nem értem, miért megoldás, és gáz, hogy belegányol a core modulba: [link]
Itt pedig pont a Fuzzy-ra meg a Trip Search-re hivatkoznak: [link]De basszus, most nézem a Fuzzy Search oldalát, ott épp ezt írják:
"This module provides drupal sites with a fuzzy search engine to allow for broader keyword matches including partial or misspelled keywords."
Akkor mi a kérdés?Sk8erPeter
-
Sk8erPeter
nagyúr
... és ím' Sk8erPeter ama kürt hívószanának hallatán jövé' vala, ama nemes szándéktól vezérelvén, hogy bajtársát mielőbb igyekezzék kisegíteni ama nehéz időkből.
Szóval valóban NAGYON rút az a megoldás.
Most olyan megoldásokat mondok, amik elsőre eszembe jutnak (lehet még több is):
1.) /contact elérési út helyett másik használata (pl. /contact-us), saját statikus tartalom belerakása egy adott node-ba - de gondolom Te szeretnéd inkább mégis ezt az elérési utat használni. Bár mégis ez lenne a lehető legegyszerűbb.
2.) Contact modul kikapcsolása, saját node létrehozása a statikus tartalommal, ennek beállítása a /contact elérési útra - nem olyan jó megoldás, mert ütközés van, ha később mégis be akarod kapcsolni a Contact modult.
3.) page-contact.tpl.php módosítása; a következő sor kikommentezése (Zen esetén):
<?php print $content; ?>
és ennek lecserélése a saját, statikus tartalomra, tehát így:
<div id="content-area">
<?php print $content; ?>
</div>HELYETT
<div id="content-area">
<?php
// print $content;
?>
asdlkjasdlkasjdlkasjdklasjd
</div>- szintén NEM túl szép megoldás.
4.) Modulban - mindenképp hozz létre egyet, úgyis hasznát fogod még venni!
Mutatok egy példát (úgy tudom, 6-ost használsz!):
A modult kiegészítem egy általam írt függvénnyel, aminek szerintem debuggolásnál még hasznát veheted: var_export_drupal_set_message() - ez tulajdonképpen a keveréke a var_export() és drupal_set_message() függvényeknek. Így könnyen kiírathatod a változók értékeit, ott mutatja, ahol a státuszüzeneteket. Mutatok is a használatára példát: kiíratom a $form_id változó értékét. Egy-két helyen kommentként benne hagytam egyéb példákat, amiket felhasználhatsz debuggolás céljára.
Elérési út (ide pakold a modult!!):
sites/all/modules/modSiriusbEzenbelül a két fő fájl, ami szükséges:
==================================================
modSiriusb.info
; $Id$
name = "Siriusb - Test module"
description = "Test Module by Siriusb"
package = "Siriusb"
core = "6.x"
php = 5.2==================================================
modSiriusb.module
<?php
// $Id$
/**
* @file
* Siriusb's test module.
*/
define('SIRIUSB_MODULE_MACHINE_NAME', 'modSiriusb');
/**
* Sets a Drupal message which outputs a parsable string representation of a variable
*
* @param mixed $var The variable of which we would like to output a parsable string representation
* @param string $text The message to output
* @param string $type The type of the message
* - 'status'
* - 'warning'
* - 'error'
*
* @see http://php.net/manual/en/function.var-export.php
* @see http://api.drupal.org/api/drupal/includes%21bootstrap.inc/function/drupal_set_message/6
*/
function var_export_drupal_set_message($var, $text, $type = 'status') {
// $type: e.g. 'status'
drupal_set_message($text . ': <pre>' . var_export($var, TRUE) . '</pre><hr />', $type);
}
/**
* Implementation of hook_form_alter()
*/
function modSiriusb_form_alter(&$form, &$form_state, $form_id) {
// var_export_drupal_set_message(__FUNCTION__, 'function');
// teszt célból kiírjuk a $form_id-t --> csak debug-célra, használat után ELTÜNTETNI!
var_export_drupal_set_message($form_id, '$form_id');
}
/**
* Implementation of hook_form_FORM_ID_alter()
*/
function modSiriusb_form_contact_mail_page_alter(&$form, &$form_state){
// var_export_drupal_set_message(__FUNCTION__, 'function');
// var_export_drupal_set_message($form, '$form...');
// var_export_drupal_set_message($form_state, '$form_state...');
$form['#after_build'][] = 'modSiriusb_form_contact_mail_page_alter_after_build';
}
function modSiriusb_form_contact_mail_page_alter_after_build(&$form, &$form_state) {
// eltüntetjük az eredeti formot
unset($form);
// új tartalmat teszünk bele a $form változóba
$form['contact_info'] = array(
'#value' => '<div>Ide jön a saját tartalmad!</div>',
);
return $form;
}Az érdekesség az, hogy csak az #after_build függvényben eltüntetve működik úgy, ahogy akarjuk most (eltüntetni, majd felülbírálni a contact formot).
A modSiriusb_form_contact_mail_page_alter() függvényben viszont plusz esetleges saját mezőket is lehet hozzáadni (meg persze a modSiriusb_form_contact_mail_page_alter_after_build() függvényben is).
Fontos tudni, hogy az #after_build függvényekben vissza kell térni a $form változóval.=====================================================
Ettől függetlenül talán még mindig az tűnik a legkevésbé erőforrásigényesnek, ha saját node-ot létrehozol, és ezt beállítod pl. a /contact-us címre. A Contact modult meg addig kikapcsolhatod, amíg nincs szükséged rá.
Remélem segítettem!
Sk8erPeter
-
Sk8erPeter
nagyúr
"settings.php-ben hozzáadtam, hogy ini_set('max_execution_time', 0); , hatástalan"
Ez a beállítás nem tudom, miért lenne jó.
Egyébként érdemes inkább a set_time_limit() függvényt használni: [link].A 30 másodperc néhány esetben tényleg kevésnek is bizonyulhat, ezt érdemes magasabbra állítani, van, amikor cron-feladatok, update, cache-elési mechanizmusok, vagy épp több modul egyszerre történő telepítése (ehhez többek közt a táblák adatbázisba való feltöltése), stb. fut, ami hosszabban tarthat, nem érdemes kockáztatni, hogy esetleg egy script megszakad - és pl. ezáltal egy modulhoz feltöltendő tábláknak csak mondjuk a fele kerül az adatbázisba - a túl kevés futási idő miatt.
Hogy a lényegi részre is térjek:
először is nem ártana, mi volt az az "1-2 apró módosítás".
Másrészt: próbáld meg azt, hogy az index.php fájl ELEJÉRE berakod ezt (nyilván a <?php után):function set_error_reporting() {
error_reporting(E_ALL|E_STRICT);
ini_set('display_errors', TRUE);
ini_set('display_startup_errors', TRUE);
}
set_error_reporting();
// .......Ha ettől behal (mondjuk így is behal), akkor kommentezd ki a fv.-en belüli harmadik sort, vagyis ezt: ini_set('display_startup_errors', TRUE);
Számomra az meglepő volt, hogy hasonló problémánál a /admin/reports/dblog címen elérhető adatbázisnapló elérhető volt, innen tudtam törölni az Admin menü segítségével a cache-t, és így megoldódott a dolog.
Persze olyan is előfordul, hogy belekerül valami modulba egy gányolás, és így totálisan meghal az egész oldal.
Nálam egyszer attól is para volt, hogy Devel modullal rámentem, hogy telepítsen újra egy-két modult (tehát disable, uninstall, majd megint install, asszem az enable már manuális), de a folyamat felénél valamiért megszakadt, és ez nem tett túl jót az oldalnak. De aztán az Admin menüben lévő cache-törlő menü ezt is megoldotta.Sk8erPeter
-
Sk8erPeter
nagyúr
Ismerős a jelenség, úgy nevezik: White Screen of Death (WSOD)
A linkelt oldalon sok megoldási lehetőséget is kínálnak.Az admin-oldalakat nem éred el? Ahogy írtam is korábban, ez elő szokott fordulni esetenként, hogy pl. az adatbázislogot megnézed, azon a címen, amit írtam fentebb (az is a 6-osra vonatkozott, feltételezem, mi egymás közt a 6-osról beszélünk, mert eddig ha jól tudom, arra fejlesztettél).
Azt is csinálhatnád első körben tesztelésként, hogy a cache-táblákat törlöd: [link].
Lehet admin-felületről, meg adatbázisból, manuálisan (most ehhez férsz csak hozzá ezek szerint).Mondjuk lehetne kóddal is ugyanezt, úgy, hogy ezt az index.php fájlod elejére teszed ÁTMENETILEG (aztán kitörlöd az első futtatás után): drupal_flush_all_caches().
De így:
require_once("./includes/bootstrap.inc");
$cookie_domain = $_SERVER['HTTP_HOST'];
drupal_bootstrap( DRUPAL_BOOTSTRAP_FULL );
drupal_flush_all_caches();
die();Ennek is lehetne adni egy próbát.
Szóval én első körben mindenképp a cache-táblákat buzerálnám ilyen esetben, az már annyiszor segített.
Aztán ha ez sem jött be, végiggondolnám még egyszer, mit cseszhettem el.
Persze adatbázis is megtörhetett valahol, de akkor érdekes, hogy így jelentkezik, nem mondjuk egy query sikertelenségében.
Meg nehéz elképzelni, hogy egy adatbázissérülés csak az egyik projektet érintette volna....Mondjuk persze nem nehéz akkor, ha mondjuk csak az adott adatbázis fájlja sérült (pl. MySQL-nél).[ Szerkesztve ]
Sk8erPeter
-
Sk8erPeter
nagyúr
Nincs mit!
Akkor ezek szerint a hibakeresés véget ért.
Nagyon sok oka lehetett, de az a baj, hogy fel kellett fedeznem, hogy Drupalban a hibakezelés a 6-osban legalábbis igencsak erősen hagy kívánnivalót maga után (a 7-essel egyelőre nem szoptam annyit, csak egy viszonylag egyszerű többnyelvű céges honlapot készítettem el), pl. ilyen esetben is elnyomja a hibákat, pedig mondjuk normálisan kivételkezeléssel pl. szerintem lehetne egyértelműsíteni, mi is a gond ilyen fatális jellegű hibáknál is, mint a WSOD. A hibák köre elég tág, épp ezért kellene rájuk felkészülni, amint felmerül a lehetőség, betenni a megfelelő hibaellenőrzést. Így a hibák csekkolása jó hosszú lehet, de legalább ilyenkor nem nézel, mint borjú az új kapura, hogy most akkor mi a sz@rt rontottál el (ismerem az érzést).Sk8erPeter
-
Sk8erPeter
nagyúr
Ja, megértem, hogy nem akartál időt elcseszni arra, hogy debuggolj.
Mondjuk későbbi tanulságként én akkor is végig szoktam szívni ezt az időszakot, miután már a fél világot elküldtem a halál farkára, és a fél hajállományomat kitéptem.Ja, a 7-esben elég sok minden nagyon kézenfekvően meg van csinálva, szerintem kellemes az átállás a 6-osról, tetszik a full AJAX-os új admin-felület is, szerintem egész jól eltalálták. Könnyen kezelhető, átlátható, modern felület, pont jó.
Igen, én is azért részesítettem előnyben úgy fél éve egy projektnél a 6-os Drupalt, mert rengeteg modul még nem volt kész 7-eshez, vagy írták a modul oldalán, hogy nem is tervezik a 7-esre fejlesztést.
Mondjuk ezen tanultam meg Drupalt fejleszteni, elég volt hozzá egy viszonylag összetett feladat, tele szívással.
Ha most kezdenék el egy projektet, egyértelműen a 7-est választanám (ahogy azt az egyszerű céges honlapot is ebben készítettem, és nem bántam meg). Az biztos, hogy a 7-es bőven tartogat számomra újdonságokat, mert nagyon sok mindent változtattak a 6-oshoz képest, sok minden ésszerűbb lett a modulfejlesztés terén.
Az ImageCache és a CCK is a core-ba került, ami mondjuk szintén igen jó.A Drupal 8 újításairól még őszintén szólva én sem olvastam semmit, hogy mi is az oka, hogy major verzióváltásra volt szükség, milyen komolyabb dolgot változtatnak a core felépítésén, ami nem fért volna bele egy minor verzióváltásba, tehát egy laza update-be.
Sk8erPeter
-
Sk8erPeter
nagyúr
Jaja, nekem kifejezetten tetszik. Azt persze meg kell szoknod az átálláskor, hogy elég rendesen átstrukturálták, nagyon sok minden változott, az elérési utak is mások lettek, az admin-felületen elérhető menüpontok nevei is helyenként újak lettek, más sorrendben vannak, stb.
Eleinte akadós, de azért gyorsan rá lehet állni. Amúgy az új, default AJAX-os felületnél van egy shortcut menü, amire a saját linkjeidet rápakolhatod, olyan menüpontokat az admin-felületen, amit gyakran használsz, így gyorsabban eléred. Csak van egy korlát, hogy mennyi fér rá.Sk8erPeter
-
Siriusb
veterán
Nos, úgy tűnik, az internationalization modul teszi hidegre a pathauto-t. Telepítéskor ezt az üzenetet kapom:
Notice: Array to string conversion in i18n_string_group_string_list() (line 273 of /.../sites/all/modules/i18n/i18n_string/i18n_string.admin.inc).
Valami ötlet, hogy ne csak magamban beszélgessek?
-
Sk8erPeter
nagyúr
Jé, van élet a topicban. (bennem most nincs, túl sok volt a pia )
Hmm, ez fura. Melyik változatot használod ezekből?
A multilanguage dolog azóta végül akkor összejött?
(#123): inkább írtál volna konkrét URL-t, most elő kellett kotornom.
Most nem vágom, erre gondoltál?
/admin/config/search/path/patternsA másik, ha már erről a beállítási oldalról beszélünk.
Kérdezted priviben, hogy lehet Pathauto-nál fieldekből generáltatni az URL aliast.
Létrehoztam egy "My Test Content Type" nevű content type-ot, azonbelül egy field_stuff azonosítójú mezőt, és a "Pattern for all My Test Content Type paths" részhez ezt írtam:
my-test-ct/[node:field_stuff]
Ez nálam jól működik, persze miután mondjuk adott node-nál az Edit lapon az "URL path settings"-en belül a "Generate automatic URL alias" checkboxot bepipáltam.Sk8erPeter
-
Sk8erPeter
nagyúr
Ja, beleprogramozták a részrehajlást.
A tesztelési célra felrakott Drupalomon próbálkoztam, sok modul van fent:
http://i.imgur.com/67G3e.jpg
Bocs, az Imgur kissé lebutította a minőségét, azért ilyen fos minőségű, de talán olvasható még.
Szerintem mondjuk ebből csak a Token és a Pathauto a lényeges...Ja, amúgy amivel én próbálkoztam, az egy sima textfield. Te milyen mezővel próbáltad?
[ Szerkesztve ]
Sk8erPeter
-
Sk8erPeter
nagyúr
Már ma is itt vagyok, muhahaha!!!
Ez amúgy nem is olyan sok modul.Hogy a fieldgroup bezavar, az nem egy hülyeség, de ez nyilván csak akkor derül ki, ha
1.) kiveszed belőle, és úgy teszteled
2.) létrehozol egy új mezőt tesztelési célból, és azt adod meg patternnek.Sk8erPeter
-
Sk8erPeter
nagyúr
[node:original:source:nid]
Ilyen szinten nem ismerem ezeket a tokeneket, de miért lenne ez jó neked ehhez: "some/thing/1 (az eredeti változat NID=1) illetve vala/mi/1 (a magyarra fordított node, NID=2)"?
Most létrehoztam egy "Test multilingual type" nevű típust, és nálam most a magyar, német és angol nyelvek vannak engedélyezve, és az /admin/config/search/path/patterns elérési úton a következők vannak erre a típusra vonatkozóan:
Pattern for all language neutral Test multilingual type paths
Pattern for all English Test multilingual type paths
Pattern for all German Test multilingual type paths
Pattern for all Hungarian Test multilingual type pathsTehát mindegyikre külön-külön megadhatok egy mintát.
Ergo az esetedben a "Pattern for all English Test multilingual type paths" lehetne some/thing/[node:nid], a "Pattern for all Hungarian Test multilingual type paths" pedig vala/mi/[node:nid].Ez így nem jó neked?
Sk8erPeter