@Valle: was soll das denn heissen?

Ich geb auch noch bisserl Senf dazu, allerdings ohne mir die Muehe gemacht zu haben, den Code anzusehn. Security-Reviews gibts sind dann doch etwas aufwaendiger.
Ein paar allgemeine Kommentare kann ich dir geben:

• Valle hat Recht wenn er dir MVC ans Herz legt. Nein, eine Template-Engine macht deinen Code nicht MVC-konform. Ja, ein MVC-Framework hilft dir. Ich empfehle Symfony 1.4 und Doctrine (ist in symfony enthalten) als Framework-Loesung. Damit sind auch die von Frederic angesprochenen Prepared Statements abgehakt.
• index.php5 ist eine Sache die es nicht geben sollte. index.php ist schon eher richtig - FYI: es gibt nur eine unterstuetzte PHP-Version, und das ist PHP5. Hoster bei denen Dateien die Endung php5 haben muessen, damit PHP5 greift kannst du in die Tonne kloppen. Ausserdem ist .php die Standard-Erweiterung fuer PHP-Skripte. Ich aendere doch nicht meine Apache-Einstellungen (wo PHP bei Dateien mit der Endung .php greift) um ein CMS ausfuehren zu koennen. Sorry, aber is nicht.
• @Valle: camelCase funktioniert anders. Ich empfehle uebrigens einen Blick auf die PEAR oder ZF Coding-Guidelines - diese sind akzeptierter Standard. Da stehn noch ein paar andere sinnvolle Dinge drin.
• 777 ist toedlich. Ganz ehrlich: wenn www-data irgendwo schreiben soll, machs ueber die normalen Gruppen- und Benutzer-Berechtigungen von Linux. Es gibt keinen Grund warum der mysql-Benutzer in den Apache-Skripten rumfummeln darf oder warum Dateien gar ausfuehrbar sein sollen. 644 (Files) bzw. 755 (Directories) kombiniert mit chown und chgrp sollte dein bester Freund werden.
• Um das functions.php-Beispiel weiterzufuehren: wenn du die Funktionen logisch in Klassen kapselst und mit nem Autoloader arbeitest dann sparst du dir das unnoetige Laden von zig Funktionen. Das Parsen der PHP-Dateien kostet naemlich ohne Opcode-Cache richtig viel Zeit. Wenn dein Code nur eine von 20 Klassen braucht, wird auch nur die geladen, und dann auch erst sobald sie benoetigt wird. Guck dir hierzu mal spl_autoload() an. Da ist uebrigens noch ein Vorteil von MVC-Frameworks: diese implementieren sowas bereits
• Um Valle noch den Gefallen zu tun: bei der Performance-Optimierung eines grossen Ticketing-Systems haben wir uns entschlossen, ein is_preg-Flag in die Tabelle einzufuegen um so zu entscheiden ob wir per preg_match vergleichen oder per == wenn PREG nicht von Noeten ist. Das Ergebnis: der Code war nachher um den Faktor 20 (!) schneller. Muss ich noch mehr dazu sagen?

Mein ganz freundlich gemeinter Tipp: guck dir mal folgende Tutorials an: A gentle introduction to Symfony und Practical symfony (for Doctrine). Sobald du mal die Vorteile des Systems gespuert hast wirst du sie nicht mehr missen wollen (ich sag nur I18N, Test-Frameworks, Routing-Klassen, CRUD-Generation, etc. )

Greetz
alcaeus

Hallo,

ich möchte gerne noch die Sachen, welche alcaeus genannt hat unterstreichen. Hoster, die nur PHP in der Version 5 verwenden, wenn die Dateiendung .php5 ist, sind für die Tonne. Ich weiß dass es sowas noch gibt, aber der Einsatz eines längst nicht mehr unterstützen Software-Pakets ist ein Armutszeugnis für jeden Hoster...

