Maris-S

Leksika patiešām nepatīkama, bet par tēmu pameklē php mime type, domāju Tavā gadījumā pietiks ar finfo_file. Izmēģinājis šo neesmu.

Pag, vai tad move_uploaded_file kā destination nav jānorāda pilns faila nosaukums? Tev tur ir direktorija tikai.

Ja Tev if izpildās, tad iespējams nenostrādā vaicājums vai arī move_uploaded_file(), paskaties vai tagad datubāzē parādās ieraksts, kad esi izlabojis formai enctype='multipart/form-data'? Būtībā ja šīs vietas nestrādātu, tad laikam izvadītos kļūdu paziņojumi, iespējams ka tomēr ceļš uz augšupielādes direktorijām nav pareizi norādīts.

Oi, sorry sajuka, domāju iptables. http://www.netfilter.org https://help.ubuntu.com/community/IptablesHowTo

Aizmirsu pieminēt, paskatīties kas notiek tīklā vari mēģināt ar netstat, ja vajag ko jaudīgāku par šo, tad jāmeklē, no galvas neatceros utilītiņu nosaukumus, bet kādreiz manīju cmd utilītas, kam bij gui (protams cmd līmeņa grafiskais interfeiss).

Kā noķert vai identificēt datorlaužus īpaši palīdzēt nevarēšu, bet par ugunsmūri paskaties šeit: http://www.proftpd.org https://help.ubuntu.com/community/ProFTPD

Ne vienmēr tas ir iespējams, piemēram ja sanāk tulkot atsevišķus vārdus, tas var gadīties tabulāriem datiem. Uz ātro nesanāk izdomāt konkrētu piemēru, kas varētu rasties reālā sistēmā.

Sāku pētīt gettext tulkošanas iespējas. Ienāca prātā situācija, kad vienam angļu valodas vārdam varētu būt vajadzīgi dažādi tulkojumi, piemēram, uz latviešu valodu. Piemēram vārds bug varētu tikt tulkots kā vabole un arī kā kļūda. Ja šie vārdi parādās vienā lapā, tad vārdam bug varēs izveidot tikai vienu tulkojumu, bet latviešu valodā vajag abās vietās iztulkot dažādi. Izmantoju poedit programmiņu. Tik tālu kā risinājumi ienāca vienīgi variants, piemēram vienam no vārdiem pielikt klāt atstarpi, jo web principā to neredzēs, bet liekās ka šis variants būs ne visai pareizs. Vēl variants ko iedomājos ir oriģinālvalodas vietā rakstīt tādus kā identifikatorus, kurus pēc vajadzības varēs nosaukt vienalga kā, bet tad tulkošana būs vēl sarežģītāka kā izveidot atsevišķas lapas versijas vai arī salikt tulkojumus masīvos. Par tulkojuma iedošanu tulkam šādam gadījumam vispār nevar būt runa. Gribētos uzzināt kādus risinājumus no pieredzējušiem cilvēkiem, kas izmanto šīs tulkošanas iespējas.

