Blog

Op het huidige ogenblik zijn we een website aan het ontwikkelen waar enerzijds inhoud in Drupal zelf ingevuld en beheerd zal worden, en anderzijds een deel inhoud uit een Oracle database dient opgehaald te worden. De inhoud van de Oracle database wordt via een andere applicatie beheerd.

In de praktijk betekent dit dat het dus niet mogelijk is om alle inhoud éénmalige te importeren. Omwille van de grote hoeveelheid data is het ook niet mogelijk om alle inhoud op regelmatige basis in zijn geheel te importeren.

Drupal connecteren met Oracle

Een connectie leggen met Oracle vanuit Drupal is relatief eenvoudig. Er is een Oracle db driver module beschikbaar die de gehele Drupal database interface implementeert. De vereiste Oracle libraries geïnstalleerd krijgen op je Linux server is echter een heel ander verhaal. Gelukkig zijn er ook al anderen met dit probleem geconfronteerd geweest en is er een uitgebreide uitleg beschikbaar.

Even terzijde, er is eveneens een MSSQL driver beschikbaar, maar die kan je (momenteel) alleen onder Windows gebruiken. Ontwikkelen met MSSQL betekent dus ook dat je webserver onder Windows zal moeten draaien. Er zijn uiteraard nog alternatieve mogelijkheden, maar dat is voor een volgende blogpost.

Inhoud

Aangezien het niet mogelijk was om de grote hoeveelheid data in zijn geheel over te brengen (en deze data is dan ook nog eens veranderlijk), konden we niet echt één van de methodes gebruiken die in deze oude blog post aangehaald werden.

Introductie

Heel wat modules op drupal.org zijn gemaakt met het oog op gebruik in een ééntalige site. De grootste oorzaak is dat de auteurs vooral Amerikanen zijn. Meestal zijn de interface strings wel vertaalbaar maar andere configuratie instellingen zelden. En als deze vertaalbaar zijn worden ze nog steeds veel te vaak door t() gehaald wat helemaal geen goede oplossing is.

In deze blog post zal ik uitleggen hoe je een module schrijft die volledig vertaalbaar is. Met deze info kan je dan ook bestaande modules aanpassen en een patch op drupal.org zetten zodat de module vertaalbaar is voor mensen die na jou deze zullen gebruiken.

t()

De t() functie is waarschijnlijk bekend bij de meeste Drupal ontwikkelaars. Deze functie dient echter enkel en alleen om vaste interface strings van het Engels naar andere talen te vertalen via de Translate interface functionaliteit. Dat wilt dus zeggen dat je enkel Engelse strings in t() mag plaatsen.

Zorg er ook voor de je veranderlijke tekst doorgeeft als parameter zodat de tekst bijvoorbeeld niet voor elke gebruikersnaam dient vertaald te worden. Zoals het voorbeeld:

$text = t("@name's blog",
  array('@name' => format_username($account)));

De t() functie dient dus niet om dynamische content zoals bevestingsberichten of custom berichten op bvb. submit knoppen vertaalbaar te maken. Als je in een configuratiescherm van een module het volgende zou zien:

$form['message_ok'] = array(
  '#type' => 'textfield',
  '#default_value' => variable_get('message_ok', 'Ok!'),
);

En dan op het moment dat deze getoond wordt het volgende:

drupal_set_message(t(variable_get('message_ok', 'Ok!')));

Dan is dat niet ok. Als je het oorspronkelijke bericht verandert verlies je namelijk ook je vertalingen. Dit was een tijdje geleden namelijk nog het geval met de flag module.

Het komt vaak voor als je met Drupal werkt dat je voor een rol of in een specifieke context een form veld moet verwijderen via hook_form_alter() omdat de huidige gebruiker op dat moment niet het recht heeft om die waarde aan te passen. Om dat te bereiken zijn er niet minder dan 3 verschillende methodes. Eén van die methodes zou eigenlijk niet moeten gebruikt worden en alhoewel de 2 andere schijnbaar hetzelfde doen is dat achter de schermen helemaal niet zo.

unset()

Dit was de methode dat ik in het begin zelf gebruikte. Gewoon het veld unsetten en voila het veld was niet meer zichtbaar in het formulier. Het probleem hiermee is dat andere modules misschien ook nog zaken aan dat veld willen veranderen of dat er in validate en submit callbacks zaken mee gebeuren. Als er op die plaatsen niet gecheckt wordt of die property wel gezet is veroorzaakt dit notices.

#printed = TRUE

De render API laat je toe om bepaalde elementen in een renderable array te verbergen via hide() alvorens je de array output met render(). Het enige wat hide() eigenlijk doet is de #printed property op TRUE zetten zodat render() die niet meer themen. Je kan dus ook in een hook_form_alter() #printed op TRUE zetten zodat het veld niet getoond wordt.

Het probleem met deze methode is dat form API niet weet dat de gebruiker eigenlijk geen toegang heeft tot dit veld en dat een kwaadwillige gebruiker dus zelf het element terug kan toevoegen in de html en de waarde er nog van kan veranderen.

In mijn vorige blogpost had ik het over de verbeteringen mbt gebruiksvriendelijkheid in Drupal 7. Deze keer zal ik het hebben over enkele van de talrijke verbeteringen mbt toegankelijkheid.

Een toegankelijke website is een website die toegankelijk is voor iedereen, inclusief personen met een functiebeperking. Tijdens de ontwikkeling van Drupal 7 werd er heel wat aandacht besteed om Drupal toegankelijk te maken. Hiervoor baseerden de ontwikkelaars zich op de WCAG en ARIA specificaties. Dit zijn internationale richtlijnen voor het ontwikkelen van toegankelijke site inhoud en web applicaties.

Skip to main content

Als je nu na het laden van de pagina één enkele keer op de tab toets duwt komt er bovenaan een link tevoorschijn met de tekst “Overslaan en naar de algemene inhoud gaan". Voor de meeste mensen betekent dit niet veel maar voor mensen die een screen reader hebben is dit een handig hulpmiddel. Bij het voorlezen van de links op de pagina is dat de 1e link die wordt voorgelezen en geeft hun de kans eventuele volgende menu’s en blokken over te slaan en in 1x naar de algemene inhoud te springen waarna hun screen reader programma de echte content zal beginnen lezen.