Turecky

Tāds jautājums lielākiem profiņiem visā šajā sakarā. Vai nebūtu labāk, ja tos pieprasījumus rakstītu nevis kā PHP f-jas, bet visas tās f-jas ierakstam DB un izsaucam tad f-jas no DB.

Vēl laba lieta 5.3 versijā, ka beidzot normāli strādā MySQL izveidoto funkciju uzsaukšana, jo cik esmu mēģinājis vecajās versijās bija problēmas ar funkciju izsaukšanu, kas glabājās iekš DB, bet 5.3 versijā beidzot tas ir novērsts. Pats vienu brīdi cīnijos un nevarēju saprast, kapēc tās funkcijas nevar izsaukt, izrādījās, ka PHP gļuko, bet 5.3 versijā ir ok. Tik nedomāju, ka hostētāji pacentīsies uzlikt jauno versiju, jo tomēr patīkami, ja daļu MySQL funkcijas var iekš DB glabāt, tas man iepatikās, kad strādāju ar PL/SQL, bet katram jau savi prieciņi.

A tas ir pavisam elementāri, katrs no tiem browseriem interpretē pa savam, tā ka nāksies CSS uzrakstīt tādu, lai ietu uz abiem vienādi. Viens no piemēriem, ja veidojam vertikālo menuci, IE lai būtu koreti jānorāda rindas augstums, FF bez tā var iztikt, bet ja pievienos, tad abos būs vienādi. Tā ka nāksies pacīnīties, ja raksti savu CSS no nulles un gribi lai uz visiem browseriem strādā.

Nu ja detalizāciju ielasīsi bulkā, tad detalizāciju pievieno pēc nosaukumu salīdzināšanas. apmēram kas tāds sanāk: <?php if($produkts==$produkta_nosaukums_detalizācijā) { veicam insertu } else { izvadam kļūdu, vai arī liekam to masīvā un izvadam kad skripts ir izpildījies } ?> doma apmēram tāda varētu būt.

Vēl viens variants. Atkarībā no tā, kā tiek pievienota detalizācija produktam. Ja atveram produktu un spiežam pievienot detalizāciju, tad pirms tā var vienkārši veikt pārbaudi vai detalizācija jau ir pievienota, ja nav tad izvadām pievienošanas pogu vai formu, ja detalizācija ir, tad neizvadam. Ja detalizācijas formā norādām kādam produktam tiek pievienota datalizācija, tad veidojot sarakstu izslēdzam tos produktus, kam jau ir detalizācija pievienota un parādīsies tikai produkti, kam nav detalizācija. Tā pirmajā brīdī jau grūti ieteikt, jo ja nezin, kā tev tā sistēma darbojas, grūti ko konkrētu ieteikt. Tāpēc, ja būtu uzrakstījis aptuveno darbību variantu, kas un kur parādās un no kurienes uz kurieni jāsūta dati tad vieglāk būtu saprast.

Cik sapratu, tur runa par gataviem risinājumiem, bet man vairāk interesētu, ja tāds veikals tiek taisīts no nulles. Kāda tam varētu būt cena.

Ir šāda lapele: http://www.ecotoys.com.au/store/ Interesētu pieredzējušāku lietotāju domas, par to, cik tāda lapa varētu maksāt. Paskatoties cenas interneta veikaliem amplitūda ir pietiekami liela, tāpēc gribētu zināt vismaz zemāko robežu.

Problēma tāda, ka nepieciešamība būtu palaist interneta veikalu. Pašam ja godīgi slinkums no nulles taisīt, tāpēc varbūt kāds kas ir ar šīm CMS saskāries varbūt kādu labu bezmaksas interneta veikalu varētu ieteikt? Paldies par atsaucību! Piebilde: būtu vēlams tādu variantu, lai pasūtot preces nav jāreģistrējas.

Ja gribi, lai ierakstās datu bāzē visi linki, kas ir spiesti, tad paskaties, kā taisa vienkāršu HIT COUNTER, tad arī sapratīsi, kā to dabūt gatavu. Ja pareizi atceros, lai noteiktu, kāds skripts šobrīd strādā iekš PHP to varēja izdarīt ar $_SERVER['SCRIPT_NAME'].

Ar to sesijas ID var gadīties tā, ka tas tiek uzveidots tāds pats, tāpēc nepieciešams vēl kāds parametrs, kā, piemēram, IP adrese, ko būs pagrūti noemulēt, lai nozagtu sesiju un līdz ar to parastai mājas lapai ar tādu neviens neņemsies. Vienkārši nevaig aizmirst katru reizi pārbaudīt vai sesijas dati sakrīt un vai tie nav mainījušies. Pamanās jau vienmēr atrast caurumus drošības sistēmās, bet tas jau atkal cits stāsts.

