HF leon képe

Beküldte HF leon - 2017. július 31. 13.00

Ráadásul a kérdésemre sem feleltél.

Egy-két tipp, hogyan tudod ellenőrizni a CKEditor verzióját:

1;
Látogass el a tárhelyeden, ahova a drupal van telepítve az alábbi mappába: core\assets\vendor\ckeditor
Itt a ckeditor.js, vagy a CHANGES.md fájlban megtalálod a CKEditorod verzióját.

2;
Nyiss meg egy olyan oldalt, ahol a CKEditor betöltődik és keresd a forráskódban az alábbi sort:
<script src="/core/assets/vendor/ckeditor/ckeditor.js?v=4.6.2"></script>

Természetesen a verziószám a kérdőjel után eltérhet, ha neked modernebb, vagy elavultabb verziót töltene be a Drupal.

A Drupal CKEditor kiegészítő modulok a hibaüzeneteikben, amelyben hiányolják az adott plugint. Mondhatni össze vissza dobálóznak a verziókkal. Most, hogy ránéztem, teljesen kedvük szerinti verziókat írnak az üzenetbe. Volt, amelyik a 4.5.6-oshoz kéri a plugint, volt, amelyik a 4.7.1-hez. Tehát ezekre nem kell adni. Az üzenet lényege, hogy hiányzik az adott js plugin-t tartalmazó mappa a libraries könyvtárból. A plugin verzióját viszont a drupal-ban valóban betöltődő CKEditor verziójához kell igazítani.

Sajnos igazán jól integrált a CKEditor színvonalát megütő más szerkesztő nincs jelenleg a Drupal 8-hoz.

Amik jelenleg léteznek:
UEditor
Ez egy komolyabb próbálkozás, habár az is igaz, hogy a kínai baidu-hoz kapcsolódik.
Aloha Editor
Ez viszont elég fapados.

0
0
HF leon képe

Beküldte HF leon - 2019. március 19. 18.30

Ahogy látom valóban teljesnek tűnik a library. Még van benne hiba. Az Insert selected, még nem működik csak a Save and insert. (Valószínű a twitter videóban újabb dev verzió volt, mint, ami tegnap este elérhető volt a drupal.org-on, mert abban úgy néz ki működik)
A most elérhető dev is tartalmazza a hibát. Csak a mentés és beillesztéskor adja hozzá a tartalom médiamezőjéhez az elemeket. Ha nincs új feltöltés, csak a meglévők közül választunk ki elemeket, akkor nem működik.
Valamint a távoli video esetén a szélesség, magasság szabályozása is nehézkes a tartalom megjelenítésénél. iframe az iframe-ben :).

Sajnos a twitter-en is mondta webchick, hogy a kész ui nem azt jelenti, hogy stabil is.

Lehet, mégis csak a 8.8-ra lesz belőle valami. Minden esetre úgy tűnik a médiakönyvtár jól halad és szépen közeledik a stabil verzió, még, ha a 8.7-re nem is készül el a stabil kiadás. Bár, még reménykedem.

Az embed-re, még nincs core megoldás sajnos. Van, még idő, de jó kérdés vajon eldől-e milyen formában valósul meg és elkészül-e a 8.7-re, mert ebből jelenleg kísérleti verzió sincs :(.
Nagyon kíváncsi vagyok rá végül milyen formáját választják a media embed megvalósításának.

Ui:
Nem hoztam létre domaint a gyors próbához. Úgy néz ki almappába telepítve elrontja az ajax kérést Insert selected esetén. Na majd este újratelepítem. Mondjuk azért ettől függetlenül működnie kellene almappa esetén is.

Ui2:
Nos most újratelepítettem a legújabb dev verziót domain-nel. Most működött az Insert selected és a Save and insert is. A távoli video esetén a szélesség, magasság szabályozása továbbra is nehézkes a tartalom megjelenítésénél. iframe az iframe-ben :).

0
0
Joee képe

Beküldte Joee - 2019. szeptember 22. 18.29

