HTML Formular an externe .php ohne Seitenwechsel + PHP-/MySQL Anfängerfragen

[FredHoff]

Hi,

ich möchte ein Formular aus meiner index.html an meine mysql_add.php übergeben, ohne, dass die Seite gewechselt wird.
Mit meinem bisherigen Code-Schnipsel werden die Daten erfolgreich in die DB eingetragen und der Nutzer wird auf die mysql_add.php weitergeleitet. Letzteres (die Weiterleitung) möchte ich unterbinden, sodass die index.html nur aktualisiert wird.

index.html

 <form action="mysql_add.php" method="POST">
      <input type="text" name="muster_var"><br>
</form>

mysql_add.php

$link = mysql_connect($server, $user, $pass);
$muster_var = $_POST["muster_var"];
$add = "INSERT INTO `muster_dbname`.`muster_table` (`muster_var`) VALUES ('$muster_var');

if (mysql_query($add, $link)) 
{
    echo "Daten wurden erfolgreich übertragen<br><p></p>";
} else 
{
    echo "Error: " . $add . "<br>" . mysql_error($link);
}

//Ausgabe
    $tabellenname = "muster_dbname";
    $spaltenname = "muster_var";
    $abfrage = "SELECT $spaltenname FROM $tabellenname";
    $ergebnis = mysql_query($abfrage);
    echo '<b>' . $spaltenname . '</b><br>';
    while($zeile = mysql_fetch_object($ergebnis))
    {
        echo $zeile->Muster_var;
        echo '<br>';
    }

Bisher habe ich nur Lösungen via JS und Ajax gefunden. Diese wollte ich aber wegen Sicherheitsbedenken / mobiler Verfügbarkeit vermeiden.


Tabellen und Frames gehören AFAIK zur "alten Schule"; Oder sind Frames zu diesem Zweck noch freigegeben? Gibt es in HTML sonst eine Möglichkeit dazu bzw. kann man innerhalb einer Form auf das gleiche Dokument verlinken?
Ist es richtig HTML und PHP zwecks Übersicht strikt voneinander zu trennen (vgl. *.html / externe *.css) oder wird der Mix gerne gesehen?
Und zum Schluss:
Ich bin auf der Suche oftmals auf Diskussionen über mysql / mysqli gestoßen. So wie ich das bisher verstanden habe ist mysqli eine aktualisierte Version. Kann mir das jemand bestätigen / widerlegen?


Entwicklungssoftware: Notepad++, XAMPP Vers. 3.2.1 (Apache, MySQL), Chrome Vers. 39.0.2171.65m


Besten Dank!

 

[Snooty]

Was genau stört dich an der Weiterleitung? Du kannst beim Formular natürlich die Seite mit dem Formular selbst als Ziel angeben. Wenn aber Daten irgendwie verarbeitet werden sollen, kommst du nur mit deiner index.html nicht weit. Müsstest stattdessen also eine index.php verwenden, die das Formular verarbeitet.

Oder du leitest von der mysql_add.php wieder zur index.html zurück.

 

[FredHoff]

Fett, genau den letzten Teil Deiner Antwort wollte ich hören, Snooty! Danke!

Die Weiterleitung stört mich, weil ich momentan Darstellung und Verarbeitung strikt voneinander getrennt habe.
Der Nutzer soll mit der Verarbeitung an sich (möglichst) nichts zu tun haben.

Gut zu wissen, dass eine Weiterleitung per PHP grundsätzlich möglich ist. Spontan habe ich

header('location: url');
exit();

gefunden. Den Befehl muss ich dann vermutlich hinter dem DB-Disconnect bringen, damit sich der Nutzer ordnungsgemäß von der Datenbank trennt.

Weiterleitung im Formular selbst macht für mein Vorhaben keinen Sinn, die Verarbeitung muss unbedingt stattfinden, sonst bräuchte ich ja keine DB (deshalb auch der PHP-Ausschnitt)


Ich würde den Thread, trotz Beantwortung der Kernfrage, noch gerne weiterhin geöffnet lassen, um die anderen Punkte zu klären.

 

[Drexel]

Natürlich kannst Du in einer index.html auch PHP ausführen, das ist doch nur eine Konfiguration Frage. Du kannst die Weiterleitung auch komplett loswerden, indem Du als Form action auch die index.HTML angibst. Du kannst Darstellung und Verarbeitung auch weiterhin trennen, indem Du je nach Status der Seite (z.B. erster Aufruf, Fehler in Eingabe, Datenverarbeitung) andere Dateien inkludierst. Das wäre zumindest ein erster primitiver Ansatz.

