Klient s e-shopem na WordPressu s WooCommerce pluginem mě požádal o funkčnost, aby se mu objednávky provedené na eshopu stahovaly do jeho pokladního a účetního programu WinShop. S tím jsem neměl žádnou zkušenost, a dokumentace byla také značně omezená, ale po nějakém pátrání se ukázalo, že stačí, když bude eshop vytvořené objednávky v XML formátu ukládat do nějaké složky na FTP. Z té si je pak bude WinShop sám stahovat a importovat po své ose, a e-shop už to nemusí zajímat. Také je bude po importu z tého složky sám odmazávat.

Připravil jsem tedy plugin, který v časovém intervalu u nově vytvořených objednávkek kontroloval, zdali  již byly exportovány, tedy uloženy jako XML soubor do patřičné složky. Pokud ne, vygeneroval se XML soubor se všemi objednávkovými informacemi ve WinShop formátu, uložil se do složky, a k objednávce se poznamenalo, že již exportována byla. Pak se spustí další kontrola – pokud byla objednávka exportována, a její soubor již ve složce nebyl, tak to byla informace pro e-shop, že si WinShop tuto objednávku již stáhl a importoval, a soubor odmazal. To se poznamenalo také, a těchto objednávek si už pak e-shop nevšímá, neboť je má za plně vyřízené.

WinShop nabízí i export produktových dat (…) z programu do WooCommerce, ale klientovi šlo primárně o stahování objednávek, takže jsem zabudovával pouze tuto funkčnost.

Potřebujete-li také propojit svůj WooCommerce e-shop s WinShop účetním programem, neváhejte mě kontaktovat.

Nedávno jsem pro klienta (jiného vývojáře) opět propojoval WordPress a Realman realitní aplikaci, a tentokrát to byla větší výzva než jindy. Klientův web byl totiž vícejazyčný, přes WPML plugin byl rozdělen na CZ a EN mutace. A po chvíli vývoje samozřejmě vyvstal požadavek, aby při importu českého inzerátu z Realmanu došlo automaticky i k vytvoření jeho EN mutace. Pro své multijazyčné weby  používám vždy Polylang plugin, který mi připadá koncipovaný jako více WordPress-like než zmatelný WPML, a tato práce s WPML na úrovni PHP funkcí mě v tom jen utvrdila. Naimportování nové nabídky z Realmanu tedy vytváří vedle CZ záznamu ještě EN záznam se všemožnými specifiky. Zajímavým oříškem byla práce s fotografiemi, protože z výkonnostních důvodů se při importu nabídky nezpracovávají všechny, ale v několika dávkách se následně dostahovávají. A já musel neustále myslet na to, aby se každé takovéto pozdější změny promítaly také do EN mutace českého inzerátu.

(Pokračování textu…)

Nečekal jsem to, ale na vlastní kůži jsem si vyzkoušel, jaké je to mít hacknutý vlastní web. Že by staré lidové moudro o kovářově kobyle? 🙂 Na začátku listopadu jsem se po dlouhé době potřeboval podívat na FTP server svého webu, a naprostou náhodou si tam mezi WP složkami souborů všiml cizokrajné složky /yeg49e0/. Vytvořena 1. 11. v 17:10. A ke stejnému času modifikovaný soubor wp-load.php, ve kterém přibyl jeden jediný řádek PHP kódu: include(‚…/yeg49e0/1a9ra.php‘). Tedy každé načtení stránky webu spouštělo i skript nějakého malwaru. Ten jsem deaktivoval, odmazal, a prozkoumal web – nikde nic zvláštního, nebyl doinstalován žádný podezřelý plugin, vytvořen nový administrátor, nebo články infikovány zpětnými odkazy nebo divným, javascriptem. Překvapující ale bylo, že malware neodhalil Ithemes Security bezpečnostní plugin.

(Pokračování textu…)

