ANEXIA Blog

CodeIgniter 4 – Was ändert sich?

Manuel Wutte

Wie bereits im vorigen CodeIgniter-Beitrag angesprochen, wurde das CodeIgniter-Framework von EllisLab (welche das Framework ursprünglich entwickelt haben), an das BCIT (British Columbia Institute of Technology) übergeben.

Bereits wenige Wochen nach dieser Übernahme kam eine neue, überarbeitete Version, nämlich Version 3.x des Frameworks, heraus.
Obwohl damit zwar eine relativ solide Basis geschaffen werden konnte, hinkte das Framework seiner Konkurrenz immer noch teilweise stark hinterher.
So hatte CodeIgniter im Vergleich zu Laravel verhältnismäßig immer weniger Chancen, um bei Entwicklern zu punkten, da der Funktionsumfang und die Art, wie damit programmiert werden kann, bei der Konkurrenz immer eine Spur besser war.

Doch mit Version 4 von CodeIgniter könnte sich das Blatt nun doch wenden.

 

Der große Umstieg

Im offiziellen CodeIgniter-Forum wurde am 26.06.2016 bereits verkündet, dass der erste Meilenstein von CI4 nun erreicht wurde. Gleichzeitig wurde das Repository auch auf GitHub transferiert: https://github.com/bcit-ci/CodeIgniter4

Eine Dokumentation ist hier zu finden. Zu beachten ist nur, dass auch diese aktuell noch nicht fertig, und daher teilweise noch ziemlich lückenhaft ist.

Die wohl auffälligste und offensichtlichste Änderung zu den Vorgänger-Versionen ist die Tatsache, dass es nun ein „public“-Verzeichnis gibt.

Wie auch bei anderen Frameworks der Fall, hat dies einen essentiellen und sicherheitsbedingten Hintergrund: die Trennung von Applikation/Framework und öffentlichen Ressourcen (wie beispielsweise Javascript, CSS oder Bilder).
Dadurch, dass das Framework nun nicht mehr so freizügig preisgegeben wird, fällt es potentiellen Angreifern wesentlich schwerer, Sicherheitslücken (o.ä.) zu finden bzw. gezielt auszunutzen.

Das Einzige, was dafür serverseitig notwendig ist, ist eine kleine Modifikation der Vhost-Konfiguration (sofern vorhanden bzw. möglich). Der Document-Root wird nun nicht mehr ins Hauptverzeichnis von CodeIgniter gelegt, sondern in den Public-Ordner.

Eine solche Vhost-Konfiguration könnte nun beispielsweise so aussehen:

<VirtualHost *:80>
	ServerName codeigniter4.local
	DocumentRoot /var/www/vhosts/codeigniter4.local/public/
</VirtualHost>

 

Die wesentlichsten Änderungen

Ganz offensichtlich ist hier mal die relativ hoch angesetzte Mindestanforderung an den PHP-Interpreter. Für die Installation und den Betrieb wird hier PHP > 7.0 gefordert.

Ein Blick auf die Ordnerstruktur des Frameworks erinnert auf den ersten Blick ziemlich stark an Zend 1 oder Laravel.

CI4 stellt nun (wie beispielsweise bereits von Laravel bekannt) für die Datenbank Migrations und Seeds bereit. Dadurch fallen Deployments und Änderungen nun wesentlich leichter, da Datenbank-Anpassungen nun nicht mehr manuell, sondern automatisiert durchgeführt werden. Optionale Seeders dienen dann in weiterer Folge der Befüllung der Datenbank mit Dummy-Daten.

Für die Konfiguration der Environments (also der Umgebung, in welcher das Framework läuft, und die damit verbundenen Konfigurationen) können nun via DotENV ( .env) konfiguriert werden.
Als Vergleich: CI2 bot nur die Möglichkeit für eine einzige Umgebung, CI3 dann für drei (Development, Testing, Production).

 

Installation

CodeIgniter setzt nun nach dessen Rewrite mit Version 4 auf das bereits vielen vertraute PSR-4 Autoloading in Kombination mit Composer.

Für alle, die nicht wissen, was Composer ist: hierbei handelt es sich um ein kommandozeilenbasiertes Paketverwaltungssystem für PHP, durch welches stets die aktuellsten Vendor-Pakete installiert und deren Versionen zentral gemanaged und upgedated werden können.

In der aktuellen Dev-Version von CI4 nutzt das Framework überwiegend Pakete vom Zend Framework und vom Symfony Framework.

Nachdem alle Dateien des Github-Repositories in das entsprechende Verzeichnis am Server kopiert wurden, muss als erstes Composer initialisiert werden.
Dazu wird ein neues Terminal (bzw. unter Windows die Eingabeaufforderung/CMD) geöffnet und in das Hauptverzeichnis von CodeIgniter navigiert.

Sofern Composer am jeweiligen System installiert ist, kann nun via composer setup  Composer für das neue Projekt initialisiert werden.

Wenn man nun im Browser die URL des neuen Vhosts aufruft, wird einem auch schon der Welcome-Screen angezeigt.

Wer sich den Public-Ordner mal näher ansieht, wird auch gleich feststellen, dass sich dort bereits eine .htaccess mit einer Basis-Konfiguration befindet.