Btw. lustig, dass Du wegen JS und Ajax Sicherheitsbedenken hast, Dich SQL Injection aber nicht zu stören scheint...

 

[mambokurt]

Das einfachste wäre es sicherlich du gibst als Ziel fürs Form die index.php an und machst in der index.php ein Include auf dein Mysqladd Zeug, dann bleibst du gleich in der index.php und sparst dir das Herumgespringe.

 

[Daaron]

Alle Mobilgeräte haben standardmäßig JavaScript aktiv. Da würde ich mir eher bei Desktops Sorgen machen, da gibts viel mehr Paranoiker mit NoScript & Co.
Und welche Sicherheitsbedenken? Wenn du deine Eingaben mal sauber validieren würdest, anstatt direkt ne potentielle SQL Injection Lücke einzubauen, hat das GAR NICHTS mit Sicherheit zu tun, ob du jetzt per JavaScript versendest oder über einen regulären Form Submit.

Tabellen und Frames gehören AFAIK zur "alten Schule";

Tabellen sind semantisch sehr wichtige Elemente.... wenn man sie denn auch semantisch korrekt verwendet. Frames sind tot, iFrames kann man unter Umständen noch sehr sinnvoll verwenden (z.B. Mobile-fähiges Youtube Embedding oder Social Media Elemente).
Das ändert nichts daran, dass auch <iframe> dir hier nichts hilft. Du musst einen vernünftigen Flow programmieren.

kann man innerhalb einer Form auf das gleiche Dokument verlinken?

Klar. Es kommt doch nur auf das Action-Attribut an. Rein theoretisch kann man Action sogar leer lassen bzw. komplett weg lassen. Dann hast du aber ne riesige Clickjacking-Lücke in deiner Anwendung.
Also: Gib als Action das Dokument selbst an, Problem gelöst.

Ist es richtig HTML und PHP zwecks Übersicht strikt voneinander zu trennen (vgl. *.html / externe *.css) oder wird der Mix gerne gesehen?

Falsch gedacht. Du trennst Logik von Darstellung, aber nicht PHP von HTML. Du baust mit PHP dein HTML auf, du trennst nur eben den PHP-Teil, er dir dein HTML-Dokument erzeugt, von der Logik, die dir die Daten für dein Dokument erzeugt.

Ich bin auf der Suche oftmals auf Diskussionen über mysql / mysqli gestoßen. So wie ich das bisher verstanden habe ist mysqli eine aktualisierte Version. Kann mir das jemand bestätigen / widerlegen?

Warum schaust du nicht einfach auf der PHP Homepage? Da steht das ausführlich und -drücklich.

Die Weiterleitung stört mich, weil ich momentan Darstellung und Verarbeitung strikt voneinander getrennt habe.
Der Nutzer soll mit der Verarbeitung an sich (möglichst) nichts zu tun haben.

Das eine hat doch nichts mit dem anderen zu tun.
Als Nutzer erwarte ich z.B., dass ich bei Fehleingaben von der Seite benachrichtigt werde. Ich gebe Daten ein, sende sie ab, sie durchlaufen auf dem Server einen Validations-Algorithmus und dann entscheidet sichs... Sind die Daten Schrott, erhalte ich vom Server eine Rückantwort, was denn falsch war (z.B. Passwort falsch, falsches Datumsformat,...). Sind die Daten verwertbar, dann möchte ich vom Server nicht nur blöde im Kreis herum auf den Ausgangspunkt (das Formular) geschoben werden, ich möchte ein "Vielen Dank für Ihre Nachricht".

Den Befehl muss ich dann vermutlich hinter dem DB-Disconnect bringen, damit sich der Nutzer ordnungsgemäß von der Datenbank trennt.

Solltest du, musst du aber nicht zwingend. Rein theoretisch sollte exit; auch bestehende DB-Verbindungen terminieren.

Besser wäre aber: Du schreibst eine vernünftige objektorientierte Datenbank-Abstraktion, die in einer Destructor-Methode die Verbindung explizit trennt.

Natürlich kannst Du in einer index.html auch PHP ausführen, das ist doch nur eine Konfiguration Frage.

