„A legújabb php, mysql, composer, drush, stb. kell hozzá”
Ez nem igaz. Pl. composer egyáltalán nem kell a tárhelyre, legfeljebb akkor, ha valami speciális workflow-t használsz az üzemeltetésre. És a többi komponensből sem kell a legújabb. Annyi, hogy PHP 7-el gyorsabb lesz, mivel egyrészt az eleve gyorsabb, másrészt meg úgy optimalizálták, hogy minél jobban kihasználja az abban rejlő lehetőségeket.
Itt találod a szükséges komponenseket: https://www.drupal.org/docs/7/system-requirements/php
Ugye nem csak a drupal modulokat töltötted le és telepítetted fel, hanem a CKEditor honlapjáról az aktuális drupal-odban lévő CKEditor verziójához passzoló plugineket is?
Fontos, hogy a CKEditor drupal 8 modul projektek csak egy keretet adnak az adott pluginhez, de a plugint nem tartalmazzák. A drupal 8 esetén ezeken a modulokon keresztül lehet becsatolni a CKEditor pluginjeit. A folyamatosan frissülő drupal 8 verziókban pedig a CKEditor is frissül, de általában csak a 8.x.y verziók x számának változásával. Vagyis nem feltétlenül a legfrissebb CKEditor verzió található meg az aktuálisan legfrissebb drupal-ban.
Még hozzá is szóltatok, de a "nehasználjálimagegombot" felkiáltás fátyolán át nem vettétek észre a lényeget.
Észrevettem, csak mindig elfelejtem, hogy használni kellene :) Az érdekfeszítő vita pedig nem a formázás színteréről szól, hanem arról, hogy egyáltalán hol kezdődik a formázás. Na így már mindjárt más, nem? :)
Közben a kérdezőnek nem nagyon adtunk kézzelfogható választ:
$node->field_mezoneve[0]['view']-val érdemes próbálkozni, általában pedig tedd fel a Contemplate modult, az megmutatja az elérhető változókat, onnan könnyen lehet puskázni tpl.php-k írásakor.
Sziasztok!
Létrehoztam az adatbázist az egyik szerveren. Amikor installálnám a drupalt a webszerverre, bekéri az adatbázis adatait. Beírom és nem történik semmi. Homokórázik egy kicsit és visszaadja ugyanazt az ablakot, ahol az adatokat kell beírni. Nincs hibaüzenet sem.... Miért lehet ez?
A forward modulhoz nem találtam magyar fordítást.
Mivel katasztrofális kinézetű volt a "végeredmény", elkezdtem lefordítgatni.
Az admin felület "Configure settings for forward module." részben bizonyos dolgokat átírogattam, de igazából semmi különös hatása nem volt a küldött üzenet kinézetére.
A "forward.module" átírásával már sokat változott a kép azonban
Az "ANSI" kódolású szövegből hiányoztak az ékezetes karakterek.
Sziasztok!
A fent említett modulok segítségével szeretnék képeket feltölteni, hogy aztán galériákba tudjam rendezgetni őket. Két képméretre lenne szükségem. Az egyik egy kis bélyegkép(ez jelenne meg a galériák összegzésénél, valamint a galériában lévő képek összegzésénél), a másik pedig egy nagyobb(ez jelenne meg, amikor rákattintok az egyik képre).
Drupal 7
Egyszer csak azt láttam, hogy összezavarodtak az angol menüpontok.
Néztem a taxonomy-ban, aztán az általa generált menüben, majd az az alapján létrehozott menükben.
A taxonomy-ban egy konkrét menüpontot szerkesztés módban nézve átváltottam az angol fordítására, ezt látom az oldalon:
Undefined index: href in menu_local_tasks line 2052 of ...../includes/menu.inc
karaktersorozatok frissítése, cache törlése, semmi....
Ha van iconv támogatás a szerveren (az utf-8 szövegek "fordítása"), akkor ehhez egy kis segítség:
$text1 = "ma délután ősöm elálmosodott";
print "$text1";
$text2 = iconv("iso-8859-2", "utf-8", "$text1");
print "$text2";
$text3 = iconv("utf-8", "iso-8859-2", "$text2");
print $text3;
A bemeneti szöveget utf-8-asítja, majd vissza. Végülis mindegy hogy melyik szerveren csinálod meg ezt - ott ahol fogadják a szindikált tartalmat, vagy a te drupalos oldaladon.
Időközben az alábbi módosításokat végeztem:
if ($enc="iso")
{
$output = "*** beállítod az isot ***";
/* többit nem bántod */
drupal_set_header('Content-Type: text/xml; charset=iso-8859-2');
$output = iconv("utf-8", "iso-8859-2", "$output");
print $output;
}
else
{
$output = "*** beállítod az utf-8-at ***";
/* többit nem bántod */
drupal_set_header('Content-Type: text/xml; charset=utf-8');
print $output;
}
A Drupal alap ,htaccess fájlja a PHP néhány beállítását változtatja meg. Ezt valahogy el kell érni, hogy a php.ini-ben vagy a te hosztod számára állítsák be. Sajnos ini_set()-tel beállítani ezeket már késő, ezért van a .htaccess-ben. Ezen kívül a speciális kiterjesztéseket védi olvasástól, amit viszont az IIS-ben is be lehet állítani. Ráadásul a rövid webcímeket is onnan próbálja támogatni, amit másképp kell csinálni IIS alatt. Ezzel elvileg megvan az alap .htaccess tartalma.
A files mappában létrehozott .htaccess létrehozását és létezésének ellenőrzését nyugodtan kikommentezheted. Azt állítsd be, hogy onnan semmilyen futtatható programot ne indítson el az IIS. A .htaccess ezt próbálja elérni. Tehát ha valaki feltölt egy .php szkriptet, akkor ne fusson az ott le.
Sajnos ez tényleg így van
Én már most fel tudnám sorolni, hogy kik lesznek következők, akik a futanet.hu sorsát nem fogják tudni elkerülni. A legbosszantóbb pedig az, hogy nem azért nem tudják elkerülni, mert nem ismerik a biztonsági réseket. Figyelmeztettem rá őket, és sz...ak rá. És nem egy cég, hanem szinte az összes. Nulla büntetőjogi felelősség, nulla kockázat. Miért is foglalkozna vele ? Inkább bízik benne, hogy nem ő lesz a következő és előbb fog fizetni a grafikusnak az új logóért vagy a marketingesnek aki még több látogatót hoz, mint a biztonságért.
szabozee (zee zee zee kukac free mail pont hu)