Valcha

Pirms dažām dienām nosūtīju newsletter ziņu uz ~ 1200 e-pastiem. Izmantoju hostinga e-pasta servisu, bet izsūtītāja epasts bija mans inbox.lv pasts... Vai nepastāv risks, ka mans e-pasts nonāk spamlistēs? Domāju - gala adresāta e-pasta serveris, piemēram, gmail.com, ierauga, ka uz viņam piederošām 400 adresēm pienāk gandrīz vienāda kontenta saturs minūtes laikā un nolemj - pieteik, valcha, būsi nu melnajā sarakstā? Kāda ir jūsu pieredze, veidojot newsleeter apziņošanu?

Kāds jau ir paciemojies šajā hostingā? Neatrodu nekādas atsauksmes. Interesē, lai pēkšņi neaizver lapu, nedzēš datubāzes utt.

marrtin, bet kā tad man tas sessija variablis $_SESSION['started'] būs pieejams, ja sessija pēc ~ 50 minūtēm dzēšas? Varbūt vakars un labi nedomājas.. :) Man kaut kā izskatās, ka velk uz sessijas glabāšanu datubāzē. Vai tiešām nav variantu, kā vienkārši ar php iebūvētām funkcijām panākt 24h ilgu sessiju?

Pievienoju jaunu session path: ini_set('session.gc_maxlifetime', 3); ini_set('session.gc_probability', 1); ini_set('session.gc_divisor', 1); ini_set ('session.save_path', 'c:\session'); session_start(); $_SESSION['cnt'] = isset ($_SESSION['cnt']) ? $_SESSION['cnt']+1 : 0; print_R ($_SESSION); Iztīru, protams, arī cookies, bet tāpat vecā dziesma. Jaunajā direktorijā sessijas fails rakstās, bet neko... Pozitīva skripta iznākuma gadījumā būtu jābūt, ka session['cnt'] = 0, ja 3 sekundes ir neaktīvs... - - - Directive Local Value Master Value session.auto_start Off Off session.bug_compat_42 Off Off session.bug_compat_warn On On session.cache_expire 180 180 session.cache_limiter nocache nocache session.cookie_domain no value no value session.cookie_httponly Off Off session.cookie_lifetime 0 0 session.cookie_path / / session.cookie_secure Off Off session.entropy_file no value no value session.entropy_length 0 0 session.gc_divisor 1 1000 session.gc_maxlifetime 3 1440 session.gc_probability 1 1 session.hash_bits_per_character 5 5 session.hash_function 0 0 session.name PHPSESSID PHPSESSID session.referer_check no value no value session.save_handler files files session.save_path c:\session no value session.serialize_handler php php session.use_cookies On On session.use_only_cookies On On session.use_trans_sid 0 0

Man šī problēma ir uz visiem pārlūkiem bez izņēmuma! Mēģināju arī uzinstalēt Opera pārlūku, kas agrāk nebija - tā pati problēma. Tiešām nedomāju, ka browsera problēma... Bet paldies par ideju!

Būtiba - vēlos, lai sesijas dati nepazustu 24 stundu garumā. Pašlaik ir tā, ka sesija pazūd un pārģenerējas sessijas id, ja taimauts ir mazliet zem 60 minūtēm. Esmu pārlasījis pusi gogles, risinājumu nerodu. Nedarbojas ne uz Win, ne uz Linux. PHP versija 5. Pēc būtības vajadzētu iztikt ar: ini_set('session.gc_maxlifetime', '86400'); ini_set('session.gc_probability', 1); ini_set('session.gc_divisor', 1); /* arī šo rindiņu mēģināju, man izskatījās, ka viņa darbojās galīgi ne - ok */ ini_set('session.cookie_lifetime', 86400); Patiesībā šis ne vella neadarbojas. Mēģināju arī samazināt sesijas laiku uz 10 sekundēm, arī nekas nemainās - dati nedzēšas. Varbūt kāds palīdzēs ar padomu? - - - PHP sesijas conf: Directive Local Value Master Value session.auto_start Off Off session.bug_compat_42 Off Off session.bug_compat_warn On On session.cache_expire 180 180 session.cache_limiter nocache nocache session.cookie_domain no value no value session.cookie_httponly Off Off session.cookie_lifetime 86400 0 session.cookie_path / / session.cookie_secure Off Off session.entropy_file no value no value session.entropy_length 0 0 session.gc_divisor 1 1000 session.gc_maxlifetime 86400 1440 session.gc_probability 1 1 session.hash_bits_per_character 5 5 session.hash_function 0 0 session.name PHPSESSID PHPSESSID session.referer_check no value no value session.save_handler files files session.save_path no value no value session.serialize_handler php php session.use_cookies On On session.use_only_cookies On On session.use_trans_sid 0 0

