Bild einfügen mit PHP-Script Einstellungen

[Conny]

Moin Gemeinde,

ist es möglich beim laden einer Seite jedesmal wenn die Seite erneut aufgerufen wird ein anderes Titelbild zu laden?

Ich stelle mich das also so vor, daß es einen Ordner mit -sagen wir mal- 20 verschiedene, aber gleich große Bilder gibt.
Jedes mal wenn eine Seite aufgerufen wird sucht sich das Script wahllos -oder nach einem bestimmten Muster- ein Bild aus diesem Ordner aus, welches dann mit geladen wird.

Es geht hier reell um einem Bild im Header-Bereich einer Seite. Der Header ist auf allen Seiten dieser Webseite gleich und wird durch einen PHP-Include in der jeweiligen Seite geladen.
Nun soll sich also in diesem Header das Titelbild beim Aufruf einer nächsten Seite ändern...

Die Seite ist noch in der Entwicklung, eine erste Probe ist dennoch online: KLICK

cu
Conny

[Conny]

Hi,

habe auch mal ein Wenig gesucht, habe auch einiges gefunden, meistens alles zu viel, zu groß, zu viele Features.

Habe dann aber ein Script zusammen 'gestript' bis zur winzig Größe.
Das Ergebnis ist wie folgt:
Ordner anlegen in der die Bilder die gewechselt werden liegen.
Diese Bilder durchnummerieren ( 1.jpg, 2.jpg usw.)
Das Script im gleichen Ordner ablegen und auf der Seite per include aufrufen.

Scriptinhalt ist wie folgt:

QUELLTEXT

<?php

// Zahl der Bilder die sich im Ordner befinden
$total = "3";
$file_type = ".jpg";

// Pfad zum Ordner
$image_folder = "pics/headers";
$start = "1";
$random = mt_rand($start, $total);
$image_name = $random . $file_type;
echo "<IMG SRC=\"$image_folder/$image_name\" ALT=\"$image_name\" />";
?>

Lokal funktioniert es schon mal

cu
Conny

[Thomas]

Die einzige Optimierung wäre noch, den Verzeichnisinhalt dynamisch einzulesen, dann könntest du die möglichen Bilder einfach durch die Dateien im Verzeichnis festlegen und müsstest nicht zusätzlich das Skript ändern, wenn du z. B. ein weiteres Bild anzeigen möchtest. Auch wären die Dateinamen wahlfrei.

So wie du es jetzt machst, ist es übrigens egal, wo das Skript liegt, da der Bilderpfad unabhängig vom Skriptpfad festgelegt wird.

Um noch eine neue Idee in den Ring zu werfen: Du könntest das Skript auch das Bild selbst zurückliefern lassen (mittels Dateiauslesen und header()).

[Conny]

Die einzige Optimierung wäre noch, den Verzeichnisinhalt dynamisch einzulesen, dann könntest du die möglichen Bilder einfach durch die Dateien im Verzeichnis festlegen und müsstest nicht zusätzlich das Skript ändern, wenn du z. B. ein weiteres Bild anzeigen möchtest. Auch wären die Dateinamen wahlfrei.

DAS wäre sicherlich eine Optimierung!
Aber da setzt Du bei mir vllt. zuviel voraus

So wie du es jetzt machst, ist es übrigens egal, wo das Skript liegt, da der Bilderpfad unabhängig vom Skriptpfad festgelegt wird.

Ja, ist es auch, der Übersichtlichkeit halber habe ich das für mich so festgelegt, um alles beisammen zu haben.

Um noch eine neue Idee in den Ring zu werfen: Du könntest das Skript auch das Bild selbst zurückliefern lassen (mittels Dateiauslesen und header()).

?

cu
Conny

[Thomas]

Die einzige Optimierung wäre noch, den Verzeichnisinhalt dynamisch einzulesen, dann könntest du die möglichen Bilder einfach durch die Dateien im Verzeichnis festlegen und müsstest nicht zusätzlich das Skript ändern, wenn du z. B. ein weiteres Bild anzeigen möchtest. Auch wären die Dateinamen wahlfrei.

DAS wäre sicherlich eine Optimierung!
Aber da setzt Du bei mir vllt. zuviel voraus

Also auf die Schnelle:

QUELLTEXT

<script language="php">
  $pth = 'absoluter/Pfad/zu/den/Bildern';
  $img_names = array();
  if ($handle = opendir($pth)) {
    while (FALSE !== ($file = readdir($handle))) {
      if ($file != "." && $file != ".." && !is_dir($pth.'/'.$file) && preg_match('/\\.jpg$/',$file)) {
        $img_names[] = $file;
      }
    }
    closedir($handle);
  }