Varbūt pamēģini slackware, neesmu izmēģinājis kā memcached strādā uz viņa, bet daži iesaka arī izmantot serverim. Vismaz memcached kompilēšanas skripts ir pieejams (http://slackbuilds.org/repository/13.0/network/memcached), tātad jābūt iespējams to izmantot, teorētiski. 64bit versija slackwarem arī ir. Vienīgi varbūt ir vērts pagaidīt kamēr šie jauno pabeigs līdz galam taisīt (13.1) beta jau ir, būtu labāk serverim jaunāko uzlikt, bet nav ne jausmas cik ilgi vēl līdz stable būs jāgaida. Konfigurēšana slackwarem kā jau tam jābūt izmantojot teksta failus. Cik tas ir ātri vai ērti jau katram jāizlemj pašam, iespējams var arī kādus web interfeisa konfigurēšanas sistēmas uzlikt, neesmu meklējis un pētījis tādas lietas. Ar automātiskiem jauninājumiem gan slackware nevar palielīties.

Kāpēc uzskatāt ka mysql nestrādās pareizi ar multibyte?

Man jau šķiet vai izmantot vai neizmantot matemātiku atkarīgs no uzdevuma. Savā laiku universitātes laikos programmēju lodes lidošanas augstuma un attāluma (kopēji arī trajektorijas) atkarību no laika, tad sanāca arī fiziku izmantot šim uzdevumam, mazliet un elementāri, bet tomēr. Domāju kādi riktīgie šifrēšanas algoritmi, fizikas aprēķini spēlēm vai līdzīgi uzdevumi bāzējās uz diezgan nopietniem matemātiskiem aprēķiniem.

No mysql dokumentācijas: 'The maximum row length, except for variable-length columns (VARBINARY, VARCHAR, BLOB and TEXT), is slightly less than half of a database page. That is, the maximum row length is about 8000 bytes. LONGBLOB and LONGTEXT columns must be less than 4GB, and the total row length, including BLOB and TEXT columns, must be less than 4GB.' Pārbaudei: CREATE TABLE `content` ( `content_1` TEXT, `content_2` TEXT, `content_3` TEXT, `content_4` TEXT, `content_5` TEXT, `content_6` TEXT, `content_7` TEXT, `content_8` TEXT, `content_9` TEXT, `content_10` TEXT, `content_11` TEXT ) ENGINE = InnoDB; Tagad pamēģiniet ielikt katrā laukā aptuveni 1kb tekstu, nezinu, paņemiet ziņu portālā vienu rakstu un salieciet katrā laukā, liekot 11 lauciņā būs kļūda.

Nedomāju ka Tev pašam pēc gada kādai mājas lapai būs vienkāršāk domāt par tās konstantēm, nekā administrācijas sadaļā (ar paša lielākā administratora paroli) pievienot vienu valodu un augšupielādēt vienu karodziņa attēlu. Lietotāji ne vienmēr ir slinki lai administrētu savu lapu, bieži vien pat lapas būtība ir tāda ka tās saturu jāpapildina dienā vairākas reizes un jāadministrē visu laiku (ziņas, blogi, nekustamie īpašumi, internet veikali, grāmatvedības sistēmas utt.). Strīdēties tiešām nevajag, vajag izteikt savas domas un pamatot tās kāpēc tā domā, citiem atkal, ja ir vēlēšanās, nav jāstrīdas pretī, bet gan jānorāda uz kļūdām un jāpamato tās. Tu neuzmanīgi izlasīji ko es rakstīju. :) Innodb tādus laukus kā text, blob un tml. pašā ierakstā nesaglabā pilnīgi, bet gan tikai sākuma baitus (līdz cik tieši skaitli nezinu), pārējā daļa iet ārpusē (terminus kā tās daļas sauc nezinu), teorētiski lauks ar atbilstošu tipu var sasniegt 4GB. Stipri aptuvens pašā ierakstā saglabājamo datu izmērs varētu būt 8000/11 baiti, jo tieši pie 11 koloniņām var parādīties šīs problēmas, ja katrā no viņām saglabātie dati sasniedz vai pārsniedz šo sākuma baitu lielumu, id koloniņu var šoreiz ignorēt, aprēķini aptuveni un tā ir salīdzinoši maza. Nevarēšu pateikt ko nozīmē "ierakstam ārpusē', tur jālasa mysql struktūras dokumentācija par viņu 'database page" un visām pārējām lietām. Tur ir daudz ko pētīt ja iedziļinās. Varbūt kāds mysql speciālist varēs mūs apgaismot par pašu teoriju kā notiek saglabāšana ierakstos. Personīgi es tik stipri neesmu pētījis, vismaz pagaidām.

