How to fix „SSL certificate problem: unable to get local issuer certificate“ on Windows

Du weißt bestimmt, dass ich auf Windows entwickle. Im Gegensatz zu vielen, die auf Macs oder Linux schwören, bleibe ich hartnäckig auf Windows – auch wenn dies bedeutet, dass ich Probleme sehe, die für andere unsichtbar sind. Ich sehe da allerdings die Chance, mehr zu lernen.

Eins dieser „mehr lernen“ Erfahrungen hatte ich heute. Meine phpunit tests laufen automatisch bei github und travis durch, keine Fehlermeldungen, alles gut.
Bis ich dann eben die Tests auf meiner Konsole ausführen wollte:

Anstelle des Erwarteten Fehlers SSL: no alternative certificate subject name matches target host name 'domain.xyz' erwartet mich:

SSL certificate problem: unable to get local issuer certificate

Wie seltsam … jetzt starte ich phpunit mal in meiner WSL Umgebung und siehe da, die Tests laufen alle durch. Das wieder so ein „Typisch Windows“ Problem.

Die Ursache liegt darin, dass du bei Windows-PHP-mit-Curl keine Zertifikatsinformationen per default eingestellt hast … das kann jetzt gut und schlecht sein, auf jeden Fall führt das zu dem Fehler.

Es gibt dazu allerdings auch eine Lösung und die funktioniert recht einfach:

1. Downloade gültige Zertifikatsinformationen von https://curl.se/ca/cacert.pem
2. Benenne die Datei um in curl-ca-bundle.crt
3. Kopiere die Datei, wo du sie gut verwalten kannst, bei mir liegt die in D:/www
4. Editiere deine php.ini. Du musst folgende Einträge ändern:
4.1. curl.cainfo = D:/www/curl-ca-bundle.crt
4.2. openssl.cafile=D:/www/curl-ca-bundle.crt
5. Speichern und Apache neu starten

Und nun laufen auch meine Tests durch 💪

 

Laravel – „production.ERROR: No application encryption key has been specified.“

Puuuh, was habe ich an diesem Fehler gesessen und wie einfach doch die Lösung war.

Aber von Anfang an: Beim Zusammenspiel meiner API mit einer Anwendung, die diese API aufruft lief zuerst alles ganz gut. Allerdings: Sobald ich diese zweite Anwendung testen wollte, erschien sporadisch dieser Fehler. Sporadisch im Sinne von: Er trat auf, und das jedesmal, allerdings immer an völlig zufälligen Stellen.

Lange Geschichte kurz: Bei zu vielen Anfragen konnte die .env nicht mehr korrekt geladen werden. Meine Vermutung ist, dass das Dateisystem von Windows einfach zu lahm ist, weil es bei einem Kollegen auf einem Mac funktioniert und er noch nie diese Meldung zu Gesicht bekam.

Der Fix dazu ist relativ einfach: Du musst die Config cachen, dazu einfach dieses Kommando eingeben:

php artisan config:cache

Und dann hat es wunderbar funktioniert mit dem Zusammenspiel.

SourceTree startet nicht mehr (Fehler CLR20r3)

Mein SourceTree startet nicht mehr.
Das so etwas passiert, ist nicht schön, besonders, wenn man dieses tolle Tool beruflich benötigt. Es macht die Arbeit einfacher, gerade dann, wenn man viele Repos verwaltet und einfach auf dem laufenen bleiben möchte.

Schaut man in die Ereignisanzeige, dann offenbart sich der Fehler CLR20r3. Dieser Fehler liegt tiefer und wenn man ein wenig sucht, dann findet man die Lösung dazu:

  1. Deinstallieren von SourceTree
  2. Nun nicht direkt neu installieren, sondern in das VZ „%localappdata%\Atlassian\“ gehen und dort alle Unterverzeichnisse mit „SourceTree“ löschen!
  3. Nun SourceTree neu installieren.

Nun muss man leider das Programm nochmals neu konfigurieren, aber immerhin läuft es nun wieder 😀

 

Im jQuery tablesorter nach deutschem Datum sortieren

Den jQuery tablesorter kennen bestimmt viele, ich benutze diesen sehr häufig und gern. Allerdings kann das Ding von Haus aus nicht nach dem deutschem Datumsformat (dd.mm.yyyy [hh:mm]) richtig sortieren.

Hier dazu mein „Plugin“, dass in die entsprechende JavaScript Datei gehört:

$.tablesorter.addParser({
 id: 'germanDate',
 is: function(s) {
 return false;
 },
 format: function(s) {
 var dateMatches = s.match(/([0-9]{1,2})\.([0-9]{1,2})\.([0-9]{2,4}) ([0-9]{1,2}):([0-9]{1,2})/i);
 return dateMatches[3]+dateMatches[2]+dateMatches[1]+dateMatches[4]+dateMatches[5];
 },
 // set type, either numeric or text
 type: 'numeric'
 });

$('#tblApps').tablesorter({
 sortList: [[1,0]],
 headers: {
 0: { sorter: false },
 2: { sorter: 'germanDate' },
 3: { sorter: false }
 }
 });

Damit kann mein Frontend nun auch innerhalb von Tabellen nach Terminen im deutschen Datum richtig sortieren.

Verzeichnisse ignorieren bei pdepend und phpdox

Im Zuge der „continuous integration“ setzt du bestimmt auch auf Tools wie pdepend oder phpdox. Allerdings würde ich gern nicht alle Verzeichnisse durchgehen, sondern ein paar davon exkludieren (Vendor-Zeug wie smarty oder das Zend-Framework).

Wer bei pdepend Verzeichnisse ignorieren will, der sollte es nicht wie in der Doku angegeben mit „–exclude“ versuchen, denn diese Option funktioniert schlicht einfach nicht.

Die Lösung ist bei pdepend der Parameter „–ignore=…“ dem man einfach alle Verzeichnisse kommasepariert übergibt, z.B. aus meinem ant-Script:

<arg value="--ignore=${basedir}/smarty,${basedir}/Zend" />

Bei phpdox kann man Verzeichnisse ausnehmen, wenn man diese auf die exclude-Liste des collector-Blocks setzt, den ihr in der entsprechenden phpdox.xml findet. Dieser Block kann dann z.B. so aussehen:

<collector publiconly="false" backend="parser">
<!-- @publiconly - Flag to disable/enable processing of non public methods and members -->
<!-- @backend - The collector backend to use, currently only shipping with 'parser' -->

<!-- <include / exclude filter for filelist generator, mask must follow fnmatch() requirements -->
<include mask="*.php" />
<exclude mask="**Zend**"/>
<exclude mask="**smarty**"/>

<!-- How to handle inheritance -->
<inheritance resolve="true">
<!-- @resolve - Flag to enable/disable resolving of inheritance -->

<!-- You can define multiple (external) dependencies to be included -->
<!-- <dependency path="" -->
<!-- @path - path to a directory containing an index.xml for a dependency project -->
</inheritance>

</collector>

Der „Trick“ dabei sind die beiden * vor und nach dem Namen.
Zumindest in meinem Jenkins läuft nun alles wie es soll 😀

Update/Upgrade von phpStorm 7 auf phpStorm 8 inkl. aller Einstellungen

Der Trick ist, die Einstellungen alle VOR dem Upgrade in phpStorm7 zu exportieren und dann in phpStorm8 wieder zu importieren.

  1. phpStorm7 öffnen und auf den Startschirm gehen (ggf. Projekt schließen)
    Auf „Configure“, dort dann „Export Settings“ wählen
    image2014-9-17 11-19-39
  2. Alle Checkboxen an, Speicherort wählen, den Namen „settings.jar“ aber unbedingt behalten:
    image2014-9-17 11-20-28
  3. phpStorm7 schließen, phpStorm8 öffnen, „Configure“->“Import Settings“
    Zu importierende Sachen wählen (alles):
    image2014-9-17 11-21-32
  4. phpStorm8 neu starten, ggf. Plugins updaten, fertig.
  5. phpStorm7 kann nun gefahrlos deinstalliert werden.

phpStorm: „File size exceeds configured limit (2560000), code insight features not available“

Wer diese Meldung in phpStorm bekommt, der versucht ganz offensichtlich, eine ziemlich große Datei zu öffnen, was phpStorm dann mit dieser Meldung quittiert. Und das, obwohl du eigentlich genug RAM hättest:

File size exceeds configured limit (2560000), code insight features not available

File size exceeds configured limit (2560000), code insight features not available

Das Dumme an der Sache ist nur, dass es über die „Settings“ nicht zu ändern ist; da kannst du lange suchen.

Die Lösung: Öffne einen Editor als Administrator und gehe in dein phpStorm/bin Verzeichnis. Dort findest du eine „PhpStorm.exe.vmoptions“. Diese öffnest du und gibt dort eine neue Zeile ein (bzw.änderst den Wert, falls es diese Zeile schon gibt):

-Didea.max.intellisense.filesize=999999

phpStorm startest du nun neu und fort ist die Meldung.

May the code be with you  😉