Telepítéskor adatbázishoz nem tudok csatlakozni

kkwx képe

Hellósztok

Most szedtem le a Drupal 7.28-at és amikor az installálásnál az adatbáziskapcsolathoz érek egyszerűen nem tudok továbblépni :S.

Beírtam az adatbázis nevét:
d7-teszt
Felhazsnálónév/jelszó párost:
admin/admin

majd ezt az üzenetet kaptam:
"In order for Drupal to work, and to continue with the installation process, you must resolve all issues reported below. For more help with configuring your database server, see the installation handbook. If you are unsure what any of this means you should probably contact your hosting provider.

Drupal verzió: 

Pathauto linkek automatikus átirányítása másik oldalra

tiburi képe

Sziasztok,

egy (számomra) érdekes kérdésben szeretném a tanácsotokat kérni.

Adott egy honlap több ezer tartalommal, amit felvásárolt egy másik honlap üzemeltetője és most minden ott lévő "article" node tartalom átkerül oda (másik domainra, másik (szerencsére) drupal, azonos verziójú 7-es motorra).

Drupal verzió: 
Melyik modulhoz, modulokhoz kapcsolódik a téma?: 

Fontyourface-probléma

szoda képe

A fontyourface modul segítségével telepítettem egy betűkészletet, az Infini-t. Konvertáltam, feltöltöttem custom font modul segítségével. Drupal 7 alatt ment is rendben. Váltottunk Drupal 8-ra, akkor nem ment, illetve sokáig csak úgy működött, hogy ha a betűkészlet az adott gépre telepítve volt. Aztán valamitől megjavult, lásd: http://94.199.178.26/~heimatmu/

Drupal verzió: 
Melyik modulhoz, modulokhoz kapcsolódik a téma?: 

OG group group tartalom létrehozásakor EntityMalformedException hiba

Kocsis Kata képe

Egy e-learning rendszert üzemeltetünk sok éve az OG modul használatával. Nem tudom, mihez kötődik a hibajelenség, a legfrissebb OG verzió 7.x-2.10. csak gyanítani tudom, hogy esetleg a legfrissebb verzióhoz köthető.

Ha egy tartalomtípust csoporthoz akarunk kapcsolni, és létrejön a Group Audience mező, akkor az alábbi hibaüzenetet kapjuk a tartalom szerkesztésekor:

EntityMalformedException: node típusú entitáson hiányzik a mezőcsoport tulajdonság. entity_extract_ids() függvényben (...)

Drupal verzió: 
Melyik modulhoz, modulokhoz kapcsolódik a téma?: 

Ki készítse a vállalati weboldalt? - DDN2011

Désiré képe

A 2011-es Debreceni Drupal Napok keretében a résztvevők végigkísérhetik egy egyszerűbb kisvállalati weboldal elkészítésének folyamatát. Mindezt Drupal alapokon, hét előadásban, a Drupal és a közösség bemutatásától a leghasznosabb modulok ismertetéséig.

Az utolsó - hetedik - előadás viszont más megközelítésből vizsgálja a kisvállalati honlapok témakörét:
A többi előadásból egyértelműen kiderül majd, hogy a Drupal segítségével gyorsan és egyszerűen, komoly programozói ismeretek nélkül, gyakorlatilag bárki összeállíthat egy jó honlapot vállalkozása számára. Az utolsó előadás viszont azt a kérdést vizsgálja, hogy mindennek ellenére érdemes-e saját kezűleg nekivágni egy ilyen projektnek, pontosabban, hogy mikor érdemes.

Erre az utolsó témakörre magam is jelentkeztem előadónak. Bár még nem tudni, hogy ebben a témában ki fog előadni a DDN-on, de úgy gondolom, mindenképpen érdemes ezt a kérdéskört kicsit boncolgatni. Így az alábbi bejegyzés tulajdonképpen egy vázlata az előadástervemnek.

A kérdés tehát az, mikor érdemes kiadni a weboldal elkészítését egy fejlesztő cégnek?

aboros képe

