DDD - Do and Don´t Drupalu
Čeho se vyvarovat a jak to dělat správně. Přečtení vám zabere několik minut, ale ušetří vám celé dny vašeho drahocenného času (kreativnějším jedincům i týdny :-)).
Neupravujte jádro
Úprava souborů jádra Drupalu je zásadní chyba a v podstatě vám znemožní upgrade (přijdete o všechny změny), nebo z něj udělá zábavu na měsíc (než všechny změny dohledáte). Jádro je vše kromě adresáře sites.Povolené jsou pouze změny v souborech .htaccess a ROBOTS.txt; při upgradu si samozřejmě musíte pohlídat, abyste je nepřepsali. Pokud se bezpečnostní upgrade týká i těchto souborů (výjimečně), zapracujete vaše změny do nových souborů.
Nově nahrané moduly a témata vzhledu
NEPATŘÍ do adresářů modules a themes v jádře Drupalu. PATŘÍ do adresářů sites/all/modules a sites/all/themes, které si nově vytvoříte.Neupravujte původní moduly ani témata
Tedy nejen moduly a témata jádra, ale ani ty, které nově nahrajete. Neupravujte v nich vůbec nic, ani CSS soubory. Všechny změny funkčnosti i vzhledu webu patří výhradně do vašich vlastních (vámi napsaných) modulů a/nebo do vašich vlastních (vámi nově vytvořených nebo vámi odvozených) témat vzhledu.Zásadní odkazy:
Tipy na literaturu (Drupal 6):
Používejte relativní cesty
Pro interní odkazy (tj. odkazy na obsah vlastního webu) NEPOUŽÍVEJTE absolutní URL. Jinak budete mít problémy, když web kamkoliv přestěhujete. (Třeba jen na lokální server pro testování čehokoliv. Zkuste si to představit: kliknete na odkaz v menu a ani si nevšimnete, že už jste na ostrém webu…). SPRÁVNĚ: zadávat relativní cestu, tedy jen to, co je za lomítkem hned za adresou webu. Například: node/4 pro uzel, který má NID 4, contact pro kontaktní formulář apod. Stejně tak při odkazování na soubory umístěné na serveru používejte, pokud je to možné, relativní cestu (například: sites/default/files/priloha.pdf).Pozor na vstupní formáty
Ohlídejte si, aby přístup k Full HTML (nemluvě o PHP, pokud máte zapnutý modul PHP filter) měli pouze důvěryhodní uživatelé (admin, editor apod.). Základní konfigurace je v Nastavení webu > Vstupní formáty, přičemž výchozí nastavení je bezpečné: pokud nepovolíte Full HTML (případně PHP) žádné roli, bude k němu mít přístup jen hlavní admin, tj. uživatel s UID 1. (Další omezení můžete nastavit při vytváření nových polí pomocí modulu Content Construction Kit – CCK: volba „plain text“).Čtěte
- README soubory (v některých není skoro nic, zato v jiných je kompletní návod na konfiguraci modulu a spousta užitečných tipů).
- Informace na stránkách jednotlivých modulů na Drupal.org (důležité jsou hlavně informace o stavu vývoje modulu, který hodláte instalovat, o spolehlivosti jednotlivých verzí, o souvislostech či ne/kompatibilitě s ostatními moduly a v neposlední řadě o případných zvláštnostech při upgradu na vyšší verzi).
Sledujte bezpečnostní aktuality
Česky na Drupal.cz, přehled v angličtině na http://drupal.org/security, samozřejmě nejlepší je přihlásit se k odběru e-mailem (nastavíte přes váš uživatelský účet na Drupal.org).Zálohujte a testujte svoje zálohy
Před každým upgradem si udělejte zálohu souborů i databáze a vyzkoušejte, že je záloha funkční (update.php opravdu nemusí být infarktová záležitost).Pozn.: K výše uvedenému mě napadla jen 1 výjimka: Téma Acquia Marina je „zařízené“ na to, abyste mohli dělat úpravy CSS přímo v něm. Postup je popsaný v souboru local_sample.css. (Teoreticky může něco takového existovat i v jiném tématu vzhledu, ale o žádném dalším nevím).
Eva Rázgová
Nově nahrané moduly a témata vzhledu
Zdravím, zvykl jsem si dávat stažené moduly z drupal.org do adresáře /modules, adresář sites/…/modules si nechávám na vlastní moduly, které nejsou na drupal.org.
Připadá mi to logičtější a žádné problémy s aktualizacemi to nedělá. Co si o tom myslíte?
ne neni to logicke a je to
ne neni to logicke a je to spatne. principem je vzit sites/ a prenest kamkoliv. bude tvuj web pak fungovat? pokud budes napr web aktualizovat pres SVN, musel bys na kazdy jednotlivy modul udelat ignore.
SVN nepouzivam a ani jsem se
SVN nepouzivam a ani jsem se nesetkal s zadnymi dalsimi problemy. Spojeni SVN a Drupal me zajima, co takhle o tom neco napsat? ;-)
taky pouzivame svn a
taky pouzivame svn a v sites/*/modules si to jeste delime na contrib a custom slozky do contrib davame moduly z d.o a do custom vlastni
lip se nam to updatuje je to pro nas prehlednejsi a lip se nam dela dokumentace
my mame na moduly podobne:
my mame na moduly podobne: /contrib-stable, /contrib-pending, /contrib-dev a /custom
ja jen nevim s tema
ja jen nevim s tema relativnima odkazama. podle me je to kravina. kdyz tam napisu href=„node/4“ do bloku tak mi to pokazde odkazuje jinam. nemelo by to radsi byt href=„/node/4“ ?
když v tom je právě problém.
když v tom je právě problém. Jakmile nemáš web hned v rootu webu ale až třeba v /drupal/, tak vznikne problém. adresa bude odkazovat na /node/4 – což je nesmysl – měla by na /drupal/node/4. Možná tohle řeší htaccess a nějaký rewrite. Poradí někdo zkušenější, jak to je?:)
ma nejaky rozumny vyznam
ma nejaky rozumny vyznam davat drupal jinam nez do rootu? tak nejak jsem nepocital s tim ze by to nekdo mohl udelat.
třeba na localu to jednoduše
třeba na localu to jednoduše jinak neuděláš
lokalni porty
X-krat sem resil podobnej problem a nakonec mi prijde jednodussi nastavit pro kazdej lokalni web jinej port, napr: „http://localhost:2001“, abych ho moh mit v rootu, nez abych musel hlidat vsechny odkazy. V konfiguraci Apache staci pouzit tyhle direktivy:
Lepsi je provozovat si nejake
Lepsi je provozovat si nejake jednoduche lokalni DNS. Klidne v etc/hosts…
Já má osvědčeno si si
Já má osvědčeno si si v Apachi nastavit pro každý web virtualhosta:
A pak v souboru hosts:
127.0.0.1 devnejakyweb.czLokální stránky pak jsou na
devnejakyweb.cza na netu to jenejakyweb.cz. A s cestama pak není problém.delam to uplne stejne, imho
delam to uplne stejne, imho neexistuje lepsi reseni.
navic se takhle da resit i i18n pri detekci domenou. akorat se nesmi zapomenout to pak prenastavit kdyz to hodite na ostry provoz.
XAMPP a VirtualHost
Snad se může hodit pro ty, co použivaji XAMPP
http://maff.ailoo.net/…for-windows/
Obcas se hodi po techto zasazich v httpd, apod. vyrestartovat Apache.
Jak to odchytnuti domeny
Jak to odchytnuti domeny udelam, kdyz pouzivam unixovy system?
nastaveni apache je stejne na
nastaveni apache je stejne na vsech os, hosts soubor by tam podle me taky mel existovat(mozna pod jinym nazvem), a drupal se nastavi v nastaveni jazyku – misto prefixu to rozlisovat podle domeny. klicova slova pro google: myego vhost
je to fakt super.
/etc/hosts
/etc/hosts
multisite instalacia
multisite instalacia
Právě při použití multisite
Právě při použití multisite by měl být drupal v rootu, ať obslouží všechny domény na něj směřované.
nejen to ...
pokud není drupal v rootu, a používá se detekce na základě domény, funguje to špatně. Vyzkoušeno – Drupal směruje každou chvíli na „tu druhou“ doménu, a má problém s relativními cestami a tvorbou linků. Občas byl problém i dostat se do administrace …
kdyz to delam v kodu, tak
kdyz to delam v kodu, tak vzdy <?php print l(‚Text‘, ‚node/4‘); ?> coz zaridi pripadny podadresar. Text by melo dle potreby byt obaleno t()
Jestě k těm modulům: Mám
Jestě k těm modulům: Mám nějaký nový vzhledy, z toho požívám jen jeden v stabilně /Salamader 4/. Z ostatních modulů pak Poormanscron. Jsou v také adresáři Modules, to proto, že když jsem s Drupalem začínal, tak jsem nevědel. To se stává. FCK je již v Sites. Při aktualiacích je to bez problémů, aktualizované soubory nahrávám přes FTP. Vše chodí bez jediného zádrhelu a problému, web je validní. Pouze FCK je mírně upravený, pokud je aktualizován tento modul /stalo se tal za mojí Drupal kariéru již 2×/ změny ručně zavedu znova, není jich zase tak moc, práce na 5 minut. FCK jako jediný modul při aktualizacích odinstalovávám, Drupal to vyžaduje, pouhé vypnutí mu nestačí. Uvažuji tedy o tom, že bych to s přechodem na D7 jež se blíží, uvedl do pořádku. Ostatní navíc stažené moduly vzhledu mohu vypustit a smazat, používat je zřejmě nebudu, byly jen na zkoušku, je jich asi pět. Tedy upravit před aktualizací na D7, nebo před? Nepodělám něco? Díky za rady.
úprava modulov
Ahoj. Všade sa odporúča, nezasahovať do pôvodných modulov. Aký je teda správny postup, keď potrebujem niečo malé upraviť?
Napr. ak v štandardnom kontaktnom formulári z jadra nechcem, aby všetky položky boli povinné na vyplnenie. To je nastavené natvrdo v kóde modulu. To mám kvôli tomu vyrábať nová modul?
Ano. Funkcia z API drupalu
Ano. Funkcia z API drupalu
hook_form_alter()sluzi presne na ten ucel – modifikacia existujucich formularov.Jsem zatim v Drupalu
Jsem zatim v Drupalu začátečník a chtěl bych si upravit nějakej ten vzhled či modul. Nahrál sem ted vzhled do SITES/ALL/THEMES ale nevim jak ho mám v administraci zapnout. Mezi ostatními tématy se mi nezobrazil
Odpovídá verze tématu verzi
Odpovídá verze tématu verzi Drupalu? (tedy: Drupal 5.x – Téma 5.x, Drupal 6.x -Téma 6.x)?
motiv
Co když potřebuji prostě nějaký motiv předělat, konkrétně Acquia Marina? Jak je na tom licence?
Licence je GNU/GPL :-)
Licence je GNU/GPL :-) Prekvapuje me, ze je treba to jeste porad vysvtlovat.
Tema muzete jakkoliv upravit a distributovat. Plati jedine – jakmile ho distribuujete, musite ho distribuovat vcetne zdrojovych kodu. Coz je vzdy pravda v pripade PHP. Pokud tema nebudete distribuovat (pouzijete ho jen na svem webu), nemusite vubec nic.
Jediny problem obcas byva s ikonkami, pokud pouzijete cizi ikonky, ktere nejsou GNU/GPL, nemuzete tema treba dat na drupal.org, protoze prijima pouze GNU/GPL kod
Díky za vysvětlení. Já
Díky za vysvětlení. Já samozřejmě GNU/GPL licenci znám, jen mě zarazilo, že tam je napsáno, že se původní témata nemají upravovat.
Ano, NEMAJI. Mate sivytvorit
Ano, NEMAJI. Mate sivytvorit podtema nebo ho zkopirovat a prejmenovat. Je to technicka podminka, ne pravni
Poslat nový komentář