Standarní PHP CLI binárka má šikovný parametr -l (lint), který bere jako argument PHP soubor a vypíše, jestli v něm nění nějaký Parser error. Pro pohodlnost lze použít tento příkaz, který projede rekurzivně všechny soubory v současném adresáři a zkontroluje u nich syntaxi:

find -type f -name '*.php' -exec php -l {} \; | grep "Parse error"

Výsledkem pak může být třeba:

vojta@vvondra-laptop:~/public_html$ sh syntax.sh
PHP Parse error:  syntax error, unexpected T_STRING in ./app/extensions.php on line 10
PHP Parse error:  syntax error, unexpected T_REQUIRE in ./app/bootstrap.php on line 14

Pomocník automatický

Ještě šikovnější věc jsem ale viděl v našem repozitáři pro phpBB na GitHubu, pre-commit hook, který zabrání commitu, pokud je v nějakém souboru syntax error.

To už je jen na vás, jak zpracujete.

Po chvilce na Google jsem přišel na příčinu, která by mě rozhodně dříve nenapadla. Některé (třeba starší IE s tím nemají problém) verze Internet Exploreru a Chromu (snad i starší Firefox byl postižen) mají problém s renderováním JPEGů uložené s CMYK barvami.

Řešení je snadné, pokud jde o designové prvky na webu, které máte pod palcem, a pokud máte po ruce Photoshop nebo GIMP. U obou shodně přejděte v menu na Obrázek / Image > Režim / Mode a zvolte RGB, GIMP dokonce nic jiného neumí.

Problém je, pokud to uživatelé nahrávají na web. Pak je potřeba obrázek načíst přes GD a znovu uložit. Nejnovější funkce imagecreatefromjpeg() a imagejpeg() to převedou do RGB. GD s CMYK pracovat neumí a nevýhoda tohoto řešení je ztráta kvality při změně barev.

$image = imagecreatefromjpeg('/cesta/k/souboru');
imagejpeg($image, '/cesta/k/souboru');

Detekovat jestli je obrázek RGB nebo CMYK lze snadno s funkcí getimagesize()

$info = getimagesize('/cesta/k/souboru');
if (sizeof[$info['channels']) == 3)
{
    echo 'RGB!';
}
else if (sizeof($info['channels'] == 4))
{
    echo 'CMYK!';
}

Většina prezentací by si zasloužila hodiny dvě. U Davida Grudla by mi přišla přednáška prázdná. Na to, jak vytvořit v Nette autocomplete by se mohl udělat stránkový tutorial. Chtělo by se to spíše zaměřit na konkrétnější a zajímavější věci.

Až na výjimky vypadali přednášející připraveně, někde mohl být projev plynulejší nebo přednáška mohla být lépe strukturovaná. Honza Král povídající o NoSQL by mohl začátek prezentace udělat přehlednější, byl určen lidem, co neznají základní pojmy u databází a právě pro ty to mohlo být špatně srozumitelné.

Je mi dost líto, že jsem nestihl přednášku D. Steigerwalda o objektech v JavaScriptu, ohlasy u oběda byly docela pozitivní. Pro mě nejpřínosnější byly příklady z praxe od Jirky Knesla, zvlášť co se komunikace týče. Zároveň mě přesvědčil, abych důkladněji se věnoval testům u svých aplikací.

Celkově mi příšlo IDF jako výcuc, který mohl mít na třídenní přednáškovou konferenci se skvělým obsahem. Příště by to chtělo stejnou či lepší úroveň přednášejících, delší a hlubší příspěvky, klidně více specializované. Přednášky by měly konceptuálně navazovat, systém “od všecho trochu” mi přijde trochu nešťastný. Vyhozených (studentských) šest stovek to ale nebylo.

Celý zdroj je k dispozici na GitHub a je uveřejněný pod MIT licencí. Dejte si ale pozor na smluvní podmínky od Seznamu, které například omezují použití CAPTCHY pro komerční účely. Na webu API najdete celé znění podmínek. Limity pro využití jsou nastaveny následovně: max. 500 dotazů za 10 sekund, nebo 1 000 dotazů za 60 sekund.

CAPTCHA nabízí i odkaz pro přehraní kódu zvukově, což je příjemné pro handicapované uživatele.

Stáhnout Seznam CAPTCHA plug-in pro phpBB
Diskuze na phpBB.cz

