Probleme cu site-ul Pontes

[Campus]

Datorita unor probleme interne ale firmei imperialiste ce ne gazduieste site-ul , astazi, 29 03 2010 intre orele 17 si ceva - 19 si ceva site-ul Pontes nu a functionat. Problema apare de la programul php al serverului care nu recunoaste printre altele functia date_default_timezone_set() functie prin care defineam fusul orar in interiorul scripturilor. Pana la remedierea problemelor la hostgator am dezactivat aceasta functie in asistenta it si in biblioteca. Ca urmare programul asistenta it si datele pentru operatiunile din biblioteca din ultimele ore nu sunt afisate corect Exista posibilitatea sa apara si alte probleme in urmatoarea perioada de timp deoarece se pare ca problema este mai extinsa la hostgator.
In masura in care forumul va functiona, puteti semnala aici orice problema legata de afisarea paginilor site-ului Pontes
Toate cele bune
Campus

[Campus]

Pana la urma problemele s-au rezolvat. Se pare ca intr-un fisier htaccess era setat ca program php implicit php4 iar o serie de functii mai noi folosite de mine nu fusesera inca inventate in acea versiune a programului. Este posibil ca aceasta eroare sa fi generat deasemenea intreruperi frecvente la fonoteca. De asemenea a mai afectat temporar harta transportului in comun si scriptul de sarade. Totodata datorita desetarii temporare a fusului orar lista descarcarilor din biblioteca pentru ziua de astazi partial nu este corecta in privinta orei
Toate problemele s-au rezolvat prin editarea fisierului htaccess.
Pe de alta parte sunt foarte multumit de suportul oferit de imperialistii de la hostgator la care gazduim site-ul. In 4 ore am schimbat vreo 8 mailuri ceea ce la o firma din romania s-ar intampla cam intr-o saptamana jumate. Inca mai am unele amintiri urate legate de raspunsurile celor de la romarg cand ii intrebam de ce se incarca greu site-ul!!!
Toate cele bune!
Campus

[Manu]

Ai vazut ca si problema setarii limitei de upload de care s-a izbit biblioteca a fost rezolvata cu promptitudine de serviciul de asistenta de la Hostgator, imediat au pus toate sugestiile la dispozitie, clar si la obiect, astfel incat ai putut rezolva ok problema din php.ini.
Acolo nu merge sa raspunda aiurea, fiecare raspuns il noteaza clientul cu o nota de la 1 la 10, iar in functie de asta i se masoara competenta angajatului respectiv.
Unde pui ca aici in Romania, ori in general in Europa, nu gasesti o gazduire ca lumea, decat foarte scumpa cu care nu am putea face nimic. De exemplu pentru 3 giga, am plati vreo 20 de euro, cel putin asa era inainte. La hostgator avem doar cu 10 dolari spatiu nelimitat, astfel incat ne permitem o fonoteca, o biblioteca etc. Degeaba, americanii stiu sa vanda cu mult succes ceva ce nu trebuie extras din sol sau obtinut cu bratele.

[Paul11]

nu reusesc sa deschid niciun test din sectiunea rezolvati teste online cu tasta enter si cand apas tasta aplicati imi apar optiunile:inspecteaza elementul inapoi si inainte indisponibil

[Manu]

Voi arunca o privire.

[IonPop]

Eu am incercat sa caut pe forum, dar am primit urmatoarea eroare:


Eroare generala



Could not obtain matched posts list

DEBUG MODE

SQL Error : 1146 Table 'ldvcluj2_phpbb1.forum_search_wordmatch' doesn't exist

SELECT m.post_id FROM forum_search_wordlist w, forum_search_wordmatch m WHERE w.word_text LIKE 'pontes' AND m.word_id = w.word_id AND w.word_common <> 1

Line : 340
File : search.php

[Manu]

Am dezactivat căutarea atunci când au fost probleme. Am golit tabelul acela imens care se tot extindea, în care se tot băgau cuvintele dintr-un post câte unul per înregistrare.
Nu ştiu acum dacă ar fi bine să decomentez codul, să înceapă iar să creeze tabelul. Atunci am primit avertisment şi ne-a limitat pentru că erau foarte multe query-uri "INSERT INTO" într-o buclă.

[IonPop]

Fara sa vad codul, iata ce inteleg eu din acea eroare:

"Could not obtain matched posts list".

Presupun ca la adaugarea unui comentariu, phpBB imparte textul in cuvinte si le introduce rand pe rand intr-un tabel, in care va cauta cand cineva va folosi functia de cautare a forumului.
Daca nu gaseste cuvinte in acel tabel, probabil ca nu va returna oricum niciun rezultat, asa ca acele cuvinte trebuie introduse acolo.

