Kategorien
Development

Update auf Piwik 3.0: Lösung des Datenbankproblems

Wer sein Piwik-System auf die Version 3.0 updated wird vielleicht die selbe Fehlermeldung erhalten wie ich heute:

Kritischer Fehler während der Aktualisierung:
SQLSTATE[42S02]: Base table or view not found: 1146 Table ‚databasename.piwik_plugin_setting‘ doesn’t exist.

Folgende Lösung hat bei mir geholfen:

Zuerst muss die Tabelle piwik_site_settings erstellt werden, sofern nicht schon vorhanden:

CREATE TABLE piwik_site_setting (
idsite INTEGER(10) UNSIGNED NOT NULL,
plugin_name VARCHAR(60) NOT NULL,
setting_name VARCHAR(255) NOT NULL,
setting_value LONGTEXT NOT NULL,
INDEX(idsite, plugin_name)
) ENGINE=INNODB DEFAULT CHARSET=utf8

Falls diese wie bei mir schon vorhanden ist, reicht es, ihr das Feld plugin_name  hinzuzufügen.

ALTER TABLE `piwik_site_setting` ADD `plugin_name` VARCHAR(60) NOT NULL AFTER `setting_value`;

Schon müsste das Datenbank-Update funktionieren und das System läuft wieder.

Vielen Dank an den User Weltenkreuzer, der hier im Forum  die Lösung des Problems beschrieben hat.

Wichtig: Macht davor unbedingt ein Backup eurer Datenbank!

Kategorien
Development

Einfachen Bild-Shortcode (Responsive) für WordPress erstellen

Ab und zu verwende ich Bilder aus der Mediathek in HTML-Seiten in einem WordPress-System. Bei Seiten mit speziellen Formatierungen usw. kann das durchaus mal sinnvoll sein. Nun kann man zwar mit den hauseigenen Mitteln von WordPress einen img -Tag generieren lassen, doch ist dieser wenig flexibel, da er die komplette Bild-URL beinhaltet, und enthält dieser (Stand: Feb-2017) noch kein srcset  und sites -Attribut, was für responsive Webseiten durchaus von Vorteil ist.

Die Lösung: Ein eigener Shortcode

Viel kürzer und schöner, zudem flexibler und funktionsreicher, ist ein WordPress-Shortcode/Shorttag. WordPress selber demonstriert das zB. anhand des Gallery -Shortcodes. Für einzelne Bilder bietet das System bisher aber noch keine Lösung, dafür aber für zahlreiche andere Anwendungen.

Einen img -Shortcode selber zu definieren ist allerdings nicht schwer:

Kategorien
Web

Laravel 5: Validation / Validierung über Requests

Heißt es Validation oder Validierung? Ich glaube im Kontext der Informatik eher Validation.

Über das PHP-Framework Laravel habe ich schon relativ viel geschrieben. Seit einiger Zeit ist dieses in der Version 5 erschienen. Hierbei hat sich wahrlich einiges Verändert. Eine Änderung möchte ich hier gesondert beleuchten, da sie als Grundlage für einen zukünftigen Beitrag über die Validation von Bildern.

Dieser Artikel soll daher die neuen Methoden zur Validation von Formular-Daten erklären und mit den alten Methoden vergleichen:

Kategorien
Development

#4 Aktuelle Spracheinstellung auslesen (Laravel Kurztipps)

Wer mit Spracheinstellungen in Laravel zu kämpfen hat kann diese über zwei Methoden zum debugging auslesen:

Lang::getLocale();

App::getLocale();

Dies nur als mini kleiner „Kurztipp“ ;-)

Kategorien
Development

#3 Zeitzone angeben (Laravel Kurzipps)

Laravel bietet von Haus aus einiges an Zeitfunktionen, die meisten über Carbon (Artikel) realisiert.

In der App-Konfigurationsdatei (config/app.php) kann man entsprechend ein der php-unterstützten Timezones eintragen.

	/*
	|--------------------------------------------------------------------------
	| Application Timezone
	|--------------------------------------------------------------------------
	|
	| Here you may specify the default timezone for your application, which
	| will be used by the PHP date and date-time functions. We have gone
	| ahead and set this to a sensible default for you out of the box.
	|
	*/

	'timezone' => 'Europe/Berlin',

Alternativ oder auch für’s debugging lässt sich dieser Wert über die Config-Klasse setzen oder auslesen:

// Auslesen der festgelegten Timezone
Config::get('app.timezone');

