Před lety jsem pro jednoho klienta z realitní branže propojoval jeho WordPress web se systémem Realman (v tom už mám značnou praxi). Klient se nedávno ozval znovu, že chce změnit realitní software, ve kterém své nemovitosti spravuje, a chce přejít ze systému Realman na systém Realitní správce. Tím mě dokonale zaskočil, protože jsem o této aplikaci ještě neslyšel. Inu, uvidíme, jak to půjde.
Ukázalo se ovšem, že k exportu nabídek z Realitní správce neexistuje žádná dokumentace, takže jsem musel vše vykoukávat ze samotných dat … což byl další problém, protože i když tam měl klient nabídky navkládané, tak ty nebyly aktivní, a export nabídek byl tudíž prázdný. To se ale časem vyjasnilo, a já se mohl pustit naplno do implementace. Chtěl jsem vyjít ze svého původního Realman importního můstku pro tento WordPress web, jenže v něm se logika práce s daty natolik liší, že by mi to ani moc nepomohlo. Zatímco v jeho případě web celou dobu pasivně čeká, až na smluvený endpoint zničehonic dorazí z Realman serveru data nabídky, kterou on musí obratem zpracovat, tak u Realitního správce jde o tradiční postup „z této tajné URL si stáhni data všech nabídek, a sám si nějak rozhodni, které nově importovat nebo jen aktualizovat“.
V případě tohoto importního můstku je tedy třeba řešit i výpočetní náročnost – samotné zpracování jedné nabídky do WordPress postu trvá sekundu, ale stažení a import každé jedné její fotografie do Knihovny médií trvá sekundy tři, pět, i více … a kompletní zpracování jedné nabídky je najednou otázkou desítek sekund, což už snadno narazí na hostingové limity, a import nabídky selže. A pokud makléř upraví více nabídek najednou, které se mají záhy všechny naráz importovat, tak je na problém zaděláno. Podstatnou částí přípravy importního můstku tedy bylo vymýšlení neprůstřelného systému, který by takovou situaci dokázal zvládnout a nabídky i fotky postupně úspěšně naimportoval.
Pokud chcete váš WordPress web také propojit se softwarem Realitní správce, tak se na mě klidně obraťte, rád vám pomohu.
V nedávné době se ke mně dostal požadavek, zda bych dokázal propojit WordPress webové stránky s aplikací Recruitis. Nejdříve jsem si tedy musel zjistit, co to ten Recruitis je – jde o rozsáhlý software pro správu náborových procesů / nabírání nových zaměstnanců, a vše kolem těchto záležitostí. Klient si v tomto systému řešil své záležitosti, a na svém firemním web chtěl mít aktuální přehled volných pracovních pozic. A samozřejmě – když už je jednou zadal do Recruitisu, tak je nechtěl znovu ručně přeťukávat někde do WordPress administrace.
Zorientoval jsem se tedy v dokumentaci API rozhraní, a začal pracovat na novém pluginu, který si bude periodicky stahovat klientovy inzeráty a porovnávat, které ještě nemá uložené, které se mezitím změnily, nebo byly zrušeny. Přímočarost řešení mi zkomplikoval fakt, že API vrátí maximálně 50 záznamů najednou, a já netušil, kolik inzerátů bude klient za rok za dva řešit. Třeba to nikdy nebude 50 a více volných pozic, ale co když ano? Nezbylo mi než s tím raději počítat, a získávání dat dle toho ošetřit.
Klient si také přál zobrazovat u inzerátů spoustu „štítků“ – pro koho je pozice určena, jaký úvazek, v jaké lokalitě, a tak dále. Všechny tyto a další informace tedy při importu překlápím do WordPress štítků. Teoreticky pak nebude problém vytvořit libovolný filtr nabídek.
Pokud hledáte řešení, jak propojit svůj WordPress web a Recruitis náborový systém, rád vám pomohu. Stačí mě kontaktovat.
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.
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.
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.