Roze

Kur?

Tas nozīmē, ka php handlerim (apache mods vai fastcgi (atkarībā kā serveris nokonfigurēts)) tiek padots php fails/adrese, kas neeksistē. Ja tā strādā, tad pamēģini no beigām izmest index.php, proti: $url_site = 'http://'.$_SERVER['SERVER_NAME'].'/'; jo kodā gan jau kaut kur izvadās $url_site.'stilafails.css' un tad, ja ir iekabināts tur index.php, tad urlis sanāk nekorekts (http://saits/index.phpstilafails.css) attiecīgi CSS/bildes neielādējas. Vēl problēma varētu būt ar: RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteRule (.*) index.php/$1 [L] kas nozīmē, ka visi (fiziski) neeksistējošie faili/direktorijas tiek rewraitoti caur relatīvu index.php (parasti liek /index.php kas ir nozīmē webroot foldera index failu). Proti isumā (grūti gan tā no malas pateikt neredzot kas patiesībā notiek (konfigu/logus/html sourci)) situācija varētu būt šāda: 1. Tev ir nekorekts $url_site 2. PHP kods uzģenerē kaut kādu http;//saits/dir/lala un uz to spiežot .. 3. Tā kā tāda direktorija/fails neksistē Apache internāli rewraito to par http;//saits/dir/lala/index.php/dir/lala 4. Bet tāds fails/ceļš arī fiziski neksistē, attiecīgi php nekas cits neatliek kā izvadīt No Input file..

Kas par iemeslu tādam nosaukumam? :) Bet nu atliek uzcept aplikāciju, kas "trackotu" nobraukumu + teiksim piedāvātu automātiski ievadīt izmaksas brīžos, kad iebrauc benzīntankos, tad varētu būt interesanti - savādāk pārāk pedantiskiem lietotājiem.

Ja ir vēlme mācīties un joma patīk (t.i. to nedara sakostiem zobiem tikai tāpēc, ka salīdzinoši ari citām sfērām atalgojums ir optimālāks), tad arī ar zaļu gurķi var visu panākt.

Kāpēc izmantot to Wincache un nevis nativo Zend OPcache? Jebšu tur ir vēl kaut kāda funkcionalitāte bez opkoda keša?

Tāda pieeja nav visai korekta, jo nu IIS ir tikpat "daudz serveri" kā piemēram nginx (var paskatīties dažādu webserveru "šāri" http://news.netcraft.com/archives/2015/06/25/june-2015-web-server-survey.html). Tāpat pieņēmums, ka apache+php uz Win būs tieši tas pats kas IIS gadījumā (ņemot vērā, ka iespējams php darbināt dažādos veidos - kā Fastcgi vai ISAPI moduli). izņēmums, protams, ir ja tiešām visa problēma ir kaut kādā MSSQL php draiverī, bet tad ar būtu jāpārliecinās vai ir, piemēram, jaunākā draivera versija ( https://www.microsoft.com/en-us/download/details.aspx?id=20098/ MS pat piedāvā sourci https://github.com/azure/msphpsql ) tāpat alternatīvas ir izmantot ODBC un/vai PDO implementāciju utt. Būtiskākais gan ir arī pats "saits", proti, ja kods ir <?php sleep(60); ?> (ne burtiski protams), tad neviena no servera/os kombinācijām "nepalīdzēs", tai pat laikā ir tikpat liela iespēja "45k apmeklējumus" izprocesēt sekundes laikā :) p.s. es nekādi negribu atturēt no migrācijas, tikai rosināt problēmas risināšanu un (tehnisku) lēmumu pieņemšanu no savādāka aspekta

Tad īstenībā jautājums/argumenti ir vairāk par organizatoriskām lietām, ne tehniskām :) Ja kompānijai nepieciešams "aiz tā", tad pretarguments - vienmēr jau ir iespējams iegādāties dažāda līmeņa komerciālu atbalstu - Red Hat Enterprise Linux, Suse SLES, Ubuntu LTS/Canonical utt. Platformas maiņa (OS, DB u.c.) nekad nav viegls/viennozīmīgs pasākums, visvienkāršāk, manuprāt, kaut ko pierādīt ir (mēģināt - lai saprastu vai vispār ar pieejamajiem resursiem (cilvēk-,zināšanas,tehniskie) un "produkta" īpatnībām tas vispār ir iespējams) izveidot paralēlu sistēmu ar kuru tad salīdzināt kaut kādus statistiskos rādītājus (pieprasījumi sekundē/cpu noslodze/ram prasības utt) uz kuru pamata pieņemt lēmumu - vai ir vai nav vērts. Visi minētie produkti (nginx/apache/php/mysql) gan darbojas arī Windows vidē, ja OS maiņa ir lielākā sāpe un ja vēlme ir tikt vaļā tikai no IIS, tad personīgi liekas, ka apache + php isapi modulis varētu būt vienkāršākais variants.

