PHP

Egyedi smink készítésének alapjai Drupal 6 alatt

Rendszeresen megkeresnek azzal a kéréssel, hogy hogyan kell egyedi Drupal sminket készíteni, mert nem akrarnyak egy már elkészített contrib fejlesztést használni.
Én is általában azt szoktam javasolni, hogy inkább készítsük el saját magunk a meglévő psd alapján a sminkünket, mert igaz az esetek legtöbbségében meg lehetne oldani valamely már meglévő fejlesztés css-ének módosításával, de az mégsem az igazi. Egyrészt azért, mert a contrib sminkek több dologra vannak felkészítve mint amire nekünk szükségünk van, másrészt a végeredményben úgyis egy 3000 soros css-t kapunk amiben egy rakás osztály, vagy id több helyen van definiálva. Másrészt ahogy a contrib modulokba se szokás beleirkálni, szerintem a sminkeket se kell piszkálni.

Ha saját sminket készítünk, saját tpl és css fájlokkal akkor ezek a problémák kiküszöbölhetőek, és nem egy ördöngös feladat.

Leszögezném, hogy ez a bejegyzés csak az alapokról szól, nagyon sok egyéb dologra felkészíthetjük a sminkünket, pl: $logo, $site_slogan, $mission, $search_box stb. Az elérhető változókat itt lehet megnézni.

A Drupal 6, a Wysiwyg API, a TinyMCE 3 és a Drupal teaser megadása és különválasztása a teljes tartalomtól

A WYSIWYG editorok lényege, hogy a felhasználó HTML tudás nélkül is tudjon webes felületen formázni. Ezt úgy érjük el, hogy a html szöveget tartalmazó textarea-ra egy JavaScript szerkesztőfelületet adunk, ami a begépelt és formázott szöveget HTML kódokká alakítja át.

Drupal alá is létezik sok közkedvelt WYSIWYG editor modul, pl: FCK Editor vagy a TinyMCE Editor, melyek mindig előkelő helyen vannak a leggyakrabban letöltött Drupal modulok között.

Drupal-ban az elsődleges linkek (primary links) helyére képek a themes_links() fgv. kifejtésével

Nekem már többször előfordult olyan problémám, hogy a Drupal elsődleges menüjének (primary links) egyedi kinézete miatt, kizárólag képekből álló menüt kellett készítenem. Ezalatt azt értem, hogy nincs a háttérkép felett semmilyen szöveg, a menü címe is a képen szerepel.

A háttérképeket egyszerűen megadhatjuk, a menüpontok egyedi azonosítója miatt (pl. menu-130 stb.), viszont a rajta lévő szöveget el kell tüntetni valahogy.

CSS-ben ha levesszük a betűméretet 0px-re sajnos nem a megfelelő megoldás, mert IE-ben, Chrome-ban és Operában kicsiben, de látszik.

Egy megoldás, ha a hyperlinkek szövegét span elemek közé tesszük, és a span elemeket tüntetjük el CSS-ben a display: none; definícióval, tehát a cél az lenne, hogy így nézzen ki egy menüelem:

<li class="menu-129"><a class="menu-129" href="/"><span class="primary-title">Nyitólap</span></a></li>

Ekkor minden további nélkül megadhatjuk CSS-ben a következőt:

ul.primary-links span.primary-title {
display: none;
}

Igenám, de hogy érjük el, hogy a Drupal span elemek közé tegye a linkek címét?

A megoldás az, hogy a sminkünk template.php fájljába kifejtjük a theme_links() fgv-t.

Íme a kód:

/**
 * Csak kepekbol allo menu elkeszitesenek alapjai
 *
 * @param unknown_type $links
 * @param unknown_type $attributes
 * @return HTML
 */
