Tak kdyz jsem koukal do toho pluginu verze 2.0, tak bych k nemu mel nekolik pripominek:
1. práce s časem - to je něco téměř nepochopitelného - např. z aktualizace.php řádky 151-153

 
    $rozdil_rok=366*(strftime('%Y',strtotime($dotaz_data['datum']))-strftime('%Y',strtotime($GLOBALS['muj_datum'])));
    $rozdil=strftime('%j',strtotime($dotaz_data['datum']))-strftime('%j',strtotime($GLOBALS['muj_datum']))+$rozdil_rok;
    if ($rozdil>=0):

lze nahradit mnohem kratším a přehlednějším (a navíc trvale počítat s tím, že rok má 366 dní je taky dost divné)

 
    if ( strtotime($dotaz_data['datum']) >= strtotime($GLOBALS['muj_datum']) ):

intervaly datumů lze řešit v php pomocí strtotime('-7 day')

2. kromě toho by bylo mnohem vhodnější to filtrování udělat už na úrovni SQL, aby se nevracely všechny záznamy, ale jen ty, které se mají zobrazit a celé filtrování v php si tím ušetřit (a navíc tím ušetřit i spoustu výkonu serveru, když nemusí z SQL načítat a držet v paměti všechny záznamy)
v MySQL jsou na to funkce DATE_ADD a DATE_SUB

3. jak už jsem psal vedle, tak bych doporučoval zrušit funkci NactiKonfigHod a zjednodušit to na jeden SQL dotaz, který rovnou naplní všechny proměnné, když se stejně vždy všechny načítají

4. v aktualizace-tabulek.php je $pole - dost nepřehledná proměnná
lépe je $pole['akw_sekce_cla_ne']=1 a pak použít cyklus foreach, ktery projde vsechny prvky pole a nemusi se zjistovat jejich pocet funkci count()
a zase asi byl lepší jen jeden SQL dotaz, který by to, co najde v db v $pole funkcí unset() zrušil a nakonec by se provedl INSERT hodnot, které by v tom poli zbyly, místo toho, aby se pro každou hodnotu provaděl dotaz a zkoumal, jestli je v tabulce nebo nikoliv - a lze udelat jeden insert, ktery bude vkladat vice hodnot najednou :
INSERT INTO config VALUES('NULL', 'akw_sekce_cla_ne', '1'), ('NULL', 'akw_sekce_cla', '2'), ('NULL', 'akw_sekce_kom', '3')

5. SELECT * FROM je zbytecne, když je potreba jen hodnota z IDC, tak je mnohem lepsi pouzit SELECT idc FROM, opet se tim zmensi narocnost na pamet, kterou php potrebuje a usetri se tim vykon SQL, kdyz bude vracet mene dat



Celkem upraveno 7×. Poslední úprava MirekS v 28.05.2009 13:34.

tak se trochu služebně nudím a nedalo mi to a zkusil jsem ten plugin trochu poupravit (nemam k dispozici zadny web, kde bych to mohl otestovat, takze to nemusi byt zcela funkcni, ale jako inspirace by to mohlo stacit)

jinak pri te prilezitosti jsem narazil na dalsi chybky:

- v generovaném html kódu je použito jen & místo entity & takže validátor zde bude zase nespokojený

- zobrazované údaje nezohledňují levely, takže i uživatel s levelem 1 bude vidět nově přidané věci s vyšším levelem (musely by se modifikovat dotazy tak, aby vracely záznamy jen se správnými levely a nikoliv všechny bez ohledu na level)

a ještě druhý soubor

Mrknu na to.

Pozn.

Citace:
- zobrazované údaje nezohledňují levely, takže i uživatel s levelem 1 bude vidět nově přidané věci s vyšším levelem (musely by se modifikovat dotazy tak, aby vracely záznamy jen se správnými levely a nikoliv všechny bez ohledu na level)

musím trochu oponovat, protože i to je základní myšlenkou a dokonce to funguje. Uživatel nepřihlášený vidí to co je nastaveno v konfiguraci pluginu. Samozřejmě že je dodržena zásada, že vyšší level automaticky vidí vše co ty nižšší.

