Weblabor

Ilyen konstrukciót még nem láttam, <input type="submit"> elemet leginkább űrlapokba szoktak tenni.

Megnyitod a konzolt (ugye mindig nyitva van fejlesztés közben?), az én Chrome-omban ez F12. Kicsit kattintgatsz és elő fog jönni.



Ha jól látom a headben van egy inline js snippet, ami jQuery-t akar használni, ami ott még nem áll rendelkezésre.

Akkor a megjelenítéssel nem mondtam újat, valóban nem az erősséged :). Némi tanulással és igényességgel azért a problémák jó része orvosolható. A style attribútumokat eltünteted, a nem létező CSS definíciókat (pl. float: center) kitörlöd, megnézed a diven kívül milyen HTML tagek vannak és hogy kell használni őket, aztán egyszer csak kijön belőle valami.

Értem. Szerintem az, hogy eltűnt a szöveg a közösségi oldalakról, az azért van, mert az felhasználók többségének nincs ideje/nem szeret sok időt olvasással eltölteni. Van az amondás is, hogy "Egy kép többet, mint 1000 szó" (vagy valami hasonló), magamból indulok ki, én is ebbe a rétegbe sorolnám magam. Ha csak abból indulok ki, hogy ha 9gag-en böngészek, és ha van egy post, ami legalább 2-3 hosszabb szövegbuborékot tartalmaz, akkor pörgetem is tovább.



Jól értem tehát, hogy az oldal értéke nem az olvasásban, hanem a megosztásban rejlik? Ha ez így van, akkor miért nem inkább a megosztás részét tesztelitek az oldalnak, mintsem azt, hogy hogyan lehet olvasni egy cikket? Hogy értsd mire gondolok, ha a tartalom megosztó felhasználó réteg a célközönség, akkor inkább létrehoznék egy/több demo felhasználót (csak azért, hogy ne kelljen regisztrálni), és arról gyűjtenék visszajelzést, hogy milyen a tartalom megosztás folyamat; természetesen a megosztott tartalmat olvasni is kell...

Egyébként tanulmányok készültek erre, hogy a felhasználók mit szeretnek olvasni, és az lett általában az eredmény, hogy a sok szöveg akkor kerül hatékony felhasználásra, hogy sokszor megtörik a tartalom látványos képekkel, így rövidebb blokkokat tud a felhasználó is olvasni, nem beszélve arról, hogy több időt tölt az oldalon.

Költséghatékonyabbnak látnám a helyetekben egyébként, ha nem egyből egy komplett rendszert adnátok ki tesztelésre, hanem statikus HTML oldalakat, amiből kiderül, hogy UX szempontból rendben van-e és ha igen, akkor a visszajelzések alapján érdemes lefejleszteni a háttér megoldásokat.

Másik fontos dolog a mérés: használtok valami eszközt? Pl, Google Analytics, Mixpanel? Rengeteg hasznos visszajelzés érkezik a statisztikákból, és világosan látszik, hogy melyik részét érdemes erősíteni a rendszernek.

"angol a böngésződ" - szerintem meg chrome, de szólj ha tévedek. :)
Nincsen "ha beütsz..." , ha ez ha az. Nem magyarázunk diplomát. Véleményt kértél és kaptál, használd fel.

Ha nincs időd, nem kell "reagálni" mindenre. Amúgy sem reagálni kell, hanem inkább javítani a hibákat, amik kiderülnek.