Ja tas ir Shoutcasts (vai Icecasts) tad var mēģināt šo koda gabalu https://gist.github.com/haykuro/2de8d98031a3cd651754 (koda kvalitāte gan imo tāda so-so). Teorētisko pusi par to kad strīmā parādās meta tagi ar dziemas nosaukumu var palasīt šeit: http://www.smackfu.com/stuff/programming/shoutcast.html Es gan pameklētu vai konkrētajam strīma avotam nav pieejama jau kaut kāda gatava statusa lapa (parasti x.x.x.x:8000/ vai /stats atkarībā no programmatūras (tā kā neesi norādījis reālu adresi, grūti komentēt) un analizēt to nevis lasīt pašu strīmu..

Var droši vien mēģināt skatīties vai šeit kas neparādās: http://www.devclub.lv(fiksi pameklējot pēdējās tieši PHP-related prezentācijas gan diezgan pasen). Bet to it kā var saprast - php ir jau tā pat diezgan populārs (vai lasi "dzīvo uz veciem lauriem") līdz ar to tik enerģiski ar evanģēlismu nav jānodarbojas, nekas tik ļoti būtiski pašā valodā nav mainījies (php7 nezkad iznāks ( https://wiki.php.net/rfc/php7timeline)), ja nu vienīgi kaut ko par HHVM/Hack, HippyVM un kaut kādiem tādiem vipendroniem .. Ak jaunība ( https://c1.staticflickr.com/1/153/373225236_8c66202514.jpg) ... bet Pythons jau tagad daļēji draudzīgs ar php: pypy + php = HippyVM http://hippyvm.com/ :)

Nu alus, sņabis maisiņā .. Bet, ja nopietni, parasti jau visi tad sēž pie dockingstationiem ar ārējiem monitoriem/klaviatūrām utt ..

Lasi kontekstā ar to ko raksta CooLynx .. Tas nav domāts par šo forumu, bet gan (web) auditoriju kopumā.

Es šaubos, ka šeit uzturas šī lietotāju (end-user) grupa (personīgi uzskatu, ka mūsdienās (vidējā) cilvēka uzmanības noturēšanai ir kaut kas jāmaina nepārtraukti - un pat "činkstēšana" ir labs rezultāts (nozīmē, ka nav vienaldzība)), taču šī foruma tēma gan ir visai specifiska, ja, protams, kādam nav mērķis nodarboties ar php evanģēliju (lasi, popularizēšanu un, iespējams, izsist kaut kādu labumu no Zend), tad ņemties ar to (kas patiesībā nozīmē prasīt to darīt kādām citam) būtu samērā jocīgi .. Vismaz es izvērtēju šādus jautājumus: - Vai laacz vēl vispār ir interesanti kaut ko uzturēt? Domāju, ka jaunības maksimālisms ir garām un dzīvē ir citas prioritātes. - Vai man ir pašam laiks un enerģija veltīt kaut kādiem vipendroniem .. Droši vien, ka ne visai - slinkums, darbs u.c. atrunas (personīga pieredze piemēram ar otaku.lv) - Vai šim (php.lv) vispār ir jēga? Varbūt .. No otras puses - latviešu (latviešu valodā runājošo) skaits sarūk, tie paši ēd viens otru bez sāls. "Modīgāk" ir pirkt/lietot kaut kādu ārzemju "širpotrebu", nekā mēģināt atbalstīt kaut kādus vietējo centienus (arī IT tehnoloģijās). Uz vienas rokas saskaitāmie programmētāji emigrē un valsts (nākotnes) politika pa lielam ir indiešu imports. utt

