# CodeIgniter – das Leichtgewicht unter den PHP-Frameworks CodeIgniter gilt als [**Web-Application-Framework**](https://www.ionos.de/digitalguide/websites/web-entwicklung/webframeworks-ein-ueberblick/) für Entwickler, die Geschwindigkeit einem üppigen Funktionsumfang vorziehen. Zentrales Design-Ziel des quelloffenen PHP-Frameworks ist es der offiziellen Projektseite zufolge, ein Maximum an Performance und Flexibilität im kleinstmöglichen Programmgerüst unterzubringen. ## Was ist CodeIgniter? Bei CodeIgniter handelt es sich um ein **in** [**PHP**](https://www.ionos.de/digitalguide/websites/webseiten-erstellen/php-lernen-leicht-gemacht-das-grosse-einsteiger-tutorial/) **geschriebenes Webframework**, das sich damit rühmt, die Entwicklung von Webanwendungen durch ein kompaktes Software-Design schneller und effizienter zu gestalten. Schöpfer von CodeIgniter ist die US-amerikanische Software-Firma **EllisLab**, die im Februar 2006 die erste öffentliche Version herausgab. Am 9. Juli 2013 kündigte EllisLab an, die nötigen Ressourcen für eine Weiterentwicklung der Software allein nicht mehr aufbringen zu können. Ein Jahr später erfolgte die Übernahme des Projekts durch das **British Columbia Institute of Technology (BCIT)**. Der Quellcode des Frameworks steht unter der [**MIT-Lizenz**](http://www.codeigniter.com/user_guide/license.html "Informationen zur MIT-Lizenz auf codeigniter.com") und kann über den Onlinedienst [**GitHub**](https://github.com/bcit-ci/CodeIgniter "Quellcode von CodeIgniter via GitHub") bezogen werden. Als letzte stabile Version wird CodeIgniter 3.1.2 seit Oktober 2016 [auf der offiziellen Projektseite](https://www.codeigniter.com/ "Download-Paket des Frameworks auf codeigniter.com") kostenlos zum Download angeboten. ## Aufbau und Struktur des Frameworks Das Performance-orientierte Design von CodeIgniter zeigt sich im schlanken Aufbau des PHP-Frameworks. Dieses orientiert sich am Software-Architekturmuster **Model-View-Controller (MVC)**. Das Grundprinzip hinter MVC ist die strikte **Trennung von Programmcode und Präsentation**. Diese wird durch einen modularen Software-Aufbau und die Auslagereng von PHP-Code realisiert. Man unterscheidet drei zentrale Komponenten: das Datenmodell (Model), die Präsentation (View) und die Steuerung (Controller). - Das **Datenmodell (Model)** repräsentiert die Datenstruktur einer auf Basis von CodeIgniter entwickelten Webanwendung. Dazu werden im Quellcode sogenannte Modellklassen („model classes“) definiert. Diese beinhalten spezielle Funktionen, mit denen Informationen aus einer Datenbank abgerufen, in dieser hinterlegt oder aktualisiert werden können. - Die **Präsentation (View)** ist der Teil einer Anwendung, der dem Endnutzer präsentiert wird. In der Regel handelt es sich dabei um ein HTML-Dokument, in das Inhalte via PHP dynamisch eingebunden werden. Ein View ist somit eine Art Template. CodeIgniter bietet zudem die Möglichkeit, Webpage-Fragmente wie Header und [Footer](https://www.ionos.de/digitalguide/websites/webseiten-erstellen/was-ist-ein-footer/) oder RSS-Seiten als View zu definieren. In der Regel nutzen Webanwendungen mehrere Views, die Ihre Inhalte über dasselbe Datenmodell beziehen. So lassen sich unterschiedliche Programm-Features in verschiedenen Ansichten präsentieren. - Die **Steuerung** **(Controller)** dient als vermittelnde Instanz zwischen Model, View und jeder anderen Ressource, die benötigt wird, um eine HTTP-Anfrage zu bearbeiten oder eine Webpage dynamisch zu erzeugen. Diese Komponente nimmt eingehende Anfragen entgegen, validiert den Input, sucht den gewünschten View heraus und reicht Inhalte, die das Datenmodell aus einer Datenbank geladen hat, an diesen weiter. Folgende Grafik zeigt das Zusammenspiel der MVC-Komponenten in einer schematischen Darstellung: [![Bild: Schematische Darstellung des MVC-Architekturmusters](https://www.ionos.de/digitalguide/fileadmin/_processed_/0/6/csm_DE-codeigniter-schematische_bceab56cd2.webp "Schematische Darstellung des MVC-Architekturmusters")](https://www.ionos.de/digitalguide/fileadmin/DigitalGuide/Screenshots/DE-codeigniter-schematische.png) Interaktion der MCV-Komponenten Model, View und Controller Die MVC-Struktur ermöglicht ein **flexibles Software-Design**, bei dem einzelne Programm-Module mit minimalem Aufwand ausgetauscht, überarbeitet und wiederverwendet werden können. Änderungen an einer Komponente haben in der Regel keine Auswirkung auf den Quellcode anderer Komponenten (vorausgesetzt es werden keine Änderungen an den Schnittstellen vorgenommen). Die strikte Trennung zwischen Programmlogik und Präsentation sorgt für einen übersichtlichen, **gut strukturierten Programmcode**. Webapplikationen auf MVC-Basis gelten als **wartungsfreundlich**. Im Fehlerfall beschränkt sich die Suche nach der Fehlerquelle meist auf eine der Komponenten. Darüber hinaus bietet das MVC-Architekturmuster die Möglichkeit, Logik und Layout einer Webanwendung separat zu entwickelt. Arbeiten Back-End- und Front-End-Entwickler dabei parallel, lassen sich Anwendungen deutlich schneller fertigstellen. CodeIgniter macht sich MVC zunutze, bindet Anwender jedoch nicht komplett an dieses Architekturmuster. Während es sich bei den Komponenten Controller und View um obligatorische Bestandteile handelt, sind Verbindungen zu Datenbanken via Model optional. Darüber hinaus lässt sich eine Anwendung auf Basis von CodeIgniter auch mit einer **Hierarchical-MVC-Architektur (HMVC)** realisieren, die das klassische MVC-Muster um eine hierarchische Logik erweitert. ## Der Anwendungsfluss des PHP-Frameworks CodeIgniter basiert auf einem **URL-Konzept**. Das bedeutet, der Controller als zentrale Steuereinheit zwischen View und Model wird durch die Eingabe einer URL in die Suchleiste des Webbrowsers angesprochen. Entwickler erstellen dazu sogenannte **Controller-Klassen** (classes). Dabei handelt es sich um PHP-Dateien, die diverse **Funktionen** beinhalten, um Bibliotheken (libraries), Erweiterungen (plugins) oder Helfer-Klassen (helper) zu laden, Verbindungen zu Datenbanken herzustellen, ein Datenmodell einzubinden oder einen bestimmten View herauszusuchen. Der **Anwendungsfluss von CodeIgniter** basiert dabei auf folgendem URL-Grundschema: *example.com/class/function/parameter* Auf die **Domain** (*example.com*) folgt eine **Controller-Klasse**, die angesprochen werden soll, sowie eine bestimmte **Controller-Funktion**. Den Abschluss bilden optionale **Parameter**. Diese dienen dazu, dem ausgewählten Controller IDs oder Variablen zu übergeben. In der Praxis könnte eine CodeIgniter-URL wie folgt aussehen: *example.com/news/article/511* Eine solche URL spricht den Controller *news* auf der Domain *example.com* an und veranlasst diesen, die Funktion *article* auszuführen (beispielsweise, um einen gleichnamigen View für die Artikelansicht zu laden). Welche Inhalte über das Datenmodell aus der Datenbank abgerufen werden sollen, geben optionale Parameter an, die dem Controller mit der URL übergeben werden – in diesem Beispiel ein Artikel mit der ID 511. In der Ausgangskonfiguration führt CodeIgniter die *index.php* in jeder Anwendungs-URL auf: *example.com/index.php/news/article/511* Diese PHP-Datei beinhaltet Informationen darüber, wo sich die Core-Dateien des Frameworks sowie eingebundene Bibliotheken, Erweiterungen oder Helfer-Klassen befinden und in welchem Verzeichnis die Applikationsdateien liegen. Die *index.php* dient somit der **Initialisierung sämtlicher Basisressourcen**. Läuft CodeIgniter auf einem **Apache HTTP Server**, lässt sich die *index.php* via *mod\_rewrite* aus den Anwendungs-URLs entfernen, um Endnutzern und Suchmaschinen-Crawlern „saubere“ Webadressen zur Verfügung zu stellen. Entwickler fügen dazu folgenden Codeblock in die **.htaccess-Datei** des Webservers ein: ```none RewriteEngine On RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteRule ^(.*)$ index.php/$1 [L] ``` Die Grundstruktur des PHP-Frameworks stützt sich in erster Linie auf Controller-Klassen, Modell-Klassen und View-Templates. ### Controller-Klassen CodeIgniter bietet Entwicklern die Möglichkeit, individuelle Controller als **benutzerdefinierte Klassen** zu programmieren. Dazu legen Webentwickler für jeden Controller eine separate PHP-Datei im Verzeichnis *application/controllers/* an. Controller enthalten die Programmlogik einer mit CodeIgniter entwickelten Webanwendung und werden als Unterklassen der *CI\_Controller class* erstellt. Im Quellcode realisieren Programmierer dies mithilfe des Schlüsselworts *extends*. ```none class News extends CI_Controller { } ``` Als untergeordnete Klasse erbt *News* von der Elternklasse *CI\_Controller* sämtliche Funktionen der Sichtbarkeit *public* und *protected*. --- ### Tipp Die Schlüsselwörter *public*, *protected* oder *private* dienen in PHP dazu, die Sichtbarkeit einer Eigenschaft oder Funktion zu definieren. Wird ein Element als *public* deklariert, haben alle Klassen einer Software Zugriff auf das Element. Soll dieser Zugriff auf Elternklassen und abgeleitete Klassen beschränkt werden, verwenden Programmierer das Schlüsselwort *protected*. Ein Element, das als *private* deklariert wurde, steht lediglich der Klasse zur Verfügung, die das Element definiert. --- Jede benutzerdefinierte Controller-Klasse muss zudem eine **Konstruktor-Funktion** enthalten, mit der sich Bibliotheken, ein Datenmodell, Datenbanken oder Helfer-Klassen einbinden lassen. Ab PHP5 wird *\_\_construct()* als standardisierte Konstruktor-Funktion verwendet. ```none load->helper('url'); //lädt eine Helfer-Klasse für die Arbeit mit URLs $this->load->helper('file'); //lädt eine Helfer-Klasse für die Arbeit mit Dateien $this->load->database(); //lädt eine Datenbank $this->load->model('News_model'); //lädt ein Model mit dem Namen „News_model“ } ?> ``` Das Beispiel zeigt die Klasse *News* als Unterklasse von *CI\_Controller*. Die Konstruktor-Funktion *\_\_construct()* bindet zwei Helfer-Klassen, eine Datenbank und das Datenmodell *News\_model* ein. Die einzelnen Codezeilen sind im Quelltext auskommentiert. --- ### Hinweis Alle Controller-Klassen, die in PHP für CodeIgniter definiert werden, müssen mit einem Großbuchstaben beginnen (*News* statt *news*). In der URL schreibt man sie hingegen klein. --- ### Controller-Funktionen Steht das Grundgerüst des benutzerdefinierten Controllers, folgt die eigentliche **Programmlogik** in Form von **Controller-Funktionen**, mit denen sich Views abrufen oder Interaktionen mit einem eingebundenen Datenmodell realisieren lassen. Damit der Controller einen View laden kann, muss das zugrundeliegende HTML-Dokument als PHP-Datei im Verzeichnis *application/views/* abgelegt werden. Ein einfacher View für eine Artikelansicht könnte beispielsweise so aussehen: ```none <?php echo $title; ?>

