In mijn eerste post had ik al benoemd dat ik het "Media Responsive Theme" tegen was gekomen. Dit was een Drupal 7.x versie, we werken nu met Drupal 8.x. Het leek me wel leerzaam om nu zelf dit thema om te gaan bouwen, dat blijkt een behoorlijke uitdaging te zijn. Op deze site stond ook het Mobile Responsive Theme, daar ben ik eerst mee aan de slag gegaan.
Bij drupal kon je werken met php bestanden (node.tpl.php), die bestanden heten nu inmiddels .twig (dus page.html.twig). Het is de bedoeling dat je daar met {% if site.breadcrumb %} ... {{ site.breadcrumb }} ... je data in het sjabloon plaatst. Dus geen inline PHP code meer. Een deel van de data komt "gewoon" uit Drupal zelf, zoals {{ page_top }}, {{ page }}, {{ page.content }}. Maar je zult ook je eigen gegevens in het sjabloon willen krijgen.
Dat kun je doen door in het bestand [themanaam].theme je eigen " pre-process " functies aan te maken.
Ja, je leest het goed. Een bestand met .theme-extensie dat eigenlijk een gewoon PHP bestand is. Ik heb dat netjes gedaan, omdat mijn thema de naam "mobile_responsive_theme" heeft is dat:
function mobile_responsive_theme_preprocess_page(&$vars) {
$vars["huidigjaar"] = date("Y");
}
Zo kan ik in het sjaboon {{ huidigjaar }} gebruiken. Ik ga de naamgeving nog wel een beetje aanpassen, het gaat om het idee.
Er gebeurt dus helemaal niets. Ik moet hierbij wel even vermelden dat ik het thema al geïnstalleerd had en als standaard ingesteld had. Nadat ik het thema in het admin-deel van Drupal verwijderd had en weer toegevoegd had (en als standaard ingesteld had), toen werkte het wel. Ook real-time aanpassingen. Waarschijnlijk was bij de initiële installatie het bestand niet aanwezig of niet goed ingesteld (??).
Ik was al eerder tegen het feit aangelopen dat je niet zoals bij Wordpress "on the fly" je aanpassingen kunt bekijken. Drupal laadt zaken in het geheugen, doet wat met caching. Voor performance en dergelijke is dat fantastisch, maar als je zoals ik stuk voor stuk zaken moet omzetten is dat niet handig. Lees: verrekte irritant. Omdat ik dit toch op mijn eigen macbook aan het ontwikkelen ben, kan ik daar gerust die zaken uitzetten. Via een aantal sites het volgende gevonden:
In /sites/default/settings.php plaats je onderaan de volgende code:
// ff niet cachen!!!!$settings['container_yamls'][] = DRUPAL_ROOT . '/sites/development.services.yml';
$settings['cache']['bins']['render'] = 'cache.backend.null';
$settings['cache']['bins']['dynamic_page_cache'] = 'cache.backend.null';
Dat scheelt. Hierna doe je nog wat aanpassingen in /sites/default/services.yml
debug: true
auto_reload: true
cache: false
Hiermee krijg je te zien of er wat fout gaat en wat de mogelijke oorzaak daarvan is. Met deze configuratie kon ik wel fatsoenlijk lokaal zaken gaan configureren en testen.
Uiteindelijk duurt dat best wel lang. Want er zijn toch nog wel wat zaken die je pas ziet na het de-installeren en weer installeren. Dus we doen het anders. Ik kopieer de bestanden uit de "bartik" map onder /core/themes/ naar een map in /templates/ met een eigen naam (voor het gemak even maatwerk). Vervolgens heb ik de zaken die "bartik" heten hernoemd naar maatwerk.
In dit bestand heb ik 2 zaken aangepast die me storen. Ten eerste, de weergave van de datum van een artikel. Daar zie je de Engelse notatie. (maand/dag/jaar). In het admin-deel kun je de tijdnotatie aanpassen (staat ook op dutch), maar mijn artikelen blijven deze weergave tonen.
In het bestand maatwerk.theme heb ik de functie preprocess_node aangepast naar:
function maatwerk_preprocess_node(&$variables) {$node = $variables['node'];
$nodeDate = ($node->created->getValue());
$formatted_date = $variables["date"];
if (is_array($nodeDate)) {
$nodeDate = $nodeDate[0];
$formatted_date = format_date($nodeDate["value"], 'custom', 'd-M-Y H:i');
}
$variables["date"] = $formatted_date;
}
Dat werkt. Nu nog het delen via sociale media. Ik vind de weergave op Linked-In niet echt mooi. Eerst maar even een og:title en og:image toevoegen, dat werkt bij Facebook, we zullen zien of dat bij Linked-In ook werkt, of dat dit nog even anders moet.
Ik kopieer de inhoud van /core/themes/classy/templates/layout/html.html.twig naar /themes/maatwerk/templates/layout/html.html.twig. Bovenin dit bestand plaats ik:
<!DOCTYPE html><html{{ html_attributes }}>
<head>
{{ maatwerk_og_image|raw }}
{{ maatwerk_og_title|raw }}...
De "raw" is toegevoegd omdat anders je HTML-tags gecodeerd worden, wat je niet wilt.
Dan moeten deze tags nog beschikbaar gemaakt worden. Dat doe je in maatwerk.theme:
function maatwerk_preprocess_html(&$variables) {
...$title = "Techblog Dirk Hornstra © " . date("Y");
if (!empty($variables['page'])) {
$request = \Drupal::request();
if ($route = $request->attributes->get(\Symfony\Cmf\Component\Routing\RouteObjectInterface::ROUTE_OBJECT)) {
$title = \Drupal::service('title_resolver')->getTitle($request, $route) . " | " . $title;
}
}$variables["maatwerk_og_image"] = "<meta property=\"og:image\" content=\"https://...../profile-image.png\" />";
$variables["maatwerk_og_title"] = "<meta property=\"og:title\" content=\"".$title."\" /> ";
}
In het admin-deel wordt bij het bewerken van je artikelen het overzicht nog wel wat vreemd getoond, door Seven niet alleen als admin-skin in te stellen, maar ook als skin voor het bewerken van de content kan ik in ieder geval artikelen toevoegen en bewerktn. Met deze aanpassing heb ik nu in ieder geval twee punten gefixt. Nu binnenkort nog kijken of dit nu een goed beginpunt is om de styling aan te gaan passen.