Tēmas definīcija vienkārši tāda neviennozīmīga - tomēr ir nianses vai ar tehnoloģiju domājām tehnisku risinājumu jebšu kantori/domubiedru grupu/personu, kas konkrēto risinājumu, metodi (pareizā laika momentā) ir popularizējis un, iespējams, monetizējis ar kādu catchy nosaukumu servisam vai softwares pļurzulim :) Jo nu kā spainis rakstīja bsd "jailiem" ir jau ~20+ gadi (un +vēlkautkas pirms tam Unix chroot), tad var domāt vai Linux konteineri (LXC), kas uz tiem bāzēti, uz ko savukārt bāzējas Dockeris, ir "ground breaking" vai nē .. Ja par pļurzuļiem - tad personīgi patikams "atklājums" man personīgi ir Tokutek taisītā TokuDB, kas ietver arī samērā jaunu tehnoloģiju ( http://en.wikipedia.org/wiki/Fractal_tree_index )

Šo drizāk var uzskatīt par (ērtu) front-endu Lucenei (kas savukārt nav baigi jauna, no 1999), iespējas, protams, jaukas. No "ground breaking" droši vien varētu piedomāt (praktiskam lietojumam gan nākotnes formā) par kvantu programmēšanu - potenciāli ir iespēja daudz līdz šim esošās lietas "izmest pa logu".

[] sintakse parādās tikai 5.4 .. ja skatās (un var ticēt (10 mil top saiti)) uz http://w3techs.com/technologies/details/pl-php/5/all vairāk kā puse pasaules aizvien dzīvo uz 5.3+5.2.

Svarīgi kādā formā/veidā dati tiek ielikti datubāzē, ja tie jau vienreiz ir apstrādāti, tad otrreiz to darīt nevajag (rodas šādas "ķeskas"). Pagaidām (tā uz labu laimi) var ieteikt, tur kur ir: <span style="font-weight: bold;"><?php echo htmlspecialchars($row['ttitle']);?> ...</span><br /> vienkārši izņemt to htmlspecialchars(): <span style="font-weight: bold;"><?php echo $row['ttitle'];?> ...</span><br /> Sadaļa ir "Iesācējiem", ja nav ko jēdzīgu uzrakstīt, tad labāk to nedarīt vispār ..

Var divos variantos - nogriezt ar php vai ar MySQL: a) Tur kur ir <?php echo htmlspecialchars($row['ttitle']);?></span><br /> ieliec: <?php echo htmlspecialchars(mb_substr($row['ttitle'],0,25));?></span><br /> jābūt multibyte funkciju atbalstam http://lv.php.net/mb_substr (ar parasto substr() var būt problēmas ar unicode (utf8)) vai b) tur kur ir SELECT t.title as ttitle,. ieliec SELECT LEFT(t.title,25) as ttitle Dokumentācija: http://dev.mysql.com/doc/refman/5.6/en/string-functions.html#function_left

"hosts" tas ir domāts hostinga kantoris? Nu tad droši vien viņiem būtu arī jājautā servera parametri (t.i. jāpārliecinās vai tas ir izdarīts). un tad ar tiem arī jāslēdzās, Ja tas ir tikai IMAP serveris, tad būtu jāpietiek ar 110 porta nomainīšanu pret 143 un/vai ieliekot localhost vietā pareizu dns vārdu vai IP, tad var pārbaudīt kaut vai ar neeksistējošu lietotāju/paroli, timeoutam nevajadzētu būt.

110 ports parasti ir POP3, ja tavs e-pasta serveris tādu neatbalsta (nav atvēris portu), tad būs timeouts. Noklusēti IMAP ports ir 143 (var būt arī citi porti, ja teiksim tiek izmantota enkripcija/ssl utt). Svarīgi, protams, vai vispār kāds e-pasta serveris uz localhost (ja tieši tur slēdzies) darbojās t.i. (ja tas ir kāds linux) imapd, dovecot, courier u.c., jo pēc pieredzes lielākoties linux instalācijās noklusēti ir tikai MTA (Mail Transfer Agent - Postfix/Sendmail/Exim u.c.) jebšu serviss, kas nodarbojas tikai ar vēstuļu izsūtīšanu un saņemšanu (SMTP), bet ne lietotāju autorizāciju un vēstuļu "attēlošanu".

Imo nav jēgas pagaidām mainīt (laiks un enerģija), kad tie 2 gadi paies, tad domās .. Tikmēr var parādīties N citas pievilcīgas alternatīvas vai arī pasaules gals. Šis vēl eksistē?