Hát ebből az jön le, hogy inkább szereted megmagyarázni, hogy miért mégis jó az ami sz..., nem szeretsz javítani rajta. :(
Ez gáz, így nem lesz látogatód, csak véletlenül.
Ha változik ez a hozzáállás, akkor jelezd, mert itt is írtál pár dolgot, ami tévedés. Erről akkor van értelme beszélni, ha el is gondolkodsz azokon, amit mondunk.
Pl menü nem tűnik el se fb-n, se YouTube on... Erről az oldalról nem tudtam a főoldalra navigálni, csak az url kézi módosításával...

"s csak 12 sql tábla. sqlre figyeltünk, hogy minél egyszerűbb legyen."
Egy ilyen jellegű tartalom kezelőnek nem sok 50 tábla sem, nem lesz ettől egyszerű az SQL. Természetesen egy ilyet jól megtervezni nem tud mindenki.
Érdemes az első ilyen próbálkozás előtt tanulmányozni nyílt forrású cms-ek forrását és adatbázisát. Én anno a Drupal ból rengeteget tanultam, a comment order by t csaknem lekoppintva. (Kicsivel egyszerűbben, mert nem kellett minden tudása, csak az olyan fa struktúra, amit itt is látsz.)
Szóval ebből a két mondatodból ítélve sanszos, hogy minél előbb egy új tervezés, okos db és pl egy normálisabb fw kell.

Nem kell nagy dologra gondolni, első nekifutásnak elég lenne - és már nagy segítség lenne - ha az olyan helyeken, ahol tényleg előfordulhat valami hiba (pl egy adatbázis lekérdezés esetében), ott kimented egy fájlba, hogy mikor mi történt és milyen paraméterekkel.

Érkezett itt jónéhány hibajelentés rossz adatbázis resultról. Ha tárolod valahol az összes lekérdezést, akkor nem azt kell megfejtened, hogy pontosan milyen query nem futott le, hanem a tudsz arra koncentrálni, hogy egy exact query MIÉRT nem futott le.

Létezik sok megoldás:
- Csinálhatsz saját loggert 1000000 féle képpen
- Használsz valamiféle logger webservice-t
- Használsz valami olyan libet, amit már más elkészített, és sokan használnak, pl.: https://github.com/katzgrau/KLogger

Én mindenkép az utóbbit javaslom.

Hogy mikor loggolj... háát... kinek mi az infó, DE runtime errorokat mindenkép érdemes logolni, és a hiba keletkezése előtt is.

pl.:+ Az Exception-ök kezelését is érdemes megnézni, bár nem tudom mennyire objektum orientált módon fejlesztettetek; a PHP exception-ök elkapásához nem kell feltétlenül OO alapú implementáció, de hosszú távon azzal jársz jól.

+ Hosszútávon és egy kicsit visszakanyarodva a lekérdezésekhez és az rendszer egészéhez: A mysql_* függvények rövidesen a múlté lesznek, van helyette mysqli_* függvénytár, viszont ennél is jobb a PDO. Érdemes azt használni, rugalmas, és tehermentesít; ennél feljebb már csak az ORM-mek vannak, pl Doctrine, de szerintem ne rohanjunk előre. Másrészről egy tipikusan olyan rendszert készítetek, amit PHP-s keretrendszerek hada ki tud szolgálni - ha használsz valamit, akkor a következő mondatot vedd semmisnek - (Laravel, CakePHP, Symfony, Yii, stb.), amik egyébként olyan problémákat oldanak meg, amibe tuti, hogy már 1000-szer belefutottatok, és bele is fogtok futni. Nem beszélve arról, hogy mindegyik hasonló framework full objektum orientált, ami könnyíti a hibakezelést, az egységbezárást, egyszerűbb bennük hibát keresni, van mögöttük közösség, folyamatosan fejlesztik őket, és talán már mindegyik használja a composer nevű csomagkezelőt, ami szintén segíti a project karbantartását. A verziókezelést nem említettem még, ami fontos egy ilyen project életében; ha nem verziókezeltek még, akkor személy szerint a GIT-et ajánlom, BitBucket-en lehet csinálni ingyenes privát repokat is. Érdemes megnézni néhány tutorialt, hogy egy hasonló project miként lesz karbantartható minden irányból; ezek a dolgok, amiket felsoroltam eleinte nem biztos, hogy megkönnyítik a munkát, viszont gyorsan bele lehet rázódni, és mindent a rózsaszín köd fog körülölelni.