Zen és a Drush
„Alsminket készíteni a Drupalban elég egyszerű.”
Ezt a gondolatot megerősítve: a nagyon jól összerakott Zen sminkkel és Drush használatával még egyszerűbb a dolog:
drush zen "Csodaszep Zen alsmink" csodaszepzenalsmink --without-rtl
Ez máris elkészíti a sites/all/themes
könyvtárban a csodaszepzenalsmink
alkönyvtárat és az egész alsminket, mindenhol a csodaszepzenalsmink_
előtagot felhasználva. Az olvasható név értelemszerűen a "Csodaszep Zen alsmink" lesz. A --without-rtl
kapcsoló segítségével azt érhetjük el, hogy a sminkbe ne kerüljenek a bele a jobbról-balra írós (RTL) nyelvek számunkra esetleg felesleges stílusfájljai (pl. ha valaki magyar, angol és német nyelvű honlapot szeretne, annak nyilván ezek feleslegesek).
A Zen számára a kiindulási pont ennek elkészítésekor egyébként a Zen könyvtárban lévő STARTERKIT
könyvtár, aminek a fájljaiban mindenhol a STARTERKIT_
előtagot használja fel (ezt cseréli le az alsmink elkészítésekor).
Ez még azt az 5 percet is megspórolja nekünk, ami egyébként szükséges lenne egy alsmink elkészítéséhez egy Zen alapsminkből. :)
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
Jól tetted, hogy így írtad át
Jól tetted, hogy így írtad át a .htaccess
(két s-sel :) ) fájlt (Options +FollowSymLinks
kikommentezése, Options +SymLinksIfOwnerMatch
sor beírása (ez is mindenképp kell); nem csak a Drupal rootjában lévő .htaccess
fájlt kell átírni, hanem a sites/default/files
könyvtárban lévőt is!), mivel pontosan ez a teendő a Tárhelyparkon a szigorítás óta. Akit érdekelnek a miértek, az épp az általad linkelt cikkben megtalálja a magyarázatot, valamint itt, drupal.hu-n is megtalálható a szolgáltató válasza:
http://drupal.hu/comment/69056#comment-69056
Ezen a tárhelyen NEM átmeneti ez a megoldás, hanem ez a végső megoldás.
Itt is folyt erről beszélgetés:
https://www.facebook.com/tarhelypark/posts/268993219893507
Ahogy ott is linkeltem, van ezzel kapcsolatos, Drupal 8-at érintő issue queue, amivel talán még érthetőbbé válik, miért is merült fel erre az igény:
http://drupal.org/node/1269780
Tehát nem ez az egyetlen szolgáltató, ahol ezt a korlátozást bevezették, megvan rá a magyarázat, a linkelt helyeken lehet erről tájékozódni.
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
Nálad van a gond: max_allowed_packet értékét állítsd magasabbra
Most kíváncsiságból kipróbáltam, mert engem is érdekelt már a dolog, és nekem gond nélkül működik, eljutott a telepítés legvégéig, tudtam is használni az oldalt.
Tehát ahogy írják az issue-ban, egyszerűen a MySQL-szerverednek adj több max_allowed_packet-et, ezek szerint az másoknál is hiba volt, ha túl alacsonyra volt állítva, emlékeim szerint a MySQL alapértelmezett profilja valami nevetségesen alacsony, 1MB-os értékre van állítva, ami egyetlen hosszabb távon is üzemeltetett Drupal-profilnak sem elég (igen, jól emlékeztem: http://dev.mysql.com/doc/refman/5.1/en/packet-too-large.html, "The server's default max_allowed_packet value is 1MB.").
Szóval nem a telepítési profillal van a baj.
Egy-két screenshot az installálásról:
http://i.imgur.com/P9jWeAN.png
http://i.imgur.com/otuXH0V.png
http://i.imgur.com/baCIDha.png
http://i.imgur.com/BO8zXSo.png
http://i.imgur.com/BAYTzyH.png
Aztán a kész oldal:
http://i.imgur.com/M15lUiW.png
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
ország != nyelv
pp megelőzött, de azért beküldöm, ne vesszen kárba, szenvedős kánikulában izzadó ujjakkal tableten pötyögni :)
Sokan, akár még a legnagyobbak közül is gyakran elkövetik az 1 ország = 1 nyelv általánosítás hibáját, de te ne tedd. Kérdésedben ismét két fogalom keveredését érzem: a fizikai tartózkodási geopozíció és a használt nyelv tehát két, egymástól akár véletlenszerűen is eltérő érték, ezért egymásra következtetni belőlük nem lehet.
Az IP-cím használható a geopozíció hozzávetőleges megtippelésére, a ccTLD pedig a nyelv kitalálására. Ezeknél a megközelítőleges becsléseknél mindig jobb, ha magát a usert megkérdezed, hogy hol van (írja be a címét, vagy annak egy részét) és milyen nyelvet szeretne.
De visszatérve kérdésedre: igen, a D7 tud ilyet:
admin/config/regional/language
oldalon vedd fel a támogatni kívánt nyelveket- Minden felvett nyelv sorának végén az Edit, a nyíló oldalon tudod eldönteni, hogy melyiket választod: VAGY "Path prefix language code" VAGY "Language domain". Mind a kettőt ne töltsd ki, mert összezavarodik.
- Ha három, vagy több nyelved van, akkor végig mindegyiken ugyanazt a mezőt töltsd ki, de értelemszerűen más adatokkal. Olyat tehát nem lehet, hogy a lettet doménből, a litvánt meg URL-ből döntse el.
admin/config/regional/language/configure
oldalon pedig végül sorbaállíthatod a döntési feltételeket. Ha tiszteled a felhasználóidat,akkor user preference a legelső.- Ezután jöhet a tartalmak (meg minden egyéb) többnyelvűsítése, de az már másik topik.
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
így van, állandóak
a blokkok html id -je a blokk "gépek által használt" nevéből képződik. ez néha egy szó lesz, egyedi blokkok esetében pedig a blokk entity azonosítója. ezt azért nem találod meg a fileokban sehol, mert programozottan képződik. a template_preprocess_block függvény állítja elő ezt az id -t, itt:
// Create a valid HTML ID and make sure it is unique. $variables['block_html_id'] = drupal_html_id('block-' . $variables['block']->module . '-' . $variables['block']->delta); }
a #block-block-4 példánál maradva a fenti kódból látszi, hogy az id első része "block-" az fix, a második rész azért "block" mert az egyedi blokkod tulajdonosa a block module, a négyes szám pedig a block deltája.
-
clear: both;
- A hozzászóláshoz regisztráció és bejelentkezés szükséges