szuperbonyolult oldalakat nem igazán építettem még, csak inkább egyszerűbbeket. azokat írom ide, amikre a legtöbb esetben szükségem volt vagy kimondottan szeretem használni. azokat a modulokat nem írom le, amik az alaprendszer részei, használatuk azt hiszem evidens. (pl: taxonomy)

cck - egyedi tartalom típusokat lehet vele készíteni, ezeket aztán külön lehet sminkelni és a felhasználói jogosultságok is külön állíthatók. kapcsolódnak hozzá kiegészítők, amikkel különböző típusú mezők adhatók az egyes tartalom típusokhoz. (pl: weblink)

views - segítségével nézetek hozhatók létre. ezek a legkülönbözőbb félék lehetnek a blokktól, az oldalig, listák, táblázatok, bevezető listák, teljes oldalak. az egyes nézetek nagyon részletesen meghatározhatók, szűrők, rendezési szempontok, változtatható szűrők, megjeleníteni kívánt mezők, stb. ezt a modult szinte minden alkalommal használom, szerintem ez a leghasznosabb modul a drupalban.

tagadelic - címkefelhőket készít szótáranként és összesítve is

pathauto - előre megadott minta alapján automatikusan generál útvonal álneveket a tartalmakhoz. így a tartalmak nem(csak) 'node/123' url -eken lesznek elérhetők, hanem pl: 'termekek/bukofrekvencias-homalytizedelo' címen. ez elsősorban a keresőoptimalizálás miatt fontos. nagyon jól konfigurálható, kategória oldalknak is tud automatikusan generálni álneveket, tartalom típusonként más-más mintákat lehet megadni, stb.

globalredirect - ezt minden esetben használom, amikor az előzőt is. nagyon fontos modul, nincs semmilyen beállítási lehetőség, csupán annyit csinál, hogy megnézi van e az adott tartalomnak álneve és ha van, akkor arra irányít át. így megszűnik az álnevek miatti oldalkettőzés, ami szintén a keresőoptimalizálás miatt fontos. (azt írják legalábbis:)

gsitemap - ez a kis modul a google webmaster tools 'sitemap' funkciójának használatát segíti. sok beállítási lehetősége van, súlyozni lehet a tartalmakat típusok szerint, címlapra kerülés szerint, meg még jócsomó minden. az a tapasztalatom, hogy nagyon hasznos, kimondottan szeretni fog a google, ha használod. ;)

meta tags / nodewords - ez a modul szintén egészen finom beállítási lehetőségeket biztosít és oldalak meta tegjeinek előre megadott minták szerinti automatikus generálását végzi úgy mint 'keywords' és 'description'. tartalmak beküldésekor ezek megadására külön beviteli mezők jönnek létre, ha mégsem az automatikusan generáltakat szeretném használni.

aztán persze még sokat lehetne írni, úgy mint tinymce (in the land of blind the cross-eyed is the king;), image, simplenews+mimemail, node relativity, taxonomy menu, imagecache, miegymás. valaki kérte feljebb, úgyhogy próbáltam érthetően leírni melyik mire való.

tényleg nagyon jó lenne egy-két 'recept' a legtipikusabb igényekre, szerintem a drupallal való ismerkedéskor a legnagyobb probléma a 'melyiket válasszam', annyi modul van, rengeteg átfedés köztük, irdatlan tempójú fejlődésben ráadásul, hogy autodidaktán nagyon sokáig tart mire kitapasztalja az ember, hogy milyen feladatra mi a legkézenfekvőbb megoldás. én személy szerint nagyon sokáig több zsákutcába futottam, mert nem a megfelelő modult választottam.

0
0

-
clear: both;

pp képe

A wamp ad neked egy komplet c-panelt? Nem hinném. Lehet nem kényelmes, de azért nem mondanám bonyolultnak sem a fenti metódust, figyelembe véve a ctrl-c ctrl-v lehetőségeket ;)
csak pár helyen kell átírni és már megy is. Ha mondjuk olyan sok projekted van, akkor automatizálhatod, de nem hinném, hogy napi 4-5 projektbe kezdenél bele ;)

