Keresés

Pager gondok

Beküldte Sweetchuck - 2005. augusztus 10. 11.32
Sweetchuck képe

Sziasztok (Szia Hojtsy Gábor :) )

Tartalmat oldalakra bontva jelenítek meg. Ez müködik is rendesen a rendezéssel együtt.

$header = array(
array('data'=> ''),
array('data'=> t('Caption1'), 'field'=>'myfield1')
array('data'=> t('Caption2'), 'field'=>'myfield2'),
....
);
$pager_select_sql='SELECT * FROM...';
$pager_select_sql .= tablesort_sql($header);

Ha a cimkékre kattintok akkor rendezi ahogy kell, de a problémám a következő:
Erre a listázó oldalra el lehet jutni sima linkről illetve ürlapról. Mind a két módszer átad egy azonosítót, hogy mit kell listázni. Ha linkről megyek akkor semmi gond, de ha ürlapról akkor nem jók a linkek amik az előző/következő oldalakra mutatnak illetve a fejlécen a rendező linkek sem jók.
Probáltam már azt csinálni hogy:
If(IsSet($edit['listazando'])){
$_GET['listazando']=$edit['listazando'];
}
de nem jó így sem.

Hogy lehet ezt megoldani?

Továbbá szeretném még azt is, hogy ne csak 1 mezőt lehessen megadni rendezési feltételnek.
Az nem baj ha nincsen hozzá az oldalon kezelőfelület, csak ha felhasználó rányomott az "Egyik" oszlopra akkor az "Egyik" és a "Másik" legyen a rendezés iránya.
(ORDER BY egyik ASC, masik ASC)

Most csak ennyi :)

Már letölttötem egy csomó modult, de a forráskódakat nézegetve sem találtam megoldást. :-/

Fórum: 
Modulok fejlesztése

drupal az uw-ra, vagy akárhová...

Beküldte Anonymous (nem ellenőrzött) - 2005. augusztus 10. 22.09
Anonymous képe

Sziasztok!