Můžeme to vyzkoušet na tom mém cvičném webu [http://www.jirj.wz.cz/test/index.php] (systém obsahuje jeden nevydaný článek-level 20, 3 články-level 1, 1 čtenáře-level 10.) Jako neregistrovaný uvidíš pouze 3 články, jako registrovaný pak ješte 1 čtenáře a pokud ti nastavím vyšší level uvidíš i nevydané články.

Citace:
a ještě druhý soubor

ten je funkční pouze při přidávání pluginu a jeho modifikaci (aktualizaci). Principem bylo nevymazat stávající nastavené hodnoty v případě rozšiřování pluginy o další "funkce". Samozřejmě smazat a nastavit základní hodnoty není problém.

Samozřejmě s neučesaným kódem a možností zjednodušení zcela souhlasím, nejsem učený prográátor PHP, ale samouk na nízké úrovni.

P.S.
Samozřejmě, že to všechno beru jako radu od zkušenějších, "vývoj" pluginu byl v první verzi s "natvrdo" definovanými proměnnými v úvodní části (proto ty krkolomné dotazy na proměnné) a další aktualizace jsem již nabaloval na ten první nepovedený.

---

* Klub kuželkářů Zálabák, Hankova 62, 503 03 Smiřice (Endora) * X X * Stránky ČZS ZO Třešňovka2 * X X * Cvičný phpRS web (WZ) * X X * Testovací phpRS web (WZ) *

---

* cvičná verze phpRS v 2.8.2 * X X * testovací web CMS *

---

Celkem upraveno 1×. Poslední úprava Lonanek v 28.05.2009 16:02.

kdyz to vemu od konce - ano, druhy soubor se pouziva jen obcas, a ta moje uprava taky pridava jen to co chybi v databazi a existujici hodnoty neprepisuje defaultnimi
jen potrebuje pouze jeden dotaz, pokud je jiz vse v db, pripadne pak jeste druhy dotaz, ktery prida vsechny chybejici hodnoty narozdil od puvodniho, ktery provadi 15 dotazu (pro kazdou promenou jeden) a pokud nejaka hodnota chybi v db, tak opet pro kazdou pridavanou hodnotu provadi dalsi dotaz, takze celkem to muze byt az 30 dotazu

s levely to podle me funguje tatko:
je-li v administraci nastaveno pro clanky level 2, tak seznam clanku je zobrazovan pouze ctenarum, kteri maji level 2 nebo vyssi viz podminka:

if ($sekce_cla_ne AND $GLOBALS["prmyctenar"]->UkazLevel()>=$level_cla_ne)

ale temto ctenarum se zobrazuji vsechny clanky bez ohledu na level, takze ctenar s levelem 2 vidi i clanky v levelu 3 - je to dano vyberovym dotazem z db viz:

SELECT link AS link, titulek AS nazev, datum AS datum FROM ".$GLOBALS['rspredpona']."clanky WHERE visible='1' AND datum<='".$dnesnidatum."' ORDER BY datum DESC

kde je zohledneno pouze datum a nikoliv level, takze jsou vybrany vsechny clanky s libovolnym levelem
aby byl zohlednen level, tak by se dotazy musely doplnit podminkou:

level_clanku <= $GLOBALS["prmyctenar"]->UkazLevel()

Tak to jsme se špatně pochopili. Z připomínky jsem špatně vyrozuměl o jaký způsob levelů jde.
V konečném důsledku to pouze čtenáří nenabídne článek, ale vypíše mu, že nemá oprávnění.

Na druhou stranu - někteří uživatelé (čtenáři - nepřihlášení) si snad tímto vzpomenou, že se mají přihlásit.
Pokud by se podmínka do výběru zahrnula mohly by pro neregistrované čtenáře vypadat stránky jako zcela neaktualizované.

---

* Klub kuželkářů Zálabák, Hankova 62, 503 03 Smiřice (Endora) * X X * Stránky ČZS ZO Třešňovka2 * X X * Cvičný phpRS web (WZ) * X X * Testovací phpRS web (WZ) *

---

* cvičná verze phpRS v 2.8.2 * X X * testovací web CMS *

---

no me by prislo logictejsi, abych videl jen to na co mam opravneni, k cemu mi bude, ze uvidim 10 novych clanku, kdyz si ani jeden nemuzu precist? prijde mi trochu nesmysl klikat na odkazy a postupne zjistovat, ze ke clanku nemam opravneni

Za jistých okolností s tím lze souhlasit, dalo by se to řešit i uvedením levelu pro který je článek určen.
Další možnost je přidat proměnnou, kterou si admin nastaví jak to chce zobrazovat - to se mi jeví jako nejpřijatelnější (dát možnost výběru).

Standardně jsou v phprs také zobrazeny všechny články i ty ke kterým nemáš přístup, v tom nic nelogického nevidím.

Nevím jestli tuto diskuzi nepřenést do PM a sem pak uvést pouze konečné řešení.
Zatím si zde dopisujeme pouze my dva

---

* Klub kuželkářů Zálabák, Hankova 62, 503 03 Smiřice (Endora) * X X * Stránky ČZS ZO Třešňovka2 * X X * Cvičný phpRS web (WZ) * X X * Testovací phpRS web (WZ) *

---

* cvičná verze phpRS v 2.8.2 * X X * testovací web CMS *

---

No já už končím, jen jsem chtěl ukázat, jak kód napsat efektivněji a aby se z toho mohli poučit všichni.

Ještě bych přidal poslední připomínku k tomu původnímu kódu - najednou se do 7 proměnných ($dotaz_cla_ne $dotaz_cla $dotaz_kom $dotaz_new $dotaz_dwn $dotaz_lnk $dotaz_cte) načítaly ty spousty dat z db (ad bod 2. nefiltrované na úrovni db), takže to vše se muselo najednou vejít do paměti a zcela zbytečně, protože tyhle hodnoty se pak zpracovávají postupně. Proto jsem zvolil cyklus, který postupně načítá jednotlivé sekce a má vždy načtenou jen tu jednu zpracovávanou sekci.

A teď mě vlastně napadlo ještě jedna připomínka - v případě komentářů by asi stálo za to to omezit i nějakým maximálním počtem, protože pokud se objeví nějaký "problematický" článek, pak může být několik set komentářů k danému článku během jednoho dne - takže pak by se ta stránka dost natáhla. Ale asi by to chtělo omezit i u těch ostatních, co kdyby se zase chytil nějaký robot, který přidá např. velké množství čtenářů.

Add podmínka levelů - souhlasím s výjimkou sekce cla_ne ($dotaz_cla_ne), tyto články nejsou normálně přístupné a volba byla přidána pro správce webu (po nastavení levelu) jako informace, zda není v systému nový nevydaný článek, bez přihlášení do administračního rozhraní. Nikdo tyto články nezobrazí, protože neexistuje a to komu se tyto články zobrazí nastavuje admin v systémovém menu.
Add počty výpisů - o tom jsem již také uvažoval i když se dá omezit počet dní výpisu. Pravda pokud stránky napadne robot může to být dost nepříjemný sáhodlouhý výpis, ale to by si také měl admin odstranit, či zabránit robotům přidávat zejména komentáře.

Varianta řešení je přidat dvě proměnné a ponechat rozhodnutí adminovi v nastavení.
Popracuji na tom.

Díky za připomínky a ukázku řešení kódu. Stále se učím.

EDIT
ke stažení opravené verze použijte link: [http://www.jirj.wz.cz/phprs/download.php?akce=detail&id_detail=12]

Děkuji MirekS

---

* Klub kuželkářů Zálabák, Hankova 62, 503 03 Smiřice (Endora) * X X * Stránky ČZS ZO Třešňovka2 * X X * Cvičný phpRS web (WZ) * X X * Testovací phpRS web (WZ) *

---

* cvičná verze phpRS v 2.8.2 * X X * testovací web CMS *

---

Celkem upraveno 4×. Poslední úprava Lonanek v 01.06.2009 22:01.