Annyit tennék még hozzá, hogy a háttértároló sem lassú. Egy SSD van a gépben és hely is van rajt bőven.
Ha belépek a phpMyAdmin felületére és kijelölöm a Drupal adatbázisát akkor azt is nehezen adja be. Ha utána rákattintok pl a "Méret" szerinti rendezésre akkor az is 10 mp-ig tart mire megkezdi az átrendezést. Ha a fejléc másik rendezési szempontjára kattintok azok is mind 10 mp időt vesznek igénybe mire teljesülnek. A mysql my.ini fájlban az alábbi gyorsítással próbálkoztam a mysqld szakaszban, de semmiféle változást nem eredményezett:
innodb_buffer_pool_size = 1G
innodb_log_file_size = 256M
Néztem a processzor sebességeket is a Drupal Admin menüpontok váltásakor és a legnagyobb sebességet az Apache HTTP Server foglalja (30-35%). A teljes processzor használat ilyenkor 65%.
A legtöbb memóriát a Crome foglalja 450 Mb körül.
A mysql.exe is csak 4-6% processzorsebességet használ és 96 Mb memóriát foglal el.
Ami meglepő, hogy a Drupal menüváltása után legnagyobb hálózati forgalmi terhelést a Google Chrome teszi, de az is csak 0 - 0,1 Mb/s!!! Amíg egy Facebook oldal kezdőlap újraolvastatása 11 Mb/s hálózati sebességet generál és 1-2 mp alatt betöltődik, addig egy helyi szerveren levő Drupal Admin menüváltás csak 0,1 Mb/s-ot, de 8-16 mp-et vesz igénybe. Miért kicsi és lassú a helyi szerveren levő Drupal forgalmazás, míg a távoli Facebook százszoros átvitellel repeszt? Ennyire azért nem lehet lassú az az Apache, hiszen még terhelhetné nyugodtan a processzort és memória is lenne még neki a 4 Gb RAM-ból. A háttértároló sem lassú, mert egy SSD van benn és helye is lenne neki rajt bőven.

0
0
botond1977 képe

Beküldte botond1977 - 2021. december 21. 19.17

Valahogy nem működik ez.
Például most kijött az Easy Breadcrumb 2.0.2 változata. Jelzi az adminban.
Nekem a 8x-1.15 van fent.
Upgrade-elni akarok az új branch-re.

Betettem a composer.json fájlomba a jelenlegi állapotnak megfelelő verziót:
[...]
"drupal/easy_breadcrumb": "^1.15",
[...]

Majd composer update. Szépen "fel is húzta".
composer show-ra mutatta is.
Majd frissítettem az új ágra:
composer require 'drupal/easy_breadcrumb:^2.0'
Frissült is, lekérdezésre mutatja is:
composer show "drupal/*"

[...]
drupal/easy_breadcrumb 2.0.2 Adds configuration to the system breadcrumbs.
[...]

Majd utána drush updatedb és drush cr.
Ezután visszamentem az adminba, és újra betöltöttem a frissíteni valók listáját, és ugyanúgy ott van ez a tétel:

"Easy Breadcrumb (Nem támogatott) 8.x-1.15 2.0.2 (Kiadási információk)
Ez a frissítés egy nagyobb verzióváltás, ami azt jelenti, hogy a mostani verzióval nem lesz visszafelé kompatibilis. Ilyen esetben ajánlott a kiadási információk szokásosnál alaposabb tanulmányozása és csak saját felelősségre frissíteni."

Tehát ez így nem működik.
Amit írtam korábban, hogy most az admin szerint van egy 8.x-1.15-ös változatú modulom, és a composer szerint meg van egy 2.0.2-es változatom.

Itt akárhogy is, valahogy párhuzamosan létezik két verzió a modulból.

Tehát a kérdésem továbbra is az lenne, hogy hogyan tudom "composerizálni" egyesével a modulokat? Mert ezzel a módszerrel nem történik semmi.

Vagy esetleg kihagytam volna valamit?

Előre is köszi a segítséget!

0
0
szt képe

Beküldte szt - 2009. április 4. 23.50

Igazából aboros megadta a megoldást, de azért leírom részletesen, hogy én hogy csináltam:

1.
A smink könyvtárában lévő block.tpl.php fájlról (ami alapesetben az összes blokkot generálja) készítettem egy block-menu-menu-tevekenysegeink.tpl.php nevű másolatot ugyanide.
Egy kicsit bajban voltam, hogy mi legyen az új fájl neve, ami a fentiek szerint block-[module]-[delta].tpl.php formátumú, csakhogy honnan tudhatja a magamfajta kezdő, hogy mi a [module] és a [delta] értéke? Biztos egyszerűbben is lehet, de én belekukkantottam az adatbázisomba, és ott a blocks nevű táblából ki is lehet puskázni az adatokat. Eme tábla sorai az összes blokkról szolgáltatnak adatokat: a region oszlopban lévő érték mutatja, hogy melyik régióba tettük a blokkokat (left, right, footer stb.), és ha sikerült kitalálnunk, hogy melyik a mi modulunk sora, akkor a module és delta oszlopban lévő értékeket kell a [module] és [delta] helyére helyettesíteni. Szóval így lett nekem block-menu-menu-tevekenysegeink.tpl.php.
A táblából az is látszik, hogy a delta nem mindig 0,1,2 stb. értékű szám, hanem lehet text is (pl az én esetemben: "menu-tevekenysegeink", vagy az elsődleges linkeknek "primary-links").
Egy kis angol info ehhez: http://drupal.org/node/104319

2.
Az eredeti block.tpl.php fájlban lévő kódot:

<div class="defaultblock">
   <h2><?php print $block->subject; ?></h2><!--block title-->
   <div class="blockcontent"><?php print $block->content; ?></div>
</div>

az új block-menu-menu-tevekenysegeink.tpl.php fájlomban módosítottam erre:

<div class="defaultblock">
   <h2><?php print t($block->subject); ?></h2><!--block title-->
   <div class="blockcontent"><?php print $block->content; ?></div>
</div>

Tehát csak bekerült a változó a t() függvénybe, amit már valóban könnyedén lehet lokalizálni.

3.
A Drupalban az angol nyelv az alapértelmezett (és kiirthatalan), szóval úgy járunk a legjobban, ha fordítás előtt a t() függvényekbe angol szöveg kerül. Én is átírtam a menü nevét a menüadminisztrációban angolra, hogy aztán magyarra fordíthassam...

4.
...az alábbi helyen: admin/build/translate/search.
Jelen esetben a "Beépített felület" szövegeiben kell keresni az angol menünévre, majd szerkesztés, fordítás magyarra és kész.

0
0

Védd az állatokat! ;)

erdelyik képe

Beküldte erdelyik - 2010. április 26. 16.10

Na szóval. Megtaláltam a facebook kódját az open graph alkalmazáshoz, de valami nem stimmel. Ebben kellen segítség.

ha valaki nem ismerné az Open Graph alkalmazást, akkor előbb bemutatnám. Ezt pénteken hozta ki a facebook, gyakorlatilag ki lehet vele terjeszteni az egyik legkedveltebb facebook eszközt, a "Tetszik" gombot. Eddig csak a facebook felületen jelent meg ez a lehetőség, az ismerősök által beküldött tartalmakat mellé lehetett bejelölni, hogy tetszik. Most ez a funkció beilleszthető a különböző honlapok felületére is, így nem az adott tartalom linkjét osztja meg a látogató saját facebook fiókjában, csupán kattint egyet és máris megjelenik egyrészt az érintett honlap felületén, másrészt a kattintó facebook fiókjában.

Tekintettel arra, hogy a készülő(?) drupal modul még cvs-ben sem érhető el, barkácsoltam. Két kódcsoportot kell elhelyezni az oldalon.

Az első kódcsoport a head-ben:

<meta property="og:type" content="website"/>
<meta property="og:url" content="http://www.domain.hu<?php print $node_url?>"/>
<meta property="og:image" content="http://www.domain.hu/picture.jpg"/>
<meta property="fb:admins" content="100000303940098"/>

ahol
og:type a kiválasztott tartalom kategóriája a facebooknál
og:url az adott oldal url-je. Hogy ne csak magára a portálra lehessen tetszést nyilvánítani, ide kell a path is
og:image az adott oldalt jelképező kép
fb.admins egy facebook-on regisztrált felhasználó azonosító száma, ő az aki egyébként a facebook-on kezelheti a honlappal kapcsolatos információkat.