Un ja mājas lapai ko taisi uz pasūtījumu būs nepieciešama valodas pievienošana no administrācijas sistēmas? Kā lietotājs, kas neko nesaprot no php un viņam arī nevajag saprast php, pārveidos skriptā konstanti? Protams ir vienkārši, arī konstantes modificēšanu var atrisināt kaut vai ini failā ieliekot stringu 'lv|en|ru', ko vēlāk vienkārši saliek masīvā (viens no variantiem). Tomēr šādas metodes neuzskatu par pareizākajiem un ērtākajiem risinājumiem (tikai manas domas, par vienīgo taisnību necenšos strīdēties), bet galvenais jau nav sistēmas organizēšana principā, galvenā doma manam teiktajam (sākumā) bij tieši ieraksta garuma limits innodb tabulām datubāzē (~8000 baiti). Ar laiku mājas lapa var palikt par daudzvalodu sistēmu pie tam ne ar 3, bet 5-10 valodām, kā arī norādīju piemērā man pašam personīgi pietika 4 valodu, lai limitu sasniegtu. Tas protams ir izņēmuma gadījumi un es personīgi par to uzzināju tikai saskaroties ar problēmu, tāpēc ceru kādam šis varētu noderēt. Pamēģināju sataisīt tabulu, kur varētu atkārtot šo kļūdu. Principā var vienkārši izveidot jebkuru tabulu ar vismaz 11 text, longtext, blob vai tāda veida koloniņām (tomēr tai mājas lapai ko taisīju uz katru valodu bij ne tikai īsais un garais apraksts, bet vēl kāds 3. lauks, sen jau taisīju, neatceros). Tekstam jābūt salīdzinoši garam, lai kopēji (vienā ierakstā) pārsniegtu 8000 baitus. Kļūda ko parādīs mysql, ja pārsniegs ieraksta pieļauto garumu: '1030 - Got error 139 for storage engine'. Protams daudziem radīsies loģisks jautājums kāpēc tad var daudz lielākus datus ielikt kaut vai blob laukā, ja ir mazāk par 11 koloniņām. Lieta tāda ka šo tipu lauku dati tikai daļēji tiek glabāti pašā ierakstā, tikai sākums. Sīki nezinu kā realizēta sistēma mysqlam. Kam interesē šeit var palasīt sīkāk: http://dev.mysql.com/doc/refman/5.0/en/innodb-restrictions.html

2easy, koloniņu datubāzē protams ka viegli pievienot, bet veidojot sistēmu ar atsevišķu valodu tabulu, kas tiks saistīta ar satura tabulām, domāju ka jebkurš ievadīšanas formas, piemēram, administrācijas sadaļās arī veidos automātiski, balstoties uz valodām kādas ir sistēmā, tātad nevajadzēs programmēt klāt skriptos. Protams tas ir vienkāršajos variantos. Protams var automatizēt formu veidošanu arī pēc koloniņu nosaukumiem, bet nedomāju ka būs droši to darīt.

Glabājot saturu atbilstoši valodām datubāzē ir jāuzmanās izmantojot katrai valodai atsevišķu kolonu, izmantojot innodb tabulas ir ierobežojums uz ieraksta izmēru, parasti satura glabāšanai tiek izmantoti text vai varchar datu tipi un izmantojot viņus salīdzinoši ātri var pārsniegt ierobežojumu, gadījumā ja izmanto daudz valodas. Skaitļus no galvas vairs neatceros, ierobežojumus var apskatīties mysql dokumentācijā. Man personīgi šķiet sanāca salasīt 8 vai 11 koloniņas ar text datu tipu, lapai ar 4 valodām un bij nepieciešamība rakstiem saglabāt īso un pilno aprakstu, bet iespējams ka vēl kas bij un kopā salasījās pāri tādām 8 koloniņām. Izmanotjot datu tipus kā int protams koloniņu vajadzēs daudz vairāk, lai pārsniegtu tos limitus. Risinājums glabāt saturu atbilstošajām valodām divkāršsaistītās tabulās (piemēram, id | raksta_id | lang_id | īss_apraksts | raksts), pie tam tādai sistēmai viegli pievienot jaunas valodas, ja tas nepieciešams.

Izmanto funkciju meklētāju http://lv.php.net mājas lapā, ja funkcijā pielaidīsi mazu kļūdu viņš parādīs līdzīgos variantus un varēsi viegli atrast kā pareizi saucās funkcijas, kurām nosaukumi pagaidām ir zināmi aptuveni.

Izskatās ka esi pieļāvis kļūdu funkcijas nosaukumā, gan jau šoreiz domāta ir funkcija get_headers (pēdējais burts s).