Da muss man aber mit dem Klammerbeutel gepudert sein, wenn man .html - Dateien tatsächlich durch den PHP-Parser schickt. HTML ist eine statische Ressource, und sollte vom Webserver genau so behandelt werden.
Schicke nichts an den Parser, was nicht auch geparsed werden soll. Ist sonst pure Ressourcenverschwendung und führt unter Umständen zu unerwartetem & fehlerhaftem Verhalten.

 

[Drexel]

Also für mich ist das was in der URL steht Schall & Rauch. Selbst wenn da html steht gibts doch in der Regel ein Rewrite und es wird was ganz anderes ausgeführt. In nen CMS oder auch in diesem Fall hast Du doch eh keine statische html Seite mehr. Also lass die Url doch nach html aussehen, ist doch Wurscht.

 

[Daaron]

Ja, wenn du Rewrites mit in Betracht ziehst, vor allem in Verbindungen mit anständigen Routing-Funktionen. Aber das dürften den Horizont des TE doch weit überschreiten.
Mir stößt es nur sauer auf, wenn du explizit "index.html" schreibst, denn das klingt doch arg nach dieser speziellen Datei mit ihren speziellen Eigenschaft... der Standard-Index eines Ordners halt. Niemand würde einen URL-Rewrite auf eine index.html machen. Das ist keine SEO-freundliche URL, das ist nichts aussagekräftiges, nichts hübsches,... das ist rein technisch, da kann dann genauso gut auch index.php stehen, oder index.phtml.

 

[FredHoff]

Danke für die Antworten, Danke Daaron.

Meine Grundidee war:
"Bevor ich meine Dokumente 50x überarbeiten muss, weil ich Lücken geöffnet habe, die mit Alternativen vermeidbar sind, arbeite ich lieber mit der 'sichereren Variante'(ohne JS)." Ja, ich widerspreche mir selbst, ich weiss


An SQL-Injections habe ich auch schon gedacht. Es kribbelte aber doch zu sehr in den Fingern, erstmal möglichst viele Funktionen bereitzustellen und zu experimentieren.

Genau, wegen der Feedback-Variante kam die Frage nach dem Sinn der Trennung auf.

Ein ERM habe ich gleich zu Beginn nach ACID erstellt (falls Du mir das an die Hand geben wolltest).

 

[Daaron]

Nur hilft dir das nix. Da hast du dann zwar ein wahrscheinlich hübsches Datenbankmodell in irgend einer noch hübscheren Normalform, aber die 3 Zeilen brechen dir so oder so das Genick, egal ob deine Daten vor Redundanzen strotzen oder Codd dich für die Struktur lobpreisen würde.

$muster_var = $_POST["muster_var"];
$add = "INSERT INTO `muster_dbname`.`muster_table` (`muster_var`) VALUES ('$muster_var');
 
if (mysql_query($add, $link))

Eine SQL Injection Lücke hat NICHTS, aber auch GAR NICHTS, mit einer Einschränkung der Funktionalität zu tun. Schon der konsequente Einsatz von mysql_real_escape_string(), bzw. der mysqli-Variante davon, senkt das Risiko erheblich (aber: nicht auf Null). Die sture Verwendung von Prepared Statements, entweder über MySQLi oder (was einfach besser ist) PDOs, hingegen erhöht die Performance und senkt das Injection-Risiko faktisch auf Null...

Es ist vollkommen egal, ob du ein Formular dadurch abschickst, dass du auf einen <input type=submit> drückst und die Seite wechselt, oder ob du in JS einfach form.submit() sagst. Auch ein AJAX Request mit den Form-Daten ist genau so sicher oder unsicher wie die aller-sturste JS-lose Variante.

Fakt ist:
- Setze JS nicht als gegeben voraus. Erhalte (wenn möglich) alle grundlegenden Funktionalitäten auch bei abgeschaltetem JS. Für eine komplexe Webanwendung ist das natürlich nicht möglich. Für simple Formulare hingegen schon.
- Validiere Formularfelder ERST über HTML5, dann (vor dem Submit) über JS und in letzter Instanz serverseitig nach dem Submit. Das spart deinen Besuchern viel Zeit & Frust, was dir wiederum Profit bringt.
- Lasse NIE NIE NIE die serverseitige Validierung weg! Alles vorherigen Stufen sind optional, aber der Server darf nichts ungeprüft schlucken!


Dein Kernproblem ist trotzdem ein anderes: Du kombinierst statisches HTML mit separaten PHP-Dateien. Das ist Unsinn. Du könntest z.B. dein statisches HTML-Formular nie mit Werten aus der Datenbank vorbelegen, obwohl das die normalste Sache der Welt ist.

