PHP Frage zu Einstiegs- und Unterseiten mit identischem Layout

Domi83

Rear Admiral
Registriert
Feb. 2010
Beiträge
5.202
Hallo Leute, ich hoffe ich kann es einigermaßen erklären was mein Wunsch ist...
Also ich habe eine Einstiegsseite "index.php" wo mein Basis-Content ausgegeben wird in einem DIV Block. Wenn ich jetzt auf "index.php?site=blubb" gehe, soll sich ja in erster Linie ja nur der Content verändern, wobei Title und Meta Daten wäre natürlich auch toll :)

Jetzt habe ich zwar immer mal wieder an kleinen Unterseiten von uns etwas verändert, aber nie ordentlich etwas aufgebaut. Es gibt für fast jede Seite eine Datei (index.php, impressum.php, kontakt.php etc.) und da muss ich ja immer zusehen dass das Layout identisch bleibt. Daher jetzt die Basis-Frage wie man das schöner machen kann?!

Es gibt Frameworks wie Smarties etc., womit man Layouts aufbauen kann. Aber damit habe ich noch nie gearbeitet und bevor ich Euch dann nerve wie man das alles aufbaut und ihr dann verzweifelt, falte ich mal an meine oben erwähnten Vorhaben fest.

Meines Wissens geht das mit einem handelsüblichen "switch, case" oder irre ich mich da jetzt?
Problematik ist ja nur das ich beim switch ja wie gesagt, nicht nur den Content sondern auch Daten vom Head aktualisiert haben möchte, und darum komme ich auf Euch zurück und hoffe auf eine kleine Information / hilfe wie man das aktuell so realisiert.

Ich hätte sonst einen Unterordner erstellt, darin befindet sich eine impressum.php und sobald index.php?site=impressum geöffnet wird, sollen die Daten aus der impressum.php included oder required werden, ist der Ansatz korrekt oder macht man das heute schon anders? :(

Gruß, Domi
 
Gut, fangen wir anders an...

1.) Das hätte man auch anders rüber bringen können, denn der Ton macht die Musik!!

2.) Die Seite existiert schon, ich will eine vorhandene Seite umbauen und die Inhalten kann ich NICHT in ein CMS exportieren, da es sich um mehr als 30.000 Unterseiten handelt.

Und dieses Topic habe ich schon gesehen... Dazu kommt, dass ich CMS wie Typo3, Joomla, Contao etc. kenne, es funktioniert aber nicht.

Nachtrag: Ich korrigiere mich, es funktioniert nicht, ist nicht ganz richtig. Aber ich wüsste nicht wie ich 30.000 Unterseiten in z.B. Contao importieren soll, damit alles genau 1zu1 so funktioniert, wie es aktuell der Fall ist.
 
Zuletzt bearbeitet:
So wie du dir das vorstellst geht es, einfach Switch-Case. Die Meta Daten kannst ja auch in ein Switch Case mit PHP einbauen. Einfach immer PHP auf und zu machen. Also zB.

<?
switch ()
case 'impressum':
?>
META1
<?
break;
case '...':
?>

etc

Musst beim Switch nur den Header auswerten, dazu gibt aber auch fertige PHP Funktionen. Glaub das wird sogar in einer Variable gespeichert was an den Header angehangen wurde.

Also einfach den Inhalt und den Meta Tag in ein Switch Case. Allerdings musste dann immer nen Reload ausführen damit er das auch abarbeitet.

Auch wenn die nicht mehr so gerne gesehen sind: iframe ist bei sowas doch recht praktisch ^^
 
Zuletzt bearbeitet:
Die Sache mti dem Switch Case ist schon in Ordnung, das kannst du dann auch auf den Header anwenden.
Ggf. kann dir aber auch einfach ein MVC weiterhelfen, statt direkt mit CMS zu werkeln, siehe z.B. symfony.
 