Un kā pirms termometra? Var, protams, filozofiski spriedelēt par to kas mūsu pasaulē nozīmē eksistēt, taču ja strikti pieturās pie "fiziskās realitātes", tad tas, vai homo sapiens kaut ko var "izmērīt", (vienmēr) tak nenosaka lietu eksistenci. Vai atoma kodoli neeksistēja pirms cilvēks tos iemācijās sašķelt utt? Ja tu šādi apgalvo, tad fizikālajā pasaulē mūsdienās ir diezgan daudz elementi/parametri/konstantes (sauc ko gribi) utt, kas nosacīti eksistē taču faktiski nav novērotas. Spilgtākais jebšu pēdējā laikā populārākais piemērs ir tas pats Higsa bozons. Eksperimentāli ar ļoti lielu (pieņemtu) varbūtību it kā ir (jebšu vajadzētu būt), taču 100% "redzējis" neviens nav. Tāpat dimensijas - ir/bija abstrakstas.. varbūt pēc kāda brīža nebūs. Un tur kā reiz ir minēts, ka "time" vietā tiek lietots "duration". Lai ari abiem vārdiem/terminiem latviešu valodā ir arī tulkojums "laiks", taču es ceru, ka saproti, ka tas šoreiz nav izmantots abos gadījumos. Īsumā - nevēlējos iesaistīties šajā diskusijā, Teksti kā: .. kur visas fizikas būtība ir izskaidrot un aprakstīt pasaules stāvokli un notiekošos procesus ar likumiem un likumsakarībām un pat banālam piemēram kā no lielgabala izšauta lode nekādas cēloņu un seku sakarības nepazudina, lai arī būtībā spējam, izmantojot fizikas likumus, aprēķināt tās situāciju "uz priekšu". Nezkapēc lielies ar kaut kādām cilvēces zināšanām/pieņēmumiem un kaut ko ļoti vēlies pierādīt ar dažādiem apgalvojumiem (kurus principā Tevis izteiktajā formā var reducēt uz "jūs dumji, es vienīgais pravietis" (protams, arī kopumā tēma nav ne atbilstoša konkrētajam forumam ne arī visi tās dalībnieki ir korekti)), kas patiesībā var būt nepilnīgi vai pat galam aplami. Piemēram, samērā nesen tak uzskatījām, ka saule riņķo ap zemi, visiem pārējiem vieta bija uz sārta .

Ir jau vēl https://www.youtube.com/watch?v=zqeqW3g8N2Q :)

Ja neuzdod korektu jautājumu(s), pēc kura(-iem) varētu noteikt jautātāja zināšanu līmeni būtu jāsaprot, ka var nākties arī saņemt atbildi, kuru neesi gaidījis (t.i. nav māksla izvērst pirkstus vēdeklī mētājot guru un sniegt atbildi kuru nesaprot).. Šinī gadījumā, piemēram, ir ļoti jocīgi (OMG WTF), ka Tu saki, ka nevari lietot $_POST, bet tai pat laikā nezini kā ar JS var piekļūt un piefiksēt formas/html elementu u.c. vērtības un parādīt kur un kā vien nepieciešams. Kaut kādu document.getElementByid() (ar ko visu Tevis jautāto principā var izdarīt) būtu jāzina .. Manas pēdējās 2vas kapeikas ..

Optimālākais varētu būt nelietot šādu datu struktūru meklēšanai, jo jo vairāk dažādas specifikācijas pēc kura produkti tiks meklēti, jo "neoptimālāk" viss paliks. Vispārīgi runājot MySQLam diemžēl nav INTERSECT (kā MS SQL ( https://msdn.microsoft.com/en-us/library/ms188055.aspx)) t.i. atlasīt visus elementus, kuri atbilstu visām prasībām (subselectiem). MySQLā to (bieži) risina ar INNER JOIN taču no performances viedokļa UNION ALL selects un tad grupējot atlasīt elementus kuriem HAVING count(*) >= [parametu skaits] (līdzīgs piemērs, jau diskusijā minēts http://php.lv/f/topic/22133-mysql-produktu-atrib%C5%ABti/#entry176474 ) varētu būt ātrāks:

Pieņemu, ka tas nozīmē, ka neesi "uz tu" ar Javascript. Vispārīgi runājot, tas ir Javascripts, piemēram, ar onSubmit eventu ( http://www.w3schools.com/jsref/event_onsubmit.asp) vai formu input lauku onChange/Focus eventi. Vienkāršībai var izmantot kādu JS frameworku, piemēram, jQuery, kur funkcijas ir katrai situācijai (pirms/pēc notikuma utt). Tāpat ar Javascriptu iespējams dinamiski saglabāt formas ievadu vērtības un ar tām aizpildīt kādas citas formas laukus, vai pat ierakstīt permanentā veidā - Localstorage ( http://www.w3schools.com/html/html5_webstorage.asp ) Taču Javascript šinī situācijā darbojas lietotāja pusē (client-side) un tam nevajadzētu uzticēt būtiski svarīgu lauku validāciju, proti, no tāda viedokļa N reizes submitot formu uz php un, kamēr lietotājs nav ievadījis visu korekti, vienkārši parādīt formu atkārtoti ar aizpildītiem formas laukiem (vērtības ar $_POST datiem (izmetot nederīgos)), vismaz sākotnēji, manuprāt, ir vienkāršāks ceļš. Tad kādā brīdī, kad ir vairāk zināšanas un sapratne, var sākt kombinēt abas tehnoloģijas un pārbaudi, piemēram, veikt ar dinamiskie fona Ajax pieprasījumiem. Piem. fiksie tutoriāļi meklējot googlee: Basic jQuery Form Validation: http://www.sitepoint.com/basic-jquery-form-validation-tutorial/ jQuery Ajax Validation: http://www.sitepoint.com/jquery-ajax-validation-remote-rule/