Nedávno jsem pracoval na zajímavé malé zakázce – v obci, které jsem před lety vytovřil WordPress web, byl nasazen rozhlasový systém od firmy Bártek (Bártek rozhlasy, s.r.o.). A tento rozhlasový systém umí jednotlivá hlášení zaznamenávat (nahrávat), a volitelně je nahrávat do určené složky v libovolném FTP účtu. Od toho je pak jen malý krůček k zpřístupnění jednotlivých hlášení rozhlasu k přehrátí na webových stránkách obce. A přesně s tímto požadavkem se na mě obrátilo vedení obce.

Připravil jsem tedy pro firmu Bártek přístup do vybrané složky na FTP serveru, kde se po pár dnech objevil první audiosoubor v OGG formátu, společně s dalšími metadaty v XML souboru. Pak jsem se pustil do přípravy malého WordPress pluginu, který tuto složku sleduje, a tamní audiosoubory nabízí k přehrání skrze nativní [ audio ] shortcode.

Pokročilejším řešením by pak mohlo být automatické publikování jednotlivých hlášení jako samostatných příspěvků, které by se objevily na úvodní stránce webu mezi ostatními aktualitami.

Dlouholetý klient (realitní kancelář) se rozhodl využívat aplikaci www.realman.cz pro chod své realitní kanceláře, evidenci nabídek, zákaznických dat, prostě všeho souvisejícího s realitami. V jedné aplikaci má všechna data, a vybírá si, na které realitní inzertní  servery se mají nabídky jedním kliknutím exportovat. Stejně tak chtěl ale aktivní nabídky zobrazovat i na svém WordPress webu, aniž by je musel zakládat ručně v původní k tomu určené aplikaci.

Mým úkolem tedy bylo propojit API Realmanu a WordPress web.

Narozdíl od Urbium pluginu jsou zde nabídky exportovány on-demand přímo z Realman aplikace – makléř založí novou nabídku, a odklikne tlačítko „Exportovat na web“, a Realman API v následujících sekundách pošle všechna data na zadanou URL adresu. Na to čeká můj plugin a data přijme, zpracuje, a rozřadí do původní databáze, a během okamžiku je nabídka aktivní i na klientově webu.

Během následujících měsíců bylo ale třeba doplnit několik pojistek a kontrol, protože klientův web je hostován na mírně problematickém hostingu, a nejsou neobvyklé kratičké nedostupnosti … které pokud se trefí do několik desítek sekund trvajícího importu desítek fotografií nabídky, tak celá jednorázová operace selže a již se neobnoví (plugin si data nestahuje, ale čeká, až mu jsou „vnucena“). Můj plugin tedy nyní nespoléhá na to, že se import všech dat a především fotografií zvládne vždy naráz, ale zpětně kontroluje, zda byla uložena všechna data a fotografie, a případně si fotografie (těch se to týká především) dostahovává v omezených dávkách.

Propojení Realmanu a WordPressu je každopádně velmi dobrá volba – klient si nebídky spravuje v profesionální aplikaci, rozesílá je na realitní servery, ale také se mu automaticky promítají i na jeho oficiální web, na kterém přitom nemusí být žádná rozsáhlá (a velmi pracná) administrace, číselníky, seznamy hodnot atd … to pracnost takového řešení velmi výrazně snižuje.

V posledních dnech jsem  implementoval dvě platební brány do dvou různých WordPress webů – platební bránu od www.thepay.cz a platební bránu Fio banky. A nemohl to být rozdílnější zážitek. ThePay je moderní jednoduchá krásně přímočaře implementovatelná brána, po registraci ihned získáte údaje a hesla k ostrému provozu. Svou aplikaci si otestujete s demo hesly z dokumentace a až máte vše řádně funkční, tak jen vyměníte hesla a můžete bránu používat naostro – a přijímat platby od zákazníků.

Klientka nabízí službu hlídání domácích mazlíčků, a na webu chtěla mít jednoduché platební tlačítko, aby jí mohli zákazníci snadno posílat zálohové částky na (budoucí) hlídání. Částky 500 Kč, 1000 Kč … přidal jsem k tomu kolonky na jméno, email a telefon, pak klientkou nastavitelný počet tlačítek / částek, a do administrace přehled transakcí a jejich stavů. A bylo hotovo.

No …

… a pak je tu Fio platební brána.

