Aleksejs

Skaties Foruma tēmu apkopojumā - pēc atslēgas vārdiem sadalīšana pa lapām.

Īsti paranojiķi jau pāriet uz ZTIC līdzīgiem risinājumiem: http://www.zurich.ibm.com/ztic/ ;)

Klez, Kaklz - vienkārši niki jums baigi līdzīgie - es arī pāris reizes esmu šitā uzrāvies :D

Sekot līdzi drošības jauninājumiem visām web aplikācijā iesaistītajām komponentēm. Pārbaudīt visus lietotāja ievadītos (no lietotāja nākošos) datus un neatbilstošu datu konstatēšanas gadījumā pārtraukt datu apstrādi. Veidot web aplikāciju balstoties uz pārbaudītām un labi izprastām tehnoloģijām un ievērojot labo praksi. Regulāri sekot līdzi auditācijas pierakstiem, ko veido web aplikācijā ietilpstošās komponentes. Regulāri veikt web aplikācijas komponenšu integritātes pārbaudes. Pamatlietas vari izlasīt, piemēram, šeit: http://www.owasp.org/index.php/Category:OWASP_Guide_Project

Nu, tālu no PS webā jau nav: http://aviary.com/ Jautājums tikai - vai vajag :)

Jā, tieši .zip lietošanu bez kompresijas arī biju domājis.

Nu gluži "up to date" saraksts laikam nebūs, taču šo to var uzzināt iekš: http://www.google.com/trends un arī: http://www.google.com/intl/en/press/zeitgeist/index.html

http://lv.php.net/manual/en/function.floatval.php

Mūzikas faili jau ir paši par sevi gana kompresēti, tādēļ faktiski to kompresoru vajag tikai tik daudz, lai apvienotu n failus vienā failā (kā to unixā dara tar programma) - līdz ar to, jau uzreiz vari uzlikt parametros "no compression", jo kompresija nekādu būtisku ieguvumu nedos, tā tikai nevajadzīgi noslogos procesoru un palēninās pašu nosūtīšanas procesu. Cita lieta, ja jāapvieno daudzi teksta faili (xmli utt) - tad gan ir vērts uzstādīt normālu kompresijas līmeni.

Nu, par CMS es šo lietu īsti nesauktu, bet nu nosaukumam un apzīmējumiem šajā jautājumā nav galvenā nozīme. ;) Tāpat kā jebkuras web-aplikācijas izveidošanā arī internetveikala gadījumā ir savi plusi izmantot jau gatavu risinājumu un savi plusi rakstīt pašam - tāpat ir arī mīnusi. :) Plusi gatavam: - risinājums jau ir un ir daudz vienkāršāk prognozēt izmaksas un termiņus, kad varēs sistēmu palaist, jo taisīt atliek tikai dizainu un izkārtojumu - risinājumu veidojot izstrādātāji jau ir paspējuši uzkāpt uz daudziem grābekļiem un novērst/mazināt atkārtotas uzkāpšanas iespējas - risinājumam ir pieejams atbalsts (gan maksas, gan arī bieži vien bezmaksas) un dokumentācija un cilvēki, kas pārzina šo risinājumu - risinājumam ir pieejami dažādi gatavi moduļi (gan maksas, gan bezmaksas), kas ļauj, piemēram, pielikt iespēju norēķināties ar PayPal (vai ar kredītkartēm) - risinājumiem ir pieejami atjaunojumi un labojumi Mīnusi gatavam: - visi universālie risinājumi parasti ir smagnējāki un lēnāki salīdzinot ar optimāli uztaisītu custom risinājumu - ir jāpieņem risinājumā izmantotā ideoloģija - ja gribēsi uztaisīt kaut ko, kas nav paredzēts, var nākties ieguldīt paprāvus resursus izpētē un pielāgošanā - ir jāiegulda resursi risinājuma apgūšanai (jāiemācās konkrētajā risinājumā izmantotās klases/funkcijas/metodes/objekti utt) - bieži vien izskata un dizaina variācijas ir ierobežotas - ja tiek veiktas kādas īpašas izmaiņas, tad kā papildus atbildība jāuzņemas to darboties spējas saglabāšana nākamajās risinājuma versijās Plusi paštaisītam: - visas iespējas (jāmāk tikai izmantot) izveidot optimālu un ātru aplikāciju - iespēja dizainu, izkārtojumu un pašu biznesa loģiku izveidot tieši tādu, kāda nepieciešama pasūtītājam un nevis meklēt kompromisus starp to, ko piedāvā gatavais risinājums un to, ko vajag pasūtītājam - pilna kontrole pār izejas kodu un (ja jau pats veido) pilnīga sapratne par to kas , kur un kāpēc notiek. Mīnusi paštaisītam: - pastāv liela iespēja, ka pietrūkst kompetences/zināšanu/pieredzes, lai risinātu projektā radušos tehniskos/biznesa uzdevumus (kā piemēram, šobrīd par PayPal pielikšanu), kas var prasīt papildus resursus - mazs cilvēku skaits, kas spēj orientēties izstrādātajā kodā (šī problēma ir īpaši aktuāla pasūtītājam) - "divriteņa izgudrošanas" sindroms - var gadīties, ka neparedzi/neieraugi kādu grābekli uz kura pēc tam sanāk uzkāpt - e-komercijas gadījumā sekas var būt graujošas. Tas ir tas, kas pirmajā brīdī nāk galvā. Ko varu ieteikt no gataviem? Pats neesmu [pagaidām] piedalījies e-veikalu projektos, taču ieteiktu izvēlēties tādu, kurš piedāvā vismaz nepieciešamos maksājumu moduļus (droši vien, ka bez PayPal vajag vēl kādu). Kā arī papētīt to, cik laba dokumentācija un cik aktīva community. Norādes uz dažādiem e-veikaliem ir apkopotas arī šeit: http://php.lv/f/index.php?showtopic=10276

