Valamiért
Valami oknál fogva szeretem minél egyszerűbben, tisztábban használni pl. a Drupalt, ezért csak a tényleg szükséges modulokat telepítem.
Van ennek az ellenkezője is: sokan szeretnek mindent feltenni, amit csak lehet.
Egyszer egy önlejölt dtp-snél jártam, vagy 10 éve, és úgy tele volt a számítógépes Windows asztala (persze lopott) programokkal, hogy nem is volt már több hely szinte.
Ezt azóta sem felejtettem el, annyira negatív benyomás volt.
Persze sokan használnak illegális szoftvereket, de ez az ember aztán tényleg túlzásba vitte és az volt a visszataszító a dologban, hogy egy profi képében tetszelgett, akinek nagyon megvan minden szükséges dolga a jó munkához.
Régebben nekem is volt egy két olyan programom, aminek a próbaideje már többször lejárt, de most már nincs, és tök jó érzés. Addig nem is érzetem magam igazi vállalkozónak.
Amióta legális minden és EVA-s vagyok, azaz mindent befizetek adót, amit kell, úgy érzem jogom is van arra, hogy kifogásoljak dolgokat a társadalmunkban és nem érzem magam már piti vállalkozónak.
Igaz egy program van, aminek a meg nem vételére szólítanék fel mindenkit, mert elképesztően drágán adja nekünk a sz.rt, nem úgy, mint az USA-beli honfitársainak. Ez egy olyan program, amit a géppel adnak sokszor, nekem is azért lett csak megvéve, de a dobozost szeretném, emberi áron.
Na de bocs, hogy elkalandoztam: lényeg: minél kisebb Drupalt akarok használni.
De kösz a javaslatot!
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
Nekem mással is elő fordult már
Jó pár CMS-t kipróbáltam, a legtöbb gailbát nekem a Xaraja okozta. Ez szinte automatikusan létre hozta nekem a törölhetetlen fájlokat / könyvtárakat.
A 6-os Drupálnál csak néha adódott gondom.
A 7-essel bár azonnal feltettem azt is, én még nem foglalkozom, mert sok modulból amit használok nincsen még 7-es, én ezek megjelenését várom.
És volt olyan CMS, több is, ami egyáltalán nem csinált soha ilyen problémát, de a tudásukkal viszont egyáltalán nem jelentettek számomra Drupállal szemben alternatívát. És az sem biztos, hogy ebben jobbak voltak, csak lehet éppen nem csináltak lehet olyasmit, ahol ez a probléma egyáltalán előjöhetett.
Lehet nálad a szolgáltatód részéről még szigorúbb beállítás van: én csak törölni nem tudok bizonyos helyzetekben, neked meg az írás sem engedélyezett.
Van egy nálam sokkal hozzáértőbb ismerősöm is, ő nem CMS-t használ, hanem teljesen saját maga által írt rendszere van. Neki rengeteg ilyen problémája volt, míg a szolgáltatója rám nem unt, és feltelepítettek neki valamit, ami által már ő saját maga tudta orvosolni az ilyen problémákat.
Persze gondolom ilyesmire sok szolgáltató nem hajlandó, és lehet ő is csak azért kapta meg, mert konstallálták az időfolyamán, hogy ért is hozzá, és rossz szándékai sincsenek, tehát nem fog nagy bajt okozni.
Szóval könnyen lehet, most mindenek előtt a szolgáltatódat kellene megszekálnod, hogy nézzenek utána, hogy valami náluk lévő beállítás okozza-e problémát.
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
Köszönöm.
A telepítés megy, már csak azt nem értem, hogy az uninstall miért nem hajtódik végre.
Jelenleg ezt futtatnám le a modul kikapcsolásakor, de nem történik semmi, viszont a Devel uninstall használatával már törlődik minden, viszont hibaüzenet is jön, hogy a tábla már nem létezik. Akkor most mi is fut le? :D Vagy csak a Cache-t kellene üríteni az _uninstall() futásakor?
function g_theme_uninstall() { drupal_uninstall_schema('g_theme'); db_query('DELETE FROM {system} WHERE name = "g_theme"'); db_query('DROP TABLE {gdt_smink}'); }
A Coding Standards-t pedig már néztem, de ha abba is beleköt a rendszer, hogy átláthatóbb a kódom, mert nem csak két szóköz a behúzás, az már szőrszálhasogatás. Bár ezt fejlesztője válogatja, hogy kinek mi az átláthatóbb és milyen Standerdet követ. De köszönöm. :)
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
megoldották nekem...
Az IRC csatornának hála:
- +chx: hat ha tpl.php lenne
- +chx: akkor azt mondanam hogy tegyel fel devel module-t
- +chx: es ird be has_krumo();krumo($variables);
- +chx: aztan nezegesd
- menesisz: benne van a keresett változó is, de hogyan szólítom meg?
- +chx:
<?php print $content['sell_price']['#value'];?> - +chx: csak ovatosan ugy altalaban az akarmi valtozo kiirasaval -- bar ez egy szam -- vigyazz hogy nehogy escape nelkuli stringet irjal ki
- menesisz: Az mit okoz? És honnan tudom, hogy nem szabad kiírni? :)
- alippai: tegyél köré
check_plain();függvényt, az kiszűri a trükkös emberek által bevitt szöveget (ergo nem lopja el senki a bejelentkezett session-öd és hasonló disznóságok)
Köszönet mindenkinek!
Üdv,
Ménesi Szabolcs
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
"nem pedig azokat majd egy
"nem pedig azokat majd egy külön rendszerben újra megírni, nyilvántartani és kiküldeni"
erre találták ki az integrációt különböző rendszerekkel.
Ugyanazt csinálja, amiket írtál, rulest is lehet rápakolni, csak kb a hírlevélküldés critical részeit veszi át, mint pl a hírlevél html előálítása, hírlevelek kiküldése, ez utóbbi több szempontból is igen kényes és erőforrás-igényes folyamat.
De mondok egy elrettentő példát: Full csilivili html levelet kellett gyártani, trackingel, beágyazott menüvel, tistutyafülével.
4+ hónapig kellett reszelni simplenews + mimemail + mailtemplates, vagy micsoda + még csomó minden sallang modulokkal és még mindig nem olyan, mintha egy célszoftvert állítottam volna be fél nap alatt.
És akkor arról már ne is beszéljünk, hogy ezekről raklapnyi statisztikát készíteni, grafikonokat, jelentéseket, amik egy célszoftverben difólt megvannak, azt drupalban újra fel kell találni.
Pont úgy, ahogy egy crm szoftvert sem érdemes drupalban megírni, ugyanez vonatkozik egy hírlevélküldő szoftverre a bonyolultsága folytán. De hasonló kb egy webshop is, és ennek analógiájára az a véleményem, hogy amíg valaki(k) nem kezdenek el egy drupalcommerce nagyságrendű projectet drupal hírlevélküldésre, addig a külső megoldás marad a legtöbb esetben.
Mert a simplenews az mindössze egy okos ui, hogy ne manual kelljen nyomkodni egyesével a levélküldést, az nem hírlevélküldő rendszer.
----
Rájöttem, miért kérdezek olyan ritkán a drupal.hu-n. Amíg szedem össze az infokat a kérdéshez, mindig rájövök a megoldásra.
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
Összefoglalás
Köszönök minden segitő hozzászólást! Igen, a szolgáltató volt a hunyó és tegyük hozzá a hiba jelzése után igen hamar helyre is állították az adatbázisokat.
Ha kicsit fapadosan is, de megpróbálom összefoglalni a tapasztaltakat mások okulására.
Tehát.
PDOException: SQLSTATE[42S02] jellegű hibával (min.) 3 esetben találkozhatunk :
1, Közvetlen Drupal x.y verzió telepítése után.
Ez esetben a megoldás : oldalad/install.php behívásával (újra)telepítés (új MySQL adatbázis)
2, A hibát az is kiválthatja, ha két Drupal alkalmazás egyszerre próbál hozzáférni ugyanahhoz a táblához. (pl. Két oldal teljesen azonos időben való mentése) Ez esetben adott tábla "eltűnhet" a MySQL adatbázisból. Ezt a fenti hibakód után ilyen jellegű üzenet közli :
"Base table or view not found: 1146 Table xxxxxxx.cache_update" > cache_update tábla hibája/hiánya
A táblát ilyen jellegű paranccsal lehet helyreállítani :
CREATE TABLE cache_update ( `cid` VARCHAR(255) NOT NULL DEFAULT '', `data` LONGBLOB DEFAULT NULL, `expire` INT NOT NULL DEFAULT 0, `created` INT NOT NULL DEFAULT 0, `headers` TEXT DEFAULT NULL, `serialized` SMALLINT NOT NULL DEFAULT 0, PRIMARY KEY (cid), INDEX expire (expire) )
3, Ha több vagy éppen az összes tábla hiányzik, (ezt pl. C-Panel esetén PhpMYadmin felületen lehet ellenőrizni) akkor igen valószínű, hogy a szolgáltatónál keletkezett a hiba. Ez esetben általában sikerrel kérhető a teljes MySQL adatbázis helyreállítása. Célszerű esetleg az adatbázis kiimportálásával saját biztonsági mentést is készíteni a jövőre nézve.
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
ránézésre ebből nem lesz SEO
Szia, a beállításokat nem tudom hogyan "célszerű" megvalósítani ehhez, mivel SEO szempontból maga az elképzelés nem tűnik "célszerűnek". (valószínűleg egy átirányítás a domain2.comról a domain.comra (301?) szerk: ja nem)
Itt ugyanis a duplikált tartalom legnyilvánvalóbb példája kezd körvonalazódni: épp azért nem tudom a konkrét jó beállítást ehhez, mert az ilyesmit én mindenáron igyekeznék elkerülni.
Ha mégis van valamilyen trükközés, amivel megúszhatná ezt a duplikálási akciót az oldalaid SEO-ja, az már
- SEO-fórumos kérdés,
- vagy új téma a
<link rel="canonical" href="valami" />helyes használatáról Drupal rendszer esetén (vagy amit a SEO-fórumosok mondanak :) )
Hadd tegyem hozzá, hogy ezek csak a személyes ötleteim, nem biztos, hogy jót tippelek, vagy hogy igazam van...
SZERK:
vagyis hogyha átirányítasz a domain2.comról a domain.com-ra 301-el, akkor a domain2.com nem lesz indexelve, mert egyből megy a robot a domain.com-ra, és csak ott és csak azt indexeli. (A 301 azt jelenti: moved permanently, elköltözött, már nincs itt.) De ez is SEO fórum inkább.
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
hmm
"Ha pl. így hívom meg a node-ot (url):
/node/12/1+2+3+4
"
Várj, ez biztos jó lesz így? Nem kellene inkább úgy átadni, hogy pl.
node/12/xyz/1+2+3+4
?
Csak azért kérdezem, mert sok modul regisztrál egy path-t még a node/nid utánra, pl. a devel (pl. node/12/devel) és egyéb modulok is, meg ugye a node/12/edit is egy node id mögött lévő path, nem tudom, szerencsés-e olyan módon felhasználni, ahogy Te most teszed. Én inkább utánadobnék még egy fix path-t is, és úgy hívnám meg (tehát ahogy fentebb mutattam).
"Akkor a paramétert (1+2+3+4) át szeretném adni a display suite-al beágyazott views-nak."
Milyen módon ágyazod be Display Suite-tal az adott view-t a content type-ba?
Az általad említett módszert én még nem használtam.
Ilyen módon még nem próbáltam ennek átadni, de az Entity Views Attachment modullal is próbát tehetnél.
Hozzá kell adni egy adott view-nál egy Entity Field display-t, és akkor ez a view már az adott content type-nál már a "Manage Display" fülön rendezgethető, csak még kérdés, vajon működőképessé lehet-e tenni ezt "VAGY"-olt contextual filterekre.
Ha pl. a path ilyen:
node/%/xyz/%
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
<div> vs <p>
Igen, erre rögtön az jutott eszembe, hogy a wysiwyg modulnak (ckeditor? tinymce?) meg lehet mondani, hogy hogyan kezelje a sortöréseket, amiket talál, magyarul <br />-t, <p>-t, vagy <div>-et használjon-e a bekezdések elkülönítésére.
Szerintem a <div> a legrosszabb ötlet, mert ez ugyanaz a címke, amiből az oldal legfőbb alkotóelemei is állnak. Ez azt jelenti, hogy ez a kis szövegszerkeszés közben becsúszott baki más sminknél eltűntethette volna az egész oldalsávot is, vagy bármit.
Ezzel szemben a <p> azt jelenti, hogy "paragraph", bekezdés, tehát szemantikailag is ez a megfelelő, ha meg hiányzik belőle fél pár, az sokkal kevesebb gondot eredményez (sokszor annyival kevesebbet, hogy ki sem derül).
Amúgy én januárban futottam bele ugyanebbe:
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
Ez a megoldás több sebből
Ez a megoldás több sebből vérzik, tegnap hosszukalmannal volt érdekes vitánk róla. (Szerintem csak egyből, de akkor már beszéljük meg)
1. hosszukalman szerint form elemet nem illik nem formban használni. Ami végülis jogos, hiszen html definíció szerint ez form elem. Arról, hogy ez szemantikailag befolyásol-e valamit, nem találtam semmi értelmeset. Én is csináltam már olyat, hogy fórum kezdő hozzászólását fieldsetbe raktam, nice feature olyan chat-fórumoknál, amikor már közel sem az első hszről megy a traccsparti.
Pár dolog szól amelett, hogy ez elfogadott dolog lehet, az egyik pl az, hogy valid a html kód. A másik, hogy több olyan modul van, ami form nélkül épít fieldset html kimenetet (collapsible_text, szerintem a dhtml_menu is), és nem nagyon volt miatta reklamáció. Továbbá eléggé alapigény, hogy bármilyen szöveget tudjak csikicsukiba tenni, erre viszont évek alatt nem született a drupalon belül a theme_fieldsetnél jobb megoldás.
2. Ez viszont már artériás vérzés: a csikicsukit nem hányjuk csak úgy direkt html-be. Emiatt nem is működik, csak bejelentkezetteknek, nyilván van valami form elem, netán egy dhtml menu, ami miatt a bejelentkezetteknek megvan szépen a js-ük, ami anonimnak nem töltődik be. Szóval megfelelő preprocessbe theme_fieldset($element), ahol az $element['#value'] a $vars['comments'], és menni fog, tpl-t ez esetben nem kell bántani. (hogy most melyik preprocessben érhető el a $vars['comments'], azt hirtelen nem tudom, de devel_themer megmondja.
----
Rájöttem, miért kérdezek olyan ritkán a drupal.hu-n. Amíg szedem össze az infokat a kérdéshez, mindig rájövök a megoldásra.