Tagad te papētīju... Mīnusi: 1) Nav asociatīvo masīvu. Pašam jāpārlisto masīvs 2) Order kolonnas, kas nāk kā mainīgie, tāpat jāapstrādā ar mysql_fetch_array(). Tāpat arī citi mainīgie, kas var apzīmēt kolonnas vaicājumā. 3) Vispirms visam ir jābūt iefetčotam un tikai tad var veikt nākamo selektu. Laikam es īsti nesaskatu PREPARED STATEMENTS ieguvumus...

Codez - kam par godu izvēlējies tieši mysqli nevis PDO? Vai tādēļ, ka plānoji izmantot tikai mysql, vai bija kādi citi iemesli? Šobrīd notiek tieši tā nosliekšanās uz vienu vai otru pusi. Pagaidām kaut kā patiešām vairāk velk uz MYSQLi.

Nu it kā nav gan - kā tu izmanto prepare metodi, tā tālāk ir jāizmanto MySQLi_STMT execute: $stmt = $mysqli->prepare("SELECT * FROM test WHERE id = ?"); $stmt->bind_param("i", $i); $stmt->execute(); Un pēc execute jau darbojas MySQLi_STMT metodes, kas, neatbalsta fetch_assoc.

Varbūt vari parādīt, kā ar MySQLi iegūsti asociatīvu masīvu? :) Tad es varbūt pagaidām nosliektos uz MySQLi.

Jautājums pieredzējušajiem. Beidzot esmu nolēmis atteikties no manuālā mysql_real_escape_string un pāriet uz PREPARED STATEMENTS. Neredzu nepieciešamību tuvajos gados pāriet uz citu DB. Salasījos 3 gadus vecos rakstos, ka PDO ir lēnāks par MYSQLI. Kāda ir jūsu pieredze mūsdienās? Lasu rakstus, apskatus, katrā ir pilnīgi cita versija par ātrdarbību. PDO galvenā būtība jau ir viegla pāreja uz citām DB, bet tas man nav aktuāli... Varbūt vēl kādi ierosinājumi sakarā ar šo izvēli / pāreju? Cik jau paspēju saskarties, MYSQLI problēma ir tas, ka PREPARED STATEMENTS selecta gadījumā nesaņem asociatīvu masīvu, tātad jāņem talkā pašrakstīta funkcija. Atkal - ātrdarbības samazināšana.

Mega paldies! Nebiju iedomājies paspēlēties ar absolūto pozicionēšanu procentos! Super!

Sveiki! Meklēju veidu, kā ar JQuery ērti izvērst no centra punkta uz visām pusēm divu. Līdzīgi, kā kādreiz ieslēdzās teļuki - tur gan bija tikai vertikālā izvēršanās novērojama, bet interesē visos virzienos no 1 punkta. Nav kāds redzējis gatavu pluginu, vai pieeju, kā to darīt? Negribas izmantot kaut kādu mega pluginu tipa Thickbox priekš tāda nosacīta nieka. SlideUp funkcijas mīnuss ir tāds, ka viņa izrullē no augšējās rindas uz leju. Bet mani interesē, lai tas notiktu no centra punkta. Un tieši tas pats pretējā virzienā... Negribas pašam izgudrot riteni, ja kāds kaut kur jau ar tādu braukā :) P.S. Tāpat izvairos no UI, jo tā bibliotēka ir ļooti liela.

Skaidrs, nevienam nav ko teikt. OK, jāurbj tālāk...

Tātad, man stāv nedaudz novecojusi Horde ar visām tās komponentēm. Gribu veikt upgrade, bet saprotu, ka ir mainījusies datubāze, filtru preferences glabājas savādāk utt. Cik saprotu, Upgrade notiek tā, ka [protams nobakupoju failus,db], uzkopēju jauno horde, imp, ingo, sakonfigurēju configus, preferences pēc vecās šnites. Bet tālāk sākas tas, ko es nesaprotu... Pieņemsim, ka mana Horde ir apmēram 2-3 gadi veca (3.3.X) un es nesaprotu, kādi upgrade skripti ir jāizpilda, kādi - ne. Gan Hordei, gan IMP-am, gan INGO ir scripts/upgrades mape ar visādiem upgradu skriptiem. Bet, kurus taisīt? Kādam nav pieredze ar upgrade, varbūt varat pakonsultēt? P.S. Visvairāk pārdomas man rada INGO 1.1.X pāreja uz 1.2.X.