Én nagyon régen javasoltam, hogy külön tedd fel ezeket. Az xampp-ot szoktam ajánlani, mert az végre a sok béna disztrib után egyből felmegy és nem kell állítgatni rajta millió dolgot, csak a skype-ot kell kikapcsolni. Én magam már régóta nem használok ilyen eszközöket. Itt csücsülök az Ubuntum előtt, és azt használom. Telepíteni rá nem volt túl nagy tragédia, hisz csak a synaptic-ban rákerestem az apache-ra, php-re és a mysql-re és már hopsz itt is van, no meg a phpmyadmint is felraktam mert azt szoktam meg, de van ám itt csoda mysql managger, meg mindenféle okosság is. Nem kell a neten bóklászni, fogod beírod a telepítőbe és ha van csomagból akkor feltelepedik, és automatikusan mindig a legfrissebb és legjobb csomagot telepíti a gépedre, neked azzal nem is kell foglalkoznod(csak jóváhagynod).

Mindenki azt használ amit akar, de ne mondd már nekem, hogy kényelmetlen lenne 2 fájlba 2 perc alatt megtenni ezeket a minimális változtatásokat, szembe azzal a sok óra szivornyával és sql-dump szerkesztéssel amit a másik megoldás eredményez. (nem beszélve a sok-sok lehetséges hibáról, a karakterkódolástól elkezdve az elgépelésig stb...)

Megnéztem a wamp-ban apache 2.x van tehát a változás a következő:
A fenti Virtual-host részt egy teszt1 fájlba kell másolni a sites-available könyvtárba. A sites-enabled könytárban egy szimbolikus linket kell létrehozni erre a fájlra 001-teszt1 néven. Van egy default szóval azt kéne megnézni, és módosítani. A probléma csak azzal van, hogy windows-os apache-nál nem tudom, hogy mit kell csinálni, mert ott ugye nincs szimbólikus link. Nekem meg nincs windowsom... ;)

Azért azt még elárulom megnyugtatás képen, hogy én sem így születtem, hogy tudtam ezeket, sőt. Először én is alkönyvtárba raktam a cuccot, mert annyira bonyolultnak tűnt ez az apache2 amit nem ismertem. Aztán utána olvasgattam, és most már csak mosolygok azon, hogy mennyire sokkal egyszerűbb így.

Szóval ha nincs kalapácsod, csak egy laposfogód, akkor azzal is be lehet verni 1-2 szöget, de azért 10-15 képnél elgondolkodna az ember, hogy vegyen egy kalapácsot. Azonban semmi esetre sem javasolnám azt, hogy laposfogóval verd be a szögeket, mert azzal is lehet és a kalapácsért meg el kell menni egyszer! a boltba szóval az bonyolult és körülményes. ;)

(laposfogó = az ismeret amivel rendelkezel, kalapács = az ismeret amivel rendelkezned kéne, kalapácsot venni = tanulni.)

pp

0
0
Rico képe

Nem értem miért írod ezt.

Biztos hogy egyre gondolunk?

Technikai szempontból tökmindegy hogy micsoda, ha csak arra használjuk, hogy hierarchikus sorba rendezzük vele a HSz-okat.

De ha ez alapján szeretnénk sorszámokat megjeleníteni a HSz-okhoz (mert nagyon adja magát ehhez), ráadásul úgy, hogy átmozgatás (comment_mover) esetén is helyes maradjon a számozás, akkor bizony fontos hogy mik az alapértelmezett kezdőszámok.

Sajnos az alapértelmezett kezdőszámok nem egyeznek meg a thread érték első és az összes többi helyiértékénél.
Tehát így számoz a comment_module:
01/
01.00/
01.00.00/
01.00.01/
stb.

A comment_mover pedig a megörökölt 2+-dik szintű HSz 00-val kezdődő számozásából készít elsőt, nem úgy mint a comment_module, ami 01-el kezdi az első HSzt. Így a normál első HSz sorszáma (ha nem módosítjuk sminkből) 1-es lesz, az átmozgatott első HSz sorszáma pedig 0. Ez baj.

Ha a comment_module konzisztensen számozna (amit szerinted is megtehetne, mert mindegy hogy mik a számok, a lényeg hogy egymást kövessék), akkor ez nem lenne probléma.
Ha így számozna:
00/
00.00/
00.00.00/
00.00.01/
...Akkor csak sminkből hozzáadnánk egyet minden thread-értékhez és szépen jelenítené meg, és átmozgatás után is jó maradna.