Mit Doctrine habe ich bisher Erfahrung gemacht, was deren DB-Sachen betrifft (weiß jetzt nicht genau, ob da noch mehr dabei ist). Doctrine ist ein krasser Gegensatz zu herkömlichen Datenbank-Aktionen wie man sie so vielen PHP-Scripten kennt. Aber der Umstieg lohnt sich auf jeden Fall!

@alcaeus: Hätte ja nicht gedacht dass wir uns mal so einig sind. Hatten wir uns nicht mal darüber unterhalten, dass das einsparen solcher Regular Expressions deiner Meinung nach nichts bringen würde?

Liebe Grüße,
Valle

Zitat von Valle:

@alcaeus: Hätte ja nicht gedacht dass wir uns mal so einig sind. Hatten wir uns nicht mal darüber unterhalten, dass das einsparen solcher Regular Expressions deiner Meinung nach nichts bringen würde? |

Kann mich nicht dran erinnern, in letzter Zeit warens dann doch ein paar mehr PHP-Themen als dass ich mir deren Inhalte merken koennte. Darfst aber gerne suchen wenn du magst. *gg*
Ausserdem: du musst nur oefter meine Meinung annehmen, dann sind wir uns auch einig

Greetz
alcaeus

Zitat von alcaeus:

[*]Um das functions.php-Beispiel weiterzufuehren: wenn du die Funktionen logisch in Klassen kapselst und mit nem Autoloader arbeitest dann sparst du dir das unnoetige Laden von zig Funktionen. Das Parsen der PHP-Dateien kostet naemlich ohne Opcode-Cache richtig viel Zeit. Wenn dein Code nur eine von 20 Klassen braucht, wird auch nur die geladen, und dann auch erst sobald sie benoetigt wird. Guck dir hierzu mal spl_autoload() an. Da ist uebrigens noch ein Vorteil von MVC-Frameworks: diese implementieren sowas bereits

*meld*

So ganz komme ich noch nicht hinter den Autoloader. Nehmen wir an, eine beliebige Klassendatei, bspw. content.class.php schaut so aus:

zusammenfalten · markieren

PHP-Quellcode:

<?php
require_once('dbconnector.class.php');
require_once('systemcomponent.class.php');

class content extends systemcomponent {

   //values
   var $contentid = 0;
   var $creationtimestamp = 0;
   var $modifiedtimestamp = 0;
   var $contenttype = "";
   var $title = "";
   var $summary = "";
   var $category = 0;
   var $parentcontent = 0;
   var $thecontent = "";
   var $authorid = 0;
   var $requireduserlevel = 10;
   var $ispasswordprotected = false;
   var $pass = "";
   var $commentsallowed = 1;
   var $ispublished = false;
   var $fancyhash = "";
   
   //constructor
   function __construct($id) {
        }
}
?>

Davon gibt es mehrere dieser Sorte, immer nach demselben Schema aufgebaut. Dann kommt noch eine zentrale index.php, die in etwa so aussieht:

zusammenfalten · markieren

PHP-Quellcode:

<?php
setlocale (LC_ALL, 'de_DE');
/* Start Session */
session_start();
/* Define a global Var */
define('SMARTY_DIR','./libs/smarty/');

/* Require some files */
require_once('./libs/smarty/Smarty.class.php');
require_once('./libs/nbbc/nbbc.php');
require_once('./classes/users.class.php');
require_once('./classes/searchprovider.class.php');
require_once('./classes/settings.class.php');
require_once('./classes/content.class.php');
require_once('./classes/tags.class.php');
require_once('./classes/comment.class.php');
require_once('./classes/validator.class.php');
require_once('./classes/category.class.php');
require_once('./classes/statistics.class.php');

/* Create some Objects */
$smarty               = new Smarty();
$settings            = new Settings();
$currentUser          = new Users();
$nbbc               = new BBCode();
$tags               = new Tags();
$stats               = new Stats();
//[...]
?>

Angenommen, ich möchte jetzt spl_autoload(); nutzen. Wie implementiere ich das? Irgendwie steig ich da noch nicht ganz durch... Muss ich die vorhandenen Klassen um eine autoload-Methode erweitern? Muss ich einfach den Autoloader in der index.php definieren? Oder beides?