Ar hakerēšanu nenodarbojos, tāpēc nevarēšu atbildēt tieši kā to izdarīt, var būt vienkārši nepareizi izteicos. Galvenā doma bija tāda, ka neskatoties uz to, ka lietotājs ir veiksmīgi ielogojies, kur tiek veikta pārbaude vai lietotājs eksistē, katru reizi, kad tiek pieprasīta lapa, kura ir pieejama tikai reģistrētiem lietotājiem, tomēr vajadzētu pārbaudīt vai tiešām tas ir reģistrēts lietotājs un vai viņa dati netika izmainīti. Savādāk tādā gadījumā nozogam sesiju un daram ar to lietotāju ko gribam. Man liekas, ka tomēr vajadzētu pārbaudīt vai sesijas ID nav mainījies, kā arī vai sesija turpinās no tās pašas IP adreses, jo šajā gadījumā ir vēl divi papildus mainīgie un tomēr IP uzturēt kā svešas lietotāja kompim nebūs vieglākais variants, tad arī drošība būs nedaudz lielāka. Bet par to IF runājot, kad man bija tā problēma beigās sapratu, ka neloģiski biju domājis, jo vispirms tomēr pārbaudam vai mainīgie ir, un ja ir, tad veicam darbības, bet ja neizpildās kāds no variantiem, tad beidzam sesiju, jo savādāk tiek pārbaudīti varianti ja datu nav, bet pēc būtības mums jau interesē vai dati ir, ja to nav tad visi kadījumi ir FALSE, bet tie daži, kas mums der, to ieliekam iekš IF. Nu re, nedaudz laikam atkārtojos, bet cerams, ka kādam manas domas arī palīdzēs, vismaz iesākumā.

Izteikšu arī savas domas, par to skriptu. Viss jau būtu ok, bet es darītu nedaudz savādāk. Vispirms pārbaudītu, vai sesijā mainīgie eksistē, ja eksistē, tad pārbaudām vai mainīgie ir valīdi, ja nav dzenam uz ELSE, ja ir tad izvadam lapas saturu, bet ja mainīgo nav, tad attiecīgi pirmajam IF paskrien garām uz trāpam uz ELSE, kas iztīra sesiju un pabeidz to. Jo tavā gadījumā, ja pieslēdzos un sesijā iebaroju kaut vau tukšus mainīgos tieku pie lapas satura, jo netiek veikta pārbaude vai sesijas dati ir valīdi, domāju, ka tāda pārbaude būtu noderīga. P.S. Vispār kad raksti skriptus ar IF, ELSE vispirms IFos saliec tos variantus, kad ir noteikti dati, bet pie ELSE ja datu nav vai citi gadījumu, jo gadījies, ka vispirms pārbaudam vai dati nav, un beidzam sesiju un pie els atļaujam darboties. Tādā gadījumā skripts nestrādāja kā paredzēts, bet ja saliek, ka pie IF pārbaudam vai dati ir, un ja ir tad vaicam pārējās darbībās, tad iekš ELSE iekrīt visi pārējie gadījumi. Cerams, ka mans skatījums kaut nedaudz palīdzēja!

Es piedāvātu variantu ar JavaScript pārbaudīt vai lauki ir aizpildīti. Doma tāda, ka, kamēr visi lauki nav aizpildīti, tikmēr SUBMIT poga ir neaktīva, kad aizpildam visus nepieciešamos laukus, tad arī SUBMIT pogu aktivizējas. Kaut kad ko līdzīgu taisīju, nekā pārgudra jau tur nav. Ja izgriežam visus liekos simbolus, vienalga pārbaude būs nepieciešama ar PHP, bet labāk nodrošināties un atstāt pēc iespējas mazāk caurumu.

Tur noteikti viņš parāda, kurā rindiņā jau tiek kaut kas izvadīts, jo ja pirms HEADER() ir kāds echo vai HTML tad tā arī būs, tāpēc novāc visas izvades pirms HEADER() un lieta aizies. Ja īsti nesanāk izdali kodu atsevišķā apstrādes failā. Kaut gan ja redzētu kodu un pilno kļūdu paziņojumu būtu vieglāk saprast, kas īsti par lietu.

Es ar ar šito lietu ilgi mocījos un beigās sanāca tāda lieta, ka pēc konekcijas pie MySQL un datu bāzes izvēles ieliku papildus rindiņu: mysql_query("SET NAMES utf8",$link);un tad ar latviešu mīkstinājumiem vair problēmu nebija. Es izmantoju SQLyog lai pa taisno piebarotu DB un vismaz jaunajās versijās ar LV zīmēm problēmu nav.

Ja pareizi sapratu, pēc koda izskatās, ja gadījumā $_GET["s"] nav vispār, tad pa taisno aizlido uz ELSE, jo tiek garām abiem IF un tad var iebarot jebkuru lietotāju un paroli. Nedomāju, ka to S parametru vispār vaig. Šobrīd slinkums rakstīt pašu kodu, bet es būtu darījis nedaudz savādāk. Ja nu jautājums joprojām aktuāls uzraksti, tad piedāvāšu savu variantu, ja ir interese.