Rozhodně bych uvítal minimálně slovenský překlad, pokud má někdo možnost i jiných, rozhodně dejte vědět.

There have been a few very interesting ideas that came up in the discussion of the new product. One of them was the separation of core features and moving them to a pluggable level. The main positive effect of this measure I see is that the already feature-filled interface can be simplified on each installation giving administrators an option to opt-out from using some of phpBB’s features and not bloating their board with them.

Most of the features that users will suggest and have suggested in similar experiments before were basically adding up of new features that would be useful for only a limited amount of users. Such features and add-ons should be provided in form of modifications, which allow every administrator to customize his board. The phpBB development team on the other hand should provide an intuitive and working modification interface, which would easily allow users to add such modifications.

If I return to the example of the current discussion about phpBB4, in my opinion, the discussion should be led about key structural and feature concepts. Feature themselves should be kept to a minimum. To bring up a topic and proposal that will be implemented, it is necessary to provide a well thought through concept. This means thinking about the target audience, the effect on the board as whole, maintainability and usability. It certainly is not about getting a long list of users to support your idea.

Je to napsané v PHP a obalené v třídě, která se o všechno postará.

V tuto chvíli podporuje tyto TLD: cz, info, com, net, de, eu, biz, name, org, sk

Ukázka použití:

$d = new DomainChecker($domain);
 
if ($d->isAvailable())
{
 echo 'volná';
}
else
{
 echo "registrovaná, informace o majiteli:\n";
 echo $d->getDomainData();
}

Stáhnout

Více na http://blog.genetext.cz

Co to umí?

Držet web váš i vaší konkurence pod drobnohledem a poskynout vám úplný přehled všech statistik týkajících se marketingu a SEO. Je vám nápomocný v PPC kampaňích a optimalizaci vašich stránek. Dokáže vám ukázat slabá místa vašich stránek a navrhnout změny pro zvýšení efektivity online marketingu.

* Sledování pozic a ranků webu
* Pravidelné reporty e-mailem
* Analýza zdrojového kódu vašich stránek
* Všechny tyto funkce dostupné i pro konkurenční weby
* a další…

Kde najdete informace?

Novinky z vývoje, nové screenshoty, plány a termíny vydání, plánované ceníky a další informace týkající se Genetextu najdete na blogu: http://blog.genetext.cz

Kdy to spustíme?

Začátkem února otevřeme registraci a objednávku služeb.

Kód jsem tvořil pro phpBB, které podporuje následující: MySQL, PgSQL, MSSQL, Oracle, SQLite, Firebird.

<?php
switch ($db->sql_layer)
{
    case 'mssql':
        $random = 'NEWID()';
    break;
    case 'postgres':
    case 'sqlite':
        $random = 'RANDOM()';
    break;
    default:
        $random = 'RAND()';
    break;
}
 
$sql = 'SELECT something FROM some_table ORDER BY ' . $random;
?>

Oracle mi přichystal trochu nepříjemnou záležitost, nutný sub-select:

SELECT COLUMN FROM
( SELECT COLUMN FROM TABLE
ORDER BY dbms_random.VALUE )
WHERE ROWNUM = 1

To jsem ale nezkoumal Firebird. Nejdříve je potřeba definovat vlastní funkci:

DECLARE EXTERNAL FUNCTION rand RETURNS DOUBLE PRECISION BY VALUE ENTRY_POINT 'IB_UDF_rand' MODULE_NAME 'ib_udf';

a poté použít klasický ORDER BY RAND();

Nedávno jsem měl v práci možnost opravovat jednoduchý skript (jednoduchá objednávka s odesláním mailu) a pousmál jsem se, co vytvořilo ten humbuk. Stačilo přesunutí na nový server, kde měla direktiva error_reporting v PHP jinou výchozí hodnotu. Téměř celý web se ocitl v jedné chybě jen proto, že byly najednou zobrazeny chyby úrovně E_NOTICE.

Přestože většinou tyto zprávy neovlivní chod aplikaci s omezeným error reportingem, jsou známkou špatného programování, ať už z uspěchanosti, unavenosti nebo pouhé lenosti. Kód by měl být vždycky takový, že se tyto zprávy vypisovat nebudou.

Ukázkový příklad je získání proměnné z globálního pole $_GET nebo $_POST, což je velmi často využíváno při zpracování formulářů (spíše téměř vždy):
$message = $_GET['message'];
Nyní si zapněte výpis E_NOTICE a koukněte co se stane, pokud stránku načtete; PHP vás varuje, že pouíváte nedefinovaný index pole $_GET.

