Csalódottan vettem tudomásul, hogy php 5.2.x alól 5.3.2 -re már nem lehet zökkenőmentesen upgradelni. Végignéztem a change log-ot, sok minden változott konfig szinten is, amire érdemes odafigyelni.. és persze volt néhány extension is (pl a legutóbb tárgyalt imagick) amiknek egy-egy új dll-t kellett guberálnom. Ha HTTP 500-as hibát kapsz upgrade után, akkor neked szól az alábbi pár tipp:
Időzóna.. A php.ini kapott több új direktívát, ilyen a date.timezone mostantól kötelező beállítás is. Állítsuk be a php.ini-ben tehát a következőt:
date.timezone = Europe/Budapest
Localhost és mysql esete.. Install után próbálgattam lefuttatni néhány weboldalamat, de nem ment.. jobban megvizsgálva, csak a mysql-t használó oldalak nem mentek, így gyanakodni kezdtem a mysql modulra. Az viszont rendben betöltődött, látszólag semmi gondja nem volt.. Némi guglizás után kiderült, hogy 5.3.1 óta a php valamiért nem bírja értelmezi az oprendszertől visszakapott localhost címeket, ha több mint egy ip van hozzárendelve. Így a localhost nem “fordul le” 127.0.0.1-re. Két bugfix kínálkozik, egyik sem a legszebb megoldás..
a.) localhost helyett ezentúl 127.0.0.1-et használunk adatbázis csatlakozáskor.
b.) átírjuk a hosts fájlunkat, amit a C:\Windows\System32\drivers\etc\alatt találunk:
::1 localhost
A fenti sort kommenteljük ki!
New windows specifikus, de ide tartozik, hogy az 5.3-as verzióban több függvényt is halálra ítéltek, az ítéletet viszont még nem hajtották végre. Az ilyen függvényeket ‘deprecated’ módba rakták, azaz használhatjuk, de egy új, “DEPRECATED ” típusú hiba figyelmeztet rá. Részletesen: http://www.php.net/manual/en/migration53.deprecated.php olvashatsz az érintett fügvényekről és régi-új megfelelőikről.
Egy ideje aggódva figyelem, hogy miket produkál a kb 1,5 éve vett alu MacBook-om.. Egy dolog, hogy kevés a 2GB ram, de mióta Snow Leopard fut rajta, a bootolás pl. iszonyatosan lelassult és indítás után van kb 30 mádosperc amíg látszólag semmit nem csinál.
Találtam egy valóban működő és nagyon egyszerű megoldást:
PRAM Reset.. A gép indulásakor nyomjuk hosszan az ALMA + ALT + P + R kombinációt, amíg a gép újra nem indul (újra megszólal a boot dallam).
A PRAM resetelése a gép alapbeállításainak visszaállítását jelenti. A PRAM-ban olyan információk tárolódnak mint a képernyő színmélysége, felbontása, virtális mem. beállítások, kernel panic log, stb.. Alapesetben ezt nem érdemes piszkálni, de ha lassulást észlelünk bootoláskor, akkor nagy az esély rá, hogy a PRAM konfigurációjának hibája okozza azt.
Az utóbbi hetekben a CMS fejlesztés közben többször is meggyűlt a bajom a GD2 libraryvel a transparent PNG-k kapcsán, majd speciális JPEGek és a rossz sharpness beállításokkal is. Elegem lett. Alapvetően nem vagyok a híve az észnélküli kiegészítő telepítéseknek, de az ImageMagick egy elég gyakori képfeldolgozó szoftver unix alapú szervereken, így bevállaltam, hogy a CMS rendszerkövetelményei közé bekerüljön ez is. Nekem windows alá kellett installálnom, íme, hogy is megy ez pontosan:
1. Maga az install automatikus, letöltjük az ImageMagick honlapjáról a nekünk megfelelő Windows Binary installert és elindítjuk. Ha nem tudod melyik a neked megfelelő, akkor válaszd a ImageMagick-X.X.X-X-Q16-windows-dll.exe változatot.
2. Az installer alapbeállításban hozzáadja a progit a system path-hoz, így parancssorból könnyen használható a progi. Az installer utolsó ablakában van is egy teszt példa az image magick logójával. Ezt érdemes lefuttatni, hogy működik-e a dolog magában.
3. Jöhet a php-s kiegészítő dll, amit innen tölthetünk le: http://snaps.php.net/win32/
Válasszuk a saját php verziónknak megfelelő kiadású peclX.X -win32-latest.zip fájlt és guberáljuk ki belőle a php_imagick.dll állományt! Másoljuk a php könyvtárának extension mappájába!
4. A php még nem tudja, hogy nekünk van ImageMagick progink a gépen, mondjuk meg neki! A php.ini fájlba vegyük fel a következő sorokat:
extension=php_imagick.dll
5. Indítsuk újra szervert, hogy a php.ini fájl feldolgozásra kerüljön!
6. Teszteljük!
teszt.php fájl tartalma első lépésben:
<?php phpinfo();?>
Futtatás után a phpinfo-ban szerepelnie kell egy Imagick résznek. Ha nem szerepel, akkor elrontottuk az installálást valahol. Ha szerepel, akkor próbáljuk ki:
A teszt.jpg-t másoljuk a teszt.php mellé, aminek a tartalma legyen:
Az Imagemagick egyik nagy előnye, hogy a php exec paranccsal lehetőség van a parancssoros feldolgozásra, azaz nem a php futtatja a képek átalakítását, hanem egy külön windows programszál. Erről majd máskor..
Több domain levelezését átraktam Google Apps alá, mert az jó. De tényleg.. komplett megoldást nyújt már a Standard (ingyenes) változat is, sokkal jobb (érthető okok miatt) a SPAM szűrés, mint bármilyen saját szűrős megoldás, rengeteg plusz szolgáltatást (Calendar, Docs, ActiveSync, stb..) tudunk igénybevenni saját domainünkkel, kapunk egy egyszerű admin felületet, ahol szabályozhatjuk a domain felhasználóit (postafiókjait). Nem is részletezem, próbáljátok ki!
A levelezés migrációja nem mondható bonyolultnak, néhány új MX és CNAME rekord beállítására van csak szükség domainünk NS szerverein, létre kell hoznunk a kívánt email (domain) felhasználókat, esetlegesen áttölteni a régi leveleiket, aliasokat és csoportos kézbesítéseket létrehozhzni, stb, stb..
A migrációt követően viszont van néhány kellemetlen dolog, amik megoldásával el kell játszani egy darabig, főleg ha nem tudjuk mi is igazából a probléma.
Lássuk, nálam milyen problémák jöttek elő és azokra milyen megoldásokat találtam:
1. probléma: PHP levélküldés nem működik a domaint kiszolgáló webszerveren, SPAM-be kerül a címzettnél.
Ezzel a problémával nagy valószínűséggel szinte mindenki találkozik, aki weboldalt is hosztol egy másik szerveren a GoogleApps-al használt domain alatt. Nálam a mailszerver és a webszerver is egy vason volt korábban, ilyen esteben a php.ini-ben és a mailszerveren megadott beállítások relative egyszerűek, a php mail() függvény teszi a dolgát a lokális SMTP-n keresztül, nem is kell vele foglalkoznunk.
De mi van, ha a domaint valósan kiszolgáló MTA fizikailag egy másik szerverre, jelen esetben a Google Apps szervereire kerül? Ha megmarad a mailszerver használhatjuk annak SMTP-jét, vagy telepítünk valamilyen mini SMTP szervert a webszerver mellé! Így a levélküldés működik szépen, csak az okosabb SPAM szűrők ki fogják dobni a címzett oldalán összes levelünket. Miért is?
Egyszerűen azért, mert a szűrő csak annyit lát, hogy a domainem.hu MX rekordja nem arra a szerverre mutat, amiről a levél érkezik. A Gmail szűrője (nagyon helyesen) ezt figyeli, rosszabb esetben törli és soha nem kapjuk meg, jobb esetben felcimkézi SPAM cimkével a levelet. Ha nem tenné, bárki küldözgethetne nekünk saját domainem.hu-s címünkkel leveleket..
A megoldás:
SPF rekord. Az SPF (Sender Policy Framework) TXT rekordok segítségével szabályozhatjuk DNS szinten, hogy mely szerverek küldhetnek domainünk alól levelet. Sok próbálkozás és a Google által ajánlott megoldás helyett végül a következő SPF rekord került beállításra nálam és azóta rendben mennek a dolgok:
v=spf1 a mx a:000.000.000.000 include:_spf.google.com include:aspmx.googlemail.com ~all
A 000.000.000.000 helyére a webszerver IP címét írjuk! Azét a szerverét, ahonnét php mail()-el küldeni akarunk.
Fontos! Az all végződés előtti karakter nem kötőjel (-) hanem hullám karakter!
A fenti SPF rekord beállításával működik a php-ből indított levelek küldése, nem kerülnek SPAM-be a címzettnél.
2.probléma: SPAM levelek és a POP3
A Gmailben nem lehet kikapcsolni a SPAM szűrést. Alapértelmezetten minden fiókban van egy “Spam” mappa, illetve Gmail címke, amelyet minden beérkező levél megkap. Így a bejövő levelek közt nem jelennek meg, csak a SPAM mappában (címke alatt). Innen a levelek egyébként 30 nap elteltével automatikusan törlődnek is, tehát érdemes gyakran ellenőrizni..
Ha a Gmail felületét használjuk, ott van a mappa (címke), bármikor megnézhetjük, semmi gond. Sőt IMAP protokoll használatával is szépen el lehet érni a címkét mint IMAP mappa.
Viszont a POP3 egy régi protokoll, csak arra képes, hogy a bejövő (INBOX) leveleket letöltse. Sok cégnél ragaszkodnak a POP-hoz, ezért a problémára valamilyen megoldást kellett keresnem:
A megoldás:
Sajnos csak olyan lehetőségünk van, amivel a SPAM szűrést mellőznünk kell. Persze ez arra a minimális SPAM mennyiségre vonatkozik, ami egy átlagos gmail fiókba érkezik.. (nálam napi 1-2 levél 3 ráirányított címmel). Rengeteg SPAM-et már eleve át sem enged a Gmail levélszemét szűrője és eldobja kézbesítés előtt.
A megoldás lényege, hogy létrehozunk egy Gmail szűrőt, ami a Spam mappa helyett a bejövő mailek közé rakja a levelet, így a POP kliens le tudja tölteni:
1. Hozzunk létre a Gmail / Beállítások / Szűrők menüben egy újat!
2.“Tartalmazza a következő szavakat:” nevű mező tartalma legyen ez: is:spam
3. Tovább, majd jelöljük ki a “” opciót.
4. Done. Enjoy the SPAM!
Finaly I found all the bugs in the Wordpress Post Thumbnail plugin. This fixed wppt.php file solves the famous “Loading.. ” problem, but only works under IIS hosted Wordpress blogs. If your hosting server or local development server is IIS (windows webserver) based, you should check this fix!
Please note: This is NOT a crossplatform fix, only works under IIS!
Instructions:
1. Replace the original wppt.php with the unarchived.
2. If the wp-content/uploads/wp-post-thumbnail/ directory doesn’t exist, create it!
3. Enjoy the fixed plugin!
If this bugfix saved your life or something like that, please send me some beer or donate (on the sidebar)!
Ezt a postot részben magamnak ajánlom, mert mindig elfelejtem valamelyik paramétert, részben pedig azoknak a sorstársaknak, akik a Google Apps / Gmail fiókjuk nevében akarnak emailt küldeni php mailer libraryvel.
Flashben programozni szívás, Flexben is. Ezzel a problémával több mint egy órát tököltem, ezért szentelek neki egy gyors kis blogbejegyzést..
Van egy ViewStack komponensünk (MyViewStack), ebben pedig szépen elnevezett gyermek elemek. Elnevezés alatt azt értem, hogy mindegyiknek van saját “id”-je. Szeretnénk, hogy ne csak hagyományos módon az index alapján ( MyViewStack.selectedIndex=1) lehessen elérni, hanem a “Stack” id-je alapján, amit stringként közlünk a megjelenítő metódussal.
A metódus adott: MyViewStack.selectedChild=, viszont a bemenet nyilván nem lehet egy sima változónév, Container-re kell hivatkoznunk. Naív módon próbálkoztam ilyen flashes közhelyekkel: this[target] és társai..
Persze nem ment. Mivel Container kellett neki minden áron, beimportáltam az mx.core.Container csomagot és rájöttem, hogy mennyire szépen meg lehet ezek után oldani a problémát:
Van egy remek online játék, az updown.com. Igazi tőzsdei adatokkal (minimális késleltetéssel) működő online tőzsdei game. Kapsz 1M dollár kezdőtőkét, azt okosba befektetedheted, pontosan úgy adhatod-veheted a részvényeket, shortolhatod az OTP-t mint Soros Gyuri bácsi.. Közösségileg megvitathatod mik a trendek, mit és mit nem érdemes vásárolni, stb, stb.. (OTP amúgy nincs persze, ilyen balkáni (wc)papírokkal nem foglalkoznak.
Kb. fél éve volt egy BÉT előadás a tőzsde működéséről, alapfogalmakról, amit végighallgattam. Érdekes volt, akkor regisztráltam az updown.com-ra is. Akkor 1-2 hétig játszogattam vele, jópofának tűnt. Aztán se időm nem volt, se kedvem hozzá, nem foglalkoztam vele.
Benne maradt kb 100.000 USD részvényekben. A többi alaptőkét nem fektettem be. Jelenleg 1.165.000 USD-m van játékpénzben. Elgondolkodtató, nem? Szinte random módon kiválasztott cégek részvényeiről van szó, amikről pénzügyi szempontból semmit nem hallottam eddig, nem figyelem a híreket és egy grafikonjukat sem nézegettem még trendelemzési szándékkal. Hagytam őket érlelődni 5 hónapot és mi lett belőle? Dupla annyi pénz, sőt 1,5x-ese a befektetett összegnek. Ezek után örülnöm kellene a garantált <10 %-ékoknak? Most akkor mi legyen, tőzsdézzek?
Volt szerencsém kipróbálni az e-felvételi rendszert, jelentkeztem egy MSC kézésre. Imádom a kihívásokat, ezért döntöttem az online módszer mellett. Titkon reméltem, hogy látok majd valami jó megoldást, valami olyat, amire azt mondhatom: igen a Felvisek megcsinálták. Sajnos csalódnom kellett, ez a rendszer is a következő tipikusan “magyar IT modellen” alapul:
1. Végy egy lejárt tanúsítványt.
2. Egy tehetségtelen programozót, rendszergazdát és sitebuildert. Ha elég pénzed van (közigazgatási szektor, hogyne lenne), akkor akár egy csapatnyit is.
3. Félig működő állami infrastruktúrát és kapcsolódó szolgáltatásokat (pl. Ügyfélkapu).
4. Az OTP szutyok online fizetési rendszerét.
6. Jól gyúrd össze!
Készen is van! Ha véletlenül a magyaroszag.hu-t kaptad a felvi.hu helyett, akkor rossz irányba keverted.
Persze, tudom fikázni könnyű.. hibázni mindenki szokott, én is, de ha én egymagam ennyi hibát találtam, az már tényleg gáz:
0. Hol az efelvételi? Október 15-e éjjel (a jelentkezés első napja): Nézem a felvi.hu-t… mindenütt kinn a szöveg, hogy hogyan jelentkezz, mit adj meg, hova klikkelj, de az eFelvételi menüpont hiányzik. Okt. 16 de.: még mindig semmi, hívom az ügyfélszolgálatot, hogy bocsánat, lehet, hogy én vagyok a hülye, de nem találom az efelvételi menüpontot.
“Ja, az még nincs aktiválva.” “Hmm.. és mikor várható? ” “Őőőő talán a holnapi napon. De ha nem, akkor hétfőig biztosan.” “Ja, jó.. köszönöm. Viszhall!” Kiváncsi lennék, hogy ha én 3 nappal a jelentkezési határidő után jelentkeznék, azt elfogadnák-e.
1. Dokumentumfeltöltés esetén, ha túl nagy a fájl, benyom az iframe-be egy Bad Request HTTP error böszme feliratot.. Se hibakezelés, se semmi.. a szegény hétköznapi diák meg jöjjön rá mivan..
2. Lejárt session.. ajaxos művelet esetén kiokádja a div-be újra az egész oldalt.. Site in a div effect, értem én..
3. Ügyfélkapu hitelesítés.. na ez a legszebb, komolyan.. SSL error. Rossz a tanúsítvány, de nem csak szimplán rossz, hanem durván.. én ilyet még nem láttam.. Kb. 18-at kellett klikkelnem Firefoxban mire letöltötte és elfogadta az ócska tanúsítványt. Ok, én tudom, hogy ez a programozók, rendszergazdák hanyagsága, de egy ÁLLAMI cég tanúsítványa legyen már rendben könyörgöm!! Főleg ha azon a személyes adataimat hitelesítem. Miért neveljük szerencsétlen felhasználókat arra, hogy lesz@rják a tiltó és figyelmeztető üzeneteket?!
+1 a ráadás. OTP fizetés.. Fizetek, jön az SMS, 9essze’ levonva a számláról. Böngészőben szép kis HTTP error. Visszakavarodok a felvi.hu-ra.. látom, a felületen továbbra is “Önnek 9000 Ft díjtartozása van.” Ekkor a jelentkezés folyamata során harmadszor hívom az ügyfélszolgálatot.. Azonnal felveszik, mondom mi a gond. 10 msp múlva már mondja is a srác, hogy minden rendben, jóváírták az összeget, hamarosan a felületen is ezt látom majd. Elköszön.
Leteszem, aztán elgondolkodok.. Nem is érdekelte, hogy hibás a fizetési rendszer.. Feltételezem az ügyfélkapus hitelesítésnél felugró tanúsítványablakokkal sem bírkózott meg mindenki, arról is tudnak.. és tudjátok mi van? Leszarják. Leszarják, mert na és? Mi van, ha nem megy.. max beadod papíron, vagy nem leszel jövőre egyetemista. Ez az ami baromira dühítő az egészben.. na meg az, hogy a főnökeik, meg az ő főnökeik is így gondolkoznak.
A cél egy integrált vitruális felhasználókat kezelő rendszer létrehozása volt IIS alá, ami független az IIS Manager Userektől és természetesen a Windows felhasználói fikókoktol is, ugyanakkor elérhető az IIS FTP, WebDAV és egyéb szolgáltatásaiból. A megoldás egyik alappillére a .Net Membership rendszere.
Az én megvalósításomban az adatbázis nem a megszokott Microsoft SQL, hanem MySQL. A telepítés kicsit macerás volt egy idegesítő hiba és a konfiguráció nüanszai miatt, ráadásul mivel nem vagyok .Net fejlesztő és VS-ből soha nem próbáltam ilyen kapcsolatot létrehozni, IIS-ből sem volt könnyebb.
Kapásból vakvágányra futottam, mert Google-ban keresgéltem, megszegve ezzel az MS fejlesztők és rendszergazdák elsőszámú szabályát: használd a Support weboldalakat, mert sz@runk a google-ra és nem hagyjuk, hogy a jó megoldásokat első oldalon hozza. Szal’ elkezdtem behackelni ezt a göncöt: http://www.codeproject.com/KB/database/mysqlmembershipprovider.aspx Már az SQL táblák létrehozása egy katasztrófa, hagyjuk is.
A jó megoldást a MySQL saját connectora jelenti: Connector/Net 6.2: Nem kell félni az MSI installertől, kiválóan működik.
A Connector mellé installálni kell a MySQL ODBC Drivert is. Töltsük le a MySQL oldaláról, majd telepítsük.
IIS Managerben elég bonyolult a sok kattintgatás, ezért inkább postolok egy helyes, jól működő web.config kódot:
<!-- Előbb eltávolítjuk az alapértelmezetteket, mert az IIS hiányolja őket és a sajátunk nem fog működni-->
<connectionStrings>
<remove name="LocalSqlServer" />
<remove name="LocalMySqlServer" />
<add name="LocalMySqlServer" connectionString="Datasource=localhost;Database=dbname;uid=username;pwd=password;" providerName="MySql.Data.MySqlClient" />
</connectionStrings>
<system.web>
<roleManager enabled="true" defaultProvider="MySQLRoleProvider">
<providers>
<clear />
<add name="MySQLRoleProvider" type="MySql.Web.Security.MySQLRoleProvider, MySql.Web, Version=6.0.3.0, Culture=neutral, PublicKeyToken=c5687fc88969c44d" connectionStringName="LocalMySqlServer" applicationName="LoginControl" />
</providers>
</roleManager>
<!-- autogenerateschema="true", ha nem kézzel akarjuk létrehozni a táblákat..-->
<membership defaultProvider="MySQLMembershipAppProvider">
<providers>
<clear />
<add name="MySQLMembershipAppProvider" type="MySql.Web.Security.MySQLMembershipProvider, MySql.Web, Version=6.0.3.0, Culture=neutral, PublicKeyToken=c5687fc88969c44d" autogenerateschema="true" connectionStringName="LocalMySqlServer" enablePasswordRetrieval="false" enablePasswordReset="true" requiresQuestionAndAnswer="false" applicationName="LoginControl" requiresUniqueEmail="true" passwordFormat="hashed" maxInvalidPasswordAttempts="7" minRequiredPasswordLength="7" minRequiredNonalphanumericCharacters="1" passwordAttemptWindow="10" passwordStrengthRegularExpression="" />
</providers>
</membership>
<compilation>
<assemblies>
<add assembly="MySql.Data, Version=6.0.3.0, Culture=neutral, PublicKeyToken=c5687fc88969c44d" />
</assemblies>
</compilation>
</system.web>
Jellegzetes hibalehetőségek, amikkel én is szívtam:
1. ODBC Dirver tényleg legyen rendben, akár teszteljük is, mielőtt bármit konfigurálnánk.
2. Ha az ODBC rendben, ne felejtsük a schema=”true”-t hozzáadni a MemberShip Providerhez, mert különben nem jönnek létre a szükséges táblák a MySQL adatbázisunkban.
3. Figyeljünk, hogy ne legyen hiba a connection stringben, nem szereti a jelszóban a különleges karaktereket.
Ha mindent jól csináltunk, az IIS Manager ASP.NET / .Net Users-be belépve egyrészt nem kapunk hibát, másrészt létrejönnek adatbázisunkban a szükséges táblák és akár meg is kezdhetjük a felhasználók feltöltését. Az IIS tökéletes felhasználókezelést nyújt, nemsokára posztolom az én Flexben készült “Fancy Remote” applikációmat, ami még fejlesztés alatt áll.
Most akkor mi legyen, tőzsdézzek?