Reprudokció
Még a fentihez: egy másik gépen gentoo alatt megy minden rendesen.
Szoval elakadtam és fogalmam sincs mit rontottam el.
Mindkét esetben ugyanazt telepítettem. Az egyik gépen működik a másikon nem.
Ki érti ezt.
covek
- A hozzászóláshoz regisztráció és bejelentkezés szükséges

talaltam egyet
Most talaltam egy erdekes peldat:
Ezt a linket én töröltem. chx.
A kerdesem az, hogy ilyen megoldasmegoldhato lesz javascript nelkul?
Tehat a drupal el tudja kesziteni a tablazatot a css alapjan, vagy ennek nem latjatok a realitasat?
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
hmm
Üdv!
Den:
A wordpress importálással nem lesz baj, megírom a saját php scriptemet hozzá (sok custom field miatt nem jó a wordpress_import), egyszer már a 6-os verziónál megcsináltam, de akkor végül wordpressben oldottam meg inkább a form dolgot.
CPU igény csak remélem, hogy kevesebb lesz, lévén drupalnak beépített cache rendszere van (és opcode cache-t is könnyebb vele használni), illetve ha wordpressben akarok fórumot, custom avatart, privát üzenetet, stb. akkor annyit kell rajta javítgatnom, patchelgetnem, hogy fene tudja mennyi idő alatt készülök el vele, és akkor még nem beszéltünk arról, hogy a különböző pluginok mennyire támogatják a gyorsítótárazást, mennyire stabil és gyors a kódjuk, stb. - míg drupalban ezek jelentős része beépítve elérhető - ez sokat jelent.
5; A webform beépített rendszere nem jó, ugyanis oldalspecifikus linket küldenek be, ahonnan curllel adatokat szedek le egy egységes adatlap kialakítása érdekében. Fontos tehát, hogy a linket jól adják meg, mert ezzel töltöm ki az adatok egy részét, és ezzel ellenőrzöm, hogy nem küldenek be dupla tartalmat.
nevergone:
Nem vagyok profi, de pl. ezt a formot le tudnám programozni tiszta php-ban. A probléma ott kezdődik, hogy egy frameworkhöz kell (drupal) igazítanom, ami nem tűnik túl egyszerű feladatnak. Az biztos, hogy nem 5 perc lesz, és hogy a hook_form_altert kénytelen leszek elmélyülten tanulmányozni, csak reméltem, hogy valaki már csinált ilyet.
Azt olvastam, hogy a drupal formoknak beküldés előtt van egyfajta postprocess fázis, ahol el lehet helyezni a kis php scriptjeinket, de nekem inkább előtte kéne feldolgoznom adatokat, és defaultként hozzárendelni a mezőkhöz (esetleg el is rejteni az így már értékkel bíró mezőket).
Köszönöm az eddigi segítséget, ha valakinek van még tippje, kérem írjon! (form rész lenne a legfontosabb)