phpRS 2.6.5 : phpRS Fórum
Toto fórum je určené výhradně k diskuzi o verzi phpRS v2.6.5.
phpRS - redakční a informační systém
odporny kod
Zaslán uživatelem/kou: meba (IP adresa zaznamenána)
Datum: 2005-01-15, 22:34

Zdravim,
zacal sem kvuli jednomu webu pouzivat system phpRS a bohuzel jsem se podival dovnitr, do kodu systemu. Je opravdu nutne, mit ve verzi 2.6.5 takovy kod?
<br>
myslim, ze dnes uz neni problem pouzit Smarty templates, Fast Templates apod. a oddelit uplne php od html. Kodu by to vyrazne pomohlo.<br>
je t velice neprehledne. chtel jsem si overit, zda jsou pro vsechny promenne delany testy na SQL Injection, ale za boha jsem nenasel, kde se to deje, vsude se pouziva $GLOBALS[] pole!<br>
jmena css trid uz vubec radsi nekomentuji, trida "z" "clatext" a ve vetsina sablon napr. "modryram" ci "cervenytext"...

Re: odporny kod
Zaslán uživatelem/kou: Michalek (IP adresa zaznamenána)
Datum: 2005-01-16, 11:20

Tak zaprvy, 265 neni jeste urceny pro provoz webu, ale to je jedno...

1) Jiste, neni problem pouzit jiz udelane sablony pro oddeleni vzhledu, ale je to hodne prace - zkus si to predelat sam a uvidis, jak je to casove narocne, predelat KOMPLETNE cely phpRS vcetne VSECH pluginu. Pro me je to skoro nerealne (ja vim, vsechno jde, ale...)

2) Presne nevim co je SQL Injection, takze na to reagovat nemuzu :-) Ale docela rad bych se to dozvedel, treba bych to zacal pouzivat; je nejaky odkaz nebo vysvetleni? dik

3) CCS tridy - njn; taky takovy pozustatek minulosti; priznavam ze cervenytext (ani v phpRS neni) je docela spatne zvoleny nazev, ale co se ti nelibi na clatext? me z toho jasne vyplyva, ze to je text clanku, tobe ne? :-)

--
[ SAFUS.EU | OFFLINE | FOREVER ]

Re: odporny kod
Zaslán uživatelem/kou: Franky (IP adresa zaznamenána)
Datum: 2005-01-16, 13:22

Mohl bych dostat odkaz na nejaky redakcni system, ktery ma lepe zpracovany kod nez phpRS? Mej prosim na mysli, ze jsem Čech a že mám v peněžence stovku.

Re: odporny kod
Zaslán uživatelem/kou: jirka (IP adresa zaznamenána)
Datum: 2005-01-16, 14:38

To Michalek: SQL Injection ... je útok na SQL dotaz přes vstupní proměnné, pričemž cílem je většinou provést kromě povoleného dotazu, dotaz nepovolený / vlastní.

Co se týče SQL Injection, tak phpRS je proti této formě útoku bráněno (ano, objevil se nedávno jeden opomenutý dotaz, ale ten byl ihned opraven) a nová verze 2.6.5 jde v tomto směru maximálně daleko, jak jen lze. - Co se týče phpRS v2.5.x, tak zde jsou některé části administrace méně (respektive nejsou 100%) chráněny, nicméně se do určité míry spoléhalo na prověřenost členů redakce. Tento stav již ovšem padá a dbá se na úplnou ochranu.

Co se týče Smartů, tak dle mého názor nejsou jedinou alternativou a nevidím důvod, proč bych měl pro ně bláznit.

$GLOBALS? Proč ne? Když si pohlídate to, co máte, tak to není problém. Ostatně k ke cookies a souborům se přistuje přes jejich pole a u dalších proměnných je to úplně jedno, zda použiji $_POST, $_GET nebo $GLOBALS.

Jediný menší dluh citím u CSS, ale to je do značné míry opravdu dáno historií projektu a kdo nemá dlouhodobé zkušenosti s vývojem nějaké aplikace, tak problémy se zpětnou kompatibilitou dost těžko chápe.