Kb. sikeresen feltettem az ultrawebre a drupalt, éppen csak későn vettem észre, hogy az ini_set tiltott függvénynek számít náluk... :(
Az atw-vel kapcsolatban egy másik topicban azt írta valaki, hogy kommentezzem ki a bootstrap.inc-ben és a database.inc-ben a lock tables sorokat... lehet, hogy én vagyok a vaksi, de ilyet nem találtam... (a settings.php-ban megjegyzésbe tettem az ini_set-eket...)

Nem ragaszkodom az uw-hez... De az atw-n igaz az, hogy minden elküldéskor egy újabb reklámcsíkot dob be az oldalra... (legalábbis nálam is ezt csinálta)
A freeweben is próbálkoztam. Ott viszont nem hozza létre az adatbázisomat, mert kötőjel van a felhasználónevemben... :(

Tudnátok valami ingyenes tárhelyszolgáltatót ajállani, ahhol legalább hellyel-közzel zökkenőmentesen fel lehet tenni a drupalt?
Ha a freeweb ilyen, akkor legfeljebb nem kötőjelezek, csak már kicsit unom, hogy beállítgatom a cuccot, feltöltöm, belövöm az mysql-t is... s a végén derül ki, hogy valami nem stimmel...

Előre is köszi, üdv:
A.

Fórum: 
Hoszting kérdések

Smarty template engine telepítése és beállítása

Beküldte Sweetchuck - 2005. augusztus 11. 10.01
Sweetchuck képe

Sziasztok

Hogyan kell telepíteni a Smarty template engine-t?
Elolvastam http://drupal.org/node/27566
Letöltöttem: http://smarty.php.net/download.php
bemásoltam:c:\....\htdocs\drupal\themes\engines\smarty\libs\
"templates_c" könyvtár is jó helyen
A smarty-t használó sminkeknek is meg van a templates_c.
A hiba abból áll, hogy az admin oldalon a smink listázóban nem jelennek meg a smarty sminkek.

Mit kell még beállítani?

Hol lehet még sminkekket találni a NET-en a drupal.org -on kivűl?
Olyat keresek aminek sőtét a háttere és világosak a betük.

köszönöm

Fórum: 
Sminkek

Biztonsági hibákat javít a Drupal 4.6.3 és Drupal 4.5.5

Beküldte Hojtsy Gábor - 2005. augusztus 15. 12.07
Hojtsy Gábor képe

A Drupal által jó ideje használt XML-RPC kódkönyvtárban, amelyet sok más nyílt forrású szoftverben, többen között a PEAR::XML-RPC-ben is alkalmaznak, újabb biztonsági hibát fedeztek fel. Ennek hatására jelent meg tegnap a Drupal 4.6.3, illetve a Drupal 4.5.5. Az XML-RPC-t érintő változások érdekessége, hogy nem a meglévő kódot javítják, hanem a fejlesztői verzióban használt Incutio XML-RPC könyvtárra térítik át a rendszert, ezzel kikövezve az utat a 4.7 felé. A Drupal 4.6.3-ban emellett más hibajavítások is találhatóak, ezért érdemes arra frissíteni a rendszert.

Akinek nincs lehetősége teljes rendszerfrissítésre, alkalmazhatja a bejelentésben adott foltokat, vagy törölheti az xmlrpc.php fájlt, ami javítatlanul hagyva komolyan veszélyezteti a webhely épségét.

Kategóriák: 
Hírek
Kiadások

Közeledik a 4.7.0-ás kiadás

Beküldte Hojtsy Gábor - 2005. augusztus 15. 12.24
Hojtsy Gábor képe
Frissítés: a kód fagyasztást Dries szeptember 15-re tolta el néhány fontos változtatás beépítése miatt.

A Drupal 4.7-es kiadás egyre közelebb kerül, Dries bejelentése szerint szeptember elsején tervezi a kód befagyasztását, mely után csak hibajavítások kerülnek majd a forrásba. Már most számos újítás került az alaprendszerbe, többek között AJAX technikával működő űrlapok, összecsukható űrlap szakaszok, folkszonómia támogatás, DocBook exportálás a könyvekhez, stb. Ráadásul a 4.6.3 és 4.5.5-ben előrehozottan bevezetett új XML-RPC kódkönyvtár is része a leendő kiadásnak.

Van azonban számos további olyan szolgáltatás, melyek még tesztelést, kód áttekintést igényelnek, és ebben nagyban számítanak a felhasználók segítségére. Előkészített, és folt formájában elérhető szolgáltatás csak akkor fog kimaradni, ha nem akad tesztelő!

A most látható változások alapján nem kell majd sok módosítást végezni a kiegészítő modulokon, hogy együtt tudjanak működni a 4.7-es sorozattal. Bővebben a jelenlegi fejlesztői verzióra történő frissítésről szóló dokumentumban lehet olvasni.

Kategóriák: 
Hírek
Kiadások

tracker modulhoz jogosultságok hozzáadása

Beküldte norbee_usr@norb... - 2005. augusztus 16. 12.09
norbee_usr@norbeeusr.dyndns.org képe

üdv!

azt szeretném elérni, hogy a tracker modul ne az alapján döntse el, hogy a tartalmakat követhesse-e a felhasználó, hogy magához a tartalomhoz van-e hozzáférési joga, hanem az alapján, hogy külön a követéshez van-e joga.

másképp leírva:
megnéztem, hogy a modul az 'access content' jog alapján dönt, hogy használhatja-e az adott felhasználó, vagy sem.
kicsit átírtam a modult: egy új jogot vezettem be erre a célra. 

tracker.module-ban:
 
 
/**
 * Implementation of hook_perm().
 */
function tracker_perm() {
  return array('access tracker');
}

az elérés szabályozásban be is állítottam ezt a jogot úgy, ahogy szeretném.

majd a modulban átírtam a user_access(...) függvényhívásokat, hogy az általam definiált jogot használja, ne az 'access content'-et.

és nem történt semmi.

a felhasználók, akiknek elvileg erre nincs joguk, még mindig ugyanúgy meg tudják nézni, hogy ki, mikor hányszor, stb olvasott egy tartalmat.

most akkor arra gondolok, hogy nem ilyen egyszerűen működnek ezek a jogosultság alapján történő dolgok? más modulokban így láttam megvalósítva, nem tudom nekem miért nem sikerült.

jó lenne egy kis segítség ezügyben! köszi!

Fórum: 
Modulok használata

Tartalom beküldés hibás PostgreSQL alatt

Beküldte Sweetchuck - 2005. augusztus 16. 12.52
Sweetchuck képe

Sziasztok
Azt vettem észre hogy PostgreSQL adatbázis esetén gondok vannak a fórum téma létrehozásánál. Most kénkért hiba üzenetet nem tudom mutatni, de az IF függvénnyel van a baja.
(nem PHP függbény hanem pgsql ben tárolt eljárás.)
Nem olyan tipusú datatokat amit szeretne.
A problémát orvosoltam egy másik IF() fügvénnyel

CREATE OR REPLACE FUNCTION if(int4, text, text)
  RETURNS text AS
$BODY$
    SELECT CASE WHEN ($1<>0) THEN $2 ELSE $3 END;
$BODY$
LANGUAGE 'sql' VOLATILE;

Így működik és létre lehet hozni "fórum csoportokat" és "fórumokat" de nem lehet új támát nyítni mert
hibaüzenet:
warning: pg_query() [function.pg-query]: Query failed: ERROR: invalid input syntax for integer: ""

INSERT INTO node (title, body, format, uid, type, teaser, status, moderate, promote, sticky, comment, created, changed, nid) VALUES('level küldés', 'törzs', '1', '2', 'forum', 'törzs', '1', '', '1', '', '2', '1124185792', '1124185792', '4')

A moderate és a sticky mezők kapnak ürest stirnget szám helyett.
A furcsa az, hogy már a db tábla deklarációja is különbözik a mysql-től, de nem a kérdéses mezőknél.

pg moderate integer   NOT NULL default '0',
my moderate int(2)    NOT NULL default '0',
pg teaser text        NOT NULL default '',
my teaser longtext    NOT NULL,
pg body text          NOT NULL default '',
my body longtext      NOT NULL,
pg revisions text     NOT NULL default '',
my revisions longtext NOT NULL,
pg sticky integer     NOT NULL default '0',
my sticky int(2)      NOT NULL default '0',

A probléma helyszíne:
WinXP PostgreSQL 8.03
Drupal 4.6.(0-3) Nem most vettem észre, csak most jelzem/ kérdezem hogy mi a megoldás, illetve hogy tapasztalt-e valaki hasonlót?

Fórum: 
Telepítés, migráció, beállítások