Ja pats taisi to veikalu, tad ķeries pie paša PayPala dokumentācijas lasīšanas: https://cms.paypal.com/us/cgi-bin/?cmd=_ren...veloper/home_US Ja izmanto kādu no gataviem internetveikalu skriptiem, tad tiem visticamāk šī lieta jau ir uztaisīta un (iesp[ējams par papildmaksu) dabūjama.

Vai varētu pēdējo teikumu noformulēt izvērstāk? Varbūt kādu bildi parādīšanai, kā būtu jāizskatās. Es nesapratu, kas nepieciešams arī pēc otrā skaidrojuma.

Hmm... Kad liec permissionus nospied advanced un uzliec, lai visi faili un apakšmapes visu manto no šīs mapes tiesībām.

Nu... Būtībā... Pieņemsim, ka visus ierakstus (ne no datubāzes, protams) esi ielasījis kaut kur... Piemēram, masīvā $ieraksti. Tālāk līdzīgi kā datu bāzes gadījumā. $no_kura_ieraksta = $_GET['no']; $cik_daudz_ierakstus = $_GET['cik']; for($x = max(0,min($no_kura_ieraksta,sizeof($ieraksti));$x++;$x<min($no_kura_ieraksta+$cik_daudz_ierakstus,sizeof($ieraksti))){ echo $ieraksti[$x]; } if($no_kura_ieraksta > 0){ //te izvada <a href=... uz iepriekšējo lapu } if($_no_kura_ieraksta + $cik_daudz_ierakstus < sizeof($ieraksti)){ //te izvada <a href=... uz nākošo lapu }

Viens variants ir dinamiski ģenerēt lauku nosaukumus: Piemēram: <input name="username_20090511233778"/> Ir vēl arī parametrs autocomplete, taču nezinu vai visi pārlūki to ņem vērā: <input name="username"autocomplete="off"/> Upps ne gluži: https://developer.mozilla.org/en/How_to_Tur...pletion_Feature

Hmm... Tātad, ja pareizi saprotu - skripts korekti pārvieto ar move_uploaded_file() failu uz vajadzīgo mapi, taču vienīgā problēma, ka pārvietotajiem failiem ir nepareizas piekļuves tiesības? Tādā gadījumā, man šķiet, Tev ir jāuzliek mapei ./images/users tiesības ar Windows līdzekļiem tā, lai lietotājam ar kura privilēģijām darbojas webserveris, būtu vismaz "List folder contents" un "Read" tiesības uz šo mapi. Kā arī Read tiesības (un arī Write un Modify, ja jāmaina/jādzēš tās bildes) uz tajā veidotajiem objektiem. chmod() attiecas tikai uz Unix.

Kādā veidā Tu pārvieto uploadoto failu? parādi koda fragmentu, kas no temp uploada direktorijas pārvieto uz kādu pieejamāku vietu.

Ļoti apsveicami, ka šādi paziņojat par sludinājuma aktualitātes izmaiņām.

Domāju, ka lietderīgāk šo jautājumu ir uzdot cilvēkam personīgi ;)

dod arā CSV failu, ja nav nepieciešamas noformējums. To excelis māk atvērt.

Daļēji ir iespējams tad, ja atrodies vienā subnetā ar saņēmējwebserveri (tobiš pa vidu nav routera) un brīvi spēj mainīt sūtītājserverim IP adresi. Vēl variants izmantot dažādus proxy, caur kuriem sūtīt. Bet vispārējā gadījumā - nē, Tu nevari brīvi mainīt nosūtītāja IP adresi. Ja Tu pāradresē tālāk, tad ieteiktu padot vai nu caur headeri (kā to dara visi proxy) X_FORWARDED_FOR vai arī vienkārši kā GET/POST mainīgo, kuru tad saņēmēja galā apstrādā.

Ja nesakrita mapju nosaukumi, tad noteikti tas varēja būt iemesls, kādēļ kaut kas nedarbojās. Par PDO - paskaties php.ini failā, vai tiešām nav atkomentēts, ka tādu vajag.

Nu, labi, pieņemsim, ka Tev tiešām absolūti ir nepieciešama tā alfa. Tas, kā jākompilē ir aprakstīts te: http://www.php.net/manual/en/mysqli.installation.php Taču varbūt, ka Tev der šeit esošais: http://osdir.com/ml/php.phpmyadmin.devel/2...0/msg00074.html

Īsumā: My guess would be that your mysqli extension is compiled using the old PHP version - if you have to use alpha, then either compile mysqli extension using the new alpha, or find already comiled mysqli extension that works with the alpha version.

Nu tas, ka affiliate man arī puslīdz ir skaidrs. Bet vai man arī būs kāds bonuss no tā, ka reģistrējos caur šo saiti un nevis pa taisno - tāds lūk jautājums. :)