Ještě poslední poznámka. I když to bude znít jako "samochvála", tak nemám pocit (a to mám potvrzeno i z mnoha stovek reakcí), že by kód phpRS byl nepřehledný a nedalo se v něm cokoliv najít. Naprostá větši lidí má přesně opačný názor a samotná struktura a pojetí phpRS je na jedoduchosti postaveno. - Osobně si myslím, že si pletete rozdílný styl programování se "špatným kódem", což je dost amatérský názor a s realitou je velmi těžko slučitelný.

Jiří Lukáš
webmaster www.supersvet.cz

Re: odporny kod
Zaslán uživatelem/kou: martinf (IP adresa zaznamenána)
Datum: 2005-01-16, 16:31

Pokud by byl kód phpRS špatný a nepřehledný, asi těžko by spousta "amatérů" a samouků zvládla phpRS doplňovat a "vylepšovat" desítkami pluginů, ...
Je na každém, zda se pro phpRS rozhodne. Já jsem se pro něj rozhodl a nelituji. Je to super alternativa pro ty, kteří nezvládnou něco podobného naprogramovat a nechtějí zůstat u webu udělaného třeba ve frontpage (jako já).

Martin Fous [http://www.zsjvm.cz]

Re: odporny kod
Zaslán uživatelem/kou: tchamra (IP adresa zaznamenána)
Datum: 2005-01-16, 17:29

Jeho hlavni vyhoda je ze to muzete pouzivat i s tou stovkou v kapse. A to se mu nezapre. :D

Re: odporny kod
Zaslán uživatelem/kou: xsuchy09 (IP adresa zaznamenána)
Datum: 2005-01-16, 21:32

Takze si nemuzu taky nepridat:

1) pred tim, nez jsem poznal phpRS (o prazdninach), tak jsem o php (kdyz to prezenu) nevedel nic krome toho, ze existuje

2) kod phpRS je naprosto prehledny a dobre zpracovany - prave na nem jsem se s php naucil ... a upravy se v phpRS delaji naprosto jednoduse - coz je proste uzasny ...

3) udelat to jak pise "meba", tak mnoho z nas by nevedelo kam sahnout atd. ... uz by to nebyl "nas" jednoduchy a jednoduse upravitelny system phpRS, ale zmet kodu pro profiky, nebo alespon zkusene uzivatele php - a to by phpRS ztracelo vyznam redakcniho systemu - protoze takovi uzivatele si mohou udelat svuj redakcni system (kdyz to nadsadim)

atd ...

========================
WEB: Publikační systém WAMOS
SEO: SEO analýza zdarma
OPEN PROJECTS: Studentský portál VUT
HOSTING: WebGlobe.cz
ICQ: 313887644
EMAIL: xsuchy09(at)centrum.cz
========================

Re: odporny kod
Zaslán uživatelem/kou: PaBi3 (IP adresa zaznamenána)
Datum: 2005-01-16, 23:04

Plne súhlasím...

phpRS má zo všetkých redakčných systémov najprehľadnejší zdrojový kód. Keď som sa pozrel na phpNUKE alebo na e107 tak som skoro....

phpRS je aj najlahšie upraviteľný. Keď by som si chcel upraviť iný redakčný systém tak by som sa asi musel php neučiť lepšie ako viem :) (ešte ho dobre neviem - ae učím sa !)

