Balu Ertl képe

Kézikönyvünk idevágó "Magyar felület fordítása" (http://drupal.hu/kezikonyv/forditas) fejezetét hasznos lehet átfutni, fél-egy óra alatt tisztába tehető a helyzet. Alapvetően egy család három testvéréről szól a mese:

  1. l10n_client: ezt említetted, de ide most nem ez fog kelleni
  2. l10n_update: ez kell neked
  3. l10n_server: a nagytesó, a legtöbb webhely-tulajnak nincs dolga vele.

1. Ahogy az a Kézikönyv Fordítások távoli beküldése oldalon is írja, a l10n_client modul arra való, hogy te magad fordíts angolról magyarra és azt megoszd a többiekkel a központi szerverre való feltöltéssel. De ne fáradj vele, mert már kész van :)
Screenshot of Hungarian translations done for CAPTCHA 6.26

2. Épp ezért neked is a l10n_update modulra van szükséged, ami mindig automatikusan frissíti a magyar fordításokat a központi szerverről.

1
0
Geva képe

egzakt módszer

? ...a dokumentációban nincs erre utaló megoldás. ...volt olyan honlapom, amelynél elég sok funkciót átalakítottam a verzió váltáshoz - sok munkával :-)
gondolom eddig egyenesben is vagy ezzel...

a cck 7.x modult rendkívül hasznosnak tartom a mezők migrálásánál, nincs is probléma(tartalom típusokkal sem), mint a szövegbe beágyazott képekkel
--- a beágyazott képek közül is a legproblémásabbak azok a képek, amelyek pl az img_assist modullal lettek beszúrva szöveges környezetbe - a nagyverzió váltás előtt ezeket a beszúrásokat írtam át, már ahol megoldható volt - ahol nem, ott még nem váltottam 7-re sem :-))) ezért engem is érdekelne egy egzakt megoldás :-)

....valahogy így néz ki egy emlegetett beszúrt kép: [img_assist|nid=1410|title=|desc=|link=none|align=left|width=100|height=73] ez így benne is marad a tartalom szövegébe

neked mit nem sikerült megoldanod?
milyen segítséget lehet még használni a drupal 6 -ról 7-re migráláshoz?

0
0
SecMan képe

...mert moduláris. de tényleg ;)

Amit Googletől vagy Facebooktól kapsz, azok kódrészletek, amik bővítik a weboldalad funkcióját.
Az, hogy a te weboldaladon hol, hogyan, mikor, kinek jelenik meg azt a te weboldalad kódja határozza meg. Egy statikus HTML oldalnál percse csak szövegszerkesztőben beilleszted a neked megfelelő helyre a kapott kódot és oké, de egy dinamikus rendszerben ezt nem tudod megtenni (illetve lehet jobban is csinálni).

Ahhoz kell a modul, hogy ezt a kettőt összekapcsolja.
És azért kell modul, mert a "gyári" alaprendszer ('core') ezt a funkciót nem tudja.
És azért nem tudja, mert a rendszermagnak csak azt kell tudnia, ami a rendszer működéséhez kell, ami alapvető.
Ezek a kiegészítő dolgok, mint a FB vagy G. nem mindenkinek kellenek, nem alapvetőek.

Harmadrészt, valakinek kell mondjuk a FB által nyújott összes extra funkció, amit egy weboldal csak tudhat (postwall, connect, share, stb) valakinek meg ezekből csak egy funkció? Így lehet olyan modult csinálni ami minden tud, meg olyat is ami csak egyet-egyet és mindenki azt telepíti magának, amire neki szüksége van.

0
0
Szotyi képe

off topic
Kb 2 hónapja próbáltam felrakni a gépemre: az Istennek nem jött össze, valamilyen composer vagy micsoda is kellett neki.

Augusztus 29-én ez a link alapján:
http://docs.drush.org/en/master/install/#drupal-compatibility
a Drush 8-nál: Build / fail volt a jelzés

azóta nem nézegettem, lehet, hogy továbbfejlesztették.

---
Update:
sikerült feltelepítenem a drusht 8.1.5-ös verzióját.
Ezek voltak a parancsok, hátha valakinek jól jön még:
- cd ~/
- php -r "readfile('http://files.drush.org/drush.phar');" > drush
- sudo chmod +x ~/drush
Megállapítani a régi drush helyét:
- which drush
S a kiadott útvonalat behelyettesíteni a következő parancsokba:
- sudo cp /usr/local/bin/drush /usr/local/bin/drush_old
- sudo rm /usr/local/bin/drush
- sudo mv ~/drush /usr/local/bin/drush
- /usr/local/bin/drush init

---
On topic

0
0

Péter

dongodani képe

Javaslom, hogy a Drupal 9-es verziótól már a modulok telepítésén túl, azok adminisztrálása és beállításai is egy egyszerű, Githubról utólag telepíthető konzolos felületről, különféle kapcsoló variációkkal ellátott parancsokkal történjen. Sokkal letisztultabb így a dolog. Sőt, itt már ne álljunk meg, magukról a Drupal-os weboldalakról is el kellene tüntetni a h*lye juzerek által felesleges módon favorizált gombokat, linkekeket, képecskéket, videókat és hasonló csacskaságokat, helyettük a világos és minden kockafejű programozó által sokkal inkább favorizált szép forráskódokkal kell bizonyítani, hogy a Drupal halad a korral és elébe megy a felhasználói igényeknek. A sitebuilderek is sokkal jobban örülnének a 4-5 programnyelv és pár ezer konzol-parancs elsajátításának, valamint ezen inspiráció hatására még buzgóbban ajánlanák a megrendelőiknek a Drupal rendszert, amivel immár pár év alatt egy szimpla kis céges bemutatkozó weboldal frappánsan összehozható.