Fio platební brána je strašná. Fio platební brána zamrzla v roce 1995. Technicky, procesně, dokumentačně. Fio banka používá technologii od externí slovenské společnosti Payeezy … která používá technologii od lotyšské společnosti First data … nebo tak nějak. Klientovi přijde emailem textový soubor (příloha) s certifikáty. Ten si musí uložit na disk, přepsat koncovku TXT na RAR, a náhle je z toho zabalený archiv. Ale zaheslovaný. Heslo k rozbalení … přijde druhým emailem. WTF? Tak snad kdyby ho poslali SMSkou, tak to má smysl, ale toto je bezpečnostní opatření level starověk.

Dokumentace je docela otřesná a rozprostřená po několika různých dokumentech. Nějak jsem to dal dohromady, a při testovací platbě zjistím, že na stránce brány, kde má zákazník zadávat údaje ze své karty, svítí jakési %%meno obchodnika%% tam, kde by měl být název webu, ze kterého na bránu přišel. Vždyť Fio ví, jaká firma onu bránu používá … ale nikoli, já sám musím jít a tuto značku přepsat přímo ve zdrojových souborech vzhledu brány. V rozhraní tak starém a nepřívětivém, že mě nechávalo v němém údivu…

Neuvěřitelné. Takhle musel člověk provést několik úprav, a při překlopení do ostrého provozu se stejně načetly původní čisté šablony bez mých úprav. Šokován jsem psal na podporu, co to má znamenat, proč jsem to tedy na testovací instanci brány upravoval, a ať do ostrého provozu laskavě překopírují mé úpravy.

Jenže ostrý provoz je podmíněn tím, že člověk přes to strašné rozhraní na obrázcích výše ještě provede asi 14 testovacích transakcí. Tedy provede je na svém webu, kde bránu implementoval, a v rozhraní bude zadávat jejich výsledky … a některé z nich jsou tak padlé na hlavu, že je třeba kód své implementace fingovaně upravit, aby se transakce poslala v podobě požadované daným testem, a pak úpravy zase vrátit zpět, aby transakce fungovaly dále správně. A když je toto vše hotové, tak musíte napsat na podporu a nechat si schválit, že je možné přepnout bránu do ostrého provozu … a dny čekáte, než vám opět pošlou nové certifikáty a ostrá hesla, opět zabalené v Raru …

Já byl implementací Fio platební brány TAK. STRAŠNĚ. FRUSTROVÁN, že je to z tohoto textu asi zřejmé. Již nikdy více.

(A to nebudu zmiňovat takovou „drobnost“, že ještě nedávno Fio brána neuměla takovou naprosto základní věc jako předat zpět na web informaci o tom, jakou transakci právě zpracovávala. Nevěděl bych tedy, jakou objednávku označit jako uhrazenou (…), protože brána by mi nevrátila její ID … strašné, strašné)

 

Platební systém Xpay.cz je oblíbeným řešením pro klienty, kteří chtějí zpoplatnit přístup ke svému webu, a úhradu umožnit zasláním Premium SMS. Což je mnohem jednodušší způsob, než řešit bankovní převody a platební karty. Na druhou stranu, výše těchto plateb není nikterak závratná (tuším max do 1 500 Kč), a provize mobilnímu operátorovi si také ukousne velkou část z celé transakce … ale to vše je vyváženo onou jednoduchostí platby. Vzít do ruky telefon a poslat SMS, to zvládne každý.

Při nedávné zakázce jsem platební bránu Xpay implementoval jako plugin pro WordPress. Zájemce měl web s erotickými povídkami, a hodlal jej zpoplatnit posíláním těchto SMS (to je velmi častý případ). Nejdříve jsem dlouho bojoval s dokumentací, neboť jsem s Xpay platební bránou pracoval naposledy před několika lety, a od té doby se některé věci změnily. Ale nakonec jsem se dopracoval k velmi elegantnímu řešení.