Lösung für all deine Probleme, von der Datenstruktur über die SQL Injection Lücke bis hin zur Trennung von Design und Logik: Verwende ein gutes Framework. Symfony2, Zend, Laravel... gibt so viele gute PHP-Frameworks.
Oder schnapp dir ein gutes CMS und hör auf, das Rad neu zu erfinden. ICh bin mir ziemlich sicher, dass 95% deiner Bedürfnisse von jedem guten CMS direkt erfüllt werden können, den Rest schreibst du modular dazu.

 

[FredHoff]

Hm, vielleicht das Wichtigste zuerst (wäre weiter oben wahrscheinlich angebrachter gewesen, naja): Ich bin blutiger Anfänger. Den ganzen Aufwand betreibe ich nur, weil ich mich gerade einmal seit dem vergangenen Wochenende überhaupt mit der Erstellung von Webseiten auseinander setze. Ich bin quasi, abgesehen von BB-Code, noch unbefleckt Vielleicht wird dadurch verständlich, wieso ich so viele Tags überhaupt erst einmal ausprobieren möchte. Deshalb auch der Verzicht auf Frameworks, bei denen ich derzeit ohnehin nicht wüsste, wie ich sie einbinden soll (Suchmaschine hin oder her).

Um die Behebung der Lücke habe ich mich nach wie vor noch nicht gekümmert, ich arbeite eh noch eine ganze Weile lokal. Der Tipp mit der mehrschichtigen Validierung ist aber Gold wert! Edit: Dass die Lücke durch das unkontrollierte Datenschlucken entsteht, ist mir bewusst bzw. war es schon von Anfang an.

Ich habe auch das Gefühl, dass ich ziemlich unstrukturiert arbeite: "Hier ein bisschen HTML, da CSS, ein wenig PHP, oh, jetzt fehlt mir doch noch ein Attribut in der DB", das führt doch zwangsläufig zu dreifacher Arbeit, oder ist das "normal" beim WebDev?

 

[Daaron]

Zwischendurch CSS zu schreiben, bevor die gesamte HTML Semantik steht, ist totale Zeitverschwendung.
Es ist nix dagegen einzuwenden, einen "mal sehen, ob das klappt..." - Ansatz mit stetiger Veränderung zu verwenden. Mach ich auch meistens so. Aber dabei sollten gewisse Grundlagen von Anfang an fest gelegt werden:
- Datenbank-Abstraktion
- Template-Engine
- Routing fürs URL Rewriting
- Formular-Validatoren

Es lohnt sich nicht, all diese Komponenten neu zu erfinden. Da sitzt du nur Wochen und Monate, bis du auch nur 1% der Codequalität eines der gängigen Frameworks erreichst.

 

[mambokurt]

Hi,
Tabellen und Frames gehören AFAIK zur "alten Schule"; Oder sind Frames zu diesem Zweck noch freigegeben? Gibt es in HTML sonst eine Möglichkeit dazu bzw. kann man innerhalb einer Form auf das gleiche Dokument verlinken?
Ist es richtig HTML und PHP zwecks Übersicht strikt voneinander zu trennen (vgl. *.html / externe *.css) oder wird der Mix gerne gesehen?

Da du offensichtlich ein wenig überfordert bist mit den Grundkonzepten hier mal mein grundsätzlicher Ansatz für Anwendungen:

-index.php bekommt alle Requests
-die prüft dann was für eine Anfrage vorliegt, lädt die nötigen PHP Klassen nach
-die PHP Klassen machen ihr Ding und generieren die nötigen Daten für den Output
-den Output geben sie an eine Templateklasse, die läd die nötigen Templates
-in den Templates wird dann mit PHP und den Outputvariablen aus den PHP Klassen das HTML generiert.

Für kleinere Sachen habe ich eine eigene kleine Templateklasse, um nicht immer ein komplettes Framework mitschleppen zu müssen:

<?php
 /**
 * simpleTpl

 * @package simpleTpl
 */

class simpleTpl {
  protected $sTplDir = './templates/'; //Vorbelegung Templateverzeichnis ist /templates im aktuellen Verzeichnis
  protected $aVar = array(); //Variablen, die über assign() zugewiesen wurden 
  
  /**::construct()
   * setzt momentan nur einige Templatevariablen
   **/
  public function __construct() {
    $this->clearTplVar();
    ob_start();
  }
  