Die Hilfe wirkt hier Wunder: http://de.php.net/manual/de/function.spl-autoload.php
Guck mal in den Kommentaren da sind ein paar gute Beispiele vorhanden.

Hab ich mir schon vorher angesehen. Allerdings scheint es bei mir nicht wirklich hinzuhauen. Ich habe folgende Pfade probiert:

markieren

PHP-Quellcode:

define('CLASS_DIR', 'classes');
define('CLASS_DIR', 'classes'.DIRECTORY_DELIMITER);
define('CLASS_DIR', 'xampp\htdocs\dagi_micro\classes'.DIRECTORY_DELIMITER);

Haut nicht hin. Folgender Code kommt dabei zum Einsatz:

markieren

PHP-Quellcode:

// Add your class dir to include path
set_include_path(get_include_path().PATH_SEPARATOR.CLASS_DIR);

// You can use this trick to make autoloader look for commonly used "My.class.php" type filenames
spl_autoload_extensions('.class.php');

// Use default autoload implementation
spl_autoload_register();

Soweit ich das verstehe, muss die Datei zumindes im Include-Pfad liegen. Nur, wie bekomme ich den dahin? Ich arbeite übrigens unter Windows mit XAMPP. Das finale System nutzt einen Debian-Server. Als Fehlermeldung bekomme ich nur, dass die Klasse "Settings" nicht gefunden werden kann.

markieren

Code:

function __autoload($Klassenname) {
  $Datei = suche_PhpDatei_in_welcher_die_Klasse_enthalten_ist($Klassenname);
  require($Datei);
}

// registriert sich automatisch, über seinen Funktionsnamen

oder besser doch

markieren

Code:

function MeinAutoKlassenlader($Klassenname) {
  // das kann auch eine statische Klassenmethode sein
  $Datei = suche_PhpDatei_in_welcher_die_Klasse_enthalten_ist($Klassenname);
  require($Datei);
}

spl_autoload_register('MeinAutoKlassenlader, true);

oder

markieren

Code:

function MeinAutoKlassenlader($Klassenname, $ListeDerRegistriertenDateiendungen) {
  // das kann auch eine statische Klassenmethode sein
  $Datei = suche_PhpDatei_in_welcher_die_Klasse_enthalten_ist($Klassenname, $ListeDerRegistriertenDateiendungen);
  require($Datei);
}

spl_autoload_register('MeinAutoKlassenlader, true);

jetzt einfach eine Klasse verwenden, welche noch nicht existiert
- zugehörige Datei wurde noch nicht geladen (require/include)

markieren

Code:

$Test = new IrgendeineKlasse();

nun wird also die registrierte Funktion aufgerufen, darin die benötigte Datei geladen und dann kann's weitergehn.

eigentlich recht nette sache


hab mir nun selber einen kleinen Autolader geschrieben

oder man verwendet halt den vordefinierten Autoloader und steuert ihn über
set_include_path, spl_autoload_extensions und Co.
Dieser nimmt z.B. den Klassennamen und versucht sich daraus einen kleichnamigen Dateinamen zu basteln
(sowas geht aber nicht, wenn die Dateien nicht wie die Klasse heißen und/oder man mehrere Klassen in einer Datei liegen hat)

Klasse "statistics" in "./classes/statistics.class.php"
= suchpfad "./classes/"
= dateiendung ".class.php"

dann kann das require_once('./classes/statistics.class.php'); weg
und auch alles, welches diesem Muster entspricht

Zitat von himitsu:

= suchpfad "./classes/"

Das war der Casus-Knaxus. Jetzt funktioniert es einwandfrei mit der default-autoload-funktion. Sehr cool. Jetzt noch PDO eingebaut, und es kann wieder weitergehen.

//Edit: Kommando zurück. Irgendwie ist der Fehler mittlerweile wieder da... Ich bin doch nicht blöd, oder?