</script>

So müsstest du alle Dateien aus dem Verzeichnis $pth, die die Endung '.jpg' besitzen, im Array $img_names haben. Du kannst auch mal prüfen, ob die Funktion glob() auf deinen Systemen verfügbar ist, dann ginge es noch einfacher.

Um noch eine neue Idee in den Ring zu werfen: Du könntest das Skript auch das Bild selbst zurückliefern lassen (mittels Dateiauslesen und header()).

?

Auch auf die Schnelle:

QUELLTEXT

<script language="php">
  $img = [zufällig erzeugter Dateiname];
  header('Content-type: image/jpeg');
  readfile(path_loc($img));
</script>

Dieses Skript kannst du dann direkt im IMG-Tag einbinden:

QUELLTEXT

<img src="pfad/zum/skript/skript.php" alt="Zufallsbild" border="0">

Den Code habe ich mir jetzt mal spontan von der Seele geschrieben , es könnten also eventuell noch kleinere Macken drin sein, aber ich denke, die grundsätzlichen Ideen kann man erkennen.

[Auge]

QUELLTEXT

<script language="php">
   $img = [zufällig erzeugter Dateiname];
   header('Content-type: image/jpeg');
   readfile(path_loc($img));
</script>

Den Code habe ich mir jetzt mal spontan von der Seele geschrieben , es könnten also eventuell noch kleinere Macken drin sein ...

Die größte dürfte sein, dass der Code wegen deiner Umfassung mit <script>...</script> ohne Anpassungen auf den wenigsten Servern laufen wird. Die kompatibelste Angabe, die höchstwahrscheinlich überall funktioniert, ist <?php ... ?>. Benutzt du <script type="text/php">...</script> wirklich im produktiven Einsatz?

Tschö, Auge

[Thomas]

Benutzt du <script type="text/php">...</script> wirklich im produktiven Einsatz?

Nö - ich benutze <script language="php">...</script>. Und nur wenn ich kleine Code-Schnipsel einbinde, auch mal <?php ... ?>. Beides ohne Probleme. Was spricht gegen die erste Variante?

[Auge]

Benutzt du <script type="text/php">...</script> wirklich im produktiven Einsatz?

Nö - ich benutze <script language="php">...</script>. Und nur wenn ich kleine Code-Schnipsel einbinde, auch mal <?php ... ?>. Beides ohne Probleme. Was spricht gegen die erste Variante?

Ich habe die Einbindung mit <script>...</script> mit der Variante mit ASP-Tags <% ... %> verwechselt. Die Letztere ist auf Shared-Hosting-Servern oft (fast immer) abgeschaltet. Da du der erste bist, der die <script></schript>-Schreibweise praktisch einsetzt und ich der Verwechslung mit <% ... %> anheimfiel, fragte ich nach.

Öfter bekommt man die Kurz- bzw. SGML-Schreibweise <? ... ?> zu sehen, die spätestens bei XHTML wegfällt. Die letzte, die XML-Variante <?php ... ?>, ist, meiner Erfahrung nach, praktisch immer an. Weshalb ich sie auch ausschließlich verwende.

Tschö, Auge

[Thomas]

Da du der erste bist, der die <script></schript>-Schreibweise praktisch einsetzt und ich der Verwechslung mit <% ... %> anheimfiel, fragte ich nach.

Öfter bekommt man die Kurz- bzw. SGML-Schreibweise <? ... ?> zu sehen, die spätestens bei XHTML wegfällt. Die letzte, die XML-Variante <?php ... ?>, ist, meiner Erfahrung nach, praktisch immer an.

Hängt eventuell damit zusammen, dass ich PHP schon verwendet habe als es noch PHP/FI hieß, da gab es die <?php ... ?>-Form glaube ich noch nicht . Dennoch sollten beide Versionen überall funktionieren, denn normalerweise wird doch der PHP-Parser anhand der Dateiendung auf das Skript losgelassen. Und der Parser erkennt definitiv immer beide Versionen. Und solange der Parser nicht drübergelaufen ist, muss es kein gültiges HTML/XHTML/XML oder sonstwas sein. Immer erst nachher. Und dann sind die Tags eh weg. Oder versteh ich da was falsch?

[db]

...
Und der Parser erkennt definitiv immer beide Versionen.
...