  public function clearTplVar() {
    $iTime = time();
    $this->aVar = array();
    $this->aVar['iTime'] = $iTime;
    $this->aVar['sDate'] = date("d.m.Y", $iTime);
    $this->aVar['sDateFull'] = date("d.m.Y, H:i:s", $iTime); 
  }
  
  /** ::setTplDir($sTplDir)
   * setzt das aktuelle Templateverzeichnis
   **/
  public function setTplDir($sTplDir) {
    if(!file_exists($sTplDir)) { //Verzeichnis vorhanden? 
      echo('Templateverzeichnis '.$sTplDir.' konnte nicht gefunden werden!'); //Nein: Fehlermeldung und exit
      exit;
    } else {
      $this->sTplDir = $sTplDir;
    }
    return;
  }
 
  /** ::assign($sKey, $mValue = '');
   * bekommt Schlüssel(string) und dessen Wert(mixed) und setzet diese in $this->aVars 
   **/  
  public function assign($sKey, $mVal = '') {
    $this->aVar[$sKey] = $mVal;
  }
 
  /** ::display($sTpl, $aVar)
   * 
   **/
  public function display($sTpl, $aVar = array()) {
    if(!is_file($this->sTplDir.$sTpl)) { //Template vorhanden?
      echo('Templatedatei '.$this->sTplDir.$sTpl.' konnte nicht gefunden werden!'); //Nein: Fehlermeldung und exit
      exit;
    } else {
      foreach($this->aVar as $key => $value){
       $$key = $this->aVar[$key];
       unset($this->aVar[$key]); 
      }
      foreach($aVar as $key => $value){
       $$key = $aVar[$key];
       unset($aVar[$key]); 
      }
      $aVar = null;
      $format = new simpleTplFormat(); //Formatierungsobjekt, wird im Template dann zB mit $format->geld($betrag) aufgerufen 
      include($this->sTplDir.$sTpl);
   }
   ob_flush();
  }
  
}



 /**
 * simpleTplFormat

 * @package simpleTpl
 * 
 * In dieser Klasse können beliebige öffentliche Funktionen zur Formatierung hinterlegt werden 
 */
class simpleTplFormat {
  
  public function geld($fBetrag) {
    if(is_numeric($fBetrag)) {
      return number_format($fBetrag, 2, ',', '.'); 
    } else {
      return(''); 
    }
  }
  public function datum($iTime) {
    if(is_numeric($iTime)) {
      return(date("d.m.Y",$iTime));
    } else {
      return(''); 
    }
  }
  public function datumvoll($iTime) {
    if(is_numeric($iTime)) {
     return(date("d.m.Y, H:i:s",$iTime));
    } else {
     return(''); 
    }
  } 
}

?>

Dann hier mal eine beispielhafte index.php:

<?php
 /**
 * index.php
 * @package homepage
 */
class Main {
  protected $oTpl = null;

  public function __construct() {
    require_once('./simpleTpl.class.php'); //Pfad zu simpleTpl
    $this->oTpl = new simpleTpl();
    $this->execute();
  }
  
  protected function execute() {
    $time = microtime(true);
    $this->aData = array();
    $this->oSys->oTpl = new simpleTpl();
    $this->oSys->oTpl->setTplDir('./templates/');
    $sAction = '';
    if(isset($_GET['action'])) {
      $sAction = $_GET['action'];
    }
    if(isset($_POST['action'])) {
      $sAction = $_POST['action'];
    }
    switch($sAction) {
        case 'download':
          require_once('./download.class.php');
          $oStart = new Download($this->oTpl);
        break;
       //hier kommen noch weitere Möglichkeiten
        default: //Das ist der Standard wenn keine Action kommt -> Startseite.
          require_once('./start.class.php');
          $oStart = new Start($this->oTpl);
        break; 
      }
      $this->oTpl->assign('requesttime', round(microtime(true)-$time,4).' Sekunden');
      $this->oTpl->assign('freespace', round(memory_get_peak_usage(true)/1024/1024, 3).'Mb');
      $this->oTpl->display('main.tpl');
  }
}
$oMain = new Main();
?>

Wenn ich also irgendeinen Link oder ein Form habe gebe ich entweder im Link index.php&action=xyz mit oder packe ins Form einen hidden input mit Namen action und xyz als Value.

Hier mal exemplarisch für die Startseite:

<?php
 /**
 * start.class.php
 * @package homepage
 */
class Start { //die Startseite mit Willkommensnachricht etc. 
  protected $oTpl;
  public function __construct($oTpl) {
    $this->oTpl = $oTpl;
    $this->execute();
  }
  