"SQL Error : 1146 Table 'ldvcluj2_phpbb1.forum_search_wordmatch' doesn't exist".

Aceasta este eroarea principala, si nu inteleg de ce acel tabel nu exista. Probabil ca chiar daca ar fi fost gol, ar fi trebuit sa existe.

Dupa cate mai tin minte, spuneai ca administratorii serverului au limitat accesul pentru ca se introduceau foarte multe cuvinte intr-o bucla, ceea ce in mod normal este o imputare ciudata, de parca nu ar fi ceva normal. Nu cred sa fie o problema ca baza de date era prea mare, insa presupun ca acele introduceri repetate generau o suprautilizare a procesorului, iar asta este o problema cand se foloseste un server partajat de mai multi.
Cred ca o solutie ar fi fost sa introduci o mica pauza in acea bucla, de exemplu cu usleep(50000) ca sa dureze putin mai mult introducerea cuvintelor in acel tabel si sa nu ocupe prea mult din procesor dintr-o data si administratorilor sa le apara o suprautilizare a procesorului la un moment dat.

Nu cred ca a ajutat stergerea inregistrarilor din acel tabel atat timp cat problema era legata de faptul ca se adaugau prea multe, si nu ca spatiul ocupat de baza de date era prea mare.
Din cauza asta, in caz ca phpBB nu ofera o facilitate de re-creare a acelui tabel de indexare pentru cautare, valoarea forumului s-a redus foarte mult, pana la un nivel de simplu chat fara istoric, fiindca nu se mai poate gasi o informatie discutata despre un anumit domeniu pe el.

Singura speranta este ca Google a indexat in timp paginile web si ca putem cauta acolo cu site:pontes.ro, insa cine stie daca a indexat chiar toate postarile...

[Manu]

Sigur există tabelul, dar poate variabila care îi ţine numele este goală. Mă voi ocupa şi voi reactiva căutarea punând un sleep() pe acolo.

[IonPop]

OK, mersi!
Ma gândesc ca mesajele introduse de la momentul dezactivarii nu vor fi insa indexate si deci nu vor fi gasite.
Oare phpBB are o modalitate de re-indexare a lor, care sa preia cuvintele si sa le introduca in acel tabel?

[Campus]

Cred ca in cel mai rau caz mi-as putea bate capul eu sa fac un patch cu cautare simpla daca reusesc sa vad modalitatea de afisare a rezultatelor
Pentru cautarea in sql nu e nevoie de tabel separat cu cuvinte, de aceea nu inteleg de ce are nevoie phpbb de un tabel separat. O fi pentru cresterea vitezei dar eu nu inteleg utilitatea mecanismului.

[IonPop]

In formularul de cautare apare mesajul
"Puteti folosi AND pentru a defini cuvintele ce trebuie sa fie in rezultate, OR pentru a defini cuvintele care pot sa fie in rezultat, si NOT pentru a defini cuvintele care nu trebuie sa fie in rezultate. Se poate utiliza * pentru parti de cuvinte."

Asta inseamna ca phpBB permite o cautare de tip fulltext, iar asta nu ar putea fi oferita cu o cautare simpla cu like/rlike, ci este nevoie de o indexare fulltext.
MySQL ofera posibilitatea crearii unui index fulltext, care sigur este mai rapid decat solutia phpBB, fiindca e in C, nu in PHP, asa ca si eu m-am intrebat de ce oare phpBB foloseste acel tabel cu cuvinte.
Cred totusi ca cei care au creat phpBB au avut probabil unele motive. Ma gandesc ca poate solutia lor functioneaza mai corect decat cautarea MySQL fulltext atunci cand textul mesajelor contine caractere cu diacritice sau alte caractere care nu exista in limba engleza, iar ei au vrut sa il faca sa ruleze bine indiferent de limba in care se discuta pe forum. Sau cine stie ce alte motive, dar sigur au existat ceva motive.
In cazul forumului Pontes nu cred ca asta ar fi o problema, asa ca daca codul sursa ar fi destul de clar, probabil ca ai putea face o astfel de modificare.

In principiu ar trebui adaugat un fulltext index la campul care contine mesajele, iar apoi modificata comanda SQL care face cautarea, ca sa foloseasca match/against, si atunci nu ar mai fi nevoie de acel tabel de indexare, iar codul care adauga in el ar putea ramane comentat.
Nu am mai folosit de multi ani MySQL fulltext search, dar tin minte ca pentru a putea oferi posibilitatea de a cauta cu diversi operatori ca "OR" sau expressi intre ghilimele sau cuvinte partiale si alte facilitati, trebuia sa folosesc in primul rand "in boolean mode", iar apoi pentru ca rezultatele returnate sa fie ordonate dupa relevanta trebuia sa folosesc match(...) against(...) as rank si ca coloana cautata, ca sa pot apoi sorta dupa campul rank, cat si ca conditie dupa "where" ... ca sa fie returnate doar inregistrarile relevante. Acum este posibil ca rezultatele sa fie returnate in ordinea relevantei si daca se foloseste "in boolean mode", asa ca ar fi nevoie de match/against doar ca conditie de cautare.