// Auslesen mit alternativem Rückgabewert, sofern keine Timezone hinterlegt ist
Config::get('app.timezone','Undefiniert');

// Setzen der Timezone
Config::set('app.timezone','UTC');
Kategorien
Development

#2: Hostname zur Konfiguration von Environments ausgeben (Laravel-Kurztipps)

In Laravel können Environments definiert werden um zB. das System lokal auf einem Server zu entwickeln oder auf einem zweiten zu testen. Einen Blogeintrag hierzu schreibe ich später noch und werde ihn dann hier verlinken. Kurz gesagt: Environments unterscheiden sich anhand des hostnamens und hierfür können in der bootstrap/start.php  diverse Environments angelegt werden die dann ein Array an Hostnames oder teilen davon bekommen.

$env = $app->detectEnvironment(array(

	'local' => array('localhost','lukes-macbook-pro*','127.0.0.1','localhost:8888','*fritz.box','*.local',),
	'production' => array('domain-des-systems.de','shortdomain.de')

));

Nur wo findet sich der Hostname? Oft reichen die Einträge *local oder *localhost und je nachdem wie weit ihr die Konfiguration eures Systems beherrscht habt ihr eventuell selber einen virtuellen Host eingerichtet oder so. Falls ihr aber keine Ahnung haben solltet helfen euch diese zwei Tipps vielleicht weiter:

Terminal. Im Mac OS X Terminal (Dienstprogramme/Terminal) erhaltet ihr euren hostnamen über den gleichnamigen Befehl:

device-name:~ luke$ hostname
your-host-hostname.domain

PHP. Alternativ könnt ihr im PHP-Code über die Funktion gethostname  den Hostnamen ausgeben lassen:

die( gethostname() );

Es gibt noch weitere Möglichkeiten eure Environments zu erkennen, diese sind in der Dokumentation beschrieben. Diese zwei kleinen Codezeilen können aber zuweilen ganz nützlich sein.

 

Kategorien
Development

#1 PHP-Code in Laravel-Blades ausführen (Laravel-Kurztipps)

Heute nun wie angekündigt der erste Kurztipp: PHP-Code in Blades (Twig als Template-System) einbinden. Im ersten Moment mag das komisch erscheinen. PHP-Code lässt sich natürlich durch die eigene Syntax @if @include @foreach @for usw.  schon immer in Templates einbinden. In vielen Fällen reichen die vorhandenen Funktionen aus, doch ab und zu bedarf es doch eigener Variablen usw. Andere Template-Systeme verwenden überall generischen PHP-Code und lassen daher hier schon von Haus aus sämtlichen Code zu.

Gehört Logik-Code ins View/Blade/Template?

Ist es sinnvoll/richtig in einem Template Variablen zu definieren und Logik zu platzieren? Grundsätzlich natürlich nicht. Controller und zT. Models sind der richtige Ort um sämtliche Logik zu platzieren. Im View bedarf es manchmal dennoch Variablen, die aber hier nur der Darstellung dienen, zB. wenn man abwechselnde Zeilenfarben o.ä. will. Meistens könnte man auch über diverse if/else-Abfragen zum selben Ergebnis kommen, aber dabei kann sich der Code unglaublich in die Länge ziehen. Manchmal sind hier ein paar Arbeits-Variablen tatsächlich Gold wert.

Eine Lösung für Laravel 4

Es gibt nun verschiedene Wege dieses Problem zu lösen, die meiner Meinung nach „sauberste“ Lösung (natürlich nicht wirklich sauber aber das sauberste was ich gefunden habe) ist es, denn Echo-Tag zu missbrauchen (Quelle):

{{-- */$i=0;/* --}}

Was passiert hier? Wir definieren hier ein Kommentar, normalerweise: {{– Ein Kommentar –}} , welches dann von der Engine zu <?php /* Ein Kommentar */ ?>  umgewandelt wird.  Als Kommentartext schließen wir jetzt allerdings als erstes den Kommentar */ , notieren irgendeine PHP-Anweisung $i = 0 und öffnen wieder ein Kommentar /*  welches dann von Laravel wieder geschlossen wird. Der resultierende Code ist dann:

// Laravel-Blade-Code:
{{-- */$i=0;/* --}}

// wird gerendert als
<?php /* */$i=0;/* */ ?>

Über diesen Code ist es also möglich sowohl Variablenzuweisungen zu machen, als auch zB einfache Logik-Anfragen zu starten usw.