A másik kódcsoport, amit a content résznél kell valahogyan elhelyezni:

<iframe src="http://www.facebook.com/plugins/like.php?href=http://www.domain.hu<?php print $node_url?>%2F&amp;layout=button_count&amp;show_faces=true&amp;width=450&amp;action=like&amp;colorscheme=light" scrolling="no" frameborder="0" allowTransparency="true" style="border:none; overflow:hidden; width:450px; height:20px"></iframe>

Mint látjátok, ez egy sima iframe, ahol a kódok jelentős része az iframe formázása, egyet kivéve: href=http://www.domain.hu<?php print $node_url?>

Elvileg minden bekerült a template-be, mégsem működik, illetve hibásan. Nem az egyes oldalak url-jét (www.domain.hu/tartalom) és címét (tartalom címe), hanem csak a portál url-jét (www.domain.hu) és címét (portál címe) jeleníti meg.

Az Open Graph API címe: http://developers.facebook.com/docs/opengraph

Lelkes és hálás lennék, ha valaki megfejtené, hogy mit szúrtam el. Én a <?php print $node_url ?> részre gyanakszom, de azt addig, amíg be nem állítottam a facebook-os azoosítót, még felismerte.

0
0
eager képe

Beküldte eager - 2011. július 4. 23.35

Szóval neked régiók kellenek, amibe pakolhatsz blokkokat.

  • Az .info fájl,
  • a page.tpl.php és
  • a stíluslap (.css)

a sminked mappájában lesznek (asszem, D7-ben ott vannak legalábbis), ezekkel kell dolgoznod.

Ez itt a Drupal 6 alapértelmezett page.tpl.php-je. Ebből kinéztem, hogy hogy csinálnak régiót.

A bal oldalsáv tipikus régió, azt veszem tehát példának:

      <?php if (!empty($left)): ?>
        <div id="sidebar-left" class="column sidebar">
          <?php print $left; ?>
        </div> <!-- /sidebar-left -->
      <?php endif; ?>

Neked tehát ezt az ötsoros kódot kell beilleszteni a sminked page.tpl.php-jába, oda, ahol szeretnéd, ha létrejönne a régió - csak minden olyan személyes adatot, amely itt a bal oldalsávra utal, ki kell cserélned az általad választott adatokra:

  • a régió gépi nevét,
  • a befoglaló div id-jét
  • és az a class-dolog sem úgy fog kelleni, ahogy ott van (könnyen lehet, hogy semmilyen class nem fog kelleni)

A példában a - left - a gépi neve a régiónak, illetve a 2. és 4. sorban pedig megadnak egy divet, ami tartani fogja a majd oda helyezendő blokko(ka)t (ezt a divet az id-je alapján majd css szabályokkal kell ellátni a css stíluslapon (az szintén a smink mappájában lesz) - hogy hogyan jelenjen meg).

Az alapértelmezett D6 .info fájlban a bal oldalsávot ez a sor képviseli, erről lehet lelesni a syntax-ot (egy hasonló sorral kell kiegészítened a már ott lévő régiók sorát, csak saját megnevezéseket használva):

regions[left] = Left sidebar

