iframe
IFRAME-mel az egész oldalt be tudod szúrni, egy részét sajnos a hagyományos eszközökkel nem lehetséges. És az sem biztos, hogy az oldal üzemeltetője örülne ennek. :)
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
Lehetséges h a Gallery3 írta
Lehetséges h a Gallery3 írta felül? mert az telepítgetett (önállóan) táblákat az adatbázisba. Akkor ha ez a hiba akkor ha beimportálom a régi drupalos táblákat az talán megoldás lehet? kipróbálom
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
tárgytalan minden,
időközben rájöttem mindenre az induláshoz. a custom mappában lévő php fájlt kellett a téma nevével kiegészíteni az elnevezésben és működik szépen.
Egyenlőre, ami kérdés volt az megoldódott.
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
Azt szeretném kérdezni, hogy
Azt szeretném kérdezni, hogy milyen modult kell ahoz felraknom, hogy az automatikusan az oldalra felkerülő tartalmakat automatikusan megossza a fecebook profilomba vagy az oldalam facebook profiljába ?
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
Kedves János! Kedves
Kedves János! Kedves Közösség!
Eddig csak nyomonkövettük a témát, hogy milyen irányba viszitek, de most már túl sok a félreértés, és az e-mailre is illik válaszolni, amit hozzánk címeztek.
Mivel a válasz publikus, és mindenkire tartozik, aki a drupal.hu rendszeres olvasója és építője, ezért ezt itt teszem közé.
Először is tisztázzuk azt, hogy mi az, amit értékesítünk az online-uzlet.com weblapon, és mit nem.
Az elindulásunkkor a Drupallal együtt nyújtott tárhelyszolgáltatásunkat kizárólag az oktatással, és a többi támogatással együtt kínáltuk. A hangsúly a támogatási rendszeren van, volt és lesz.
A két szolgáltatás külön választását az indokolta, hogy több projektet indító előfizetőktől ne kelljen kétszer elkérnünk a Tudásbázis használatának díját.
El kell mondjam, hogy mióta különválasztottuk a két szolgáltatást, senki nem rendelt önálló weblapot, támogatás nélkül. Nem is célcsoportunk az a réteg, amelyik magától is elboldogul a Drupallal.
Ha ebbe belegondoltok, akkor kis segítséggel Ti is beláthatjátok, hogy nem kis feladatot vállaltunk fel ezzel, és senkinek sem kell attól féltenie bennünket, hogy munka nélkül fogjuk betegre keresni magunkat.
Az előfizetőink többségének nemhogy a Drupal, de a tartalomkezelőrendszer sem mond sokat, így nagyon sok, és részletes oktatóanyagot kellett készítenünk, amit folyamatosan kell bővítenünk videókkal, marketing elmélettel, és gyakorlattal.
Ugyanez vonatkozik az újabb modulok beépítésére, tesztelésére, és fordítására is (a fordításokat hamarosan közzétesszük).
Belátom, hibáztunk a kommunikációnkkal és nem fektettünk elég hangsúlyt a támogatásra a weblapunkon, de a felhasználói vélemények is egyértelműen megerősítik azt, hogy helyes irányban haladunk a céljaink megvalósításában.
Mindazonáltal - átgondolva az aggodalmaitokat -, átalakítjuk a szolgáltatásunkat, és módosítjuk az eddigi kommunikációs gyakolatunkat is. Többek között nyilvánossá tesszük a Drupal mibenlétét, és azt az elvet is, ami szerint ha valaki meg szeretné majd szüntetni az előfizetését, az ingyen elviheti az elkészült weblapját, és az adatbázisát. A Drupalt tehát NEM ÉRTÉKESÍTJÜK.
Legvégül szeretném, ha megértenétek, hogy olyan réteget szolgálunk ki, amelynek a drupal.hu közösség segítsége mellett is minimális esélye lenne egy önálló webes projekt megvalósítására, és hiába vennének egy profi "weblapszerkesztőtől" pl. Drupal alapra megírt komplett weboldalt, nem tudnák üzemeltetni.
Kérem, hogy folytassuk a beszélgetést a fentiek tükrében, és figyelembe vételével.
Üdvözlettel:
a projekt üzemeltetői
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
Nem sok köze van a két rendszernek egymáshoz
Végeredményben azt akarom elérni, hogy megvan a drupal oldalam, és amellett (egy szerveren) van az apexes dolog is.
Az apex oracle adatbázison fut, így ha telepíteni akarod kell minimum egy oracle XE plusz egy webszerver (apache vagy tomcat...), ha felrakod ezeket egy saját szerverre vagy VPS-re, akkor rakhatsz apache-php-mysql-t is mellé. Így futtathadod őket egy szerveren. De több mint egy giga memória kell valószínűleg ezekhez.
Ilyen szinten el tudom képzelni a kapcsolatot a két rendszer között:
- Mind a drupal, mind az apex tud harmadik rendszerből, pl. LDAP-ból authentikálni.
- A drupal fut oracle-en is (bár nem tudom mennyire megbízhatóan, https://drupal.org/project/oracle).
Így ha egy db-ben van oracle alatt a két rendszer, akkor mind a drupal-ból is eléred az apex tábláit és az apex-ből is a drupal tábláit.
- Az oracle tud dblink-et (http://docs.oracle.com/cd/B28359_01/server.111/b28310/ds_concepts002.htm), így ha a drupal mysql-ben van pl. akkor még az apex láthatja a drupal tábláit, "mintha" azok oracle alatt lennének.
Ez alatt azt értem, hogy ne a külön apexes kezelőfelület jelenjen meg hanem egy általam készített drupalon belül.
Nem nagyon lehet a két kezelőfelületet összeolvasztani, mert minden más, sessionkezelés, webszerver. Persze valamilyen fapadosabb pl. iframe-s megoldással megjelenítheted az apex alkalmazást, pl. egy riportját egy drupal site-on belül. De ez nem az igazi integráció.
Az apexnek vannak letölthető fájlai de azokat nem tudom hova tegyem, mivel .sgl kiterjesztésűek.
???
Az apex alkalmazást egyben szokták exportálni, ahogy a fórumon nézegettem (részenként nem nagyon lehet verziózni, mert minden a db-ben van). Ezt az export-ot tudod két oracle között, pl. a teszt és éles szerver között mozgatni.
Maga az apex mint fejlesztő eszköz benne van az újabb oracle adatbáziskezelőkben, így ha telepíted az adatbáziskezelőt, akkor már az apex is telepítve van.
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
Igen, használják. De
Igen, használják. De angoloknál is használják és biztos vagyok benne, hogy az ottani "hétköznapi" ember se tudja, hogy mi az a hash, mivel IT szakzsargonba van a szövegbe írva és nem is tudnék egy másik szinonima szót mondani erre az angol szóra úgy, hogy ugyan azt jelentse (max one-way-coded, de ez nem minden használatnál igaz). Erről nem mi tehetünk, hogy a modul fejlesztője olyan szót tett bele a szövegbe ami IT-s... Emiatt jobb is lehet, ha nem fordítanánk le, aki akar rákeres a "hash"-re, magyar irodalomba is benne van így, nem muszáj a magyar megfelelőjét használni. De én határozottan elutasítom azt, hogy olyan fordítás legyen belőle, mint az NDK-s pornófilm szinkronizáció volt... (nem én szinkronizáltam/fordítottam még a félreértés előtt ezt leszögezem) Arról aztán nem is beszélve, hogy a szövegnek egyértelműnek kell lennie, ha azonosító lenne (identifier) akkor mindenki szerintem az ID-re fog gondolni (legalábbis a szakmabeliek biztosan valami hasonlóra).
Ha már ID, azt se hiszem, hogy minden felhasználó tudja mi az az ID. Ennek ellenére van olyan fordítás ahol ID-ként maradt a magyar szövegben, míg más magyar szövegben "azonosító"-ra lett helyesen lefordítva (az ID is helyes, csak kérdés, hogy ki érti meg ha a normál felhasználókat nézzük?). Azonosításra meg inkább az ujjlenyomat esetben van.
Ha rákeresünk, hogy "mi az a hash?" akkor a google jelenleg elégé sok jó találtatott dob ki, ahol a wikik általában konyha nyelven magyarázzák el, így ha nem értik meg a userek, azzal már semmit se tehetünk.
De ha valami gáz van, és nem megfelelő üzenet jelenik meg, akkor aztán kezdhetjük az egész rendszer debuggolni, meg hackelni, mire rájövünk, hogy mi az igazi probléma... (a fordítás) Mondjuk szerintem ezért szeretem én is angolul adminisztrálni a drupalt, mert úgy biztos nincs szöveg és valóságbeli eltérés. (legalábbis olyan nagy)
Elhiszem, hogy jó lenne, ha mindenki érteni mi az, de ez csak egy ideális képzeletbeli világban fog sikerülni talán, bármennyire is szeretnénk megoldani ezt a problémát. Itt az első az, hogy a fordítás szöveg hű legyen, azaz legyen visszakereshető így akit érdekel megnézheti, hogy mi az vagy legyen érthető egy (talán) tágabb csoport számára is.
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
kódolások krónikája
A Drupal mindenképpen utf-8 kódolással működik, mert eza legpraktikusabb, ha bármilyen nyelvi kódkészletet akar támogatni az ember. Például megjeleníthetsz német, japán és arab karaktereket is ugyanazon az oldalon. Neked most ennél persze gyakorlatibb problémád van :)
Namost azt kell tudni, hogy egy weblap mindenképpen csak egy kódolású lehet egyszerre. Mivel az oldalon Drupal által generált tartalom is ki van írva, ezért az oldal utf-8 kódolású, ez van. Alapesetben a böngészők az űrlapot az oldal kódolásával küldik el. Ez meta elemből nem változtatható, mivel a Drupal okosan HTTP fejlécet küld a használt kódolásról és azt meta elemben nem lehet felülírni.
Tehát két lehetőség van. Vagy olyan oldalba rakod az űrlapot, ami latin-2 kódolású, vagy megoldod, hogy az űrlap latin-2ben küldje az adatokat. Az elsőre megoldás hogy iframe elembe rakod az űrlapot, amit a szerverről külön fájlból töltesz be az oldalba. Akkor annak már lehet saját kódolása. A másodikra a HTML elvi megoldást ad azzal, hogy megadhatod az accept-charset="iso-8859-2" attribútumot a form elemen, amivel elvileg a böngészőnek meg kellene értenie, hogy a submitot fogadó csak latin-2 kódolást ért. Ezt ismereteim szerint kevés böngésző támogatja (gyakorlatilag nem lehet rá építeni). Itt van egy eléggé régi teszt: http://www.goof.com/pcg/marc/browser.html
Végül szerintem legjobban akkor jársz, ha valamilyen Drupalon belüli megoldást használsz. A webform modul például pont ilyen űrlapok adatainak a begyűjtésére szolgál.
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
A hozzászólásodra reagáltam
A hozzászólásodra reagáltam, ebből következik, hogy egy adott problémára válaszoltam, igaz arra is általánosan, de ezen felül írtam egy "jolly-joker" megoldást arra az esetre, ha Te nem tudsz megbírkózni a problémával.
Bár a kérdésed nagyon frappánsan megfogalmaztad, de az valójában meglehetősen komplex, így szerintem egy "szájbarágós", minden eshetőségre kiterjedő megoldást nem nagyon fogsz találni.
Kezdjük ott, hogy szinte semmit nem tudunk a :
- Milyen az régi fizetős szerver konfigurációja?
- Milyen az XAMPP szerver konfigurációja?
- Milyen az új fizetős szerver konfigurációja?
- Milyen modulokat használsz?
- Te raktad össze a Drupal oldalt?
Egyébként pedig miért nem próbálod ki azt, hogy első lépésben csak a XAMPP szerverre viszed át az oldalt? Ha az megy, akkor már menni fog a XAMPP-ról egy másik szerverre való költözés is.
Végeztél már Drupal upgrade-et? Akkor elvégzed az előkészületi lépéseket.
- Karbantártási módba lépsz.
- Lemented a fájlokat.
- Adatbázist kidumpolod.
Ha megvan, akkor létrehozod az adatbázist az új szerveren, megcsinálod a VirtualHost bejegyzést az Apache-ben, a megfelelő helyre felmásolod a fájlokat, a korábbi adatbázis dumpot betöltöd.
A settings.php-ban pedig az aktuális beállításokat megejted.
Amire figyelni kell még:
- Milyen kódolásúak a fájlok.
- Milyen kódolásban tároltad adatbázist és az új helyen milyenben szeretnéd tárolni.
- Modulonként átnézed a beállításokat, nehogy tartalmazzan egyedi speciális beállítást.
Ha lennének konkrét kérdéseid, vagy belefutnál problémába, biztos tudnánk megoldást javasolni, de sajnos ez anélkül nem megy, hogy nem próbálod ki.
Páldi Zoltán
Ha jobban megnézed
a felfedett szűrőknek alaphelyzetben is van értékük, pl. ha üres a szövegmező akkor kihagyja a feltételt a lekérdezésből, az eredmény egyértelmű. Ezeket hogy vegye az SQL figyelembe az elképzelésed szerint?
Üdv!
Dudás József