jurchiks

lolwut?

Nav jēgas spriedelēt, tāpat skaidrs, ka prasība pabeigt līdz gada beigām ir nereāla, ja vēlas normālu produktu.

Vai tev kaut kur logos parādās warning, ka tu centies piekļūt neeksistējošam variablim (konkrēti no var_dump())? Ja nē, tad gluži vienkārši $obj->{$f} ir uzsetots ar vērtību null. Vēl iespējams, ka tur tiek izmantots magic __get($key), kas returno null, ja key neeksistē.

Ok, padebugoju skriptu tā nopietnāk, izskatās, ka preg_replace kaut ko ne tā izdara: http://pastebin.com/67Hzehfb Šis kods kaut ko izdara ar burtu "Š" un pirmo burtu no vārda "Робот"... Pieliekot u modifikatoru visiem patterniem, problēmas vairs nav, vienīgi, cik atceros, man bija iemesls noņemt to, jo kaut kas strādāja nepareizi... Velns viņu zin, kas. Cerams, ka nekas nenobruks.

Tā herņa vispār tiek atpazīta kā UTF-8 teksts, ja paņemtu acis rokās, ieraudzītu, ko es uzrakstīju. Visur citur, izņemot Windows konsoli, tas arī tiek atpazīts kā UTF-8 un nekur nav nekādu eroru. Ko man iesākt, kā izdabāt Windows konsolei? Insertošanas kods ir šāds: http://pastebin.com/ME6vMKM7 $prodInsert satur PDO prepared statement ar norādītajām kolonnām, values() tiek ievietotas internal masīvā, execute() inserto (PDOStatement::execute($values)). Nekādas iekšējas datu apstrādes db abstrakcijā nav, tas arī nebūtu prātīgi. Visi faili manā projektā ir kodēti UTF-8. Ko tu domā ar pareizu eskeipošanu?

Ir tāda debīla problēma, ka nevaru palaist dažus skriptus no konsoles uz sava dev box, jo kaut kādā dīvainā veidā Windows kaut ko maina skripta izpildē un lietas nestrādā tā, kā vajag. Konkrēts piemērs: php skripts, kas ievelk XML failu, izparsē to un ievieto datus datubāzē. Uz production box (Ubuntu 13.04) nekādu problēmu nav, skriptu var izpildīt konsolē manuāli, normālā kron izpilde bez aizķeršanās, izpilde caur acp arī. Uz dev box (gan mājās, gan darbā tas pats): no acp problēmu nav (bet tur ir lapas buferēšana un izpilde aizņem laiku, katru reizi jāgaida, kamēr izpildīsies, līdz ieraudzīs rezultātu), kron uz dev box nav, bet caur konsoli ir problēmas: izpildot skriptu, brīdī, kad dati tiek ievietoti datubāzē, mysql lamājas par non-UTF-8 character sequences: SQLSTATE[HY000]: General error: 1366 Incorrect string value: '\xC5 trau...' for column 'name' at row 1 Teksts, par kuru lamājas: "Kartogrāfija tūrismam. Jānis Štrauhmanis." Otrs piemērs: SQLSTATE[HY000]: General error: 1366 Incorrect string value: '\xD0 \xD0\xBE\xD0\xB1...' for column 'name' at row 1 Teksts: "Robotpolicists. Robocop. Робот-полицейский. (DVD)" Pirms datu ievietošanas datubāzē noteicu esošo encoding un ielogoju to, tas ir UTF-8: $enc = mb_detect_encoding($name, 'UTF-8,ISO-8859-1,ISO-8859-5,ISO-8859-9,ISO-8859-15', true); \Logger::debug('1st encoding: ', $enc); // vienmēr UTF-8 if (!$enc) { $enc = mb_detect_encoding($name, mb_detect_order(), true); \Logger::debug('2nd encoding: ', $enc); // nekad netika ielogots } if (!$enc) { $this->logError('Failed to detect encoding for text: ' . $name); $enc = 'UTF-8'; } \Logger::debug('final encoding: ', $enc); Manā skatījumā problēma nav kodā, jo visur, izņemot win konsoli, viss strādā perfekti. Jautājums ir - kas šo stulbo uzvedību varētu izraisīt un kā to atrisināt? Baigi traucē, ja nevar skatīties skripta output realtaimā.

Es par šo: http://www.webdesign.org/img_articles/21046/3.jpg Man tas skaitās fancy fonts.

Arī fancy fontos?