_________________________
[http://pabi3.com/]
ICQ: 286-210-676 (nie som phpRS podpora)

Re: odporny kod
Zaslán uživatelem/kou: MirekS (IP adresa zaznamenána)
Datum: 2005-01-17, 09:41

Já mám ke kódu několik výhrad:

- používání funkce mysql_Result - není doporučována a právě protože se na tomto kódu mnoho lidí učí php, tak se ho naučí špatně (je mnohem výhodnější používat funkci mysql_fetch_assoc, mysql_fetch_row(), mysql_fetch_array() a mysql_fetch_object() - jsou rychlejší, méně zatěžují server a vrací celý řádek z databáze, takže jí stačí zavolat jen jednou a nemusí se to dělat 2x nebo víckrát pro každou hodnotu z jiného sloupečku, jako u té mysql_Result)

tahle ukázka ze spec fce je prostě hrůza :
$pocetmenu=mysql_num_rows($dotazmenu);
for ($pom=0;$pom<$pocetmenu;$pom++):
switch (mysql_Result($dotazmenu,$pom,"level")):
case 1:
// 0 - id, 1 - prep. rodic, 2 - nazev pol., 4 - id predka
$sezdruha[$poc_sezdruha][0]=mysql_Result($dotazmenu,$pom,"idt");
$sezdruha[$poc_sezdruha][1]=mysql_Result($dotazmenu,$pom,"rodic");
$sezdruha[$poc_sezdruha][2]=mysql_Result($dotazmenu,$pom,"nazev");
$sezdruha[$poc_sezdruha][4]=mysql_Result($dotazmenu,$pom,"id_predka");

když by to mohlo být takto:
while ($line=mysql_fetch_assoc(0) {
switch ($line["level"]):
case 1:
// 0 - id, 1 - prep. rodic, 2 - nazev pol., 4 - id predka
$sezdruha[$poc_sezdruha][0]=$line["idt"];
$sezdruha[$poc_sezdruha][1]=$line["rodic"];
$sezdruha[$poc_sezdruha][2]=$line["nazev"];
$sezdruha[$poc_sezdruha][4]=$line["id_predka"];

}

a navic to ušetří i volání $pocetmenu=mysql_num_rows($dotazmenu);
místo 5-ti volání funkce pro práci s databází jen jedno! a zbytek je práce jen s proměnnými, což je mnohem rychlejší a méně to zatěžuje server


- převod data:
ukázka ze specfce.php:
function MyDatetimeToInt($mysql_datum)
{
list($datum,$cas)=explode(" ",$mysql_datum);
list($rok,$mes,$dat)=explode("-",$datum);
list($hod,$min,$sek)=explode(":",$cas);
return date("U",mktime($hod,$min,$sek,$mes,$dat,$rok)); // int
}

lze udělat takto:
function MyDatetimeToInt($mysql_datum) {
return date("U", strtotime($mysql_datum));
}

řekl bych, že je to zase mnohem přehlednější (kromě toho netuším, proč se funkce jmenuje MyDatetimeToInt, když vrací naformátovaný string) a myslím si, že se lze v celém phpRS obejít bez funkce mktime a pokud chceme najít datum před měsícem, tak než to udělat takto:
$predeslymes=date("m",mktime(0,0,1,($mesic-1),1,$rok));
tak se to dá napsat takto:
$predeslymes=date("m", strtotime("-1 month"));

kromě toho se dá takto rovnou nadefinovat třeba celé datum, nejen měsíc např
date("Y-m-1", strtotime("-1 month")) - první den předchozího měsíce
date("Y-m-t", strtotime("-1 month")) - poslední den předchozího měsíce

a je-li ve funkci kalendar toto:
$predeslyod=$predeslyrok."-".$predeslymes."-1 00:00:01";
tak kdyby někdo vydal článek přesně o půlnoci (v 00:00:00), tak se mu nezobrazí neboť to hledá články s datem větším nebo rovno 00:00:01 a 00:00:00 je o vteřinu méně



- používání uvozovek u řetězců a pak nutnost následného escapování všech uvozovek - zase pro méně znalé je to méně přehledné a mohou snadno něco upravit špatně ukázka ze specfce.php
$plus="<img src=\"".$GLOBALS["adrobrlayoutu"]."plus.gif\" width=\"11\" height=\"11\" alt=\"plus\" />&nbsp;";
nebo přehlednější
$plus='<img src="'.$GLOBALS["adrobrlayoutu"].'plus.gif" width="11" height="11" alt="plus" />&nbsp;';
navíc se tvrdí, že ty řetězce v apostrofech se vykonávají rychleji (a tudíž zase méně zatěžují server), neboť se v nich nemusí hledat proměnné, ze kterých se má vrátit jejich hodnota, ano by to šlo totiž zapsat i takto :
$plus="<img src=\"$GLOBALS["adrobrlayoutu"]plus.gif\" width=\"11\" height=\"11\" alt=\"plus\" />&nbsp;";


- funkce pictures.php, je zde uplně zbytečná, jen zase zvyšuje zátež serveru zbytečným generováním obrázků, které lze snadno nahradit jejich statickou podobou (a navíc jsou zde obrázky zcela nesmyslně generovány jako jpg, když mnohem vhodnější formát je gif nebo png), tohle pouze přináší problémy s gd knihovnou, které by při použití statických obrázků vůbec nevznikly


P.S. ukázky kódu jsem teď dělal od boku, tak mě netlučte, kdyby tam byly nějaké chybky, díky kterým to zcela nefunguje, měly zde sloužit jen pro rámcové srovnání



Celkem upraveno 3×. Poslední úprava MirekS v 17.01.2005 10:15.

Re: odporny kod
Zaslán uživatelem/kou: jirka (IP adresa zaznamenána)
Datum: 2005-01-17, 10:36

Poměr mezi použitím mysql_Result a mysql_fetch_assoc (a podnových funkcí) se od verze 2.5.0 výrazně přehoupl na stranu druhé uvedené (té vykonější) a tvrdím, že ve verze 2.6.5, existuje v phpRS již pouze pár pozůstalých funkcí, které využívají mysql_Result. - Takže tohle považuji za zbytečnou kritiku.

Co se týče zpracování datumu, tak na to mám jiný názor. Myslím si, že pro každou operaci by šlo vytvořit několik různých alternativ a pak by šlo dlouze diskutovat o tom, která je lepší. - Pravdou je, že k některým částem kódu budou určitě existovat kratší (a možná i o něco rychlejší) alternativy, nicméně nemám pocit, že by to byla tak zásadní otázka. Navíc, co je přehledné pro profíka, tak není přehledné a lehce pochopitelné pro běžného programátora. On ten "efektivnější" kód je opravdu mnohdy vykoupen minimální srozumitelností (to je spíše všeobecnější teze). - Na druhou stranu musím říci, že kód prochází neustálým vývojem a funkce se obměňují (inovují) a dost možná přijde čas i na tyhle již dost staré programové části.

Uvozovky vs. apostrof je otázka spíše zažité konvence a navíc to vychází z dřívějšího častého použití přímo zápisu proměnných do řetězce. Teď se tam již vyskytují minimálně, ale jsou tam ještě aktivní znaky, které potřebují mít možnost překladu. - Nicmén od zápisu tohoto kódu se taky pomalu ustupuje (tedy od textu ohraničeným uvozovkami).

pictures.php? To je otázka sama pro sebe? Když potřebujete uspořit výkon, tak ano. Když chcete něco jiného (třeba pracovat s vygenerovaným obrázkem), tak zase ne. pictures.php je spíše taková ukázka možností. Navíc nemám pocit, že by to bylo zdrojem zvýšených problémů. GD knihovnu potřebuje i ke galerii. ... Krom toho, existuje řešení, které to nahrazuje prací se statickými obrázky.

Jiří Lukáš
webmaster www.supersvet.cz

Re: odporny kod
Zaslán uživatelem/kou: MirekS (IP adresa zaznamenána)
Datum: 2005-01-17, 11:39

jirka napsal/a:
-------------------------------------------------------
> Poměr mezi použitím mysql_Result a
> mysql_fetch_assoc (a podnových funkcí) se od verze
> 2.5.0 výrazně přehoupl na stranu druhé uvedené (té
> vykonější) a tvrdím, že ve verze 2.6.5, existuje v
> phpRS již pouze pár pozůstalých funkcí, které
> využívají mysql_Result. - Takže tohle považuji za
> zbytečnou kritiku.

ano, souhlasím, že už použití mysql_Result ustupuje, ale mě šlo o to, když zde byly obecné náznaky chyb, tak je konkretizovat, aby případní zájemci začátečníci věděli co z phpRS brát a co ne (kteří se třeba na phpRS PHP učí)


> Co se týče zpracování datumu, tak na to mám jiný
> názor. Myslím si, že pro každou operaci by šlo
> vytvořit několik různých alternativ a pak by šlo
> dlouze diskutovat o tom, která je lepší. - Pravdou
> je, že k některým částem kódu budou určitě
> existovat kratší (a možná i o něco rychlejší)
> alternativy, nicméně nemám pocit, že by to byla
> tak zásadní otázka. Navíc, co je přehledné pro
> profíka, tak není přehledné a lehce pochopitelné
> pro běžného programátora. On ten "efektivnější"
> kód je opravdu mnohdy vykoupen minimální
> srozumitelností (to je spíše všeobecnější teze). -
> Na druhou stranu musím říci, že kód prochází
> neustálým vývojem a funkce se obměňují (inovují) a
> dost možná přijde čas i na tyhle již dost staré
> programové části.
>

myslím si, že napsat -1 month je dostatečně srozumitelné pro každého a je pak jasné, že nás zajímá předchozí měsíc (den, rok apod, jen se místo month napíše day nebo year)

na rozdíl od:
date("Y-m-d H:i:s",mktime(23,59,59,$mesic+2,1,$rok)-86400)
kde na první pohled teda nevím, co z toho vznikne za datum a myslím, že použití date('Y-m-t 23:59:59', strtotime('+1 month')) je mnohem názornější

a navíc je zde obrovské štěstí, že v php lze pracovat s měsícem > 12 a < 1 (u dnů, hodin, minut a vteřin je to podobné, jen jsou jiné meze) neboť si to php samo převede, ale v jiných programovacích jazycích by se $mesic-1 nebo $mesic+1 musel ošetrit v případě že $mesic =1 nebo 12, aby to fungovalo (a tim ošetřit i rok -1 nebo +1), takže to nepovažuji za moc čistý kód, od toho jsou zde ty funkce pro práci s datem a jeho intervaly, které si to sami vyřeší


> pictures.php? To je otázka sama pro sebe? Když
> potřebujete uspořit výkon, tak ano. Když chcete
> něco jiného (třeba pracovat s vygenerovaným
> obrázkem), tak zase ne. pictures.php je spíše
> taková ukázka možností. Navíc nemám pocit, že by
> to bylo zdrojem zvýšených problémů. GD knihovnu
> potřebuje i ke galerii. ... Krom toho, existuje
> řešení, které to nahrazuje prací se statickými
> obrázky.

vzhledem k tomu co pictures.php dnes dělá, tak jediný její význam může být v té ukázce možností, ale dnes umí udělat jen 8 různě barevných obrázků (a žádným parametrem ty obrázky nelze změnit, lze je modifikovat jen editací toho php kódu) a na to je zbytečná (mohla by být v phpRS přiložená a kdo by chtěl, tak by se v ní mohl inspirovat, ale to může i v interní galerii u tvorby náhledů)
a ten switch v ní 2x za sebou taky není zrovna vhodným příkladem (pokud si v ní změním barvu, pak to musím změnit v obou switchích, neboť by mi jinak nesouhlasilo to textové pojmenování, takže bych to celé dal jen do jednoho a ten druhý zrušil)

------------------------------

vzhledem k tomu, že hodně phpRS běží na serverech, které nabízejí hosting zdarma a většina z nich má problémy s výkonem, tak každá úprava, která serveru ulehčí bude určitě dobrá




Celkem upraveno 4×. Poslední úprava MirekS v 17.01.2005 11:52.



Lituji, ale pouze registrovaní uživatelé mohou zasílat příspěvky do této sekce.
This forum powered by Phorum and designed by STaNBoSS.