Domi83 schrieb:
Ich hätte sonst einen Unterordner erstellt, darin befindet sich eine impressum.php und sobald index.php?site=impressum geöffnet wird, sollen die Daten aus der impressum.php included oder required werden, ist der Ansatz korrekt oder macht man das heute schon anders? :(
So wird's auch heute noch gemacht. Moderne CMS/Frameworks realisieren das im Detail anders als du dir das jetzt wahrscheinlich vorstellst - aber für deine Zwecke genügt dein Ansatz.

Du musst natürlich bestimmte Sicherheitsüberprüfungen machen: Existiert die Datei auch wirklich, erhält der Parameter für den Dateinamen nur Buchstaben und keine anderen Zeichen, sowas halt.
 
Okay, symfony schaue ich mir mal an und teste mal :)
Ich würde auch mit einem CMS arbeiten, für Kunden von mir persönlich baue ich Seiten mit Joomla oder Contao auf, aber hier in der Firma (Hauptberuf) haben wir halt eine existierende Seite wo diverse (nicht alle) Inhalte aus einer Datenbank gelesen wird. Und wenn es hieß, mach da oben links mal den Namen von einem Ort hin, lasse ich nur die Variable von der Datenbank auslesen und gut ist.

Das geht (meines Wissens) in einem CMS nicht mal so eben.
Zumal ich in der Datenbank so etwas wie title, alias, text, rufnummer, faxnummer etc. drin stehen habe, dass ist nicht wie in einem CMS wo dann der Content aus einem mediumtext besteht. Zumindest glaube ich das es ein mediumtext ist... und da müsste ich dann halt alles irgendwie anpassen, und das für mehr als 10.000 Unterseiten ;)

Sonst finde ich Contao als CMS recht mächtig... genauso wie Wordpress oder Joomla, die Systeme finde ich auch gut. Jedes auf seinem Gebiet, aber für mich irgendwie nicht das passende. Zumal ich mir dann eigene Module oder so etwas bauen müsste, und so fit bin ich dann auch nicht in der Thematik.

Nachtrag: @siconize, so wie ich das in den Datenbanken von dem einen oder anderen CMS gesehen habe, wird ja ein alias aus der Datenbank überprüft und dann die Inhalte (MediumText, Text) nur noch ausgegeben... zumindest war mir so :)

Nachtrag2: Ich versuche das für Daaron mal ein wenig aufzuschlüsseln und weiter zu spinnen... Also ich bin gerade dabei, einmal einen internen Bereich für meine Kollegen und mich aufzubauen, darin wollte ich Neuigkeiten eingeben wie (kollege, xy ist krank) oder auch einen Terminkalender (da gibt es bestimmt coole Module). Dazu kommt aber auch, dass ich eine Domain-Tabelle gebaut habe die für mich aus der MySQL Datenbank alle Domains ausließt, die ich dort eingetragen habe und auflistet.

Des weiteren haben wir eine Domain die alle Städte aus Deutschland beinhaltet, dazu sind dann die Ämter / Behörden mit aufgelistet. Es gibt eine Tabelle die nur für die Orte zuständig ist, wenn also in der URL via GET nach "muenchen" gefragt wird, wird in der Tabelle nach dem passenden Alias gefragt und Anschrift, Ort, Plz, Rufnummer, Faxnummer, Email und Internetseite ausgegeben. Was davon möglich ist.

Ich hoffe man kann ein wenig nachvollziehen wo die Problematik bei mir liegt, "mal eben" Inhalte von einer bestehenden Seite in ein CMS zu migrieren.
 
Zuletzt bearbeitet:
30.000 Unterseiten = 30.000 switch abfragen? wartung & übersicht wäre nicht schön.
da wäre es wirklich einfach in ein CMS zu migrieren ...
 
Symfony? Oh je. Schau dir wenn, Laravel 3 (nicht 4) an. Wesentlich weniger komplex als Symfony, und immer noch wesentlich komplexer als das was du vermutlich benötigst. :)

three.laravel.com/docs

Domi83 schrieb:
Nachtrag: @siconize, so wie ich das in den Datenbanken von dem einen oder anderen CMS gesehen habe, wird ja ein alias aus der Datenbank überprüft und dann die Inhalte (MediumText, Text) nur noch ausgegeben..

Du spricht von "Eigenen Seiten" (die nicht als Datei / PHP vorliegen sondern rein als Daten in der DB), oder? Aber das Konzept scheint bei dir ja nicht zu greifen.
 