  protected function execute() {
    $this->oTpl->assign('template', 'start.tpl');
    $this->oTpl->assign('name', 'Willkommen auf Blablub');
  }
}
?>

Mit diesem ganzen Gedöhns ist noch nicht eine Zeile HTML an den Browser gegangen, die eigentliche Ausgabe steckt dann in den Templates. Dazu habe ich eine main.tpl in der ich dann die anderen Templates je nach Bedarf nachlade:

<? include($this->sTplDir.'header.tpl'); ?>
<div class="container">
<div class="menu">
<? include($this->sTplDir.'menu.tpl'); ?>
</div>
<div class="main">
  <?='<h2>'.$name.'</h2><br /><br />'?>
<? include($this->sTplDir.$template); ?>
<br />
<? include($this->sTplDir.'footer.tpl'); ?>

In dem Moment, wo ich in der start.class.php die Variable Template auf start.tpl setze und in der index.php display() aufrufe, zieht er sich also in der main.tpl in der dritten Zeile von unten den Inhalt von start.tpl. Header.tpl, footer.tpl und menu.tpl werden auf der Seite immer mit eingebunden, deshhalb stehen sie hier fest mit drin. <?='xyz'?> ist abgekürztes PHP für echo('xyz') (das muss nicht jeder Server unterstützen, sollten aber die meisten). Die Templates enthalten also natürlich auch PHP, das dient aber nur dazu die übergebenen Variablen die die Templateklasse setzt auszugeben.
Egal welches Framework oder welche Templateengine du dir anschaust, letztendlich läuft es immer so ähnlich: du hast ein Templateobjekt, das lädt das Template nach, setzt Variablen und gibt die ganze Geschichte aus. Der einzige Unterschied zwischen den ganzen Templateengines ist letztendlich nur die Sprache die im Template genutzt wird (ich habe nie so ganz verstanden warum es für einen Templatedesigner von Vorteil sein soll, eine eigene Templatesprache zu lernen wenn er als Templatesprache gleich PHP nutzen kann, mehr als if/else, foreach, echo und ein bisschen Stringmanipuliererei braucht man eigentlich selten im Template). Die Templateengines größerer Frameworks haben natürlich deutlich mehr Funktionen als meine popelige Klasse. Die validieren dir auf Wunsch noch den Input im Browser, bauen dir Selects zusammen usw.

Ich hoffe mal das hilft dir ein bisschen weiter.

EDIT: Achso, und Tabellen sind vollkommen OK wenn du sie für das einsetzt, wozu sie da sind: Daten tabellarisch auszugeben.

 

[FredHoff]

Es gibt News von der Front.

Da ich nicht wirklich weiß, wie ich weiter vorgehen soll, habe ich versucht Mambokurts Code nach zu vollziehen, nach gefühlten 15-25 Zeilen hörte es dann aber auch auf und wollte einfach nicht in den Schädel. "Mal 'ne Nacht drüber schlafen" war auch nicht von Erfolg gekrönt.

Durch Framework-Dokus steige ich dann erst recht nicht - vermute ich.
Template-Engine ist, glaube ich, noch ein Schritt zu früh, den würde ich gerne nach den Formular-Validatoren machen.
Wenn ich das Rad nicht neu erfinden soll, Frameworks aber zu schwer sind - was soll ich dann machen? Irgendwie muss ich ja lernen..

Also habe ich angefangen in meiner index.php rumzubiegen, sodass ich jetzt pageIDs auf html-dokumente schieben kann (localhost/pages/startseite.html ist jetzt mit Hilfe von $_GET auch unter localhost/index.php?page=startseite erreichbar).

Wie geht's weiter?
Rewriting.........
...kann ja eigentlich nicht so schwer sein, das bisschen Syntax. Pfff, Pustekuchen.

Sporadisch greift meine Regel
localhost/index.php => localhost/index.php?page=startseite
im Chrome, dann plötzlich nicht mehr. Apache neu gestartet, Chrome neu gestartet, Dienst gekillt, Backup .htaccess rekonstruiert. Kein Plan. Firefox gestartet, geht. OK, was ist mit Chrome? Immernoch nicht, Firefox auch nicht mehr. Alles neugestartet und nur so komische Fehlerbilder, jetzt werde ich stattdessen auf meine selbst-erstellte 404 geleitet, hä?! Caches gelöscht, Cookies aktiviert(und wahrscheinlich die Hälfte bei den Cookies vergessen), no Chance.