Tut er nicht Thomas - und das ist gut so.

Die "Sprach Option Short-Tags" <? ?> ist tatsächlich eine solche. Und man kann sich das zunutze machen. Auf meinem lokalen Server werden die Short-Tags <? ?> nicht als PHP interpretiert. So ist es leicht möglich, Funktionen die lokal eben nicht ausgeführt werden sollen, einfach zu excluden.

Konstrukte wie
<?PHP if (!$go) { ?>
html
<?PHP } ?>

sind mit Short-Tags nicht möglich!

Deine Notationsweise mit &lt;script hat auch einen Vorteil: Keine kryptischen Anzeigen im Browser, wenn php nicht eingebunden ist.

[Thomas]

... Und der Parser erkennt definitiv immer beide Versionen. ...

Tut er nicht Thomas - und das ist gut so.

Es ging da um <script language="php">...</script> und <?php ... ?>. Die werden immer erkannt.
<? ... ?> und <% ... %> hingegen kann man über die Konfigurationsdatei ein- bzw. ausschalten.

Auf meinem lokalen Server werden die Short-Tags <? ?> nicht als PHP interpretiert. So ist es leicht möglich, Funktionen die lokal eben nicht ausgeführt werden sollen, einfach zu excluden.

Das kann man in dieser Richtung durchaus machen, sofern man sicher weiß, dass auf allen Produktivsystemen Short-Tags aktiviert sind - ich bin da vorsichtig, Provider machen oft die tollsten Sachen . Ich persönlich stelle im Skript fest, auf welchem Server ich mich befinde und handle dann entsprechend, indem ich z. B. serverabhängige PHP-Skripte einbinde.

Konstrukte wie
<?PHP if (!$go) { ?>
html
<?PHP } ?>

sind mit Short-Tags nicht möglich!

Wenn Short-Tags aktiviert sind, sollte auch

QUELLTEXT

<? if (!$go) { ?>
  html
<? } ?>

gehen. Zumindest bei mir funktionierts. Oder meinst du etwas anderes?

[db]

...
Wenn Short-Tags aktiviert sind, sollte auch

QUELLTEXT

<? if (!$go) { ?>
  html
<? } ?>

gehen. Zumindest bei mir funktionierts. Oder meinst du etwas anderes?

Nee, ich meine das selbe wie du. Aber du schriebst ja bereits, wenn Short-Tags ....

So ist es eben, man muss wissen, ob der Hoster short_open_tag nicht auf false setzte, default = true.
(Auge wies bereits auf XML in diesem Zusammenhang hin.)

Ob auf dem Web-Server Short-Tags erlaubt sind ist mir egal. Das wird schon vorher vom Encoder erledigt.

[Auge]

Hallo

Hängt eventuell damit zusammen, dass ich PHP schon verwendet habe als es noch PHP/FI hieß, da gab es die <?php ... ?>-Form glaube ich noch nicht . Dennoch sollten beide Versionen überall funktionieren, denn normalerweise wird doch der PHP-Parser anhand der Dateiendung auf das Skript losgelassen. Und der Parser erkennt definitiv immer beide Versionen. Und solange der Parser nicht drübergelaufen ist, muss es kein gültiges HTML/XHTML/XML oder sonstwas sein. Immer erst nachher. Und dann sind die Tags eh weg. Oder versteh ich da was falsch?

Die Deklaration einer XML-Datei sieht folgendermaßen aus: <?xml version="1.0" encoding="ISO-8859-1" ?> (siehe SELFHTML). Wie man sieht, beginnt sie mit <?, was bei einer XML-Datei, die mit dem short-open-tag eröffnete PHP-Bereiche enthält, dazu führt, dass sich der PHP-Parser an dieser Stelle verschluckt. Er nimmt ja an, dass ein PHP-Block geöffnet wird, doch dessen erste "innenliegende" Zeichen (xml) lösen bereits einen Parse Error aus. Deshalb muss der open-tag weitere vereinbarte Zeichen enthalten, hier praktischerweise den Namen der Sprache (php).

Das Problem fiele natürlich weg, wenn das Skript keine fertigen XML-Bereiche enthielte, sondern diese auschließlich selbst erzeugte.

Ob auf dem Web-Server Short-Tags erlaubt sind ist mir egal. Das wird schon vorher vom Encoder erledigt.

Man lasse der Einfachheit halber die Finger von ihnen und sich das Problem am Allerwertesten vorbeigehen.

Tschö, Auge