Zuletzt bearbeitet:
Jemandem zu raten auf ein altes Softwareframework aufzubauen, bei dem absehbar ist, dass dann irgendwann die Weiterentwicklung gestoppt wird?
Imho ein extrem schlechter Rat.

Und dann auch noch ein spezielles Framework empfehlen, es ist ja nicht so dass es in PHP mind. 20 sehr bekannte gibt. Der nächste kommt dann mit X, darauf einer mit Y und jeder empfiehlt seinen Liebling...

Der TE sollte lieber mal nach PHP Microframeworks suchen, das scheint am ehesten zu sein, wad er sucht.
 
Okay, jetzt habe ich vermutlich etwas durcheinander geworfen... das mit dem switch / case ist für die statischen Seiten die NICHT aus einer Datenbank abgefragt werden, wie z.B. das Impressum. Es handelt sich um unsere Fremdenverkehrsbüro Seite, diese wurde ungefähr 2008 aufgebaut, dann wurde immer wieder mal geflickt um umgebaut etc., sie wurde aber nie wirklich richtig neu aufgebaut.

Das versuche ich jährlich immer wieder, bis Chef mit dem Wunsch ankommt das ein anderes Thema eine höhere Priorität hat.
Einige Unterseiten wie das Impressum sind statisch und es existiert auch eine impressum.php Datei dafür, andere Unterseiten wie die Orte selbst besitzen eine Ausgabe Datei z.B. "ausgabe.php?ort=muenchen", also wird in der Tabelle nach dem passenden Alias gesucht und anschließend alles aus der Zeile gelesen... id, ort, bundesland_id, anschrift, text, rufnummer, faxnummer, email, meta_key, meta_desc etc., und um diese Daten geht es... da wüsste ich nicht im Ansatz wie ich das ins Contao migrieren sollte.

Ich hoffe ich konnte das ganze jetzt etwas genauer erklären und aufschlüsseln.
Den internen Bereich den ich bauen will, habe ich auch ganz simple aufgebaut, nach einem ähnlichem Schema... Es gibt eine Eingabemaske für bestimmte Daten (Email Empfänger), wo man Email, Name, und Zusätze eintragen kann, auf einer Unterseite kann man dann diese Leute mit einem Klick personalisiert anschreiben und fertig ist der Lack.
 
Domi83 schrieb:
Es gibt Frameworks wie Smarties etc., womit man Layouts aufbauen kann. Aber damit habe ich noch nie gearbeitet und bevor ich Euch dann nerve wie man das alles aufbaut und ihr dann verzweifelt, falte ich mal an meine oben erwähnten Vorhaben fest.
Also Smarties ess ich ja eher, anstatt ich damit irgendwelchen Unsinn im Internet anstelle ;-)
Spaß Beiseite: Mit Smarty erstellt Du Templates, womit es möglich es, Programmcode (PHP) und Ausgabe (HTML/CSS) voneinander zu trennen. Macht Sinn, wenn es öfters Änderungen am Layout gibt. Außerdem wirds dann bei einer gewissen Projektgröße einfach etwas übersichtlicher.

Blackbenji schrieb:
30.000 Unterseiten = 30.000 switch abfragen? wartung & übersicht wäre nicht schön.
da wäre es wirklich einfach in ein CMS zu migrieren ...
Stimmt natürlich, wobei es ja nicht heißt, dass jede Unterseite auch zwangsweise ein eigenes Include benötigt.

siconize schrieb:
Symfony? Oh je. Schau dir wenn, Laravel 3 (nicht 4) an. Wesentlich weniger komplex als Symfony, und immer noch wesentlich komplexer als das was du vermutlich benötigst. :)
Rein aus Interesse: Warum nicht 4?

BTT: Warum auch immer sofort ein CMS empfohlen wird, ohne zu wissen, wie überhaupt die Anforderungen an die Seite aussehen ;-)

Vielleicht ein anderer Ansatz ohne ein monströse Switch-Anweisung:

impressum.php direkt aufrufen und darin die gewünschten Basis- und Layout-Elemente inkludieren:

