Bild einfügen mit PHP-Script Einstellungen

[Conny]

... ich wüsste auch nicht, was gegen die Verwendung der einen oder anderen sprechen sollte.

Ich auch nicht! Ich bin nur nicht mit dieser Art PHP zu notieren vertraut gewesen, that's all.

... path_loc() aus dem Beispiel z. B. erzeugt mir den aktuellen lokalen Pfad aus einem Web-Pfad und war in dem Skript, aus dem ich den Schnipsel rauskopiert habe, angebracht. Diese Funktion gibt es aber bei dir nicht und sofern du den Code eins zu eins übernommen hast, kann er nicht funktionieren. Auch eine Fehlermeldung wirst du nicht erhalten, da das Skript dann einfach eine ungültige Grafik zurückliefert.

Ja, so war's, ich habe es eins zu eins übernommen, der Grund warum es nicht geht/ging ist nun verstanden, Danke

.....es funktioniert definitiv....

Ja, mit dieser Code geht es problemlos.

cu
Conny

[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

[Google Bot]