[Manu]

Cred că majoritatea forumurilor folosesc acest tip de căutare fulltext, într-adevăr e ușor să faci orice dacă ai fiecare cuvânt dintr-un post în câte o înregistrare în tabel MySQL cu ID-ul postului care îl conţine. Totuşi, o căutare de care zice campus ar fi mai ok, nu ar mai crea tabele de zeci de mega. Nu cred că au ăştia ceva pentru diacritice, rezultatele returnate erau stric pe ceea ce s-a scris.
S-ar putea face un sistem de căutare absolut independent de forum, pur şi simplu o pagină care să aibă legătură cu tabelul cu mesajele, iar acolo să fie create link-uri către topicurile găsite şi eventual un mic rezumat extras din post-ul în care a fost găsit string-ul. O eficientizare cu fulltext... se poate face eventual tot acolo.
O soluţie ar mai fi ca tabelul cu mesaje să fie dublat de unul în care să se elimine diacriticele, iar căutările să fie şi ele filtrate înlocuind diacriticele, aşa ar fi sigur că s-ar găsi ceva indiferent de cum a fost scris mesajul sau de cum este completat câmpul de căutăre.
Link-ul căutare de la începutul forumului să ducă atunci către această căutare independentă. Tabelul cu mesaje fără diacritice ar putea fi recreat sau completat din când în când, să zicem la începutul unei zile.

[IonPop]

Sistemul de cautare phpBB este de fapt un semi-fulltext, fiindca nu ofera facilitatile oferite de un index fulltext cum este cel al MySQL sau altele mai puternice. Este insa flexibil si nu depinde de setarile MySQL.
O cautare simpla ar putea fi prea lenta, mai ales daca se cauta mai multe cuvinte.
Daca nu sunt multe inregistrari in baza de date, atunci ar putea fi OK.
Ar oferi insa putine facilitati de cautare. Dar nu este asta o prioritate acum. Tot ar fi mai bine decat nicio posibilitate de cautare.
Ar fi insa ineficienta fiindca ar verifica cu like/rlike fiecare inregistrare pentru fiecare cuvant cautat in parte, si asta ar face sa foloseasca mult din timpul procesorului si ar putea aparea din nou avertismente din partea administratorilor serverului.
Cautarea fulltext ar fi mult mai eficienta, mai rapida, ar oferi mult mai multe facilitati de cautare, ar oferi si posibilitatea ordonarii rezultatelor in functie de relevanta, nici nu ar fi cu mult mai greu de implementat, fiindca pe langa modificarea comenzii SQL pentru cautare, ar trebui doar creat un fulltext index, lucru care se poate face cu o simpla comanda, iar apoi fiecare nou mesaj introdus in tabel va fi indexat automat.
Problema este ca o cautare cu un index fulltext in MySQL are anumite limitari, cum ar fi de exemplu ca nu se pot gasi cuvinte mai scurte de 4 caractere. Pentru a modifica asta trebuie modificate anumite setari ale MySQL si nu stiu daca aveti drepturile de acces necesare. Plus ca nu stiu daca merita efortul.
In ambele cazuri, adica cautare simpla si fulltext, ar putea fi nevoie sa se caute intr-o tabela duplicat, in care mesajele sa fie scrise fara diacritice. Cautarea fulltext ar putea sa gaseasca si cuvintele scrise cu diacritice cand sunt cautate fara diacritice, insa nu sunt sigur ca MySQL fulltext poate face asta, sau am vazut facilitatea asta in alt sistem de cautare. Se poate insa testa creand un fulltext index pe tabelul principal cu mesaje, iar daca nu se gasesc inregistrarile cu diacritice si cand sunt cautate fara diacritice, se poate crea un tabel duplicat si indexul fulltext in el.
Cu alte cuvinte, toate solutiile au si dezavantaje.
Ca ar mai fi si alte solutii, si mai rapide, si cu mai multe facilitati, dar si mai dificil de implementat, si alea chiar nu merita.

[Paul11]

Am o problema cand dau confirma pe unul dintre testele din subsectiunea rezolvati teste online primesc aceasta eroare :
Fatal error: Call to undefined function import_request_variables() in /home3/ldvcluj2/public_html/pontes/ro/divertisment/teste/jaws1/quiz.php on line 89