jurchiks

dmitrijs is not a Latvian name.

Ringo netik.

Varbūt kā reiz saprata, visādi gadās. Nav jau tā, ka visi uzdevumi 100% pareizi.

kā nesāpīgi varu noņemt Apache 2.4 un tā vietā uzlikt 2.2 versiju?

Nedari to.

Labāk pamēģini pats kompilēt, nevajadzētu būt tik traki, kā tu domā - nokačā src, `configure`, `make`, `make install`, galvenais norādīt pareizus parametrus configure skriptam.

Šeit: http://stackoverflow.com/a/10961531/540394

ir īsi un skaidri aprakstīts, ko katra no tām 3 komandām dara.

Tā jau no paša sākuma vajadzēja. Lieki laiku notērēji, cenšoties ar parastu form submit pielauzt.

Cik zinu, tad "(event.keyCode ? event.keyCode : event.which)" priekš jQuery nav vajadzīgs, jo event nav parastais javascript event objekts, bet gan jQuery.event objekts.

Bet vispār superīgi :)

Ar svaigu galvu izlasīju sevis rakstīto, sapratu, ka nav tas. Tagad domāju, ka to var aprēķināt šādi:

targetX = zaļā kvadrāta sākuma X offset reizināts ar (jaunais (sarkanā kvadrāta) izmērs / oriģinālais (zilā kvadrāta) izmērs)

un, protams, noapaļots. Tad vēl varētu piemest finalX = Math.max(0, targetX), lai nesanāk tā, ka resaizojot uz mazāku izmēru, zaļais rāmis aizbrauc ārpus robežām.

Nezinu, vai man liekas nepareizi, bet man liekas, ka vajadzētu būt nevis augstumu/platumu starpība dalīts ar 2, bet augstumu/platumu starpība dalīts ar (jaunais (sarkanā kvadrāta) izmērs / oriģinālais (zilā kvadrāta) izmērs).

Pilnībā var būt, ka liekas nepareizi, jo esmu pamatīgi noguris.

form aptver visu table, div saturs iekš submit pogas td. Pašu div nevajag vispār. Bet vispār jau šādām darbībām AJAX kā reiz paredzēts, kāpēc tu to neizmanto?

Nafig lai kāds uz ko tādu kaut skatītos, kur nu vēl meklētu problēmas (neskaitot acīmredzamās)?

Ģēnij, runa iet par CMS ar teksta tulkošanu, nevis par statiskiem tekstiem.

No offense, bet ar paviršu acs uzmetienu jau vairākas gramatikas kļūdas pamanīju, galvenā no kurām ir "desings" - pareizi ir "designs". Desings ir kad tu kaut ko dari ar desiņām or smth.

Javā/Scalā tad loģiski, ka tādu problēmu nav.

 

@Kavacky - kas tev nepatīk prepared statementos? Baigi patīk rakstīt "SELECT " . implode(', ', $columns) . " FROM $table WHERE $wheres"?

Šajā gadījumā es prepared statements minēju tāpēc, ka citādi būtu problēmas ar query cache, ja katrs kverijs ir ar jau iekļautiem mainīgajiem tā vietā, lai tos baindotu caur prepared statement interfeisu.

hmm nu nezinu gan vai uz katru tekstu kuram vajag tulkojumu ir prātīgi vērsties pie datubāzes, cik tad daudz pieprasījumu datubāzei būs jāapstrādā. Kaut kā noteikti var arī savādāk teiksim izvēlētai valodai tulkojumus turēt atmiņā.

Persistent connection, query cache, prepared statements.

Gribi in-memory cache - izmanto Redis vai ko tamlīdzīgu.

Jebkurā gadījumā, izmantot teksta failus dinamisku tulkojumu glabāšanai, ja tie tiek tulkoti caur webu, IMHO ir vienkārši debīli.

gettext vispār man liekas reāli neparocīgs + morāli novecojis.

Neredzu problēmu...

Ja tev vajag tulkošanas interfeisu, tad tas ir ļoti vienkārši - kverijo no db oriģinālo tekstu un tulkojumus, izvadi savā admina panelī formā input/textarea laukos, on form submit apdeito db. Ja to lapu izmantosi tikai tu vai kāds pazīstams cilvēks, kuram vari ieskaidrot, ko var un ko nevar, tad problēmu nav. Ja ir komerciāls produkts, kuru izmantos sveši cilvēki, tad nāksies vien pašam izpušķot ar visu vajadzīgo, princips tāpat paliek nemainīgs.

Ja tev vajag izvadīt tulkoto tekstu frontendā, tad var uztaisīt kaut ko šādu:

function getText($textKey)
{
    $userLanguage = $_COOKIE['language']; // piemet pārbaudes drošībai
    $text = database->getText($textKey, 'table name', $userLanguage); // pseido-kods, aizvieto ar savu reālo kodu
    
    if (empty($text)) // nav tulkojuma, ņemam oriģinālo tekstu (kaut kam jābūt)
    {
        $text = database->getText($textKey, 'table name', 'default language');
    }
    
    return $text;
}

$textKey ir kaut kāds db key tekstam, kuru tulkot (vēlams nevis ID, bet kaut kāds description, piemēram, "text_save" -> "Save/Saglabāt/Сохранить", tā būtu vieglāk saprast kodu).

Ņihuja nevar saprast. Jebkurš db klients neder, lai labotu tekstus caur datubāzi?

COLLATE='utf8_unicode_ci'

Cik es esmu lasījis, CHARSET un COLLATE vērtības nedrīkst likt pēdiņās, nestrādājot or smth. Tas pats ar, piemēram, "SET NAMES utf8" utml.

Visi ienīst WP

fix'd

Tip: iemācies angļu valodu.

Tas principā atkarīgs no tā, kāda mājaslapa. Draugiem.lv vai fecesbook ar visu to, kas viņiem tur sabāzts, protams, "pielabot" ar media-queries diez vai sanāks, bet vienkāršākām lapām, kurās pārsvarā dominē galvenais menu un saturs, nevajadzētu būt tik traki.

Slikta pieredze tev bijusi...

Nu piedod, bet mani interesē tikai un vienīgi kvalitāte, un Wordpress maniem standartiem galīgi neatbilst.

<?php

$string = '[{"id":1,"children":[{"id":4},{"id":5,"children":[{"id":6}]}]},{"id":2}]';

$data = json_decode($string, true);

 

function draw_menu($data, $nestingLevel = 0)

{

foreach ($data as $menuItem)

{

echo str_repeat('-', $nestingLevel * 4),

$menuItem['id'], '<br/>';

 

if (!empty($menuItem['children']))

{

draw_menu($menuItem['children'], $nestingLevel + 1);

}

}

}

 

draw_menu($data);

IMO jautājumam nav objektīvas atbildes - katram savs.

IMHO Wordpress ir priekš sliņķiem un tiem, kas nemāk programmēt.

Tu jauc child ar parent. Item 4 parent ir Item 1.

Ja tev būtu child, tad būtu Item 1 children = [4] (jābūt masīvam, jo var būt vairāki child itemi).