Správný zápis vypadá následovně. V této fázi se rovněž uplatní zkontrolovat datový typ, který očekáváte, hlavně u integerů.
$message = isset($_GET['message']) ? $_GET['message'] : '';

Kromě nedefinovaného indexu pole je druhou nejčastější chybou nedefinovaná proměnná. PHP je v tomto ohledu velmi flexibilní, až mi někdy přijde, že je to příliš. Pokud kontrolujete hodnotu proměnné, ujistěte se, jestli vůbec byla definovaná. Ještě lépe vždy proměnnou sami definujte, kontrola neinicializovaných proměnných může být s zapnutou direktivou register_globals velmi nebezpečná.

Dalším případem může být zapisovatelnost adresáře nebo souboru, se kterými vaše skripty počítájí. Místo toho, abyste byli nemale překvapeni, když skript nenajde to co potřebuje, nejdříve zkontrolujte, zda-li má dostatečná oprávnění. V takovém to výčtu mohu jít mnohem dál, pokud bych shrnul nejčastější prohřešky v tomto ohledu, tak si představím toto:

• Počítejte s všemi možnými situacemi, váše aplikace by měla běžet bez chyb nehledě na prostředí (pokud není stanoveno jinak v požadavcích, například přítomnost určitého rozšíření nebo binárky)
• Dávejte si pozor s čím pracujete, nepokládejte za samozřejmé, že je proměnná definovaná, ověřte si, že funkce dává výstup jaký očekávejte
• Vhodně a včas zachyťte výjimky a zpracujte je

Nenechte vaše skripty, aby se vám vymkly z rukou

Uživatelé na vašem webu mohou být hraví, mohou zkoušet různé parametry (např. pokud máte někde script.php?action=delete), zadávat nesmyslné hodnoty, budou se pokoušet probourat do vaši aplikaci. Nenechte je, a postavte vaši aplikaci tak, aby jste ji ovládali vy a vědeli co dělá. Musíte to ale udělat tak, aby to co nejméně zasáhlo samotného uživatele.

Na formulářích je to vidět ze všeho nejlépe, vždy si ověřte zadávané hodnoty. Využijete regulérní výrazy, kontrolu délky, někdy postačí jen kontrola datového typu. Pokud uživatel něco zadá špatně, buďte vlídní a přesměrujte ho zpátky a naveďte ho na správné řešení.

Pokud je možno více druhů zápisu nějakého pole, zkuste je zpracovat více způsoby a pokud i tehdy nebudou zadaná data dávat smysl, přesměrujte uživatele zpět a mile ho upozorněte.

Opomenutím tohoto bodu se často můžete vystavit nepříjemným věcem jako jsou XSS útoky, z nedávné doby jistě každý ví o co jde. Hlavní pravidlo tedy zní:

Předpokládejte, že uživatel může udělat cokoliv na vašem webu, dovolte mu provést jen to, co by měl!

Nepodceňte bezpečnost

Toto téma jenom zmíním ve zkratce, zaslouží si mnohem více prostoru než zde můžu poskytnout a mnoho lidí už napsalo lepší články, než bych dokázal já.

Při návrhu a psaní aplikace je potřeba dbát na bezpečnost vašich skriptů, různé zkratky jako XSS, CSRF nebo třeba SQL Injection jsou vám jistě známé.

Při tom stačí velmi málo, abyste jim zabránili. Ověřujte veškeré uživatelské proměnné a pro různé případy escapujte obsah podle potřeby.

S tímto okruhem je často spojena jedna otázka, a to jestli povolit HTML v uživatelských formulářích. V tomhle ohledu je moje stanovinsko ne, všechny způsoby filtrování značek nejsou stoprocentní a už vůbec nejsou flexibilní. Na místě je použít nějaký alternativní značkovací jazyk, jako je Texy nebo vlastní implementace známého BBCode

Závěřem

Pokud tvoříte nějakou aplikaci, piště ji s co nejlepším svědomím a snažte se dodržet všechny principy, které jsem tu sepsal. Zároveň se ale nebojte své nedokonalosti, mnoho mých skriptů by někdo napsal mnohem lépe a už mnohokrát by pomohl kritický pohled jiného člověka. Nebojte se vaši práci konzultovat s někým jiným a nechat si poradit s efektivnějšími postupy.