andrisp

A kas notiek ?

if(logins_ir_korekts){include('table.php');} else { header("Location:login.php");}/ Šāds kods ir neoptimāls, jo rada vienu lieku indentācijas soli (kā arī plusā vēl vienu lielu nevajadzīgu kontrolstruktūras bloku). Protams, šinī rindiņā indentācija nav vispār, jo viss ir vienā līnijā. Kā arī iespējams, šajā konkrētajā kodā nekad nebūs vairāk par dažām koda rindām iekš if blocka. Tomēr ja rindas būs daudz, tad labāk šādi: if (logins_ir_koreks == false) { die(); } // daram lietinjas pa daudzaam ko da rindaam

Nu - nekompetenti admini nav PHP problēma. Par to substr. Vispār, ja nemaldos, tad PHP6 versijā substr un līdzīgās atbalstīts utf8 by default. Btw, MB modulis piedāvā vēl ļoti daudz dažādas funkcijas, tāpēc varbūt nebūtu bijis loģiski, ja, piem., substr pataisītu par mb draudzīgu, kas ņem vērā mb_internal_encoding() fju. Tāpēc arī visas MB funkcijas ir izdalītas atsevišķi. http://lv.php.net/mbstring

Nu - tāpēc, ka sākumā bija substr(), kas atbalsta tikai ASCII, bet pēc tam parādījās vajadzība multibyte enkodingu atbalsta. Tāpēc arī ieviesa jaunas funkcijas nevis aizvietoja vecās, lai nesalauzta eksistējošās aplikācijas. Es gan nezinu vai tas ir galvenais iemesls, bet varētu būt. :) Jaunības kļūdas. :) Tos taču var atslēgt (un jaunajās versijās defaultā tas jau ir atslēgts). Par nosaukumu nekonsistenci gan piekrītu.

Protams, to visu var.

Zandi, imo tas otrais urlis ir labāks par "parasto" urli.

Zandi, nu tā to sauc. Optimizācija nevienmēr nozīmē ātrdarbības uzlabošanu. Tas ir - ja tu to tā domāji.

Ai ai ai... http://www.w3schools.com/sql/default.asp http://www.w3schools.com/sql/sql_insert.asp

Jau jau tu nezini kā to vispār dara, tad kā tu vispār vari izteikt kaut kādas prognozes par to, cik tas daudz varētu aizņemt laika ? Lamāties gribas, mļin.

Pastāv arī iespēja to visu pārnest uz procedūru. Tas tā - ja nav pieejams mysqli modulis. Un vispār - vai tik nevarēja vienkārši sadalīt to visu pa kverijiem un izpildīt atsevišķi pēc kārtas ? Man liekas, ka otrajā kverijā būs piejams pirmajā kverijā uzsetotais mainīgais.

Relatīvi viegli iemācīties, plašs lietotāju skaits, plaša pieejamība uz hostingserveriem..

JS frameworki piedāvā tādas fiškas. Piemēram, jquery. PS. Un tie ir neatkarīgi no pārlūka.

Jā, domāju, ka tev derēs tās kolācijas. PS. kolācijas nevis koalīcijas.

Un nestēšana nenotiek ?

Diezgan mistiski. Problēma, man liekas, ir šeit: #leftpane, #rightpane { padding-bottom: 32767px !important; margin-bottom: -32767px !important; } Pamēģini atbrīvoties no tiem. (Pēc tam lai panāktu, ka kreisai kolonai ir melns fons, varēsi izmanto faux columns metodi. Šinī gadijumā ideāli darbosies).

Ko tu esi dzirdējis, ka tā dara ? md5 ? Kolāciju norādi utf8_general_ci vai utf8_latvian_ci. Tak to jau izrunājām. PS. "koalīcija" :]

utf8_general_ci noziimee, ka kaartoojot vai mekleejot, lv burti netiks gluzhi pareizi izmantoti, bet taa kaa tu teici, ka diezvai tie buus, tad taa nav probleema. Tev tie 20 simboli ir visiem varchar laukiem ne tikai username un pass. Paroli vispaar ieteiktu glabaat hash formaata - md5. Tad gan lauku vajadzees garaaku.

1. Tas ir drošībai (kinda). Un arī loģiski nebūt augšupielādēt vienu un to pašu failu divreiz. Btw, atceries, ka ar JS vispār type="file" vērtību nav iespējams mainīt. 2. Ar JS protams ;) var template = byid('sampe').cloneNode(true); template.getElementByTagName('input')[0].value = ''; // tālāk veic ievietošanu ar template.innerHTML. Šis gan strādās pareizi tikai tad, ja type="text" būs pirmais input elements.

Nu pag - nejauc reģistrāciju ar autorizāciju. Reģistrācijā gan vari prasīt visvisādus datus, bet autorizācijā vajadzētu pietikt ar username/password. Bet vispār - ja tu saki, ka tā ir iekšējā sistēma, tad no reģistrācijas ir maz jēgas. Tā pat nebūtu vēlama, varbūt. Par tabulām - neizmanto to ucs, tev viņu 99.9% nevajag. Izmanto utf8. Un nesauc tabulu par "tabulu". Izdomā reālu nosaukumu. Varchar(20) nebūs par īsu ?

Ja pašam ir pa spēkam, tad veido pats savu login skriptu, jo, godīgi sakot, tur nekā tāda nav. Ja zināšanu nav, tad gan vari ņemt gatavu (vai samaksā citam, kas uztaisīs tavā vietā). Pašam čakarējoties, visticamāk, uztaisīsi vēl caurāku nekā paņemot kādu gatavu. PS. Vispār jau pie autorizācijas vajadzētu pietikt ar username + pass bez vārds, uzvārds.

Tas byid() tev atgriež elementu pēc ID. Un tā kā tu viņu kopē, tad visi atribūti arī tiek nokopēti. Arī value.

millers, tāpēc, ka visticamāk atšķīrās PHP konfigurācijas. Iespējams, ka uz WinXP output_buffering bija On.

1) Domāju, ka labāk tev būs izmanto utf8 kolācijas nevis ucs2. Ja tajā glabāsies latviski dati pārsvarā, tad izmanto utf8_latvian_ci (CI nozīmē Case Insensitive). 2) Nu tas atkarīgs no tā kādi dati un cik tie var būt lieli. Ja tā ir cena, tad iesaku izmantot DECIMAL, ja vārds, uzvārds, tel. un līdzīgi - VARCHAR(*), bet konkrētais garumi ir ļoti atkarīgi no tā, kas īsti būs jāglabā šajos laukos. Ja tas var būt pagarāks teksts, tad TEXT. Ja tas noteikti būs vesels skaitlis, tad INT. 3) Nu - tu pārāk vispārīgi aprakstīji savu db, lai vispār kaut ko ieteiktu. Noteikti atceries izveidot tai otrai tabulai "id" lauku (Primary, INT, Autoincrement) pēc kā identificēsi katru ierakstu.

Explorer, var būt bija vērts izveidot jaunu topiku, nevis rakstīt neatbilstošā vecā. Vispār jau editoram ar ko raksta html/css ir maz sakara ar pārlūkiem, uz kuriem pēc tam šo html/css testēsi.

Explorer, tak ar pārlūku jebko var pamainīt (gan html, gan css, gan js, gan teorētiski arī jeb ko citu), ja ir gribēšana. Reāli, ja vajag, tad izmanto, tikai nevajag aizmirst arī server pusē uzlikt pārbaudi.