marcis

Ne gluži. if(!empty($_SESSION['valid']) && $_SESSION['valid']>=time()){ $_SESSION['valid']=time()+60*60*3; }else{ session_destroy(); }

Es īsti neredzu problēmu šajā piemērā. Iespējas dažādas (ja es sapratu problēmu, tad tu negribi visu laiku bakstīt $_GET masīvu?): 1) nodefinē klases mainīgo $this->augstums=$_GET['augstums'] 2) nodefinē mainītgo ārpus klases un funkcijā show() lieto global Es gan domāju, ka es nesapratu problēmu ;)

exec("zip ..."); :)

Tas jau laikam nebūs īpaši svarīgi, bet lai kods būtu smukāks/pārskatāmāks/etc vari šīs darbības iznest uz atsevišķu funkciju.

Burvis, tā nemaz nav tik superīga ideja. Ja nu tu sadomā kaut ko pamainīt autorizācijā? Ej nu maini tagad visus failus.

... $data=array(); while(...){ $q=... if(!array_key_exists($q,$data)){ $data[$q]=1; continue; } ++$data[$q]; } foreach($data as $q=>$c){ echo $q,' ',$c,'<br />'; }

xmp darbojas :)

Šeit problēma nebija brouzera cache, bet vispār šeit ir daži domugraudi par šo tēmu.

To jau laikam sauc par koda arhitektūru - ko un kur inklūdot, etc. Pareizāk darīt būtu tā, ka visu laist caur index.php, atvērto lapu identificē caru GET mainīgo, piemēram index.php?users vai index.php?clients, etc. Vispirms šajā index.php pārbaudi vai ir sesija un vai tā ir derīga, atkarībā no iznākuma, skaties, kādas darbības veikt tālāk - rādīt login lapu vai inklūdot attiecīgo failu. Runājot par inklūdojamajiem failiem - datubāzes konekts būs tikai index.php, bet šo failu apskatīt caur index.php būs iespējams tikai autorizējoties, itkā nekas slikts tāpat nenotiks, ja fails tiks atvērs "pa taisno". Vēl pastāv iespēja aizliegt šo failu apskati ar .htaccess

Nu tad jau problēma ir tikai koda arhitektūrā ;) Vispirms veic vajadzīgās izmaiņas datos un tikai tad selektē atjaunotos datus. Alternatīva varētu būt taisīt redirect'u, bet tas nederēs, ja dati tiek atjaunoti pie katras lapas ielādes reizes.

Par kādiem datiem tieši ir runa? Brouzera cache, tb css/js/attēli?

My bad, neiedziļinājos jautājuma tekstā. Tad jau gan paliek tikai paļauties uz brouzeri vai ik pa laikam taisīt ajax pieprasījumu un pieglabāt kaut kādus mainīgos servera pusē.

Ir brouzeri, kas parulē lapu uz pozīciju, kāda tā bija lapu atstājot, kad tik nospiesta back poga. Tādā gadījumā varētu izmantot javascript history.back(), bet, šķiet, ka nedara visi brouzeri, tātad šāds risinājums nederēs. Ok, es vienkārši skaļi domāju. Es domāju, ka labākais risinājums būtu izejošajiem linkiem piekabināt klāt kaut kādu GET mainīgo, kas identificēs, piemēram, tuvāko anchor enkuru. Piemērs, lapa1.php: <h2 id="virsraksts6">Virsraksts 6</h2> <a href="lapa2.php?pos=virsraksts6">Links</a> lapa2.php <a href="lapa1.php#<?=$_GET['pos'];?>">Atpakaļ</a> Labi, es ilgi rakstīju.

Zem windows norādot smtp datus. Šķiet, ka *nix māk izsūtīt tikai caur localhost, tas nozīmē, ka tev uz servera nepieciešams sendmail.

Man kaut kā šķiet, ka cīnīties ar spamojošiem klientiem vajadzētu savādāk, nevis vienkārši nogriezt smtp/sendmail. ini_set("SMTP","smtp.serveris"); ini_set("smtp_port",25);

Pēc teksta nopostēšanas caur prastu input'u ar php tu vairs nekādi neatradīsi nevienu word'a formatējumu, patiesībā tu viņu pazaudēsi brīdī, kad teksts tiks iekopēts input'ā.

Nesapratu, kas tev tur īsti notika, bet pieļauju domu, ka tu to krāsu mainīji neīstajam elementam.

$dst="e:/UPLOAD/katalogs/$folder".$_FILES["PDF"]["name"]; echo $dst; // paskatamies vai patiešām ceļš ir derīgs if(copy($_FILES["PDF"]["tmp_name"],$dst)){ ... } Ja display_errors ir izslēgts, tad slēdz vien iekšā :)

Nē, teorētiski, partīcija nekādi neietekmē datora/procesu darbību.

Nu atkarībā no vajadzības (etc), nav jēgas izmantot js tur, kur tas nav vajadzīgs. Protams, nezinu šī konkrētā gadījuma nianses. Lieku galdā alternatīvus variantus.

Elementa saturu ar css nesanāks samainīt. Vienīgi vari likt background-image un a:hover nomainīt background-position.

img + javascript + textarea

Šķiet, ka šajā arhīvā vajadzētu būs extension'iem.

pathinfo()

Cik nu man māte gūgle pastāstīja, tad darbība ir līdzīga kā ar sms. Sūtam mms uz tālruņa e-pastu (katram tālrunim ir savs e-pasts, to gan vairs neatceros, piemēram, [email protected]). Šāda e-pasta sintakse gan nav zināma (pieļauju, ka fails jāsūta base64 kodējumā), es, drošvien, nosūtītu mms no telefona uz savu e-pastu un noskaidrotu sintaksi.