Esetleg valakinek ott a fejlesztők között nem sikerült véletlenül a homlokára böknie, hogy skacok..., mi volna, ha az admin felületen történő modul telepítésekkel együtt a függőségekre is mellékesen úgy rápislantanánk, uram bocsá' még implicit módon telepítenénk is őket...? Persze lehet hogy lehurrognák, hogy ilyet korábban már csináltunk, működött is de akkor hol marad a fejlesztés...??

1
-2
Balu Ertl képe

Az előttem szólók javaslatain túl még megnézheted a PHP logokat, ott ír-e valamit, ami segít?

A két PHP-telepítést úgy is összehasonlíthatod, hogy meghívod a phpinfo() függvényt egy fájlban, amit felteszel a tárhely gyökerébe:

  1. <?php

Ezt a kettőt lokálon és szerveren is végignézve szemmel összehasonlítva, a különbségeket megoldva mit tapasztalsz?

Milyen Drupal verzió? 7 vagy 8?

0
0
Balu Ertl képe

Lehet, kipróbálnám, hogy hozzáadok a felhasználó entitáshoz egy ezen modul által definiált theme_field_type mezőt, így a felhasználó ki tud választani egyet a webhelyen telepített sminkek közül.

Ezután az alábbi kettő valamelyikével megnézni, hogy lehet-e szabályt írni a mező értéke alapján?

0
0
eMeLA képe

Szerintem azért ez így egy kicsit sarkos. Nagyon vígan el lehet lenni composer nélkül (meg Drush nélkül is). Teljes értékű oldalt létre lehet hozni és karbantartani.
Persze amit a Composer (és Drush) nyújt kényelmi funkciók azok akkor nincsnenek.

Én azt gondolom, hogy az adott esetben kell megnézni mi és hogyan célszerű. Egy "családi vállalkozáshoz egy (statikus) weboldal"-nál, egy webtárhelyes felállásban
én nem erőltetném a Composert.

Két példa:
Most firssÍtettem - Composer nélkül - egy oldalt Drupal 7.x ról Drupal 10.x-re. Nagyon meglepődtem, hogy milyen "egyszerű" volt és milyen nagy százalékban átment minden a migrate core modulon keresztül, úgy hogy a 8.x és 9.x Drupal ki is maradt.

Munkahelyen több összetettebb Drupal oldalt kezelünk Composerrel. Kinszenvedés tud lenni a dependenciák, patchek összeakadása miatt a frissítés. Olyan óraszámok jönnek ki... Láttam rövid úton több kollégát, hogy elvérzett egy-egy frissítésbe. Persze azt nem tudom, hogy mi lett volna, ha Composer nélkül frissítünk...

Szóval lehet jó és lehet macerás is a Composer, de ott ahol nincs szükség rá ott szerintem nem kell erőltetni... :)

0
0

...mit tudok: http://web.termuves.hu

Anonymous képe

szóval az érintett rész a sminkben:

if ($mission) {
  switch (i18n_get_lang()) {
    case 'en':
      $own_page = node_load(2);
    break;
    case 'de':
      $own_page = node_load(3);
    break;
    default:
      $own_page = node_load(1);
  }
  echo theme_node(node_prepare($own_page));
}

így még nem teljesen jó, mivel a mission megléte alapján dönti el a kiiratást (szóval minden nyelven kell lennie vmi missionnak amit persze nem iratunk ki), úgyhogy azt kell még módosítani... emlékeim szerint van valami $frontpage v. ilyesmi ami pont jó lesz a $mission helyére. ezt még kidebuggolom, átírom és kész is...

kérdés persze továbbra is az, hogy hogyan lehet ezt szebben és egyszerűbben megoldani?!

0
0
pp képe

a hook_menu-ben csak azt modnod meg, hogy melyik útvonalhoz melyik függvény fog tartozni, vagyis melyik függvény fogja feldolgozni az adott kérést.

a hook_menu-ben oldalakat (page) hozhatsz létre. Ez a feldolgozó függvény fogja kiíratni a formot, a többit a Drupal elintézi neked. Nem kell semmit tenned, csak ha a feldolgozás után másik oldalra akarsz eljutni.

No nézzük hogyan indulj el: (mégquickstartabb gájd)

fogd meg a quickstart-ban található függvényeket(csak a függvényeket a többi kódot hagyd ki!) és tedd bele egy modul fájlba!

Plusz még tegyél bele egy modulneve_menu függvényt:

function modulneve_menu($mc){
$items[] = array(
      'path' => 'test', 
      'title' => t('Ez egy teszt'),
      'callback' => 'test_page',
      'access' => user_access('acces konyvtar letrehozasa'),
      'type' => MENU_CALLBACK,
      );
return $items;
}

Ha minden igaz ez megjelenít neked egy formot, ha a test útvonalat nézed ;)
Nempróbáltam, az rád vár ;)

pp

0
0