index.php

<?php
	$page = isset($_GET["page"]) ? $_GET["page"] : "default";
	$pc = getPage($page);
?>

.htaccess

RewriteEngine On
RewriteCond %{QUERY_STRING} ^startseite.html$
RewriteRule ^index\.php$ /index.php?page=startseite [R=301,L]

Bevor ich jetzt auf Amazon geschickt werde
Mein Grundlagen-Buch zur Erstellung dynamischer Webseiten von der Uni Hannover habe ich übrigens durch. Die Zeit hätte man sich auch sparen können..

Was jetzt? Währenddessen probiere ich mich am Schreiben von Funktionsbibliotheken.


Merci

 

[Daaron]

Durch Framework-Dokus steige ich dann erst recht nicht - vermute ich.

Es sind Dokumentationen, und kein purer Code mit n paar Kommentaren. Da ist schon ein großer Unterschied dazwischen...

Der Zaubertrick an einem guten Framework ist doch, dass dir die DETAILS der verschiedenen Funktionen ziemlich egal sein können. Du willst eine Datenbank-Abfrage nach einem bestimmten Query-String mit 2 WHERE-Parametern machen? Dann könnte sowas in der Art hier funktionieren:
$this->Database->prepare("SELECT * FROM users WHERE username = ? OR email=?")->execute($username,$mailaddr);
Dir muss dabei nicht klar sein, wie die zugrunde liegende Datenbank-Klasse funktioniert. Du weißt nur, wie du eine Abfrage vorbereitest und mit Parametern fütterst.

Wenn ich das Rad nicht neu erfinden soll, Frameworks aber zu schwer sind - was soll ich dann machen? Irgendwie muss ich ja lernen..

Schnapp dir ein Open Source CMS mit guter Code-Qualität (also: nicht Wordpress!) und guck, wie es da gelöst ist.

Was ist denn dein Ziel?
Willst du programmieren lernen? Dann hilft eh nur, sich von Grund auf durch anständige Tutorials zu ackern und sich eben direkt mit guter Code-Qualität zu umgeben.
Willst du tatsächlich eine Seite ans Netz bringen? Nimm ein CMS und arbeite dich da ein. Kein Sinn, das Rad neu zu erfinden. Alles, was du in nächster Zeit schreiben könntest, hat jemand anderes schon viel besser geschrieben. Du kannst nur zusehen und lernen. Wenn du dann tatsächlich mal was besseres/neueres hin bekommst, dann solltest du selbiges natürlich dem ursprünglichen Projekt wieder zufließen lassen.

(localhost/pages/startseite.html ist jetzt mit Hilfe von $_GET auch unter localhost/index.php?page=startseite erreichbar).

Durchaus nützlich, wobei es deutlich sinnvoller wäre, PHP-Dateien einzubinden statt statischer HTML-Dateien. Aber: Du musst hier auch noch gucken, dass du keine Directory Traversal - Lücken reißt. Das geht bei solchen Include-Geschichten per GET-Parameter schnell..

Bevor ich jetzt auf Amazon geschickt werde
Mein Grundlagen-Buch zur Erstellung dynamischer Webseiten von der Uni Hannover habe ich übrigens durch. Die Zeit hätte man sich auch sparen können..

Ah komm, Uni-Lehrbücher sind doch oftmals hoffnungslos veraltet und taugen wirklich nur für Grundlagen und grobe Einblicke. Das ist doch kein Vergleich zu einem wirklich aktuellen Buch... Gibt bestimmt was gutes von Galileo Books.

 

[mambokurt]

Es gibt News von der Front.

Da ich nicht wirklich weiß, wie ich weiter vorgehen soll, habe ich versucht Mambokurts Code nach zu vollziehen, nach gefühlten 15-25 Zeilen hörte es dann aber auch auf und wollte einfach nicht in den Schädel. "Mal 'ne Nacht drüber schlafen" war auch nicht von Erfolg gekrönt.

Wie die Templateklasse das intern regelt, brauchst du eigentlich nicht zu wissen. Für dich wäre nur relevant:

//in der Index.php
require_once('./simpleTpl.class.php'); //Pfad zu simpleTpl
$this->oTpl = new simpleTpl();
$this->oSys->oTpl->setTplDir('./templates/');
//dann aufruf von 'unterpunkten'
require_once('./download.class.php'); //Klasse des Unterpunktes laden
$oStart = new Download($this->oTpl); //neues Objekt des Unterpunktes erstellen und Templateobjekt mit rübergeben, damit du im Unterpunkt Zugriff darauf hast
$this->oTpl->display('main.tpl'); //gesammelte Templatedaten aus aktueller und aufgerufenen Klassen ausgeben