Ha pedig így számozna:
01/
01.01/
01.01.01/
01.01.02/
...Akkor meg nem is lenne szükség módosítani a számot a sminkben a megjelenítéshez, 36-ból 10-es számrendszerre való visszakonvertálás után egyből jól nézne ki minden HSz, és átmozgatás után is jó maradna.

A mostani helyzetben viszont muszáj hozzáadni egyet minden thread-szinthez a sminkben a megjelenítéshez, ÉS kivonni egyet a legelső helyiértékből (mert azt 1-ről és nem 0-ról indítja a comment_module), tehát azt így nem módosítottuk végülis.
De mivel a comment_mover gyakran 2+-dik szintű HSz-okat tesz meg első szintűnek (amiknek adott thread-értékének elejéből lemetsz annyit, amennyit kell), és ezek számozása 0-ról indul, az első szintre helyezetteknek (a fenti +-1 eljárás miatt) 0 marad a kezdőértéke.
Ezért a comment_movert már kénytelen voltam meghekkelni (ami nem core hack, de hack).

Ha bizonyos lenne hogy semmilyen más szerepe nincsen, és esetlegesen kezdődnek 1-el 0 helyett az első szintű HSz-ek (nem pedig valami miatt vagy érdekében), akkor érdemes lenne a core-ban módosítani a számozás kezdőértékeit azonosra, és a frissítés során az összes meglévő thread-értéket az adatbázisban kiigazítani (az első szintből kivonni egyet).

(Szerk.: Picit pontosítottam hogy mit csinál a comment_mover.)

0
0
pp képe

A .htaccess fájl tartalmaz plusz beállításokat. Ezeket el lehet helyezni a virtualhost konfigurációs részénél. Ez a szolgáltatód tudja megtenni. Ez ajánlott is, hisz .htaccess nélkül sokkal gyorsabb és stabilabb kiszolgálást lehet biztosítani. Ez a megoldás viszont rugalmatlan, hisz ezt csak az tudja módosítani aki tudja szerkeszteni a virtualhost konfigját. Muhahah. Értelmes szolgáltató aki nem akar sok problémát, inkább engedélyezi ennek a használatát, hisz ilyenkor nem neki van gondja ezzel, hanem a zügyfélnek. Gondolj bele, ha frissítesz Drupal-t és változnak a .htaccess beállításaid akkor addig nem tudsz frissíteni amíg a szolgáltatód ezt nem vezeti át.

Azonban ez a clean-url-hez kevés. Ahhoz kell még a modrewrite kiegészítés is(már ha apache a kiszolgáló) Ha nincs modrewrite akkor hiába is tennék be a virtualhost beállításai közé a .htaccess-ben található dolgokat nem fog menni.

Nekem kétszer volt ilyen szolgáltatóval kapcsolatom. Az egyik nagyon "segítőkészen" azokat a beállításokat amiket jónak látott azt betett a virtualhost konfigjába. Amiket nem azokat kihagyta. Ennek következtében kaptam egy olyan suta oldalt hogy csak na. Ezután már hiába kértem, nem vették ki ezeket a beállításokat, mert én aztán nem fogom őket ugráltatni. Azt sem árulták el, hogy miket tettek bele, csak mantrázták a "higgye el, hogy beletettünk minden szükséges dolgot". Sok-sok telefonálgatás után eljutottam a marketing igazgatóig. Ne kérdezzétek miért hozzá, őt kapcsolták. Nos a marketing igazgató végighallgatott és azt javasolta vigyem el az oldalt. Tehát nem én találtam ki, hanem ezt nekem a marketing igazgató javasolta. Magyarország egyik legnagyobb internet szolgáltatójáról van egyébként szó. Ez megismétlődött egy másik nagy internet szolgáltatónál is. Itt várnunk kellett fél évet, hogy na akkor lesz tuti szerver, aztán mégse lett olyan tuti. Ezért én ha azt hallom, hogy valahol nem engedélyezik a .htaccess egyből azt javaslom vidd olyan helyre az oldalt, ahol tudod, hogy nincs probléma.