PHP:
<?
include('/includes/header.php');

include('/includes/navigation.php');

// {content}

include('/includes/footer.php);
?>

Vorteil gegenüber einem "Master-Template": Sollten Unterseiten zusätzliche JS- oder CSS-Dateien benötigen, kannst Du das einfach in der jeweiligen Datei zusätzlich angeben.
 
ice-breaker schrieb:
Jemandem zu raten auf ein altes Softwareframework aufzubauen, bei dem absehbar ist, dass dann irgendwann die Weiterentwicklung gestoppt wird?

L3 wird de facto nicht mehr weiter entwickelt (es gibt wohl noch Bugfixes).

ice-breaker schrieb:
Imho ein extrem schlechter Rat.
Deine Meinung in allen Ehren, aber hast du dich mit der Thematik beschäftigt? Ein Framework, bei dem Bugs noch gefixt werden, sollte für die Zwecke des TEs genügen. Er benötigt nicht die neueste Technologie. Abgesehen davon heißt "alt" hier: Monate alt, nicht Jahre. Mehr siehe unten.

ice-breaker schrieb:
Und dann auch noch ein spezielles Framework empfehlen, es ist ja nicht so dass es in PHP mind. 20 sehr bekannte gibt. Der nächste kommt dann mit X, darauf einer mit Y und jeder empfiehlt seinen Liebling...
Ich habe die Büchse der Pandora nicht geöffnet :D Jemand warf Symfony in den Ring. Der TE ging darauf ein. Da war das Übel schon geschehen und jemand musste versuchen, ihn von Symfony abzubringen.

ice-breaker schrieb:
Der TE sollte lieber mal nach PHP Microframeworks suchen, das scheint am ehesten zu sein, wad er sucht.
Das klingt sinnvoll. Laravel 3 könnte für ihn ebenfalls zu viel Overhead haben.

--

rephluX schrieb:
Rein aus Interesse: Warum nicht 4?

L3 hat auf mich den Eindruck gemacht, das am schnellsten zu erlernende Framework zu sein. Ich habe mich jetzt nicht mit allen großen im Detail beschäftigt, aber das ist mein Eindruck.

L4 hat im Vergleich zu 3 einen doch recht deutlichen Sprung gemacht und ist meiner Meinung nach deutlich schwieriger zu erlernen. L4 setzt z.B. ganz auf Composer - lässt sich in L3 einbinden, ist aber nur optional. L3 lässt sich somit leichter installieren, ist auch viel kleiner und viel besser überschaubar. Man kann ziemlich schnell verstehen wie das Framework funktioniert und falls gewünscht modifizieren. L4 ist da mehr wie Symfony und würde Domi83 mener Einschätzung nach keine Vorteile, sondern nur Nachteile bringen.
 
Zuletzt bearbeitet:
siconize schrieb:
Deine Meinung in allen Ehren, aber hast du dich mit der Thematik beschäftigt? Ein Framework, bei dem Bugs noch gefixt werden, sollte für die Zwecke des TEs genügen. Er benötigt nicht die neueste Technologie. Abgesehen davon heißt "alt" hier: Monate alt, nicht Jahre. Mehr siehe unten.

Auch Bugs werden nicht ewig gefixxt und früher oder später wird es dann ganz eingestellt. Deswegen finde ich es fast schon fahrlässig eine veraltete Software zu empfehlen, an der nicht mehr weiterentwickelt wird und die nur noch Bugfixes bekommt, denn mit denen ist es auch irgendwann vorbei. Und früher oder später ist da immer Ende, das wird dann nur ganz plötzlich entschieden, eventuell wird in nem halben Jahr entschieden, dass es nur noch 1 Jahr Bugfixes gibt, oder ähnliches.
Keine alte Software wird ewig weitergepflegt, spätestens wenn kaum noch jemand Laravel 3 nimmt, wird man über das Ende von Bugfixes nachdenken. Das 4er ist nun zwar gerade erst rausgekommen, trotzdem wird man das 3er irgendwann fallen lassen, auf alte Software setzen ist immer eine schlechte Idee.

siconize schrieb:
L4 hat im Vergleich zu 3 einen doch recht deutlichen Sprung gemacht und ist meiner Meinung nach deutlich schwieriger zu erlernen. L4 setzt z.B. ganz auf Composer - lässt sich in L3 einbinden, ist aber nur optional.
Composer? Die beste Software für PHP seit Jahren, hat das Management fremder Libraries extrem vereinfacht, also als Nachteil will ich das nicht sehen. Endlich kann jede Lib per Autoload geladen werden und es gibt nicht mehr einzelne Entwickler die die Namenskonventionen verweigern und man dann rumtricksen muss, um diese autoloadbar zu machen. Ein Aufruf auf der Kommandozeile und ich habe ne fremde Library "installiert", also schwierig ist da gar nix.
 
Zuletzt bearbeitet: (fixed missing closing tag in quote)
Der sinnvollste Ansatz wäre: Nutze deine GET-Parameter als Alias für eine Datenbanksuche. Lager in der Datenbank eine Tabelle deiner Unterseiten mit all ihren möglichen Variationen gegenüber dem Master-Template. Mögliche Spalten wären:
- Meta Description
- Meta Keywords
- Title
- zusätzlicher Headercode
- welches PHP-Script den Content-Code enthält

Jetzt baust du in der index.php als allererstes deine DB-Verbindung auf und guckst, welche Unterseite anhand ihres Alias angefragt wird. Somit hast du alle Informationen zusammen, mit denen du ein durchaus brauchbares Ergebnis erzielen kannst.

Nachträglich jetzt noch ein Framework unter die Daten zu schrauben wäre wohl genauso Overkill wie ein Wechsel auf ein CMS. Da schreibst du dann 80% deines Codes neu...
 
ice-breaker schrieb:
Auch Bugs werden nicht ewig gefixxt und früher oder später wird es dann ganz eingestellt. Deswegen finde ich es fast schon fahrlässig eine veraltete Software zu empfehlen, an der nicht mehr weiterentwickelt wird und die nur noch Bugfixes bekommt
Wenn du L4 empfiehlst, hast du das selbe Problem, nur später. Ich weiß ehrlich gesagt nicht wie ich mich ausdrücken soll ohne dass es zu harsch klingt, aber ich habe keine wirklichen Argumente herausgelesen - nur allgemeine Aussagen à la "keine Updates -> schlecht". L3 ist nicht besonders weit verbreitet. Die Chance, dass für ältere Versionen Sicherheitslücken entdeckt und publiziert werden, dürfte stark gegen 0% tendieren. L3 ist sehr solide so wie es ist; etwas anderes als Bugfixes wird Domi83 nicht benötigen für seine Situation.

ice-breaker schrieb:
auf alte Software setzen ist immer eine schlechte Idee
Ersetze "immer" durch "in der Regel" und ich stimme dir zu. Ich bin kein PHP Guru und auch kein Laravel Experte - aber L4 ist meiner Auffassung nach gegenüber L3 eine neue Ausrichtung. Konkrete, eigene neue Features und Vorteile fallen gering aus im Vergleich zu den Änderungen an der Architektur (Composer ausgenommen - ist ja kein Teil von Laravel und auch für L3 verfügbar). Den zusätzlichen Lernaufwand empfinde ich dahingegen als durchaus erheblich.

ice-breaker schrieb:
Composer? Die beste Software für PHP seit Jahren, hat das Management fremder Libraries extrem vereinfacht, also als Nachteil will ich das nicht sehen. Endlich kann jede Lib per Autoload geladen werden und es gibt nicht mehr einzelne Entwickler die die Namenskonventionen verweigern und man dann rumtricksen muss, um diese autoloadbar zu machen. Ein Aufruf auf der Kommandozeile und ich habe ne fremde Library "installiert", also schwierig ist da gar nix.
Wer stellt die Vorteile von Composer in Abrede? Ich jedenfalls nicht. Composer wird dem TE nicht helfen seine Probleme zu lösen, es sein denn du suchst ihm passende Packages heraus. Und selbst dann, kann er Composer auch in L3 nutzen, dafür gibt es bereits fertige Bundles.
 
Zuletzt bearbeitet:
Zurück
Oben