Des Weiteren gibt es dort auch eine robots.txt, welche derzeit alle Crawling-Bots fernhält. Bei der robots.txt handelt es sich um eine Textdatei, welche Informationen für die Crawler der Suchmaschinen enthält – also welche Bereiche indiziert werden dürfen, und welche nicht.

 

Konfiguration

Die Basiskonfiguration welche bis CI3 noch unter /application/config.php zu finden war, befindet sich nun unter /application/Config/App.php (Groß- und Kleinschreibung in den Pfaden und Dateinamen beachten!)

Die Konfiguration ist nun auch kein einfaches Array mehr, sondern eine eigenständige Klasse (mit Vererbung und eigenen Namespaces) geworden:

<?php namespace Config;

use CodeIgniter\Config\BaseConfig;

class App extends BaseConfig
{

	/*
	|--------------------------------------------------------------------------
	| Base Site URL
	|--------------------------------------------------------------------------
	|
	| URL to your CodeIgniter root. Typically this will be your base URL,
	| WITH a trailing slash:
	|
	|	http://example.com/
	|
	| If this is not set then CodeIgniter will try guess the protocol, domain
	| and path to your installation. However, you should always configure this
	| explicitly and never rely on auto-guessing, especially in production
	| environments.
	|
	*/
	public $baseURL = '';

	/*
	|--------------------------------------------------------------------------
	| Index File
	|--------------------------------------------------------------------------
	|
	| Typically this will be your index.php file, unless you've renamed it to
	| something else. If you are using mod_rewrite to remove the page set this
	| variable so that it is blank.
	|
	*/
	public $indexPage = 'index.php';
	...

Für einen reibungslosen Betrieb von CI4 ist notwendig, dass die Base-URL hier einmalig konfiguriert wird. Dies wurde übrigens bewusst aus Sicherheitsgründen so gewählt.

public $baseURL = ‚http://codeigniter4.local/‘;

Die optionale Konfiguration der Datenbank wird in der Database.php vorgenommen. Zu beachten ist hier, dass es jeweils zwei Konfigurationen gibt: eine für die Applikation selbst und eine zweite fürs Testing (z.B. PHPUnit).

Diese Parameter lassen sich auch via DotEnv (.env) konfigurieren. Hierfür können solche Parameter auch in der .env-Datei im Rootverzeichnis definiert werden.

database.default.username = 'root';
database.default.password = 'passw0rd!';
database.default.database = 'codeigniter4';

 

Coding-Beispiele folgen, sobald die Version 4 des Frameworks einigermaßen stabil geworden ist. Momentan gibt es da noch einige Bugs, durch welche u.a. die Migrations noch nicht richtig funktionieren.

 

 

Roadmap

Hier nun eine kurze Aufstellung der bereits umgesetzten und noch geplanten Funktionen. Diese sind auch dem aktuellen User-Guide zu entnehmen.

 

Meilenstein 1

Im ersten Meilenstein konnten diese folgenden Funktionen implementiert bzw. überarbeitet werden:

 

Meilenstein 2

Diese Funktionen befinden sich derzeit in Beabeitung (Stand: Juli/August 2016):

Es ist durchaus möglich, dass es nach Abschluss dieses Meilensteins bereits eine erste Stable-Version oder zumindest ein Release-Candidate (RC) geben wird.

Die geplante Fertigstellung dieses Meilensteins ist im Dezember 2016.

 

Meilenstein 3

Dieser Meilenstein stellt nach aktuellem Stand nur Erweiterungen und neue Funktionen bereit, welche (theoretisch) auch in Form von Updates nachgereicht werden könnten.

 

 

Fazit

Ein Blick auf den aktuellen Entwicklungsstand von CodeIgniter 4 macht soweit schon mal einen mehr als positiven Eindruck. Da diese Version des Frameworks bereits PHP 7 als Grundvoraussetzung erfordert, ist es auf dem neuesten Stand der Technik. Allerdings könnte es zum jetzigen Zeitpunkt bei vielen Providern und Shared-Hosting-Anbietern noch problematisch sein, da noch nicht alle auf diesen Zug aufgesprungen sind, und daher in vielen Fällen noch kein PHP 7 anbieten können.
Meiner Meinung nach hat das BCIT mit deren CI4 aus aktueller Sicht schon mal gute Chancen sich adäquat etablieren zu können, da jetzt auch nahezu alle Wehwehchen der Vorgänger-Versionen  beseitigt und die Software von Grund auf neu geschrieben wurde.

Da sich das Framework aktuell noch in der Entwicklungsphase befindet, sollte es noch keinefalls in produktiven Umgebungen eingesetzt werden!

Zuletzt noch gute Nachrichten an alle Anhängerinnen und Anhänger der 3.x-Version: das BCIT plant bereits ein neues Update: v3.1.0 – dieses wird gleichzeitig aber auch das letzte aus der 3er-Reihe werden.

Bei bestehenden 3.x-Projekten sollte dann voraussichlich ein Upgrade auf die Version 4 ebenfalls möglich sein (jedoch wurde dies seitens des BCIT noch nicht offiziell bestätigt).

Man darf also gespannt sein, was da noch kommt!

Die mobile Version verlassen