Klient si může v administraci WordPressu nastavit až pět různých platebních metod, které se liší výší poplatku, a tím i délkou předplatného, po kterou je uživatelský účet aktivní. Můj plugin pak čeká na pokyn od Xpay brány, že (zjednodušeně) telefonní číslo 789123456 uhradilo 99 Kč. Plugin z nastavení ví, že takovému zákazníkovi má vytvořit účet s platností na např. 30 dní, na pozadí vytvoří nového WordPress uživatele, vygeneruje mu heslo, a Xpay bráně vrátí znění SMS, která je poslána zpět na mobil zákazníka. Například ve tvaru „Děkujeme za vaši platbu! Byl vám vytvořen účet se jménem ABCD a heslem M2f58kWx, platný po dobu 30 dní.“. Zákazník má tedy pár okamžiků po zaplacení poplatku v ruce přístupové údaje na web, a může se přihlásit.

Klient má ve správě stránek a příspěvků k dispozici nastavení, kdy si sám určuje, který obsah je placený (a zobrazí se místo něj pokyny k SMS platbám a přihlašovací formulář), a který je volně přístupný. Může i snadno označit část stránky, která bude veřejná, a která část bude přístupná až po přihlášení … a tedy čtenáře nalákat několika prvními odstavci textu.

Obrátil se na mě klient s žádostí řešení situace, kdy má firma s celoevropskou působností svůj hlavní mezinárodní web a cca 10 webů poboček v různých státech (a jazycích), a ty by měly ideálně bezpracně zobrazovat fotogalerii referencí z hlavního mezinárodního webu. Tamní rozsáhlá fotogalerie obsahuje cca 600 referencí s kvalitními a poutavými fotografiemi a je neustále doplňovaná … jenže to samé provádět na webech všech národních poboček by bylo nepříjemně pracné (vložení nové galerie na hlavní web by obnášelo desetkrát tento úkon opakovat i na ostatních webech). Ovšem tyto kvalitní fotografie tam nemít by zase bylo trestuhodné nevyužití jejich potenciálu.

(Pokračování textu…)

Nedávno jsem dokončil zakázku na propojení webu realitní společnosti Luneta reality a její databáze nemovitostí v realitním systému Urbium. Použil jsem svůj Urbium WordPress plugin. Web společnosti využívá tradičně rozsáhlou placenou „realitní“ šablonu, která sama obsahuje možnost kompletní správy nemovitostí, ale to vše by musel klient řešit ručně bez možnosti automatizace – nejdříve by své nemovitosti zadával v Urbiu (aby byly kopírovány na inzertní servery), a poté by je musel znovu zadávat v administračním rozhraní šablony, aby se zobrazovaly na jeho webu.

Můj plugin zajistil jejich zkopírování z Urbia na web, a dále bylo třeba připravit „na míru“ jejich zakomponování do šablony. Díky tomu, že šlo o realitní šablonu, nebylo třeba vymýšlet něco nového, ale mohl jsem rovnou zvolit z několika předpřipravených podob přehledu nemovitostí a jejich detailových stránek (tedy to si samozřejmě zvolil klient). Přesto to obnášelo podrobné zpětné inženýrství, kdy jsem ze šablony vyzobával jednotlivé prvky a nechával je zobrazovat mým pluginem. Jde o situaci, kdy šablona o žádných nemovitostech neví (žádné ve své správě nemá), ale ví, jak mají případně vypadat, zatímco můj plugin nemovitosti má (stáhl si je z Urbia), ale neví, v jaké podobě je na webu prezentovat.

Po drobných finálních laděních a úpravách je vše hotové a funkční.

Obrátil se na mě zákazník s prosbou o vyřešení problému s napadeným WordPress webem, který během posledních 24 hodin rozeslal cca 25 000 spamových emailů, a jejich hosting jim ho vypnul. Ihned jsem se pustil do práce. V přeposlaném e-mailu od hostingu byla ukázka z logu, kde byly spamové requesty očividně zastoupeny voláním „POST /wp-admin/admin-ajax.php“. Už to mi mělo napovědět, že to nebude úplně běžné napadení – to se totiž nesoustředí jen na jeden soubor, ale má rozesetá zadní vrátka po celém webu.

(Pokračování textu…)