``` --- ### Tipp HTML-Dokumente, die PHP-Code enthalten, müssen als PHP-Dateien gespeichert werden (*.php*). Nur so lässt sich sicherstellen, dass der PHP-Interpreter des Webservers Skripts ausführt und den PHP-Code nicht lediglich als Text ausgibt. --- Um einen View in den Controller zu laden, wird eine benutzerdefinierte Funktion benötigt. Im nachfolgenden Codebeispiel kommt die Funktion *article()* zum Einsatz, um den View *article.php* zu laden. ```none public function article() { if (!file_exists(application/views/article.php)) { show_404(); } $this->load->view('article'); } ``` Der Programmcode liest sich wie folgt: Zunächst prüft CodeIgniter, ob das Verzeichnis *application/views/* eine Datei mit dem Namen *article.php* enthält. Diese Abfrage wird durch das **Sprachkonstrukt *if*** und die verneinte (*!*) **Bedingung *file exists()*** realisiert. Trifft die Bedingung zu und es findet sich keine gleichnamige Datei im entsprechenden Verzeichnis, gibt *if* den Wert **TRUE** zurück, und CodeIgniter führt die unter *if* aufgeführte **Funktion *show\_404()*** aus. Ein Anwender bekäme in diesem Fall den Hinweis, dass die angefragte Datei nicht existiert. Ist die *if*-Bedingung jedoch nicht erfüllt und wird *!file\_exists* als **FALSE** evaluiert, führt CodeIgniter die **Funktion *$this->load->view('article')*** aus*.* Diese dient dazu, die entsprechende Datei als View in die Anwendung zu laden. Sofern es sich um das **Format PHP** handelt, kann die gewünschte Datei in der Funktion *view()* ohne Suffix aufgeführt werden. Sollen andere Formate geladen werden, ist das jeweilige Dateisuffix obligatorisch. CodeIgniter kommt in der Regel im Rahmen dynamischer Webanwendungen zum Einsatz. Diese spielen Anwendern statt statischer HTML-Seiten dynamisch erzeugte Webpages aus. Dies lässt sich realisieren, indem man den View mit Daten füllt, die den **Parametern** entsprechen, die CodeIgniter mit der URL übergeben bekommt. *example.com/news/article/511* Bisher wurde mit der Funktion *$this->load->view('article')* lediglich eine **Ansicht** für die Artikeldarstellung geladen. Nun gilt es, speziell die Inhalte einzubinden, die mit dem Parameter 511 verknüpft sind. Wir gehen davon aus, dass sich dabei um eine ID handelt, die mithilfe eines **Datenbank-Management-Systems** mit einem bestimmten Newsartikel verbunden ist. Um diesen aus der Datenbank ins Programm zu laden, muss das obenstehende Beispiel so ergänzt werden, dass das im Konstruktor eingebundene **Datenmodell** angesprochen wird. ```none public function article($id) { if (!file_exists(application/views/article.php)) { show_404(); } $data = $this->News_model->get_data($id); $this->load->view('article', $data);} ``` Das übergebene Funktionsargument (hier unter dem Variablennamen *$id*) entspricht dem ID-Teil der URL – beispielsweise 511. Die noch zu schreibende Modell-Funktion *get\_data()* dient dazu, den mit der ID verknüpften Artikelinhalt aus der Datenbank zu laden. Die *view()*-Methode ruft den *article*-View auf und übergibt ihm diese Daten in Form eines assoziativen Arrays (*$data*). Das Datenmodell *News\_model* übergibt also die ausgelesenen Daten dem Controller *News*, der diese an den View weiterreicht. Alle mit dem Datenabruf verbundenen Operationen werden an das eingebundene Datenmodell ausgelagert. ### Modell-Klassen Datenmodelle kommen bei CodeIgniter zum Einsatz, um Funktionen bereitzustellen, mit denen sich bestimmte Datenbank-Operationen durchführen lassen. Genau wie Controller-Klassen lassen sich auch Modell-Klassen mit dem PHP-Framework benutzerdefiniert programmieren. Um eine Modell-Klasse anzulegen, wird zunächst ein Klassenname vergeben – in diesem Fall *News\_model*. Analog zu Controller-Klassen sind alle **benutzerdefinierten Modell-Klassen** Unterklassen der **Elternklasse *CI\_Model***. Die Vererbung wird durch das Schlüsselwort *extends* realisiert. Auch Modell-Klassen binden Datenbanken und andere Ressourcen über die Konstruktor-Funktion ein. ```none class News_model extends CI_Model { public function __construct() { parent::__construct(); $this->load->database(); } } ``` Auf diese Grundstruktur folgen sogenannte **Modell-Funktionen**, in denen Entwickler alle Datenbank-Operationen definieren, die dem Controller über das jeweilige Datenmodell zur Verfügung stehen sollen. ### Modell-Funktionen Modell-Klassen ermöglichen es Entwicklern, individuelle Funktionen für Datenbank-Operationen zu definieren. In einem vorhergehenden Beispiel haben wir in der Controller-Klasse *News* die benutzerdefinierte Funktion *get\_data()* verwendet, um Artikelinhalte aus der Datenbank in den View zu laden. Im Modell definieren wir nun, welche **Datenbank-Operationen** sich hinter dieser Funktion verbergen. ```none class News_model extends CI_Model { public function __construct() { parent::__construct(); $this->load->database(); } public function get_data($id) { $this->db->select('content'); $this->db->from('example_table'); $this->db->where('id', $id); $query = $this->db->get(); return $query->result(); } ``` In der Modellklasse *News\_model* wird die oben benutzte Funktion *get\_data()* als Datenbank-Operation definiert, die die unter *select()* angegebene Spalte des Datensatzes mit der übergebenen ID-Nummer (*$id*) aus der unter *from()* angegebenen Datenbanktabelle via *get()* abfragt und mithilfe der Funktion *result()* als **Array** zurückgibt. Ein Datenmodell stellt in der Regel eine Vielzahl an Modell-Funktionen bereit. Entwickler können dabei auf die Klasse **Query Builder** zurückgreifen, die eine Reihe vordefinierter Funktionen für klassische Datenbank-Operationen umfasst. Einen Überblick finden Sie in der offiziellen [**Dokumentation des CodeIgniter Frameworks**](https://www.codeigniter.com/userguide3/database/query_builder.html "Mehr zur Query Builder Class auf codeigniter.com"). ### Routing mit CodeIgniter Welche Controller-Klasse und -Funktion angesprochen werden sollen, wird CodeIgniter mit einer URL vorgegeben. Das Webframework nutzt dafür die URL-Struktur *Klasse/Funktion/Parameter.* Dieses Grundschema lässt sich bei Bedarf anpassen. CodeIgniter stellt dazu die Datei *routes.php* im Verzeichnis *application/config/* zur Verfügung. Diese enthält ein Array namens ***$route***, das es Entwicklern ermöglicht, eigene **Routing-Kriterien** zu definieren. In der Ausgangskonfiguration finden sich im Array *$route* drei Default-Einträge: der **Standard-Controller**, eine Routing-Regel für das **404-Override** sowie eine Regel für das automatische **Ersetzen von Bindestrichen** (-) durch Unterstriche (\_). ```none $route['default_controller'] = 'home/welcome'; $route['404_override'] = 'home/welcome'; $route['translate_uri_dashes'] = FALSE; ``` Der erste Default-Eintrag bestimmt den **Standard-Controller** der Anwendung. Dieser wird von CodeIgniter immer dann geladen, wenn eine URL außer der Domain keine weiteren Routing-Informationen enthält. Im aktuellen Beispiel definiert die Routing-Regel die Controller-Klasse *home* als Standard-Controller. Besucher, die in der URL keine Angaben zur Ziel-Webpage machen, werden somit auf *home* umgeleitet und bekommen den View *welcome* präsentiert. Üblich ist eine Umleitung auf die Startseite. Wurde kein Controller als Standard definiert, zeigt CodeIgniter beim Aufruf der Startseite eine **404-Fehlerseite** an. Der zweite Default-Eintrag im *$route*-Array definiert einen Controller, der immer dann aufgerufen wird, wenn der durch die URL angesprochene Controller in den Applikationsdateien nicht gefunden wurde. Die Routing-Regel *$route\['404\_override'\] = 'home'* überschreibt die 404-Fehlerseite, die in einem solchen Fall normalerweise ausgespielt wird, und leitet stattdessen auf die Controller-Klasse *home* um. Der dritte Default-Eintrag im *$route*-Array verhindert Routing-Fehler aufgrund von Bindestrichen. Der Bindestrich ist kein valides Zeichen für Klassen- oder Funktionsnamen und wird daher bereits in der Standardeistellung in URLs automatisch ersetzt. Soll eine benutzerdefinierte Routing-Regel für eine dynamische URL erstellt werden, stehen Webentwicklern mit CodeIgniter zwei Möglichkeiten zur Verfügung: Routing-Einträge für dynamische URLs lassen sich mit **Wildcards** (Platzhalter) oder mit **regulären Ausdrücken** definieren. Die *routes.php* unterstützt zwei Arten von Platzhaltern: --- ### Hinweis Webseiten mit einer großen Anzahl an 404-Fehlerseiten sind schlecht zu crawlen und erschweren Suchmaschinen den Zugriff auf relevante Inhalte. Dies kann – neben den Auswirkungen auf die User-Experience – einen negativen Einfluss auf das Ranking in der Suchmaschine haben. In der Regel sind Webentwickler daher bemüht, 404-Fehlerseiten zu vermeiden. ---
Wildcards der routes.php Beschreibung
:num Fungiert als Platzhalter für Integer (Ganzzahlen)
:any Fungiert als Platzhalter für einen String (Zeichenkette)
Folgendes Bespiel zeigt einen Eintrag in der *routes.php*, der es ermöglicht, die Funktion (*article*) aus der URL zu streichen: ```none $route['news/article/(:num)'] = 'news/$1'; ``` Durch den Platzhalter *:num* wird der Parameter einer dynamischen URL ausgelesen und in der Variablen *$1* gespeichert. Sofern Sie Routing-Regeln mit *:num* oder *:any* definieren, müssen Sie diese in der *routes.php* in einfache Klammern setzen. Die *routes.php* akzeptiert zudem Routing-Regeln in Form von **regulären Ausdrücken**. Die beiden Platzhalter-Typen lassen sich somit auch folgendermaßen notieren: ```none :num entspricht \d+ :any entspricht [^/]+ ``` Eine Alternative zum obenstehenden Beispiel wäre somit folgende Schreibweise: ```none $route['news/article/(\d+ )'] = 'news/$1'; ``` Auch reguläre Ausdrücke werden in der *routes.php* eingeklammert. ### Der Anwendungsfluss im Überblick Folgende Grafik fasst den Application Flow einer Anwendung auf Basis von CodeIgniter in sieben Schritten zusammen: [![Bild: Der Anwendungsfluss des PHP-Frameworks CodeIgniter](https://www.ionos.de/digitalguide/fileadmin/_processed_/4/5/csm_DE-codeigniter-anwendungsfluss_f6c8f53b95.webp "Der Anwendungsfluss des PHP-Frameworks CodeIgniter")](https://www.ionos.de/digitalguide/fileadmin/DigitalGuide/Screenshots/DE-codeigniter-anwendungsfluss.png) Der Application Flow (Anwendungsfluss) des PHP-Frameworks CodeIgniter im Überblick **1.** Die ***index.php*** dient CodeIgniter als Front-Controller für eingehende [HTTP-Requests](https://www.ionos.de/digitalguide/hosting/hosting-technik/http-request-erklaert/ "HTTP-Request erklärt"). Hier werden alle Basisressourcen initialisiert, die benötigt werden, um die Anwendung auszuführen. **2.** Im Rahmen des **Routings** prüft CodeIgniter, welche Aktion ausgeführt werden soll. Dazu gleicht die Anwendung die URL in der Anfrage mit den in der *routes.php* definierten Routing-Regeln ab. **3.** Auf das Routing folgt das **Caching**. Findet sich eine zum Request passende Antwort im Cache der Anwendung, wird diese direkt an den anfragenden Webbrowser ausgeliefert. Andernfalls wird der während des Routings ermittelte Controller mit vorgeschalteter Filterfunktion ausgeführt. **4.** Das CodeIgniter-Framework beinhaltet einen integrierten **Filter**, der schädliche Anfragen abfängt. Bevor die Anwendung einen zur Anfrage passenden Controller lädt, wird jeder HTTP-Request einem Sicherheitscheck unterzogen. **5.** Passiert die Anfrage den Filter, wird der **Controller** ausgeführt. Dieser wählt einen passenden View aus und lädt das Datenmodell sowie alle Bibliotheken, Helfer-Klassen, Erweiterungen und Skripte, die benötigt werden, um die Anfrage zu beantworten. **6.** Sobald dem **View** alle relevanten Daten übergeben wurden, kann dieser an den Webbrowser ausgeliefert werden. **7.** Ist ein **Caching** aktiviert, hält CodeIgniter ausgehende Daten temporär vor, um sich wiederholende Abfragen direkt beantworten zu können. ## Vorteile des CodeIgniter Frameworks Mit mehr als 13.000 Sternen ist CodeIgniter ein viel beachtetes GitHub-Entwicklungsprojekt und auf Platz 3 der beliebtesten PHP-Frameworks. Doch wie jede Software hat CodeIgniter sowohl Vor- als auch Nachteile. Diese gilt es gegeneinander abzuwägen, bevor Sie sich als Webentwickler für das schlanke PHP-Framework entscheiden. Dies sind die Vorteile der Anwendung: - **Geringer Konfigurationsaufwand:** CodeIgniter bietet einen schnellen Einstieg. Nutzer brauchen sich nicht lange mit der Konfiguration des Frameworks aufhalten, sondern können nahezu unmittelbar nach der Installation mit der Entwicklung der geplanten Anwendung beginnen. Der Konfigurationsaufwand beschränkt sich im Wesentlichen auf die Einstellungen in der *config.php* im Verzeichnis *application/config/*. Anwender definieren hier einen Standardpfad für den Zugriff per Webbrowser, einen Schlüssel für die Verschlüsselung, einen Namen für den Session-Cookie und Einstellungen zum Cross-Site-Scripting (XSS). Zudem empfiehlt es sich, eine .htaccess-Datei anzulegen, um die *index.php* via [RewriteRule](https://www.ionos.de/digitalguide/hosting/hosting-technik/was-ist-eine-rewrite-engine/) aus dem Pfad der Anwendungs-URLs zu entfernen. Darüber hinaus ist eine Konfigurationen der Datenbank-Verbindung notwendig, die Sie in die Datei *database.php* eintragen. - **Small Footprint:** CodeIgniter hinterlässt nur einen kleinen Fußabdruck im System. Das Download-Paket des Frameworks umfasst rund 11 MB. Mehr als 9 MB entfallen dabei auf die ausführliche Dokumentation der Software. Der geringe Codeumfang kommt dadurch zustande, dass das CodeIgniter-Basissystem lediglich ein paar kleine Bibliotheken umfasst. Zusätzliche Ressourcen lassen sich bei Bedarf laden. - **Sehr gute Performance:** Das schlanke Basissystem führt dazu, dass CodeIgniter im Vergleich zu anderen PHP-Frameworks mit einer hohen Geschwindigkeit punkten kann. Gelobt wurde diese u. a. vom PHP-Erfinder Rasmus Lerdorf. Dieser verkündete 2008 auf der Free and Open Source Conference (FrOSCon), dass ihm CodeIgniter gefalle, da es schneller, leichtgewichtiger und weniger wie ein Framework sei („because it is faster, lighter and the least like a framework“). - **„Saubere“ URLs:** CodeIgniter generiert automatisch nutzerfreundliche, suchmaschinengeeigneteURLs. Statt den Zugriff auf dynamische Webinhalte wie andere PHP-Frameworks durch Query Strings zu realisieren, setzt CodeIgniter auf einen segmentbasierten Ansatz. URL mit Query String: *example.com?controller=news&function=article&id=511* Segmentbasierte URL: *example.com/news/article/511.* - **Freier Programmierstil:** CodeIgniter basiert auf einer freien Interpretation des MVC-Architekturmusters. Entwicklern ist somit kein Programmierstil vorgegeben. - **Umfangreiche Dokumentation:** CodeIgniter verfügt über eine ausführliche Dokumentation in englischer Sprache inklusive Einsteiger-Tutorial. Zudem ist der Quellcode übersichtlich und gut kommentiert. Die CodeIgniter-Dokumentation steht auf der Projekt-Website als Onlineguide und Download-Version zur Verfügung. - **Community-Support:** Entwickler, die Anwendungen auf Basis von CodeIgniter entwickeln, können sich auf die Hilfe anderer Nutzer stützen. Das Projekt wird von einer aktiven Community begleitet. Ein öffentliches Forum wird unter [https://forum.codeigniter.com](https://forum.codeigniter.com "Das offizielle CodeIgniter-Forum") angeboten. Aktuell tauschen sich dort mehr als 7.300 Anwender in rund 65.000 Threads über den Einsatz und die Weiterentwicklung des Frameworks aus. ## Nachteile des CodeIgniter-Frameworks Da die Entwicklung des CodeIgniter-Frameworks vor der Übernahme durch das BCIT zeitweise stagnierte, suchen Entwickler einige technologische Entwicklungen, die von vergleichbaren Frameworks in den vergangenen Jahren adaptiert wurden, bei CodeIgniter vergeblich. - **ORM nur über Drittanbieter:** Unter objektrelationaler Abbildung („object-relational mapping“, ORM) versteht man eine Technik der Software-Entwicklung, die es Anwendungen ermöglicht, in einer objektorientierten Programmiersprache wie PHP geschriebene Objekte in einer relationalen Datenbank abzulegen. CodeIgniter unterstützt ORM nicht nativ. Die Technik kann jedoch durch Drittanbieter eingebunden werden. - **Keine Template-Engine:** CodeIgniter rühmt sich damit, ohne Template-Engine auszukommen. Stattdessen stellt das Framework optional einen einfachen Template-Parser zur Verfügung. Dies kann als Vorteil angesehen werden. Der Einsatz einer Template-Engine ist in der Regel mit einem Performance-Overhead (Zusatzaufwand zur Laufzeit) verbunden. Darüber hinaus muss zusätzlich zum Framework auch der Gebrauch der Template-Sprache erlernt werden. Andererseits erlaubt es eine Template-Engine, die Datengenerierung vom Code für die Präsentation zu separieren, und führt so in der Regel zu einem übersichtlich strukturierten Quellcode. Kommt eine Template-Engine mit schlanker Syntax zum Einsatz, kann dies den Gesamtumfang des Application-Codes deutlich reduzieren. - **Kein Namespacing:** Mit Namespaces bietet PHP die Möglichkeit, Code verschiedener Anwendungsgruppen zu trennen. PHP-Entwickler machen sich dieses Feature zunutze, um Konflikte zu vermeiden, die bei der Benennung von Klassen und Funktionen auftreten. Gängig sind beispielsweise Namenskollisionen mit internen PHP-Klassen, -Funktionen, -Konstanten oder -Elementen, die von Drittanbietern eingebunden werden. CodeIgniter nutzt dieses PHP-Feature bislang nicht. - **Kein PHP-Auto-Loading:** Seit Version 5 bietet PHP mit *\_\_autoload()* und *spl\_autoload\_register()* zwei Funktionen, die es ermöglichen, Klassendefinitionen bei Bedarf automatisch zu laden. Im CodeIgniter-Framework steht dieses Feature nicht zur Verfügung. - **Weniger Built-in-Bibliotheken als andere PHP-Frameworks:** Aufgrund des schlanken Software-Designs bietet CodeIgniter in der Ausgangskonfiguration deutlich weniger Bibliotheken als andere PHP-Frameworks. Diese umfassen in erste Linie die wichtigsten Aufgaben der Webentwicklung wie Datenbankzugriffe, E-Mail-Versand, die Validierung von Formulardaten, das Aufrechterhalten von Sessions oder die Arbeit mit [XML-RPC](https://www.ionos.de/digitalguide/websites/web-entwicklung/was-ist-xml-rpc/). Für Aufgaben, die über die Basis-Features hinausgehen, müssen eigene Bibliotheken oder Ressourcen von Drittanbietern eingebunden werden. Ein Punkt, den Entwicklern, die ein auf das Minimum reduziertes Framework suchen, auch als Vorteil interpretieren können. ## CodeIgniter für den eiligen Leser Nachstehende Tabelle zeigt die Eckdaten des CodeIgniter-Frameworks in der Übersicht:
CodeIgniter
Entwickler British Columbia Institute of Technology (BCIT)
Aktuelles Release Version 3.1.2
Design-Muster MVC/HMVC, Active Record, Chain of Responsibility
Benötigte Kenntnisse PHP, Objektorientierte Programmierung (OOP)
Programmiersprache PHP 5.6 oder höher
Lizenz MIT-Lizenz
Datenbankunterstützung MySQL (5.1+), Oracle, PostgreSQL, MS SQL, SQLite, CUBRID, Interbase/Firebird, ODBC
ORM Nur über Drittanbieter
Caching ja
Template-Engine nein
Namespaces nein
PHP-Auto-Loading nein
Suchmaschinenfreundliche URLs nein
Sicherheits-Features Cross-Site-Request-Forgery (XSRF), Cross-Site-Scripting (XSS), SQL-Injection
Testing-Library PHP Unit
--- ### Fazit Mit seinem kompakten Design und der einsteigerfreundlichen Syntax eignet sich CodeIgniter vor allem **für angehende Programmierer**. Wer bereits erste Erfahrungen mit der dynamischen Webentwicklung auf Basis von PHP gemacht hat, wird sich auch in das PHP-basierte Lightweight-Framework in kürzester Zeit einarbeiten. Und auch **erfahrende Webentwickler** schätzen die Flexibilität, die ihnen ein auf Grundfunktionalitäten reduziertes PHP-Framework einräumt. Wer CodeIgniter nutzen möchte, sollte sich jedoch mit dem MVC-Architekturmuster anfreunden und auf eine Template-Engine sowie natives ORM verzichten können. Trotz minimalem Codeumfang eignet sich CodeIgniter gleichermaßen für kleine und große Webprojekte. --- This is a markdown version of: [https://www.ionos.de/digitalguide/websites/web-entwicklung/codeigniter-das-schlanke-php-framework/](https://www.ionos.de/digitalguide/websites/web-entwicklung/codeigniter-das-schlanke-php-framework/) for AI/LLM consumption.