sminkben adatot módosítani?
helyette a theme_preprocess_node -ot kell inkább a template.php -ban megvalósítani és ott kedvünkre módosítani a $content (és egyéb változók) tartalmát
Sminkben adatot módosítani gányolás. (Persze én is csinálom, meg még ennél durvább dolgokat is. :D) Sminkben legfeljebb megjelenítést, "statikus" elemeket illik módosítani. Például így jön ki a motorból:
<div class="valami">adat</div>
És helyette ezt szeretném:
<div class="valami"><span>adat</span> valami</div>
... ahol a "valami" mondjuk nyelvfüggő, vagy az adat értékétől függően változik. Viszonylag ritka eset.
display:none is for loosers:)
A nagykönyvet szépen megtanulta a leányzó, de nem sok valós munkatapasztalata lehet. :) Például a keresődoboz labeljét rendszeresen display:none-nal tüntetem el. Egy ilyen dolog miatt többnyire nem éri meg formalterezni, hacsak nincs napi egymillió látogatónk, ahol az a pár byte is számít. Általában kissé egészségtelen dolog, ha a megjelenítési célból írt PHP kód önmagában egy nagyobb modul méretére duzzad – mert itt nem élvezzük a közösségi karbantartás előnyeit.
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
csak akkor, ha a címlap egy node
A címlapot csak akkor számolja, ha egy node van beállítva címlapnak:
<?php if (variable_get('statistics_count_content_views', 0)) { // We are counting content views. if ((arg(0) == 'node') && is_numeric(arg(1)) && arg(2) == '') { … } } ?>
Ha nem node a címlapod, akkor az accesslog táblában látod a lekéréseket (feltéve, hogy engedélyezted a logolást az /admin/reports/settings oldalon).
Statistics Advanced modul, további hasznos linkekkel a projektoldalon.
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
Szia!
Szia!
Köszönöm a reagálást!
Sajnos a domenem.tld/update.php elérhető akkor is ha nem vagyok bejelentkezve és futtatni lehet az adatbázis frissítést.
Az oldal élesben megy és ez a hiba a legutóbbi frissítés után jött elő, mikor 10.1.6-ra frissítettem.
A setting.php fájlban kommentelve vannak ezek a sorok:
ezek szerint nem hivatkozza be a settings.local.php fájlt.
$settings['update_free_access'] egyszer szerepel csak a fájlban.
Úgyhogy tovább keresgélek és köszi ha még van valami ötleted!
SimonT
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
Gyanus ez a problema
Darabokra szedtem a lapot, igy nez ki a page.tpl.php:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" lang="<?php print $language ?>" xml:lang="<?php print $language ?>"> <head> <title><?php print $head_title; ?></title> <?php print $head; ?> <?php print $styles; ?> </head> <body> <div id="page"> <div id="main"> <a href="http://klikide.hu">Egy nagyon hosszu link amely kifut az oldalbol</a> Tobb mint egy A4 oldalnyi szoveg Tobb mint egy A4 oldalnyi szoveg Tobb mint egy A4 oldalnyi szoveg Tobb mint egy A4 oldalnyi szoveg ...... ...... </div> <div id="footer"> footer </div> </div> </body> </html>
A CSS kod itt van (Csak ez van a style.css fajlban) :
#main { overflow: hidden; width: 704px; }
Ha "overflow:hidden" be van kapcsolva akkor a "nagyon hosszu" link nem fut ki az
oldal tartalmabol, de a nyomtatasnal a lap igy nez ki:
http://img76.imageshack.us/img76/6700/pagefa8.png
Az elso oldal belemegy a masodikba, es a masodik oldal is tele kene legyen szovegel! de sajnos nem igy tortenik...
Ha lenne valami otlet kerlek irjatok!
Koszonom!
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
jó lenne tudni _pontosan_ hogy mit akarsz csinálni
nem kamuságokat, úgymint htmlt szúrni a nodeba, hanem a pontos elvárt célt lenne jó tudni.
az előfeldolgozóban állítódnak össze a tpl.php számára a változók, azokból az adatokból, amiket a hook_nodeapi view ága rakott össze. ezeket a változókat kedvedre módosíthatod és újakat is bevezethetsz, de az újak kiíratásáról neked kell gondoskodni a kapcsolódó template fileban.
például szeretnék egy új változót, a neve legyen mondjuk response. (sminkem neve playground)
template.php
function playground_preprocess_node($vars) { $vars['response'] = 'yahoo, it works!'; }
node.tpl.php valahol, ahol neked ok:
<?php if ($response) : ?> <div id="response"> <?php print $response; ?> </div> <?php endif; ?>
vagy ha mondjuk a $content értékéhez akarsz fűzni valami dolgot, akkor megint template.php:
function playground_preprocess_node($vars) { $vars['content'] .= '<br />yahoo, it works!'; }
hát így.
ha pontosan megmondod mit akarsz elérni, akkor pontosan meg tudom mondani, hogyan csináljad azt. perpillanat leginkább egy "vajon kitalálja e aboros, mit akarok csinálni" kvízműsorra hasonlít ez a szál, nem valami produktív így a segítségnyújtás, vaktába lövöldözök csak.
-
clear: both;
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
nem kell atirni a bootstrap.inc -et
eleg orult otlet.
igen, a proxy miatt van.
masok is futtatnak am drupalt proxy kornyezetbe, gondolod, hogy nem futottak meg ebbe a problemaba es nincs ra mas megoldas, mint barbarul atirkalni a bootstrap inc?
de van.
mondjuk telepiteskor nem lett volna rossz elolvasni pl a default.settings.php filet mielott lemasolod. (sajnos nincs benne az INSTALL.txt -ben, hogy nem art elolvasni.. bar az install txt is tudod hanyan olvassak el? senki kb.. aztan sirnak, hogy nem megy)
szoval idezem a default.settings.php -t:
/** * reverse_proxy accepts a boolean value. * * Enable this setting to determine the correct IP address of the remote * client by examining information stored in the X-Forwarded-For headers. * X-Forwarded-For headers are a standard mechanism for identifying client * systems connecting through a reverse proxy server, such as Squid or * Pound. Reverse proxy servers are often used to enhance the performance * of heavily visited sites and may also provide other site caching, * security or encryption benefits. If this Drupal installation operates * behind a reverse proxy, this setting should be enabled so that correct * IP address information is captured in Drupal's session management, * logging, statistics and access management systems; if you are unsure * about this setting, do not have a reverse proxy, or Drupal operates in * a shared hosting environment, this setting should be set to disabled. */ # 'reverse_proxy' => TRUE, /** * reverse_proxy accepts an array of IP addresses. * * Each element of this array is the IP address of any of your reverse * proxies. Filling this array Drupal will trust the information stored * in the X-Forwarded-For headers only if Remote IP address is one of * these, that is the request reaches the web server from one of your * reverse proxies. Otherwise, the client could directly connect to * your web server spoofing the X-Forwarded-For headers. */ # 'reverse_proxy_addresses' => array('a.b.c.d', ...), # );
szoval, sajat settings.php -ban, kiveszed a kommentet a megfelelo sorok elol... reverse_proxy => TRUE, megmondod a reverse_proxy_addresses tombbe a proxy ipket (szolgaltatodtol elkered)..
es kesz.
itt a tema 2007bol, amiben a kerdessel foglalkoznak.. 2007 november 26 ota megoldott a dolog es nem kell hozza atirni a bootstrap.inc!!
http://drupal.org/node/173408
ugyan ez a beallitasi hianyossag okozza a masik problemadat, a statisztika gyaszt..
-
clear: both;
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
Most kipróbáltam 3 különböző
Most kipróbáltam 3 különböző SMTP Drupal modult.
1.) Swift Mailer
- 3 metódust kínál: Sendmail, PHP és SMTP
- az első kettővel jönnek a levelek (de a webszerver IP-ről)
- az SMTP-vel hibaüzenet (gmailes és ofiice365 SMTP-ről egyaránt)
An attempt to send an e-mail message failed.
Nem lehet emailt küldeni. Ha a probléma tartósan fennáll, akkor értesíteni kell a webhely üzemeltetőjét.
2.) SMTP Authentication Support
- a levél eljön, de a metaadatok a szokottak:
Received-SPF: softfail (google.com: domain of transitioning [email protected] does not designate webszerverIP as permitted sender) client-ip=webszerverIP;
Authentication-Results: mx.google.com; spf=softfail (google.com: domain of transitioning [email protected] does not designate webszerverIP as permitted sender) smtp.mail=[email protected]; dkim=neutral (bad format) [email protected]
- ha a Drupalban mindenhol a gmailes címemet állítom be levélküldőnek, akkor akövetkező az üzenet:
Received-SPF: neutral (google.com: webszerverIP is neither permitted nor denied by domain of [email protected]) client-ip=webszerverIP;
Authentication-Results: mx.google.com; spf=neutral (google.com: webszerverIP is neither permitted nor denied by domain of [email protected]) smtp.mail=[email protected]
- tehát még mindig látszik a webszerver IP-je. Vagy ez normális?
3.) PHP Mailer
A beállítások mentése megtörtént.
SMTP -> ERROR: Failed to connect to server: Connection timed out (110)
A test e-mail has been sent to [email protected]. Check the logs for any error messages.
Ez a hibaüzenet:
SMTP error: could not connect to SMTP host
Server response:SMTP -> ERROR: Failed to connect to server: Connection timed out (110)
Subject: PHPMailer test e-mail
Body:
Your site is properly configured to send e-mails using the *PHPMailer*
library.Message:
array (
'id' => 'phpmailer_test',
'module' => 'phpmailer',
'key' => 'test',
'to' => '[email protected]',
'from' => '[email protected]',
'language' => NULL,
'send' => true,
'headers' =>
array (
'X-Mailer' => 'Drupal',
),
)
Nem lehet emailt küldeni. Ha a probléma tartósan fennáll, akkor értesíteni kell a webhely üzemeltetőjét.
Hát, szóval ennyi... Szerintetek, kihez forduljak? Illetve, ha a tárhelyszolgáltatóhoz, akkor mit mondjak neki, mit állítson át?
Kovács Márk
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
A probléma pontosítása
(A VIEW-et fordítva írtam, de már nem tudom javítani.)
Most így néz ki a select:
SELECT users.uid AS uid, field_data_field_felhasznalo_teljes_nev.field_felhasznalo_teljes_nev_value AS field_data_field_felhasznalo_teljes_nev_field_felhasznalo_te, 'user' AS field_data_field_felhasznalo_teljes_nev_user_entity_type FROM {users} users LEFT JOIN {field_data_field_felhasznalo_teljes_nev} field_data_field_felhasznalo_teljes_nev ON users.uid = field_data_field_felhasznalo_teljes_nev.entity_id AND (field_data_field_felhasznalo_teljes_nev.entity_type = 'user' AND field_data_field_felhasznalo_teljes_nev.deleted = '0') WHERE (( (users.status <> '0') AND (users.uid NOT IN ('1')) )) ORDER BY field_data_field_felhasznalo_teljes_nev_field_felhasznalo_te ASC LIMIT 10 OFFSET 0
Mező nyelve: Aktuális felhasználó nyelve
Ez bekapcsolva: "A mező nyelvi feltételeinek átadása a lekérdezés számára ha szükséges"
A problémám tehát, ha az ORDER BY-ban szerepel a "teljes_nev" ami fordítható mező, akkor nem csak az aktuális nyelvhez tartozó sorok jelennek meg. Egészen pontosan 2x jelenik meg magyar nyelven minden felhasználó neve, még csak nem is angol a második soruk :)
Gondolom, hogy az is megoldaná a duplikálási problémát, ha a WHERE feltételbe valahogy bekerülhetne, hogy figyelje a nyelvet, de a VIEW-ben, nem találok ilyen kattintgatási lehetőséget. Kérem a segítségeteket. Mi lenne a megoldás?
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
Fast Gallery - minek? Inkább valami tisztességes galériakezelő.
Ez jó, hogy megosztottad a problémád forrását. DE már többször felmerült bennem a kérdés - és annyiszor került terítékre a fórumon ez a modul, hogy már muszáj rákérdeznem -, hogy vajon miért szeretik a zzzemberek a Fast Gallery-t? :)
Úgy tudom, a FG csak annyit csinál, hogy bizonyos külön-külön létrehozott, képekkel és egyebekkel teletömködött könyvtárakból kibogarássza a tartalmat (bővítve esetleg újabban feltöltöttekkel a rescan gomb hatására), egyébként ennek megfelelően igencsak rugalmatlan és bedrótozott megoldás. A fájlokat nem a Drupal-módon kezelgeti, hanem csupán lazán csatolt módon. A fájlokat a tárhelyre FTP-csatlakozás (vagy a tárhelyre más módon csatlakozás) útján kell feltölteni, simán akárhonnan bejelentkezve a Drupalos weboldalra, a szokásos feltöltős módon nem lehet (vagy csak nem írják a project oldalán).
Egyszerűen nem látom indokoltnak a használatát, főleg, hogy több modul is létezik arra, hogy egyszerre sok képet fel lehessen tölteni, mindenféle adott esetben (pl. nem saját környezetben) kényelmetlen FTP-csatlakozási kényszertől mentesen.
Ráadásul a modul állapota jelenleg "Unsupported".
Túl sok előnyt eddig nem látok.
Ez ráadásul hatalmas bullshit:
Fast Gallery is a simple, lightweight, and fast image gallery. Making albums is as easy as putting images or videos into folders and uploading them to the gallery directory. It is fast because it is not based on nodes and doesn't implement some of the more complex features of larger gallery systems.
Ja, ez tök jó, hogy egy könyvtárba kell behánynod mindent, rescan gombokat nyomkodni, és tök jó, hogy egyszerű és bután rugalmatlan az egész, mint egy marék lepke.
Ráadásul írtad, hogy most lőtted be az egészet (legalábbis nekem úgy jött le). Eleve most már a 6-ossal nem szabadna kezdeni, egyből a 7-est kellene előkapni, a 6-oshoz (magához a core-hoz és a contrib modulokhoz is) a support amúgy is már egyre szegényesebb. A 7-es Drupalhoz meg vicc a Fast Gallery használata, annyi annál ezerszer értelmesebb galériamodul van.
De mivel most a 6-os a téma, és írtam, hogy létezik alternatíva, itt van egyből kettő:
Image FUpload
https://drupal.org/project/image_fupload
Plupload integration
https://drupal.org/project/plupload
(ja, ez utóbbi csak dev)
+
Node Gallery
https://drupal.org/project/node_gallery
aztán biztos, hogy van még egy csomó más, most hirtelen ezek jutottak eszembe. Például az előbbi kevésbé tűnik overkillnek.
De ha teheted, amúgy is állj át inkább a 7-es Drupalra (upgrade), és használj legalább egy fokkal komolyabb modulokat, mint a Fast Gallery. :)
Nem kell persze ezzel egyetérteni (ellenvéleményeket elfogadok), de érdemes megfontolni, hogy biztos jó-e elfogadni a Fast Gallery könyvtárkotorászós kötöttségeit. :)
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
Szia!
Szia!
Mi is tárhely szolgáltatással foglalkozunk, nem akarom magunkat reklámozni, inkább csak pár infót írnék, ami talán még hasznos lehet a keresgélés során.
Ha szolgáltatót választasz leendő drupal weboldaladnak (weboldalaidnak), az alábbiakat érdemes szem előtt tartani:
- több szolgáltatónál csak régebbi php verziók vannak telepítve, így nem biztos, hogy a legújabb verziójú drupal futni fog.
- Ha több weblapot is szeretnél, és ezek verziói eltérnek egymástól, sok szolgáltató tárhelyhez köti a php verziót (ha jól tudom a cPanel ilyen) és nem pedig aldomainhez. Ekkor több tárhelyet kell vásárolnod még akkor is, ha amúgy elférnének egymás mellett a weblapok.
- A drupal sok szolgáltató szerverén minősíthetetlenül lassan fut, ezért mindenképp olyan szolgáltatót érdemes választani, ahol vannak valamilyen memcache és egyéb gyorsítási lehetőségek (itt pont nem egy SSD tárhelyre gondoltam, mert egy SSD tárhely a sok sql lekérdezést és php futtatást nem gyorsítja).
Azt ajánlanám, hogy olyan szolgáltatót keress, akik adnak ingyenes vagy próba tárhelyet, vagy van náluk indoklás nélküli pénz visszafizetési garancia, ha esetleg nem felel meg a szolgáltatás minősége, sebessége.
Mi pl. egy gyors regisztrációt követően (csak a bejelentkezés miatt kell, nincs reklám, sem hírlevél feliratkozás) igyen adunk 100Mb dinamikus tárhelyet, a weblapot ezen össze lehet rakni és a sebességét le lehet tesztelni. Ha később kevés lesz, akkor van lehetőség nagyobb csomagra váltani. SSL-t és hozzá IP-t is tudunk biztosítani sok szolgáltatóhoz képest sokkal olcsóbban (az ingyenes tárhelyre is). Van egy alkalmazás telepítőnk, melybe a jövő héten kerül be a legújabb drupal verzió.
Nálunk saját fejlesztésü admin rendszer van, úgy oldottuk meg, hogy aldomainhez köthető a php verzió futtatás is (5.4, 5.5, 5.6, 7 verziók futtathatók).
Remélem tudtam segíteni, hogy megfelelő szolgáltatót tudj majd találni. Amennyiben a mi szolgáltatásunk érdekel, privátban nagyon szívesen megírom a webcímünket.