(látható, hogy a "gépi név" itt annyi: left - ez jön vissza az 1. és 3. sorban ( a "Left sidebar" pedig az "ember neve" a régiónak, így lesz megnevezve az adminfelületen)

Cache ürítése: Drupal 7-nél - ha az .info fájlt is érintette a módosítás - nekem nem volt elég a Theme registryt újraépíttetni, hanem csinálnom kellett egy full Cache ürítést a performance oldalon - hátha ez megoldja, hogy a többi régiód ne tűnjön el...

(ha a sminket egy dummy-telepítésen csiszolod, akkor nem kell visszaállítgatni sem a webhelyedet, ha valami nem jön össze elsőre)

További info, hogy állítólag a sminkekre is igaz, hogy nem piszkálunk bele az eredetibe (mert mi van, ha frissíteni akarod), hanem kell csinálni egy belőle származtatott alsminket, és azon végrehajtani a módosításokat (az alsminkekről nekem nincs bővebb infóm).

Ebben a cikkben lehet olvasni azokról az átfogó feladatokról, amelyeknek a részét képezi a fenti beavatkozás...

5
0
Balu Ertl képe

Beküldte Balu Ertl - 2024. március 27. 22.41

Nem egyszerű a képfeltöltés itt Drupal․hu-n, javítottam. A kép alapján ezzel a paranccsal indultál:
php -d memory_limit=256M web/core/scripts/drupal quick-start demo_umami (Van esetleg valami oka, hogy nem Drush-sal indítod a telepítést?)

A kapott hibaüzenet pedig:
[ERROR] You must have the pdo_sqlite PHP extension installed. See core/INSTALL.sqlite.txt for instructions.

A hivatkozott core/INSTALL.sqlite.txt fájlban az „SQLite database creation” cím alatti első bekezdés nyers fordítása:

„A Drupal telepítője létrehozza az SQLite adatbázist. Az egyetlen
követelmény, hogy a telepítőnek írási jogosultsággal kell rendelkeznie a könyvtárhoz ahol az adatbázis fájl található. Ez a könyvtár (nem csak az adatbázis-fájl) is írhatónak kell maradnia a webkiszolgáló számára, hogy az SQLite a továbbiakban is továbbra is működni tudjon.”

A hivatalos Evaluator Guide („Kipróbálási útmutató”) is egy ugyanígy felparaméterezett parancsot ajánl az „Install Drupal & Log In” c. szakaszban. Ugyan nincs kihangsúlyozva ebben a leírásban, de fontos tudni, hogy ezzel a paranccsal a Drupalt egy úgynevezett Quick Start („Villámindítás”) üzemmódban telepíti fel. Ennek lényege, hogy sem webkiszolgálót, sem pedig adatbáziskiszolgálót nem igényel annak érdekében, hogy a felhasználó minél hamarabb kipróbálhassa. Előbbi céljára a PHP saját belső beépített webkiszolgálóját, míg az utóbbira az SQLite-ot használja. (Ennek az adatbázismotornak az a különlegessége, hogy egyetlen fájlban tárolja minden adatát, így – a nevéhez hűen – valóban „pehelysúlyú” tud maradni.) Ebben a Quick Start üzemmódban nincs döntési lehetőséged a használni kívánt adatbázismotorról.

Visszatérve a képernyőképedre: a vörös hibaüzenet arról tájékoztat, hogy a PHP-d jelenlegi telepítésében nincs bekapcsolva az SQLite futtatásához szükséges kiegészítő. Ebből következően a Quick Start üzemmódban sem tudod elindítani a Drupalt, amíg ez a követelmény nem teljesül.

Két lehetőséget látok:

  1. Ha mindenképp Quick Start üzemmódban szeretnéd elindítani: egy $ php --ini parancs kimenetében keresd meg a „Loaded Configuration File” sort és az ott látható útvonalon lévő konfigurációs fájlban töröld a pontosvesszőt a ;extension=pdo_sqlite sor elejéről. Nem tudom, nálad hogy van feltelepítve a PHP, de biztos-ami-biztos alapon újraindítanám a gépet, hogy érvényre juttassam a változtatást.
  2. Ha mindenképp MySQL adatbázissal szeretnéd telepíteni (ajánlott): ebben az esetben szükséged lesz egy teljes *AMP stack („rakás”) összeállítására. Oprendszertől függően ez lehet xAMPP vagy MAMP. Ehhez magyar nyelvű útmutatást a Kézikönyv vonatkozó fejezetében találsz. (Még D8-ra íródott, de nagy vonalakban hasonlóan zajlik a folyamat D10-re is.)
0
0
Balu Ertl képe

Beküldte Balu Ertl - 2024. szeptember 24. 02.52

„Szóval akkor most a Composer, vagy a Drush telepíti magát a Drupal-t?”

A Drush, ezzel a paranccsal: $ drush site:install. Használhatod a parancs --help kapcsolóját a leírásának elolvasásához vagy online itt találod. (Ezen az oldalon ne felejtsd el kiválasztani a Drush-od verzióját, előfordulhatnak eltérések a verziói között.)

„[…] mikor lehet megadni az adatbázis infókat, mert ugye anélkül nem fut le a telepítés”

Vagy még futtatás előtt beleírod a settings(.local).php fájlodba (ekkor keress rá a $databases változóra, hogy megtaláld a leírást benne, hogyan lehet), vagy pedig magának a Drush-parancsnak adod át őket bemenetként (erről pedig az előbbi --help kapcsolóval olvashatsz).

„[…] de nincs egy összefoglaló kép az egészről.”

Ezt nem értem pontosan, mire gondolhatsz, de a Composer alfája és omegája a két fájlja a projekted gyökerében: a composer.json és a composer.lock. Ezek (szinte) minden információt tartalmaznak, amiből képet kaphatunk a projektünk összetételéről.

„És akkor ott van az, hogy globálisan, vagy lokálisan települt-e?”

Feltételezem, itt a Composer-re gondolhatsz. A projekted gyökerében állva egy $ whereis composer paranccsal kilistázhatod az ilyen nevű futtatható binárisokat, amik fellelhetőek az oprendszered (Linux vagy macOS – Windowst nem tudom) $PATH változójában felsorolt könyvtárak valamelyikében. Nekem például egy ilyen eredményt ad:
composer: /usr/local/bin/composer /var/www/html/vendor/bin/composer

Nálam ebből az első a globális, a második a projekt függőségeinek könyvtárába (vendor/ mappa) telepített, tehát a lokális. Ezeknek eltérő lehet a verziója és a beállításaik, ezért sokan ha tutira akarnak menni, szeretik fixen kiírni a projekt saját Composer-példányának az útvonalát, nehogy azon haljon el a szkript, hogy tévedésből a globális példányt keresi, ami viszont ritkán szokott telepítve lenni a szervereken.

„tehát az "install" szót használja, ami telepítést szokott jelenteni”

A drupal/core-recommended projektsablon többek között igényel egy drupal/core-project-message nevű Composer-bővítményt is. Ez a kis kiegészítő annyit csinál, hogy kiolvassa a „szülő” projektsablon composer.json fájljából az ott megadott üzenetet és megformázva visszaszajkózza a telepítési folyamat egy bizonyos pontján a parancssorba. A hátteréről ebben a 2019-es ticketben olvashatsz, ez a kettő pedig még nyitott, de szintén ehhez kapcsolódik. Ha gondolod, az utóbbi alá odakommentelheted az észrevételed az „install” szó helytelen használatáról. Ha szeretnéd, szívesen segítek megfogalmazni.

„[…] mert ha hol így, hol úgy, akkor a Drush nem fogja tudni követni a nem a Drush-ból indított frissítéseket”

Így van, ahogy írod, annyi pontosítással, hogy itt nem a Drush-ról van szó, hanem a Composer-ről, hiszen a nyilvántartást a telepített komponensekről és azok verzióiról (és még sok másról) a Composer vezet, nem a Drush.

„le lehet valahogy tiltani a grafikus felületről indítható frissítéseket?”

A kódbázis grafikus felületen keresztül való piszkálását szándékosan szorítjuk már háttérbe, már a 10.4-es alaprendszerből kikerült ez a régi örökség, a mögöttes érvekről is ugyanitt lehet olvasni. A letiltás ötlete jogos, ám életszerűtlen, hiszen általában 1–2 adminisztrátor végzi a webhely frissítését, ők pedig azért csak meg tudnak állapodni maguk között a mikéntjéről.

1
0

Acidfree már működik

Beküldte alippai - 2007. február 19. 20.16
alippai képe

Friss verzióm van: Drupal 5.1, Acidfree-HEAD mai
Eddig se ment, már mindent próbáltam, az adatbázisba is beletöröltem, meg írkodtam a régi modulba (remélem nem ez okozza a problémát)
Nemtudom, hogy csak én rontottam-e el valamit, vagy tényleg nem megy az Acidfree modul. Nekem az a bajom, hogy az automatikusan létrejövő albumok (per user) nem jelennek meg az Acidfree albums menüpontban és a képek feltöltése is csak mass importal megy, egyébként azthiszem az útvonalban ront el valamit...

Fórum: 
Modulok használata