Ha az ügyfél ragaszkodik hozzá akkor nincs mit tenni egy bicebóca oldalt fogsz működtetni. A legrosszabb viszont az lesz, hogy a .htaccess csak a jéghegy csúcsa. A következő meglepetés valószínűleg akkor fog érni amikor elindul a telepítés és a safe_mode miatt jelentkezik problémád, majd a fájlfeltöltéssel szívsz és a végén a legjobb dolgok (imagecache, stb) nem fognak menni a clean-url hiánya miatt. Ez az a pillanat amikor már rengeteg energiát beleöltél abba, hogy egy ilyen szolgáltatónál megpróbálj működésre bírni egy olyan oldalt amit már az elején el kellett volna vinned. Nem tudom, hogy milyen költségvetéssel dolgozol, de lehet jobban jársz, ha Te veszel egy olyan helyet ahol elműködhet az ügyfél oldala.

Összefoglalva a kérdésedre a válasz:
Kell modrewrite és egy olyan szupport aki ugrik ha kéred és állítják amit kérsz.

Modrewrite nélkül nincs értelme működtetni az oldalt.

pp

0
0
Sk8erPeter képe

Már említettem vala, de akkor még egyszer: a Views UI használatáról írtakat a Nagy Gusztáv-féle jegyzetből nagyon jól tudod hasznosítani itt 7-esnél is, mindenképp olvasd el az erre vonatkozó részeket, és PRÓBÁLGASD a gyakorlatban is, különben mindig csak valami misztikum marad, hogy mire való a Views, pedig sok hasznát veheted még.

A lényeg, hogy el kellene döntened, hogy amikor olyan tartalmat küldesz be, amit szeretnél megjeleníteni a főoldalon is, akkor az a tartalom Article (Cikk) vagy Blog entry típusú lesz-e, és ehhez következetesen ragaszkodni. Célodtól függ, melyiket kellene használni, itt nincs "jó" megoldás, mindkettő jó, más célra.
Miután eldöntötted, melyik típusúakat is akarod megjeleníteni a főoldalon, ezután a Views UI-nál kell készítened egy olyan view-t, ami az ilyen típusú tartalmakat jeleníti meg. Ez szerencsére a Views-zal nagyon egyszerűen összekattintgatható (ezt is elolvashatod az említett jegyzetben). Itt beállítasz egy "oldal" nézetnek egy elérési útvonalat, elmented a view-t, majd kipróbálod, hogy azon a bizonyos útvonalon a megfelelő tartalmakat látod-e - ha igen, akkor örülsz.
DE azt értsd meg, hogy ettől még egyelőre egyáltalán nem módosul a főoldalon látható tartalom, mert azon egyelőre nem módosítottál semmit. Csak ott következnek be változások, ahova az új útvonalat beállítottad.
Na, ha minden jól működik ezen az új útvonalon, akkor elnavigálsz szépen az
/admin/config/system/site-information
útvonalra, és az "Alapértelmezett címlap" résznél beállítod ezt az előzőleg kipróbált útvonalat.

Aztán még a későbbiekben ízlés szerint testre is szabhatod az előbb létrehozott view-t, pl. a pagernek (lapozó) tetszőleges számot állíthatsz be, hogy mennyi tartalom legyen egyszerre látható, a megjelenített elemek milyen formában látsszanak, stb.

(Még későbbiekben a Views Slideshow modult is telepítheted, amivel elemeket slideshow-szerűen tudsz megjeleníteni, amihez aboros oldalán van jóféle video tutorial. De egyelőre ezzel ne zavard magad össze, ezt majd akkor nézd meg, ha már sejted, mire való a Views.)

A lényeg:

  1. olvass nagyon sokat, hogy összeálljon a kép
  2. próbáld ki a gyakorlatban (tehát ne csak olvass!!)
  3. ha nem megy, a fórumon lévő sok segítőkész Drupal-felhasználótól olyan formában kérdezz, amiből minden lényeges információ kiderül, így a segítségnyújtás is jóval gyorsabb
  4. fogadd el, hogy kezdeti nehézségek nélkül nincs siker
  5. ne add fel
0
0