function phptemplate_links($links, $attributes = array('class' => 'links')) {
  global $language;
  $output = '';
 
  if (count($links) > 0) {

Az fgvtcsv beépített php fgv iso-8859-2 -es karakterkódolásban elhagyja az ékezetes kezdőbetűket

Az egyik általam készített Drupal alapú webáruház termékeinek adminisztrálása CSV alapon működik. Ez annyit jelent, hogy van egy exportáló felület, ahol a site admin lementheti a termékeit egy csv fájlba, amit aztán valamilyen csv-t kezelő programban (általában Microsoft Excel) átszerkeszt, és egy importáló felületen feltölt. Ezután az oldal feldolgozza és érvénybe lépnek a változtatások.

Ez így mind szép és jó, csak egy gond van vele. A windows felhasználók nagy része, ISO-8859-2-es karakterkódolást használ, míg a Drupal UTF-8-at. Hogy a címek és egyéb karakterkódolástól függő érték problémáját kiküszöböljük, szükség van az mb_convert_encoding() fgv-re, amely segítségével az ISO-8859-2 karakterkódolású részeket, át tudjuk konvertálni a Drupal-nak is használható UTF-8-as karakterkódolásba.

Egyszercsak jelentkezett egy probléma. Azon kezdőbetűk amelyek ékezetesek egyszerűen elvesztek. Tehát például az "Öntapadó" szóból, "ntapadó" lett.

Druplal 5-ben a $node->path, azaz a url alias érétke üres? A megoldás

A Drupal 5-ben van egy hiba amiről a programozók sokszor elfelejtkeznek.

A $node objektumnak van egy path attribútuma:

<?php
$node->path;
?>

Ez a node-hoz tartozó url alias, tehát a megadott elérési címet tartalmazza. Sokszor használjuk különböző tartalmak dinamikus gyűjtőoldalán, ezért fontos tisztában lennünk ezzel a hibával.

A probléma az, hogy amikor admin-ként vagyunk bejelentkezve a path érték megfelelő, ám ha nem akkor üres, így minden link a kezdőoldalra mutat. Ez annyit takar, hogy nem lehet elérni a kívánt bejegyzéseket, és ha nem elég körültekintő a tesztelés, akkor fel sem tűnik, mivel a session-be bentmaradunk mint bejelentkezett admin-ok, így nem is érzékeljük a hibát.

A megoldás egy egyszerű beépített Drupal fgv használata

<?php
$node->path = drupal_get_path_alias("node/$node->nid");
?>

Ez egy nagyon egyszerű megoldás, mégis ha nem vagyunk vele tisztába komoly gondot okozhat a weboldalon, de hangsúlyozom: megfelelő tesztelés esetén ki kell hogy derüljön még az élesítés előtt.

A Drupal globális base_url változója és a www redirect probléma

A Drupal-nak van egy globális változója, melynek a funkicója az, hogy visszadja azt az URL címet ahol a telepített CMS-ünk aktuálisan el van helyezve.
Ennek a lényege az, hogy pl. ha a fejlesztés egy már meglévő domain egy alkönyvtárában zajlik, akkor a site élesítésekor ne történjen semmilyen probléma. Gyakorlatilag a telepített Drupal-t akárhova pakolhatjuk, a képek elérései és az oldal elérések nem változnak.

Ez a változo a

<?php
$GLOBALS['base_url'];
?>

Ha ezt használjuk akkor mondjuk egy kép, vagy egy oldal eléréshez nem kell beledrótóznunk a fejlesztéshez használt alkönyvtár nevét.
Ha a Drupal pl. a root/ujweboldal könyvtárban van, akkor ha egy oldal elérését így adjuk meg:

<a href="/kapcsolat">Kapcsolat</a>

akkor nem a root/ujweboldal/kapcsolat oldal fog bejönni, hanem a root/kapcsolat. Ez pedig komoly problémékat okozhat.

Ezt elkerülendően általában a következő eljárást szoktuk alkalmazni:

<a href="<?php print $GLOBALS['base_url'] ?>/kapcsolat">Kapcsolat</a>

Ekkor akárhova helyezzük az oldalt müködni fog az elérés.

Viszont felmerült egy probléma ha az oldalt át akarjuk irányítani a www nélküli címéről a www-s címére.
Ez azt jelenti, hogy beállítunk egy olyan redirect-et, hogy a http://example.com automatikusan menjen át a http://www.example.com címre.

A probléma a form-ok feldolgozásánál jelentkezik!

<form action="<?php print $GLOBALS['base_url'] ?>/form-feldolgozas" method="post"></form>

Enter gombbal submit esemény a Drupal node szerkesztési felületén jQuery-vel

Olyan oldalaknál ahol egy bizonyos node tipushoz sok beviteli mező tartozik elvárás lehet, hogy ne kelljen minden módosításnál lemenni a lap aljára.

A logikus megoldás az, hogy az ENTER gomb lenyomásával jelzi a felhasználó, hogy végzett a tartalom módosításával, feltöltésével.

Az eseményt a jQuery JavaScript könyvtárral könnyen meg lehet oldalni, utána pedig már csak egy nagyon egyszerű Drupal modult kell hozzá írni, és minden olyan weblapon alkalmazni lehet ahol szükség van rá.

Íme a JavaScript fájl amint majd hozzárendelünk az oldalhoz:

var writing   = false;
var node_edit = false;
 
$(document).ready(function() {
 
  if ($('#node-form').length) {
    node_edit = true;
  }
 
  if (node_edit) {
    $('.form-textarea', $('#node-form').parent()).focus(function() {
      writing = true;
    });
    $('.form-textarea', $('#node-form').parent()).blur(function() {
      writing = false;
    });
  }
});
 
$(document).keypress(function(event) {
  if (event.keyCode == 13 && !writing && node_edit) {
 
    if (confirm_submit()) {
      $('#edit-submit', $('#node-form').parent()).click();
    }
  }
});
 
function confirm_submit() {
  var agree = confirm("Valóban menti a tartalom változásait?");
  if (agree) {
    return true ;
  } else {
    return false ;
  }
}

Menjünk végig a kódon, mi miért van!

Először is a writing változó, a node_edit változó és az oldal betöltésekor lefutó fgv-ek, vagyis a $(document).ready(function()).

A viral marketing és a MailMaster

Ebben a bejegyzésben a viral marketing megvalósításáról fogok írni egy rövid leírást.
A MarketingSzoftverek e-mail marketing szoftverét, a MailMastert használva nagyon egyszerűa viral marketing alkalmazása.

A későbbiekben fogok írok majd egy részletesebb cikket is, amiben egy konkrét Drupal modulon keresztül mutatom be ennek a nagyon egyszerű ám annál hatékonyabb rendszernek a lényegét.
Először: mi is az a viral marketing és mire jó?
A rendszer egy nagyon egyszerű és ingyenes módszer a weboldal, blog, cikk vagy akár feliratkozó form látogatottságának növelésére. Azon kívül, hogy ingyenes és hatékony másik nagy előnye az, hogy egyből a célközönséget, a potenciális érdeklődőket veszi célba.

A rendszer lényege, hogy miután valakit meggyőztünk arról hogy adja meg email címét és iratkozzon fel a levelezőlistára, saját maga ajánlhatja az oldat ismerőseinek barátaink, olyan embereknek akikről úgy gondolja szintén érdekelheti az adott oldal.

Így ha valaki ajánl nem egy, hanem akár három-négy feliratkozót is nyerhetünk, akik szintén továbbküldik az oldalt.

Viral marketing ábrázolása
 
Az ábra remekül szemlélteti a viral marketing hatékonyságát.

Email csatolmány küldése Drupal-ban a HtmlMimeMail osztállyal

Egyik ügyfelünknél felmerült az igény, hogy egy form kitöltése után automatikusan küldjünk ki egy email-t csatolmánnyal együtt.

A probléma megoldására a régebbről ismert HtmlMimeMail PHP osztályt használtam.

Nagyon jól megszerkesztett osztály úgyhogy nagyon könnyű használni, ám Drupal alatt mégsem lehetett alkalmazni a leírásban olvastakat.

Az első problémát az jelentette, hogy nem lehetett az osztályt beilleszteni, illetve objektumot készíteni belőle. Egyszerűen kifagyott tőle a Drupal és fehér képernyő jelent meg. Szerencsére van olyan verziója is, amitől nem jelentkezik ez a probléma.

Innen telölthető zip-el tömörítve (20 KB): HtmlMimeMail Drupal.

Miután ez megoldódott nagyjából a HtmlMimeMail oldalán található leírásokat kellett alkalmazni néhány dolgot kivéve.

Először egy ellenőrzés arról, hogy nem-e létezik már az osztály:

      if (!class_exists('htmlMimeMail') && !class_exists('Mail_mimePart')) {
        require_once(dirname(__FILE__)."/htmlmimemail/htmlMimeMail.php");
      }

Utána a szokásos eljárást követve létrehozzuk az objektumot, és beállítjuk a karakterkódolást is, hiszen a Drupal UTF-8 -at használ
 
      $mail = new htmlMimeMail();
      $mail->setTextCharset('UTF-8');
      $mail->setHtmlCharset('UTF-8');
      $mail->setHeadCharset('UTF-8');

A setFrom() setSubject() és a setText() vagy setHTML() beállítása ugynúgy történik mint általában:
   

Drupal 6 expedíció: Internet Corporation smink implementálása

Drupal 6 Internet Corporation theme: Letöltés / Download

Mivel még nem sok Drupal 6 smink készült el és nem akartam a Drupal 6 alapértelmezett sminkjét felrakni az oldalamra úgy döntöttem megpróbálok egy Drupal 5-öst átírni, hogy működjön.
Az Internet Corporation theme mellett döntöttem.

Szerencsére felkerült a Drupal oldalára egy dokumentáció a Drupal 6 sminkeléséről
Ez volt a kiinduló alapom, hogy mégis mért nem müködnek a Drupal 5-ös sminkek a 6-os verzió alatt.

Bevallom őszintén nagyobb problémára gondoltam mint amekkora ténylegesen volt. Az egész megvalósítás nem vett igénybe fél óránál többet, persze miután elolvastam a Drupal oldalán a dokumentációt.
Lényeges különbség, hogy kell egy info fájl, mint a moduloknál. Ebbe kell egy a sminkkel kapcsolatos dolgokat deffiniálni. Milyen css-ek tartoznak hozzá, milyen JavaScript-eket töltösön be automatikusan, milyen régiói vannak stb.

Az Internet_Corporation.info így néz ki, mivel nem igényel különösebb js fájlokat, és a template.php fájlba a régiók definiálva vannak, bár itt is megtehettem volna.
Internet_Corporation.info:

; $Id$
name = Internet Corporation
description = Implements of Internet_Corporation theme for Druapl 6
version = 1.0
core = 6.x
engine = phptemplate
stylesheets[all][] = style.css

Innenstől fogva már nagyjából működött is, persze a blokkok nem jelentek meg, mert megválzotak. Az eredeti Internet Corporation smink nem volt valid HTML úgyhogy eltávolítottam belőle a primary_links-re vontakozó hibát.