Sziasztok,
Mivel minden Drupal site fejlesztését tesztkörnyezetben (domain.hu/teszt mappában) végzem, a felhasznált képeket az írásokban/oldalakon/blokkokban relatív hivatkozásokkal szeretném elhelyezni.
Van egy site azonban, aminek a "listázó" aloldalán (domain.hu/hirek), illetve konkrét cikkoldalán (domain.hu/hirek/elso-hir) nem működik az <img src="sites/default/files/kep.jpg"> és az <img src="/sites/default/files/kep.jpg"> formátum.
Egyedül főoldalon jó ez, hisz ott tudok <img src="sites/default/files/kep.jpg"> módon hivatkozni a képekre, de "eggyel beljebb" már nem.
A hangsúly azon van, hogy jelenleg a /teszt alatt fut a site, majd az éles üzem a gyökérben lesz - ezzel nem boldogulok...
Kérlek, javasoljatok megoldást.
Köszönöm, üdv,
Csaba
Drupal verzió:
Fórum:
Insert modul?
Szia, nem biztos, hogy ez a tuti, de én kipróbálnám a helyedben az Insert modul működését.
Könnyen lehet hogy ez teljesen új alapokra helyezi az eddigi képkezelésedet, de közben hátha megoldja a problémát is (az Insert központilag szerzi be a base URL-t, szerintem megvan benne a potenciál, hogy teljesen kiváltsa a relatív linkes taktikádat → ki kéne próbálnod egy próbamigrálással!).
(egyébként a szerintem a Googleban is messzebbre jutsz, ha a képeket is rendes abszolút linkekkel kezeled (az Insert modul így csinálja))
Kipróbálom!
Kipróbálom, köszönöm!
Hát, az insert modul egyrészt
Hát, az insert modul egyrészt nem nagyon fog migrálgatni semerre sem, max az új tartalmak beszúrásánál fog dolgozni. Sőt, van olyan issue is neki, hogy settings.php-ban kell változót konfigurálni, amitől egyáltalán hajlandó lesz absolut urleket használni, de lehet, hogy fordítva, pont arra kell a $conf, hogy ne dobálja már nekem direktben a contentbe a http://ezenaszerverenfejlesztek.hu-t. Ezt most nem vágom, de jópár sitenál szívtam már vidáman inserttelgetett képekkel.
Az ilyen úton tartalomba szúrogatott absolut urlnél aztán éles oldalra költözéskor jön a vidámság, amikor az összes node-ban http://localhost/sites/default/files/stb.png lesz a kép útvonala.
A google részét nem nagyon vágom, de meglepődnék, ha egy ennyire irreleváns dolog súlyt kapna az értékelésben, de erről írhatna valaki okosat.
Röviden:
1. Az insert modul jó
2. Abszolút url nem menő
3. http://drupal.org/project/pathologic -> ezzel viszont szűrő szinten lehet mindenki igényeit kielégíteni, és nem lesz gáz a költözéskor, én ezzel szoktam az elcseszett insert által beszúrt képeket kijavítani.
----
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.
Ezt benéztem
Kösz szantog, úgy adtam a tanácsot, hogy nem migráltam Insertes webhelyet előtte, csak következtettem abból, amit a normál használat közben láttam (ráadásul nem is localon) (hogy magam mentsem: legalább beírtam: "ki kéne próbálnod egy próbamigrálással!").
Szóval köszi az alapos javítást!
eager
[update]: @szantog: mivel az Insertnek is megvannak az előnyei - pl. csak Inserttel tudok úgy képet az oldalak közepébe is betolni, hogy a Colorbox kezelje őket - szóval azóta ezen agyalok:
Akkor az Insert és Pathologic modulok tudatos együtt-használata jelenthetne mindenki számára rugalmas, mindenhol használható megoldást? (hisz te már így használod őket...?) Erre lehet hosszútávon építeni?
Akkor az Insert és Pathologic
Akkor az Insert és Pathologic modulok tudatos együtt-használata jelenthetne mindenki számára rugalmas, mindenhol használható megoldást? (hisz te már így használod őket...?) Erre lehet hosszútávon építeni?
Véleményem szerint hosszú távon az insert modul relatív útvonallal a nyerő. Pillanatnyilag nem tudok elképzelni olyan helyzetet, amikor az abszolút útvonal _kellene_ (Nyilván van, különben nem lenne a pathologic modulban a feature)
A pathologicot meg csak akkor kell feltenni, ha arra valóban szükség van, pl a rossz insert linkek kijavításához.
----
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.
Ez happy end
Csak hogy itt álljon a megnyugtató megoldás is:
Az insert modul README-jében megtaláltam az egyszerűnek és kíméletesnek tűnő megoldást az Insert relatív linkekkel való használatához:
Paths
-----
By default the path to the inserted file will be absolute, including the full domain name, such as h_ttp://w_ww.example.com/sites/default/files/image.jpg. If you prefer relative paths, such as /sites/default/files/image.jpg, add the following variable to your settings.php file:
See http://drupal.org/node/622964#comment-2451810
Miért ez az alapértelmezés?
Miért rak be alapértelmezetten abszolút url-t az insert modul? Nem látom eléggé az értelmét.
Pont az lenne a cél, gondolom, hogy relatívak legyenek az url-ek a webroot-hoz képest, hogy költöztethető legyen a honlap.
Ha meg valahova abszolút url kell, pl. az RSS-be vagy hírlevélbe, ott az ezt legeneráló programnak kellene abszolúttá alakítani a tartalomban lévő linkeket.
A jelenlegi alapértelmezés mellett, ha utólag kell a linkeket röptében módosítgatni minden megjelenítéskor (pl. a pathologic modullal), ez nem tűnik túl teljesítménybarát megoldásnak, meg egy plusz modul kell, ami "javítja" a linket, amikor átviszem a dev site-ról az élesre.
Én még úgy tanultam, hogy ne használjuk abszolút url-t site-on belüli linkekre. Hogy van ez?
Aruna
Insert relatív linket nem tud D7-en.
Mégsincs nagy happy end: most jutottam el oda, hogy használjam a gyakorlatban, és most derül ki, hogy a standard modul D7-en nem tudja a relatív hivatkozást (7.x-1.1), hiába van ott a README-ben, hogy tedd a settings.php-ba a $conf -os sort, nem működik.
úgy nézem, D6-ra itt megoldották:
http://drupal.org/node/622964#comment-2451810
a D7-es helyzet itt látható (a fejlesztő azt mondja, nehéz D7-ben kinyerni a relatív linket):
http://drupal.org/node/1149910
Úgy néz ki, hogy külön bonyolítja a dolgot, ha Colorbox-szal akarom használni (mi mással, Colorbox az kell ;D ) (mert valahogy annak a linkjeit is relatívra kéne venni).
Szóval szerintem én fölteszem a site-ot élesre, ráteszek egy .htaccess jelszót meg egy karbantartási módot is a biztonság kedvéért, aztán fölteszegetjük a képeket ott (amik így az éles szerver abszolút url-jei lesznek) (nem néz ki profin, de én sem vagyok az - site meg történetesen elég kicsi lesz)).
Legrosszabb esetben pedig valamikor később esetleg még meg kell ismerkednem a pathologic modullal is.
Ha valakinek volna erre jobb ötlete, kérem, mondja el.
Nem volt más gyors megoldás
Követtem ezt a fórumtémát az elejétől...Közben elkészült két olyan D7 oldal, amelyek Insert modullal berakott képeket tartalmaznak (jó sokat), és amiket költöztetni kellett.
Az egyik localhoston lett fejlesztve, itt tapasztaltam én is, hogy a settings.php-ba írt módosítás eredménytelen, az url-ek menthetetlenül abszolútok maradnak.
Nem volt más gyors megoldás, a Pathologic modult voltam kénytelen alkalmazni (azt, hogy ez létezik, és ilyen célra használatos, szantog hozzászólásából derült ki számomra, köszönet érte!). Kicsit agyaltam rajta, de végül is könnyen be lehet üzemelni:
1. A szövegformátumokban (amit/amiket használunk) kell a 'Correct URLs with Pathologic' sornak legalul lenni a 'Szűrők feldolgozási sorrendje' dobozban.
2. Az 'Also considered local' részbe pedig a 'rossz' url-t kell megadnunk, amit ki akarunk szűrni. Ha például localhostról költözünk szerverre, akkor ide a pl.
http://localhost/drupal/
/drupal/
/
sorokat kell beírni a Readme.txt-ben megadott http://drupal.org/node/257026 leírás alapján...
Ezután már a helyes - igaz, továbbra is abszolút - url-ek működnek.
Szóval nincs ettől jobb ötletem :)
OFF, előre is bocs, de akkor is :)
[NAGYON OFF]
Igazából számomra nem világos, hogy localhoston miért alkönyvtárakkal szívtok (pl. localhost/egyikprojekt, localhost/masikprojekt, stb.). Nagyon sokan csinálják ezt, és később kiderül, hogy igazából feleslegesen.
Érdemes inkább
hostsfájlba (Windows:%WINDIR%\System32\drivers\etc\hosts, Linux:/etc/hosts) berakni egy jól megjegyezhető, localhostra visszairányítandó címet:Ezután ezt IIS alatt külön site-ként, Apache alatt külön VirtualHostként beállítani, a megfelelő domainnel (pl.
egyikprojekt.local), megfelelő saját elérési úttal (így nem is kell mindig feltétlenül a www, htdocs és ehhez hasonló nevű könyvtárakba pakolni a tartalmat), hogy elkerülhetők legyenek a fentihez hasonló későbbi problémák - már amennyiben úgyis gyökérkönyvtárban lennének a végleges projektek.Amennyiben a végleges helyén is alkönyvtárban lenne, és/vagy esetleg ide-oda lenne mozgatva a könyvtár, abban az esetben a fenti probléma így is-úgy is felmerül természetesen, de az esetek igen nagy többségében nem ez a helyzet (tehát a Drupal úgyis a gyökérbe kerül).
[/NAGYON OFF]
haladó szint
"...hogy localhoston miért alkönyvtárakkal szívtok..." azért, mert a tanulási folyamatnak még ezen a szintjén vagyunk :)
Köszönet, hogy mutatsz más lehetőséget (bár nekem még ez a leírás is kevés ahhoz, hogy pontosan tudjam, mit-hol-hogyan állítsak be az Apache-ban, ha pl. XAMPP-ot használok :) )
Jogos
Teljesen jogos a felvetés, kicsit jobban belegondolva az első igen nagy szívásokig (amíg nem szórakoztam és anyáztam eleget a VirtualHostok megfelelő működésre bírásáig, amikor még fogalmam sem volt az Apache valódi működéséről) én sem tudtam, hogyan kell ilyesmit megvalósítani.
Épp azon gondolkoztam, hogy írok egy ezzel kapcsolatos cikket, ami segíthet másoknak, hogyan hozzuk össze a VirtualHostokat Apache-on, de gondoltam előbb rákeresek, hogy ne fedezzem fel a spanyolviaszt, és pont itt a drupal.hu-n találtam egy kivételesen érthető stílusban megfogalmazott cikket éppen XAMPP-hoz:
XAMPP telepítése, mail szerver és domének beállítása helyi gépen
Ez körülbelül ugyanaz, amire én is céloztam az imént! :) Ennek a cikknek szerintem sokan hasznát vehetik, akik még nem foglalkoztak érdemben ezzel.
(A Google Docs-os cikk működik.)
IIS-en meg ugyanez annyira magától értetődő, összekattintgatós (ezért mondjuk szeretem is az IIS-t, elfedi a felesleges konfigfájl-b×zerálást, amit sok tapasztalattal a hátam mögött sem tartok kellemesnek - ráadásul tapasztalatom szerint - az IIS 7.5 legalábbis - Windows-on gyorsabb is FastCGI PHP-vel, mint az Apache), hogy az viszonylag intuitív. De ha van rá igény, lehet, hogy írok ezzel kapcsolatos cikket.
Te tényleg ilyen kezdő környezetet használsz? :)
http://nevergone.hu/blog/110515/teljes-erteku-drupal-fejlesztokornyezet-...
Igazából számomra nem világos, hogy localhoston miért szívtok a hosts fájl állítgatásával egy local dns helyett, és az se világos, hogy miért nem használjátok az Apache beépített VirtualDocumentRoot opcióját.
:) bocs, de ezt ugye nem lehetett kihagyni.
Tényleg Win-re nem akar valaki egy leírást készíteni local dns-ről? (vagy valami olyan router trükköt amivel az megoldható?)
pp
Palócz István
https://palocz.hu | https://tanarurkerem.hu
rewritebase
mer' a mod_vhost_alias-hoz RewriteBase / -t kell beallitani es a fene sem szeret szopni azzal. En is alkonyvtarazok. Vessetek a mokusok ele.
mi a gond vele?
És mi a gond a RerwriteBase -val? :) Azon kívül, hogy a dokumentált rendszer már egy ideje jól működik, nem csak nálam.
Választ szeretnél? - Új kérdés, új téma - Tesztoldal - Trollkezelés - Frissítés
Nálam úgy néz ki a dolog,
Nálam úgy néz ki a dolog, hogy van a munka könyvtár, abban a projektek és egy .htaccess amiben ott figyel a RewriteBase, így nem kell beállítani mindenhova. (persze linuxon, mert mekken még egy mysql-t se sikerült fordítanom, nemhogy egy named-nek nekiálltam volna. :)
pp
Palócz István
https://palocz.hu | https://tanarurkerem.hu
Replace all
Én azt szoktam ilyenkor csinálni, hogy a költöztetés közben az SQL export állományban csinálok egy jól irányzott tömeges cserét. Pl. az alkönyvtár problémát könnyedén megoldom vele.
Nagy Gusztáv