Viens no variantiem autoram arī izmantot papildus lauku, kurā insertojot ziņu liec klāt autora vārdu uzvārdu, vai arī lietotāja vārdu. Kā dabūsi pašu vārdu uzvārdu tur jau atkarīgs no kopējās sistēmas, iespējams ielogojoties lietotājam šī informācija ievietojas sesijā, tad var izmantot to. Vēl viens variants papildus laukā glabāt nevis vārdu uzvārdu, bet gan lietotāja identifikatoru, bet selectēt nāksies izmantojot joinus. Briedis, es pārsvarā neglabāju datumu kā timestampu, labāk saglabāt viņu ar now() datetime laukā un ja vajag dabūt ārā kā int, tad to izdaru atbilstoši vaicājumā un tad php pusē formātu var izveidot kādu vien php ļauj, parasti to daru izveidojot vienu funkciju, kas ļauj formātu nomainīt visai lapai vienlaicīgi.

Yeahz, neviens nevarēs garantēt 100% drošību, ja garantē, tad nozīmē ka viņš melo. Arvien vairāk šajā forumā parādās ieraksti, kuru mērķis ir pasmieties par citiem un pateikt ka viņi ir stulbi, diemžēl... Vēl jo sliktāk ka tas tiek teikts par cilvēkiem kas mācās un cenšas kau ko darīt, nevis prasa par simbolisku samaksu vai vispār par velti uztaisīt viņu vietā. Agrāk tas bij sastopams daudz retāk. Rezultāts - informatīvais potenciāls šim forumam krītās. Tas labi ka var saņemt kritiku par lapu un potenciālajiem drošības caurumiem, bet ir atšķirība kā to pasaka, ja pateikts: 'Tu esi stulbs, Tev nekas nav drošs un priekš kam Tu vispār programmē', tad no šādiem izteicieniem jēgas nebūs ne lapas autoram, ne tam kas šo teica, ne tiem kas nāk uz forumu meklēt noderīgu informāciju.

Emm, vispār tur ar novecošanu nav nekāda sakara, tā funkcija ir nepieciešama gadījumos, ja tie magic quoti ir ieslēgti uz servera. Parasti es tādu funkciju atstāju. Kāpēc viņa Tev nestrādā nav ne jausmas, pamēģini darīt kā 2easy teica: function smartQuotes($value) { if (ini_get('magic_quotes_gpc')) { $value = stripslashes($value); } if (!is_numeric($value)) { $value = mysql_real_escape_string($value); } return $value; }

Nav tā ka neviens konvertors nepārkonvertē tabulu, vienkārši bieži pdf dokumentos tās tabulas ir ieliktas nevis kā tabulas objekts, bet gan sazīmētas ar līnijām (es pie tam pats ar php esmu tādus pdf veidojis zīmējot līnijas). Vari pamēģnāt solid converter, vienīgi man šķiet viņš uz wordu konvertē, bet no turienes gan jau izdomāsi kā dabūt htmlu. Es nezinu vai viņš var aptvert ka no līnijām ir uzzīmēta tabula, bet ja pdf failā tabula ir patiešām kā tabula, tad uzzīmēs. Cits variants, kas arī no līnijām zīmētu tabulu pārkonvertēs, ir abby finereader, tur pat ja viņš neatpazīs viņu kā tabulu, varēsi sazīmēt līnijas tabulai un rezultātā arī iegūsi tabulu, tiesa gan arī uz wordu.

Tā virspusēji izlasīju visas atsauksmes, iespējams ka jau tika pieminēts, bet domāju ka spēlei vajadzētu kādu aprakstu spēles mājas lapā, jo redzu ka diezgan daudz jautājumu ir uzdots kā tieši jāspēlē, tāpēc pamācība noderētu. Pārvietot karti velkot ar peli domāju ir viens no primārajiem uzdevumiem, tas stipri atvieglotu lietotājiem pārvietošanos pa karti.

Java, ja hostings atradīsies, kā būs ar lietotājiem kam nav tik labs un ātrs ārzemju internets?

Kā dinamiski pievienot elementus jau ir apspriests šajā forumā, vienkārši pielāgo savām vajadzībām: http://php.lv/f/topic/15236-bilzuvairaku-pievienosana-datubaze/page__p__117324entry117324