//in der Klasse die für den Unterpunkt zuständig ist:
$this->oTpl->assign('template', 'start.tpl'); //entsprechendes Template des Unterpunktes nachladen
$this->oTpl->assign('name', 'Willkommen auf Blablub'); //eien Variable im Template setzen auf einen bestimmten Wert

//im Template:
<?=$name?> //gibt den Wert von Name (also Willkommen auf Blablub) aus

Du musst dich da jetzt auch nicht versteifen, das sollte nur ein Beispiel sein wie es normalerweise funktioniert wenn man Darstellung und Programm getrennt halten will.

Wenn du erstmal simpel anfangen willst und nur einfache Variablen wie Strings oder Zahlen ans Template geben willst, tut es auch ein file_get_contents() auf eine Html Datei, in der du Platzhalter wie {variable} verwendest. Dann kannst du da anschließend per str_replace die Werte austauschen.

$template = fiel_get_contents('meineSeite.html');
$variablen = array('variable1' => 'hui', 'variable2' => 'klatsch'); //das sind unsere Variablen
$template = str_replace(array_keys($variablen), array_values($variablen), $template); //Variablen nach Name im Template ersetzen
echo($template);
//meine Seite.html:
<html>
<body>
Hallo und willkommen auf {variable1}
</body>
</html>

Durch Framework-Dokus steige ich dann erst recht nicht - vermute ich.
Template-Engine ist, glaube ich, noch ein Schritt zu früh, den würde ich gerne nach den Formular-Validatoren machen.
Wenn ich das Rad nicht neu erfinden soll, Frameworks aber zu schwer sind - was soll ich dann machen? Irgendwie muss ich ja lernen..

Frameworks bzw deren Templateengines sind aber auch dokumentiert und man findet dazu auch mal Tutorials im Netz. Vielleicht wäre ein Framework für dich sogar genau das richtige, das nimmt dich ein bisschen bei der Hand und schreibt dir bestimmte Sachen einfach vor. Nachteil bei den Templateengines der meisten Frameworks ist halt, dass du noch zusätzlich eine Templatesprache lernen musst.

Wie geht's weiter?
Rewriting.........
...kann ja eigentlich nicht so schwer sein, das bisschen Syntax. Pfff, Pustekuchen.

Sporadisch greift meine Regel
localhost/index.php => localhost/index.php?page=startseite
im Chrome, dann plötzlich nicht mehr. Apache neu gestartet, Chrome neu gestartet, Dienst gekillt, Backup .htaccess rekonstruiert. Kein Plan. Firefox gestartet, geht. OK, was ist mit Chrome? Immernoch nicht, Firefox auch nicht mehr. Alles neugestartet und nur so komische Fehlerbilder, jetzt werde ich stattdessen auf meine selbst-erstellte 404 geleitet, hä?! Caches gelöscht, Cookies aktiviert(und wahrscheinlich die Hälfte bei den Cookies vergessen), no Chance.

index.php

<?php
	$page = isset($_GET["page"]) ? $_GET["page"] : "default";
	$pc = getPage($page);
?>

Wenn ich das richtig sehe willst du per Rewriterule page=startseite an die url hängen? wie wäre es denn wenn du im PHP das default einfach auf Startseite setzt? Von Rewrite Rules würde ich in deinem Fall ersteinmal die Finger lassen, wenn du die ganze Geschichte in PHP soweit hast, dass sie funktioniert kannst du die nächste Front eröffnen.

 if(isset($_GET['page'])) {
$sAction = $_GET['page'];
}
if(isset($_POST['page'])) {
$sAction = $_POST['page'];
}
switch($sAction) {
case 'xyz':

break;
//hier kommen noch weitere Möglichkeiten
default: //Das ist der Standard wenn keine Action kommt -> Startseite.
require_once('./start.class.php');
$oStart = new Start($this->oTpl);
break;
}

Sieh nur zu dass du da bei includes und ähnlichem immer den Parameter Page auf bestimmte Werte prüfst und dann entsprechend includest, auf keinen Fall '/Pfad/zur/Datei/'.$_GET['pfad'].'.html' oder solche Scherze. Schön die Idiotentour gehen und pro möglichem Wert von page ein case ins Switch einfügen und dann hart die Seite einbinden.