1. Muļķības. Ja gribi vairākās valodās, vairākas valūtas un tiešām pareizi, tad tas prasīs daudz vairāk. 2. Neredzu, kā kursa starpības un pāriešanas datumi ir saistīti ar šo skriptu.

Ok, rīt pielikšu un paskatīšos. Thx.

http://www.php.net/manual/en/class.numberformatter.php Mēģināju nesen darbā šo piekurbulēt, kaut kā nesanāca, kaut gan PHP 5.5.4 stāv uz kastes un intl extension ir ieslēgts. Pievērsiet uzmanību pašam apakšējam komentāram: <?php $f = new NumberFormatter("en", NumberFormatter::SPELLOUT); echo $f->format(123456); ?> Produces the result: one hundred twenty-three thousand four hundred fifty-six Iespējams, ka tā padarīšana spēj arī citās valodās to izdarīt, bet, kā jau minēju, man neizdevās pat palaist...

noice :D

Tad labi. ...? + mans priekšnieks un vairums viņa "čomu", tai skaitā cilvēks, kurš tajā acp visvairāk darbosies, laiž ar FF.

ACP ir https, tikai sertifikāta nav (priekšnieks nav papūlējies iegādāties). Gribi teikt, ka viņiem referrer jau nav redzams un neko nevajag darīt?

Tieši URL no admin paneļa. Frontendā nekādu tādu linku nav. @rpr - kāds header location? Pliks anchor lapā.

Ir admina panelis, kurā ir tiešie linki uz citiem saitiem. Pats par sevi saprotams, citi saiti savos access logos redz admina paneļa URLi kā referreri. Vajag, lai redz kādu citu referreri. Jautājums - vai ir kāds bezmaksas saits, caur kuru var prokšot pieprasījumus uz citiem URLiem, piemēram, šādi: http://www.somesite.lv?url=your+url+here has redirekto uz your+url+here ?

Datubāzes kolonnas nosaukums ir email, tāpēc pieņemu, ka tā jau sākotnēji bijusi paredzēta e-pasta saturēšanai. Ja ir iespējams, tad obligāti jāpieliek nepieciešamās pārbaudes/apstrāde, lai nebūtu ar šitādiem sūdiem jāņemās.

Pirmām kārtām jau vajadzētu validēt vai vismaz normalizēt e-pastus pirms tie nonāk datubāzē, lai tāda huiņa nemaisītu gaisu. Pašam pēc tam būtu vieglāk. Ja nu kaut kāda velna pēc tā nevar, tad vismaz izpildi "UPDATE applications SET email = trim('.' FROM trim(t1.email))".

Uzskatu, ka tas nav loģiski. Vēlamais ir papildus obligātajam, vēlamais nebūt nav minimums.

Vēlamo uzskaitīji, bet mandatory...?

Tā jau domāju. Labi, galvenais, ka strādā, citādi tas brīnums ar pāris lapām reāli sabojāja noskaņojumu.

@Kasspars - bet tad kāpēc visas pārējās lapas iet? Tur struktūra ir identiska. @404 - mēģināšu. Vai ir jēga skatīties tos internal errorus? Izskatās, ka lamājas par tām lietām, kuras es daļēji aizmālēju cleanHTML funkcijā.

Skripts: http://pastebin.com/Pxc7TA48 Output: http://pastebin.com/wL9LwwPS Testa skripts uzskatāmi parāda problēmu. Ievelku produktu sarakstu no 220.lv ar curl, iztīru konvertēju saturu ar tidy uz XML, tad jau meklēju produktus ar xpath "//div[@class=fakeProductContainer]/h3/a". Visās lapās viss strādā pareizi, izņemot tos URLus, kuri ir masīvā dotajā skriptā (izņemot pirmo, tas ir piemēram - kādam būtu jābūt outputam). Kādam varētu būt nojausma, kas par sviestu? Es ievēroju, ka tajās lapās, kuras nestrādā, span class="product", kurš ir parent elements div class="fakeProductContainer", bija pārvietots un atradās iekš div class="fakeProductContainer". Nahuj tā notiek un nahuj tikai tajās dažās lapās? Notērēju labu laiku bezmaz vai matus plēšot, bet man nav ne jausmas.

Tad tie ir nevis latviešu, bet latviskoti vārdi. Es, personīgi, tajā sarakstā atstātu tikai tos vārdus, kuri oficiāli iekļauti kalendārā.

Par pilsoni var kļūt arī ķīnietis. Kāds te sakars Satversmei?