Php In Html, PHP Script in HTML-Seite aufrufen? Einstellungen

[Conny]

Hallo,
heute habe ich mich mal wieder mit php beschäftigt.
Ziel ist es, verschiedene htm-Seiten mit einem (php)Zähler zu versehen.

Das habe ich gemacht:
Es handelt hier sich um eine HTM-Seite in der ich folgender aufruf gemacht habe:

QUELLTEXT

<p>
<?php
include('/home/www/web784/html/scripts/count/count.php');
?>
</p>

In diesem Absatz (P) soll das Script seine Ausgabe machen.
Klappt aber nicht!

Es klappt nur wenn ich die Seite mit diesem Aufruf -anstatt htm- eine PHP-Endung gebe!

Warum ist das so??

Kann eine html-Seite kein php aufrufen? Oder muss dort nur ein anderen Aufruf hin?

Danke für Eure Hilfe

Conny (der sich wünscht er hätte mehr Ahnung von php)

[db]

Hallo,
heute habe ich mich mal wieder mit php beschäftigt.
Ziel ist es, verschiedene htm-Seiten mit einem (php)Zähler zu versehen.

Das habe ich gemacht:
Es handelt hier sich um eine HTM-Seite in der ich folgender aufruf gemacht habe:

QUELLTEXT

<p>
<?php
include('/home/www/web784/html/scripts/count/count.php');
?>
</p>

In diesem Absatz (P) soll das Script seine Ausgabe machen.
Klappt aber nicht!

Es klappt nur wenn ich die Seite mit diesem Aufruf -anstatt htm- eine PHP-Endung gebe!

Warum ist das so?? 

Kann eine html-Seite kein php aufrufen? Oder muss dort nur ein anderen Aufruf hin?

Danke für Eure Hilfe 

Conny (der sich wünscht er hätte mehr Ahnung von php)

Hi Conny,

die Dateien mit den Erweiterungen <> .php* werden natürlich nicht vom Server an PHP gereicht. In der .htaccess kannst Du das aber erzwingen sowie auch in der php.ini auf dem Server.

Ich würde das nicht machen! Es ist besser die Dateien umzubennen und nicht alle .htm über den Parser laufen zu lassen.

[Conny]

Hi Dieter,
also, wenn ich Dich richtig verstanden habe, soll ich die Dateien die php beinhalten -und wenn es nur eine Zeile ist- auch eine php-Endung geben, damit der Parser sich nicht so *quälen* tut Richtig?

cu
Conny

[db]

Hi Dieter,
also, wenn ich Dich richtig verstanden habe, soll ich die Dateien die php beinhalten -und wenn es nur eine Zeile ist- auch eine php-Endung geben, damit der Parser sich nicht so *quälen* tut    Richtig?

cu
Conny

Richtig Conny!

Du möchtest aber manchmal sicher auch selbst wissen in welchen Dateien Du PHP verwendest. :-)

Hast Du bei Deinem Hoster keinen Counter auf CGI-Basis? Der würde dann einfach als Image eingebunden.

Du kannst natürlich die Erweiterung ändern, dann gehen alle .htm über PHP. Bei PHP ist aber die Zahl der Prozesse limitiert und es könnte für die Besucher langsam werden.

[Conny]

Hi,
ok, alles klar.
CGI ginge auch und wäre in diesem Fall wohl praktischer.
Ich hätte aber mit php leicht weitere Gimmicks einbauen können, ähnlich wie hier auf qhaut: wieviel User Online sind, wann die Meisten da waren, usw.

Wenn ich sowas machen würde, dann wohl konsquent mit header.dat und foot.dat mit unterschiedlichen Inhalt. Also, eigentlich das was ich jetzt in etwa mit Includes erreichen kann. Das Ganze würde dann aber Serverseitig laufen und die Datenmenge schrumpfen lassen, weil nur noch die Inhalte 'neu' gelesen werden müßten....

Puh, das gäbe noch eine Menge Arbeit

cu
Conny

[db]

Hi,
ok, alles klar.
CGI ginge auch und wäre in diesem Fall wohl praktischer.
Ich hätte aber mit php leicht weitere Gimmicks einbauen können, ähnlich wie hier auf qhaut: wieviel User Online sind, wann die Meisten da waren, usw.

Wenn ich sowas machen würde, dann wohl konsquent mit header.dat und foot.dat mit unterschiedlichen Inhalt. Also, eigentlich das was ich jetzt in etwa mit Includes erreichen kann. Das Ganze würde dann aber Serverseitig laufen und die Datenmenge schrumpfen lassen, weil nur noch die Inhalte 'neu' gelesen werden müßten....

Puh, das gäbe noch eine Menge Arbeit 

cu
Conny

Das ist mit PHP ja kein Problem!

Zudem kannst Du bei PHP die Kompression nutzen. Sie Dir mal die letzte Zeile in den Sourcen meiner Seiten an. Zum Beispiele bei der 200 kb File Meinungen.

Interessant könnte auch eTracker sein. Findest Du auf meiner Startseite unter Statistik.

[Netizen]

die Dateien mit den Erweiterungen <> .php* werden natürlich nicht vom Server an PHP gereicht. In der .htaccess kannst Du das aber erzwingen sowie auch in der php.ini auf dem Server.

Ich würde das nicht machen! Es ist besser die Dateien umzubennen

Dateien umzubennen, die per URL erreichbar sind bzw. schon waren, ist immer schlecht und verursacht nur Probleme. Cool URIs don't change.

Darüberhinaus macht es auch durchaus Sinn, in URLs komplett auf sprachspezifische Dateiendungen zu verzichten, entweder ein generisches .html oder überhaupt nix, das macht am wenigstens Streß (den Besucher geht es ohnehin nichts an, welche serverseitigen Techniken zum Einsatz kommen).

und nicht alle .htm über den Parser laufen zu lassen.

Dürfte keinen großen Unterschied machen, zumindest wenn PHP als Modul läuft. Ohne enthaltenen PHP-Code werden die Daten einfach nur durchgereicht, viel zu parsen ist da nicht.

Aber es gibt ja auch durchaus noch andere interessante Möglichkeiten, z.B. Content Negotiation bzw. MultiViews, um nur mal ein paar Stichworte zu nennen. Die Datei heißt dann meinetwegen "foo.html.php", der Server weiß somit, wie er sie zu behandeln hat. Von außen per URL ist sie aber trotzdem als "foo.html" oder auch nur "foo" erreichbar. Somit wird nur diese Datei durch den PHP-Interpreter gejagt, alle anderen hingegen statisch ausgeliefert. Der Besucher sieht davon nix.

n!

[Netizen]

Zudem kannst Du bei PHP die Kompression nutzen.

Geht auch bei statischen Dateien mit mod_gzip.

Insbesondere Stylesheets (und unter gewissen Umständen auch GIF-Dateien aufgrund der unkomprimierten Paletteninformationen) sind lohnenswerte Ziele.

n!

[db]

die Dateien mit den Erweiterungen <> .php* werden natürlich nicht vom Server an PHP gereicht. In der .htaccess kannst Du das aber erzwingen sowie auch in der php.ini auf dem Server.

Ich würde das nicht machen! Es ist besser die Dateien umzubennen

Dateien umzubennen, die per URL erreichbar sind bzw. schon waren, ist immer schlecht und verursacht nur Probleme. Cool URIs don't change.

Darüberhinaus macht es auch durchaus Sinn, in URLs komplett auf sprachspezifische Dateiendungen zu verzichten, entweder ein generisches .html oder überhaupt nix, das macht am wenigstens Streß (den Besucher geht es ohnehin nichts an, welche serverseitigen Techniken zum Einsatz kommen).

und nicht alle .htm über den Parser laufen zu lassen.

Dürfte keinen großen Unterschied machen, zumindest wenn PHP als Modul läuft. Ohne enthaltenen PHP-Code werden die Daten einfach nur durchgereicht, viel zu parsen ist da nicht.

Aber es gibt ja auch durchaus noch andere interessante Möglichkeiten, z.B. Content Negotiation bzw. MultiViews, um nur mal ein paar Stichworte zu nennen. Die Datei heißt dann meinetwegen "foo.html.php", der Server weiß somit, wie er sie zu behandeln hat. Von außen per URL ist sie aber trotzdem als "foo.html" oder auch nur "foo" erreichbar. Somit wird nur diese Datei durch den PHP-Interpreter gejagt, alle anderen hingegen statisch ausgeliefert. Der Besucher sieht davon nix.

n!

Die Dateien werden nicht einfach so durchgereicht weil kein PHP-Code gefunden wurde. PHP übernimmt auch für diese Dateien komplett die Headergenerierung etc..

Dateien kann man natürlich problemlos für den Besucher transparent umbenenen, in der .htaccess geht das mit RewriteRule oder Redirect permanent.

Das man bei den Hostern wie 1&1, Schlund oder T-Online mod_mime-Direktiven des Servers ändern kann ist mir neu! :-)

[Netizen]

Die Dateien werden nicht einfach so durchgereicht weil kein PHP-Code gefunden wurde. PHP übernimmt auch für diese Dateien komplett die Headergenerierung etc..

Klar, nur denke ich, daß der Aufwand des parsens vernachlässigbar gering ist. Abgesehen davon hat "Komplett-PHP" natürlich auch nette Vorteile, z.B. kann man dann getrost auf SSI verzichten ...

Das man bei den Hostern wie 1&1, Schlund oder T-Online mod_mime-Direktiven des Servers ändern kann ist mir neu! :-)

Naja, über solchen Spielkram rede ich nicht.

Es gibt genügend Hoster mit guter Leistung zu fairen Konditionen, die großen Massenhoster sind da IMHO kein (guter) Maßstab.

n!

[db]

Die Dateien werden nicht einfach so durchgereicht weil kein PHP-Code gefunden wurde. PHP übernimmt auch für diese Dateien komplett die Headergenerierung etc..

Klar, nur denke ich, daß der Aufwand des parsens vernachlässigbar gering ist. Abgesehen davon hat "Komplett-PHP" natürlich auch nette Vorteile, z.B. kann man dann getrost auf SSI verzichten ...

Das man bei den Hostern wie 1&1, Schlund oder T-Online mod_mime-Direktiven des Servers ändern kann ist mir neu! :-)

Naja, über solchen Spielkram rede ich nicht.

Es gibt genügend Hoster mit guter Leistung zu fairen Konditionen, die großen Massenhoster sind da IMHO kein (guter) Maßstab.

n!

Den Aufwand des unnötigen Parsens könnte man ja noch ignorieren, man ist ja schließlich alleine auf dem Server. :-) Die Anzahl der Prozesse ist aber limitiert. Bei 20 Besuchern gleichzeitig bekomst Du da schon Probleme!

Es geht hier um ein konkretes Anliegen. Conny würde gerne mit PHP arbeiten, aber nicht alle Files an PHP weiter reichen und auch nicht gelich den Hoster wechseln.

Ok, bleiben wird konkret:

Conny,

Speichere die datei *.htm auch als *.php, mit einem Texthinweis.

Nun änderts Du die .htaccess:

RewriteEngine On
RedirectMatch permanent (.*)\.htm$ http://www.domain.de$1.php

Du kannst aber auch so vorgehen, um expliziet nur diese eine Datei zu handeln:

RewriteEngine On
redirect temp /meinedatei.htm http://www.xxxxxx.de/meinedatei.php

Dann testet Du mal und wir sehen weiter

[Netizen]

Es geht hier um ein konkretes Anliegen. Conny würde gerne mit PHP arbeiten, aber nicht alle Files an PHP weiter reichen und auch nicht gelich den Hoster wechseln.

Das sind ja gleich drei Wünsche auf einmal - das geht nun wirklich nicht![tm]

RewriteEngine On
RedirectMatch permanent  (.*)\.htm$  http://www.domain.de$1.php

Das RewriteEngine On kann raus, Redirect und RedirectMatch gehören zu mod_alias.

n!

[mipraso]

Mal ein wenig Senf von mir:

PHP in html ist kein Problem wenn man icht gerade bei 2&2, T-Offline, Stratolos oder aderen PHP-Verweigeren hostet. (Die mit Recht Angst vor Endlosscheifen, von Hobby-Programmieren haben, die die Server "platt" machen.)

Das gibt bei mir keine Probleme:

QUELLTEXT

<?PHP
 include($DOCUMENT_ROOT.'/tracker.php');
?>

Auch nicht größere Dinger, wie ein Download-Counter in eine MySQL Datenbank.

Die Datei hat die Endung .html in der .htaccess steht drin:

QUELLTEXT

AddType application/x-httpd-php htm html

Das funktioniert seit Monaten ohne Probleme.

Michael

[db]

Es geht hier um ein konkretes Anliegen. Conny würde gerne mit PHP arbeiten, aber nicht alle Files an PHP weiter reichen und auch nicht gelich den Hoster wechseln.

Das sind ja gleich drei Wünsche auf einmal - das geht nun wirklich nicht![tm]

RewriteEngine On
RedirectMatch permanent  (.*)\.htm$  http://www.domain.de$1.php

Das RewriteEngine On kann raus, Redirect und RedirectMatch gehören zu mod_alias.

n!

Was laberst Du immer?

http://httpd.apache.org/docs-2.0/mod/mod_rewrite.html


RewriteEngine On

Schadet nie, ist aber bei vielen Server zwingend erforderlich!

[db]

Mal ein wenig Senf von mir:

PHP in html ist kein Problem wenn man icht gerade bei 2&2, T-Offline, Stratolos oder aderen PHP-Verweigeren hostet. (Die mit Recht Angst vor Endlosscheifen, von  Hobby-Programmieren haben, die die Server "platt" machen.)

Das gibt bei mir keine Probleme:

QUELLTEXT

<?PHP
 include($DOCUMENT_ROOT.'/tracker.php');
?>

Auch nicht größere Dinger, wie ein Download-Counter in eine MySQL Datenbank.

Die Datei hat die Endung .html in der .htaccess steht drin:

QUELLTEXT

AddType application/x-httpd-php htm html

Das funktioniert seit Monaten ohne Probleme.

Michael

Auf meinem Server sind nur php-files und alle nutzen auch noch die Kompression mit gzcompress!

Es ging darum reine HTML-Files, die kein PHP enthalten, nicht unnötigerweise über den PHP-Interpreter zu senden. Genau das machst Du. Wenn das jeder macht, muss man sich nicht wundern, wenn die Server Probleme bekommen.

[Netizen]

Das RewriteEngine On kann raus, Redirect und RedirectMatch gehören zu mod_alias.

Was laberst Du immer?

http://httpd.apache.org/docs-2.0/mod/mod_rewrite.html

Auch selbst gelesen? Wo steht da was von Redirect oder RedirectMatch?

http://httpd.apache.org/docs-2.0/mod/mod_alias.html

RewriteEngine On

Schadet nie, ist aber bei vielen Server zwingend erforderlich!

Ja, wenn Du mod_rewrite benutzt, was in Deinem geposteten Beispiel aber nicht der Fall ist.

Aus anderem Posting:

Es ging darum reine HTML-Files, die kein PHP enthalten, nicht unnötigerweise über den PHP-Interpreter zu senden. Genau das machst Du. Wenn das jeder macht, muss man sich nicht wundern, wenn die Server Probleme bekommen.

Dann bekommt eher der Hoster Probleme, und zwar mit den Kunden. Wer PHP anbietet, muß damit rechnen, daß es auch zahlreich genutzt wird, schließlich bezahlen die Kunden für die Leistung. Kann diese nicht erbracht werden, muß der Hoster entweder das Angebot drosseln oder die Server aufstocken. So einfach ist das aus Kundensicht.

Klar ist es lobenswert, sich sozial zu verhalten und zu versuchen, nicht unnötig Resourcen zu verschleudern. Der Hoster darf sich darauf aber nicht verlassen und hat für ausreichend Kapazität zu sorgen.

n!

[Netizen]

QUELLTEXT

AddType application/x-httpd-php htm html

Das funktioniert seit Monaten ohne Probleme.

Zumindest solange wie auf dem Server kein Content Negotiation/MultiViews verwendet wird. Dies wird (u.a.) anhand des Content-types durchgeführt. In dem Fall funktioniert obiges dann nur noch für User Agents (UA), die in ihrem ACCEPT-Header neben dem üblichen text/html auch das generische */* mitsenden (ein UA, der application/x-httpd-php mitsendet, dürfte recht unwahrscheinlich sein). Tun sie das nicht, findet der Server keine für den Client akzeptable Variante der angeforderten Resource und schickt statt des angeforderten Inhalts ein lapidares "406 Not Acceptable" zurück.

Wie gesagt, ohne CN sollte es kein Problem darstellen.

n!

Der Beitrag wurde von Netizen bearbeitet: 14.10.2004 - 23:53

[db]

Das RewriteEngine On kann raus, Redirect und RedirectMatch gehören zu mod_alias.

Was laberst Du immer?

http://httpd.apache.org/docs-2.0/mod/mod_rewrite.html

Auch selbst gelesen? Wo steht da was von Redirect oder RedirectMatch?

http://httpd.apache.org/docs-2.0/mod/mod_alias.html

RewriteEngine On

Schadet nie, ist aber bei vielen Server zwingend erforderlich!

Ja, wenn Du mod_rewrite benutzt, was in Deinem geposteten Beispiel aber nicht der Fall ist.

Aus anderem Posting:

Es ging darum reine HTML-Files, die kein PHP enthalten, nicht unnötigerweise über den PHP-Interpreter zu senden. Genau das machst Du. Wenn das jeder macht, muss man sich nicht wundern, wenn die Server Probleme bekommen.

Dann bekommt eher der Hoster Probleme, und zwar mit den Kunden. Wer PHP anbietet, muß damit rechnen, daß es auch zahlreich genutzt wird, schließlich bezahlen die Kunden für die Leistung. Kann diese nicht erbracht werden, muß der Hoster entweder das Angebot drosseln oder die Server aufstocken. So einfach ist das aus Kundensicht.

Klar ist es lobenswert, sich sozial zu verhalten und zu versuchen, nicht unnötig Resourcen zu verschleudern. Der Hoster darf sich darauf aber nicht verlassen und hat für ausreichend Kapazität zu sorgen.

n!

Ich schriebs schon, "RewriteEngine On" schadet nicht, kann aber später noch interessant werden.

Bezogen auf Redirekt hast Du recht.

Natürlich verlassen die Hoster sich nicht auf die Einsichtig der Kunden. Denn unter denen gibt es reichlich Spinner, die meinen "hab ich bezahlt". So wie sie früher die Flatrate bezahlten und nicht mehr offline gingen. Aus diesem Grund gibt es ja ein Limit für die Anzahl der Prozesse und für deren Laufzeit. Dies ist acuh absolut richtig, denn die Prozessorzeiten sind nun mal _natürlich_ limitiert. Mache Domains wären wohl nie mehr erreichbar, wenn man den anderen Kunden das Prozessorsharing überlassen würde.

Nun zurück zum konkrten Anliegen von Conny. Hast Du ihm einen Vorschlag zu machen, wie er nun seine Wünsche realisieren kann?

[mipraso]

@ hdb:

Ist alles richtig. Nur wenn du lächerliche 300 "Besucher" am Tag hast und das "tracker.php" nur für die SuMas ist und der PHP-Counter aus 5 oder 6 Zeilen pro Download besteht, mein Hoster das anbietet, dann währe ich ja dumm, wenn ich es nutzen würde? Im Ernst, wenn ein Provider das anbietet, dann sollte er wissen was er macht oder?

Ich bin auch gegen Verstopfung von Servern durch Müll-Scripte. Nur, einige Sachen möchte ich nutzen.

Ein bischen PHP in html sei mir erlaubt!

Michael

[db]

@ hdb:

Ist alles richtig. Nur wenn du lächerliche 300 "Besucher" am Tag hast und das "tracker.php" nur für die SuMas ist und der PHP-Counter aus 5 oder 6 Zeilen pro Download besteht, mein Hoster das anbietet, dann währe ich ja dumm, wenn ich es nutzen würde? Im Ernst, wenn ein Provider das anbietet, dann sollte er wissen was er macht oder?

Ich bin auch gegen Verstopfung von Servern durch Müll-Scripte. Nur, einige Sachen möchte ich nutzen.

Ein bischen PHP in html sei mir erlaubt! 

Michael

Nun Michael, Du bist sicher nicht ganz allein auf dem Server - oder ? :-)

Ich schrieb es bereits, meine Scripte belasten den Server schon wegen der Kompression, entlasten ihn dadurch aber auch beim Traffic.

Es ging hier um ein konkretes Anliegen. Da sollte man schon beim Lösungsansatz nicht murksen, nur damit es flott geht. Verfolgt man nun die Diskussion, denn zur Pronblemlösung waren ja nur fünf Zeilen nötig, dann streuben sich mir die Haare. (Keine Einwände: so viele könnte es ja nicht sein!) Das ist es was ich an Foren so hasse. Leute haben ein konkretes Problem und müssn sich dann mit unzähligen Beiträgen beschäftigen, die oft gut gemeint sind, oft aber auch dem Schreiber eher als dem Fragenden dienen.

Bei php sollte man wegen der Datei-Erweiterung auch noch die serverseitige Differenzieung zwischen php[n] berücksichtigen.

So, nun wünsche ich Dir 10.000 Besucher pro Tag, damit Dein Hoster Dir endlich mal Dampf macht! :-)

[mipraso]

@ Netizen

Eben, im Moment geht es, wenn es nicht mehr geht dann, dann muss sich der Hoster was einfallen lassen. Ich bin der zahlende Kunde mit min. 25 domains dort. Wenn er das nicht mehr kann, dann bin ich weg. 2&2. T-Offline und Stratolos habe ich hinter mir, von den anderen zwei Pleite-Billig-Anbieteren bin ich auch weg.

Michael

[Netizen]

Nun zurück zum konkrten Anliegen von Conny. Hast Du ihm einen Vorschlag zu machen, wie er nun seine Wünsche realisieren kann?

Ich würde es wohl mit MultiViews versuchen:

Apache, MultiViews and PHP
http://tranchant.plus.com/notes/multiviews

Entscheidend sind die beiden Zeilen:

QUELLTEXT

AddHandler php-script php
AddType text/html php

und eventuell noch ein

QUELLTEXT

Options +MultiViews

um den ganzen Kram zu aktivieren. Danach die fragliche Datei "foo.html" in "foo.html.php" umbenennen.

Beim Aufruf der Datei "foo.html" merkt der Server dann, daß keine Resource existiert, die exakt der angeforderten entspricht (keine exakte Übereinstimmung des Dateinamens). Er macht sich also selbst auf die Suche nach Alternativen und findet "foo.html.php". Da diese per obiger Zeile als text/html deklariert ist, sollte sie auch für den aufrufenden Browser/User Agent akzeptabel sein. Durch den Handler wird zusätzlich erreicht, daß die Datei vor Auslieferung durch den PHP-Interpreter geht, und zwar nur diese Datei.

An sich ziemlich simpel. Die Frage ist halt, ob das bei ihm auf dem Server so möglich ist.

n!

[Conny]

Hui, hab' ich etwa schlafende Hunde geweckt?
Auf jedem Fall habe ich jetzt den kompletten Durchblick verloren
Mein Hoster ist Canhost und bin sehr zufrieden, ist besser, schneller als die T-Online Mammut Server wo ich vorher war!

Ich Denke das mit den Zeilen einfügen in die .Htaccess würde ich noch hinbekommen, nur wo liegt da bei mir so'ne htaccess? den einzigen den es gibt habe ich selbst gemacht und ist für eine 'restricted Area' die ich mir auf den Server eingerichtet habe. Diesen htaccess wird ihr wohl kaum meinen oder?

cu
Conny

[db]

Nun zurück zum konkrten Anliegen von Conny. Hast Du ihm einen Vorschlag zu machen, wie er nun seine Wünsche realisieren kann?

Ich würde es wohl mit MultiViews versuchen:

Apache, MultiViews and PHP
http://tranchant.plus.com/notes/multiviews

...

Schlimm, wirklich schlimm, sowas als Lösung für einen Anfänger in Sachen PHP anzubieten!

vorbehalte
ausgabetyp des PHP-skripts
MultiViews verwendet den standardtyp wie mit AddType angegeben, egal was das PHP-skript im endeffekt generiert.

ich z.b. prüfe den Accept-header, den ihr browsers sendet, nach application/xhtml+xml. wenn gefunden, wird der Content-Type-header geändert, und der DOCTYPE wird auf XHTML 1.1 gesetzt. (mehr information)

wenn also ein browser eine anfrage mit einem Accept-header, der application/xhtml+xml enthält, schickt, aber nicht text/html, würde apache fehler 406 retournieren, weil MultiViews nur weiß, daß .php-dateien vom typ text/html sind.

ich löse das, indem ich zusätzliche erweiterungen angebe:

AddHandler php-script php xphp
AddType text/html php
AddType application/xhtml+xml xphp
dann speichere ich alle dateien als .xphp-dateien und erzeuge symbolische links mit der endung .php:

(datei) multiviews.xphp
(link) multiviews.php -> multiviews.xphp
damit hat MultiViews eine auswahl an dokumenttypen, und ich brauche nur eine datei zu warten. das erspart mir auch, den Accept-header zu parsen: ich kann PHP’s $_SERVER['SCRIPT_FILENAME'] verwenden um rauszufinden, welche von den beiden dateien MultiViews ausgewählt hat.

wichtig zu beachten ist, daß der internet explorer (unter gewissen bedingungen) einen Accept-header mit */* sendet, obwohl er kein application/xhtml+xml versteht.

glücklicherweise wählt apache’s auswahlalgorithmus den alphabetisch ersten dateinamen, der die bedingungen erfüllt. indem sie die dateiendungen weise wählen, können sie so den standardtyp angeben. in meinem beispiel kommt .php zuerst, also wird text/html als fallback genommen.

versionsabhängigkeiten
PHP und apache werden ständig weiterentwickelt, es könnte also sein, daß es nicht mit allen versionen funktioniert. testen!

ich glaube nicht, daß diese lösung mit Apache 1.3 funktioniert, wegen dem 1.3-kompatiblen modul, das php-script nicht verarbeitet. wenn sie einen workaround finden, lassen sie es mich wissen und ich werden es hier dokumentieren. eine möglichkeit sind type maps: siehe content negotiation und mod_negotiation auf der Apache website.

[Netizen]

Auf jedem Fall habe ich jetzt den kompletten Durchblick verloren 

Ist der Nachteil bei Foren ohne Thread-Darstellung ...

Ich Denke das mit den Zeilen einfügen in die .Htaccess würde ich noch hinbekommen, nur wo liegt da bei mir so'ne htaccess? den einzigen den es gibt habe ich selbst gemacht und ist für eine 'restricted Area' die ich mir auf den Server eingerichtet habe. Diesen htaccess wird ihr wohl kaum meinen oder?

Wenn die in dem zu schützenden Verzeichnis liegt, dann nein. Für Dinge, welche die gesamte Website betreffen, muß die .htaccess ins Wurzelverzeichnis der Site gepackt werden, also das, in welchem der Server bei Aufruf von www.example.com nachschaut.

n!

[db]

Hui, hab' ich etwa schlafende Hunde geweckt? 
Auf jedem Fall habe ich jetzt den kompletten Durchblick verloren 
Mein Hoster ist Canhost und bin sehr zufrieden, ist besser, schneller als die T-Online Mammut Server wo ich vorher war!

Ich Denke das mit den Zeilen einfügen in die .Htaccess würde ich noch hinbekommen, nur wo liegt da bei mir so'ne htaccess? den einzigen den es gibt habe ich selbst gemacht und ist für eine 'restricted Area' die ich mir auf den Server eingerichtet habe. Diesen htaccess wird ihr wohl kaum meinen oder?

cu
Conny

Keine Sorge, Du bekommst das hin.

Nehmen wir an es geht um eine Datei index.htm im root-Ordner des Servers, also erreichbar unter www.xxx.de

Im lokalen Root-Ordner erstellst Du die Datei .htaccess mit der Zeile

redirect temp /index.htm http://www.xxx.de/index.php

Dei Datei überträgst Du mit dem Client etc. auf den Server, ggf, erweitertes List einschalten (LIST -A) damit Du die Dateien mit dem . sehen kannst.

Nun rufst Du den Browser auf www.xxx.de. In der index.php hast Du Dir eine kleinen Hinweis gemacht oder sogar den Counter. Siehst also nicht nur in der URL des Browsers welche Datei engezeigt wird.

[Netizen]

Apache, MultiViews and PHP
http://tranchant.plus.com/notes/multiviews...

Schlimm, wirklich schlimm, sowas als Lösung für einen Anfänger in Sachen PHP anzubieten!

Der Abschnitt "Die Lösung" ist nun wirklich nicht übertrieben lang.

vorbehalte
[...]

Die erwähnten Vorbehalte sind für einen Anfänger nicht relevant. Die dortigen Ausführungen werden erst dann richtig spannend, wenn man abhängig von Browserfähigkeiten z.B. HTML oder XHTML ausliefern will.

n!

[mipraso]

@ hdb:

Nun Michael, Du bist sicher nicht ganz allein auf dem Server - oder ? :-)

Bin ich natürlich nicht.

Es ging hier um ein konkretes Anliegen. Da sollte man schon beim Lösungsansatz nicht murksen...

Ist es Murks, ein n+1 in eine MySQL zu schreiben wenn ein Dowload von einer ZIP erfolgt? Kann sein, es ist nur eine Zeile Code, weil ausgelagert.

Das ist es was ich an Foren so hasse. Leute haben ein konkretes Problem und müssn sich dann mit unzähligen Beiträgen beschäftigen, die oft gut gemeint sind, oft aber auch dem Schreiber eher als dem Fragenden dienen.

Wem sagst du das?
Kenne ich alles, ich versuche immer mich kurz zu fassen.

Bei php sollte man wegen der Datei-Erweiterung auch noch die serverseitige Differenzieung zwischen php[n] berücksichtigen.

Auch richtig, nur wenn der Hoster es anbietet, egal welche PHP[n] warum sollte ich es nicht nutzen?

So, nun wünsche ich Dir 10.000 Besucher pro Tag, damit Dein Hoster Dir endlich mal Dampf macht! :-)

Der Hoster macht mir keine Dampf, ich zahle dafür, was viel schlimmer ist, sind die Downloads der Plugins, die kosten Traffic, aber das muss ich dir ja nicht mitteilen, das kennst du ja selber.

Und Conny muss leiden!

[db]

Apache, MultiViews and PHP
http://tranchant.plus.com/notes/multiviews...

Schlimm, wirklich schlimm, sowas als Lösung für einen Anfänger in Sachen PHP anzubieten!

Der Abschnitt "Die Lösung" ist nun wirklich nicht übertrieben lang.

vorbehalte
[...]

Die erwähnten Vorbehalte sind für einen Anfänger nicht relevant. Die dortigen Ausführungen werden erst dann richtig spannend, wenn man abhängig von Browserfähigkeiten z.B. HTML oder XHTML ausliefern will.

n!

Es ist Dir ganz offensichlich nicht gegeben Deine Person nicht mal im Vordergrund zu wissen.

Ich denke, für jeden ist aus dem Text "Vorbehalte" genug kritische Distanz zu Deinem Vorschlag zu gewinnen. Für Dich mag es ja spannend sein oder werden, ich find's einfach nur deplaziert.

[Conny]

Dieter, Du bist mein Held!

Ich habe eine htaccess erstelt mit dem inhalt:

QUELLTEXT

RewriteEngine On
redirect temp /bilder.htm http://www.trimmelterhof.de/bilder.php

Eine Kopie von der bilder.htm in bilder.php (mit php aufruf drin) umbenannt und das war's.

Es ist ja nur zu Testzwecke hier ist die Seite: http://www.trimmelterhof.de/galerie_brand.htm

Geh' ich recht in der Annahme, daß ich die htaccess um beliebig viele Zeilen erweitern kann, falls ich weitere php Sachen auf andere htm-Seiten einbaue?

cu
Conny

[mipraso]

@ Conny

Kannst du machen:

Sieht hier so aus:

QUELLTEXT

...
ErrorDocument 401 /fehler/401.html
ErrorDocument 403 /fehler/403.html
ErrorDocument 404 /fehler/404.html
AddType application/x-httpd-php htm html
deny from 217.67.244.
deny from 64.246.49.119
...

Frag mich nicht wo die Grenze ist, bis jetzt konnte ich keine finden.

Michael

[db]

@ hdb:

Nun Michael, Du bist sicher nicht ganz allein auf dem Server - oder ? :-)

Bin ich natürlich nicht.

Es ging hier um ein konkretes Anliegen. Da sollte man schon beim Lösungsansatz nicht murksen...

Ist es Murks, ein n+1 in eine MySQL zu schreiben wenn ein Dowload von einer ZIP erfolgt? Kann sein, es ist nur eine Zeile Code, weil ausgelagert.

Das ist es was ich an Foren so hasse. Leute haben ein konkretes Problem und müssn sich dann mit unzähligen Beiträgen beschäftigen, die oft gut gemeint sind, oft aber auch dem Schreiber eher als dem Fragenden dienen.

Wem sagst du das?
Kenne ich alles, ich versuche immer mich kurz zu fassen.

Bei php sollte man wegen der Datei-Erweiterung auch noch die serverseitige Differenzieung zwischen php[n]berücksichtigen.

Auch richtig, nur wenn der Hoster es anbietet, egal welche PHP[n] warum sollte ich es nicht nutzen?

So, nun wünsche ich Dir 10.000 Besucher pro Tag, damit Dein Hoster Dir endlich mal Dampf macht! :-)

Der Hoster macht mir keine Dampf, ich zahle dafür, was viel schlimmer ist, sind die Downloads der Plugins, die kosten Traffic, aber das muss ich dir ja nicht mitteilen, das kennst du ja selber.

Und Conny muss leiden!

Es wäre Murks, wenn man Conny einen Vorschlag machen würde, der vermeidbare Probleme jetzt oder später beinhaltet. Er möchte mit PHP arbeiten, will natürlich wie wir alle auch Erfolge bzw Fortschritte sehnen. Gut, dann soll er das korrekt erledigen können und sich nicht fragen müssen ob's nun über den Interpreter geht, bei allen Dateien oder nicht usw. Dies ist vermeidbar mit der Extension PHP. Für Anfänger hält PHP eh schon Überraschungen bereit.

Übrigens, bei meinem Vorschlag löscht er einfach die .htaccess vom Server, wenn's Probleme gibt oder er keien Bock mehr hat. :-)

Traffic? Na ja, damit muss man leben, mehr als komprimierte Setups kann man ja nicht machen.

[db]

Geh' ich recht in der Annahme, daß ich die htaccess um beliebig viele Zeilen erweitern kann, falls ich weitere php Sachen auf andere htm-Seiten einbaue?

Ja, Du kannst das für x Dateien machen. Wenn Du aber alle .htm nach .php umgestellt hast, dann bietet es sich an RewriteRule oder RewriteMatch zu benutzen, wir dann alles in einer Zeile erledigt.

Mach erst mal so weiter, Du kannst dann sehen was alles mit PHP machbar ist.

[Netizen]

Es ist Dir ganz offensichlich nicht gegeben Deine Person nicht mal im Vordergrund zu wissen.

Auch nach dem dritten Mal lesen - immer noch nicht verstanden ...

Ich denke, für jeden ist aus dem Text "Vorbehalte" genug kritische Distanz zu Deinem Vorschlag zu gewinnen.

Schön, der Text mag in Abschnitten ungünstig formuliert und überholungsbedürftig sein, das ändert aber nichts daran, daß der erwähnte Vorschlag für gegebenes Problem eine einfache und flexible Lösung darstellt, die obendrein in vielen Fällen einfach per copy & paste umsetzbar ist.

Für Dich mag es ja spannend sein oder werden, ich find's einfach nur deplaziert.

Was jetzt? Den Text an sich oder das da halt "Vorbehalte" drübersteht, wo eigentlich keine sind?

n!

[db]

Es ist Dir ganz offensichlich nicht gegeben Deine Person nicht mal im Vordergrund zu wissen.

Auch nach dem dritten Mal lesen - immer noch nicht verstanden ...

Nachdem es nun endlich gelang Conny einen rasch nachvollziehbaren Vorschlag zu machen, möchte ich das Thema nicht unnötig weiter vertiefen. Wenn ich nicht verstanden werde, muss das nicht unbedingt an mir liegen. Sollte es doch so sein, kann ich locker damit leben.

[Conny]

Wenn wir nun schon dabei sind, eine Frage habe ich noch.
Wenn ich eine HTML Datei in drei Teile 'zerschneide',
Kopfbereich nenne ich header.dat , drin ist reines HTML und zwar der Doctype, die meta's, und der Body Tag geöffnet mit der obersten helfte der 'sichtbaren' Seite.
Der mittlere Bereich nenne ich bilder.php (bleiben wir mal bei diesem Beispiel )
Die Datei beinhaltet ein Include verweis für die header.dat, der 'normale' Inhalt und ein Verweis zur foot.dat.
Der dritte Teil ist dann die Datei foot.dat , drin ist der Fuss der Seite mit dem /body Tag und /html.

Ausser das einbinden der beiden dat-Dateien haben die Seiten keine php funktionen.
Nun habe ich, sagen wir mal 100 Seiten, alle können die header- und foot.dat gebrauchen. Würde sowas sinn machen?
Werden die Seiten beim User hierdurch schneller geladen? Oder eher gebremst weil sie Geparst werden müßen?

cu
Conny

PS. ein 'Ja, macht Sinn' oder ein 'Nein, macht keinen Sinn' würde mir -zunächst- reichen

[db]

Wenn wir nun schon dabei sind, eine Frage habe ich noch.
Wenn ich eine HTML Datei in drei Teile 'zerschneide',
Kopfbereich nenne ich header.dat , drin ist reines HTML und zwar der Doctype, die meta's, und der Body Tag geöffnet mit der obersten helfte der 'sichtbaren' Seite.
Der mittlere Bereich nenne ich bilder.php (bleiben wir mal bei diesem Beispiel  )
Die Datei beinhaltet ein Include verweis für die header.dat, der 'normale' Inhalt und ein Verweis zur foot.dat.
Der dritte Teil ist dann die Datei foot.dat , drin ist  der Fuss der Seite mit dem /body Tag und /html.

Ausser das einbinden der beiden dat-Dateien haben die Seiten keine php funktionen.
Nun habe ich, sagen wir mal 100 Seiten, alle können die header- und foot.dat gebrauchen. Würde sowas sinn machen?
Werden die Seiten beim User hierdurch schneller geladen? Oder eher gebremst weil sie Geparst werden müßen?

cu
Conny

PS. ein 'Ja, macht Sinn' oder ein 'Nein, macht keinen Sinn' würde mir -zunächst- reichen 

Natürlich macht das Sinn.

Du kannst so durch Änderung einer Datei, z.B. header.dat, z.B. das Menü für alle Deine Seiten ändern. wenn diese Seiten reines html beinhalten, würde ich sie so bennen das ich sie mit einem Editor entsprechend der Extension bearbeiten kann.

Den Header würde ich nicht in Includes machen, wegen Titel, reload usw.

Hier mal ein kleines Beispiel:

QUELLTEXT

<?
ob_start();
ob_implicit_flush(0);
function CheckCanGzip(){
   global $HTTP_ACCEPT_ENCODING;
   if (headers_sent() || connection_aborted()){
       return 0;
   }
   if (strpos($HTTP_ACCEPT_ENCODING, 'x-gzip') !== false) return "x-gzip";
   if (strpos($HTTP_ACCEPT_ENCODING,'gzip') !== false) return "gzip";
   return 0;
}
/* $level = compression level 0-9, 0=none, 9=max */
function GzDocOut($level=9,$debug=0){
   $ENCODING = CheckCanGzip();
   if ($ENCODING){
       print "\n<!-- Use $ENCODING -->\n";
       $Contents = ob_get_contents();
       ob_end_clean();header("Content-Encoding: $ENCODING");
       print "\x1f\x8b\x08\x00\x00\x00\x00\x00";
       $Size = strlen($Contents);
       $Crc = crc32($Contents);
       $Contents = gzcompress($Contents,$level);
       $Contents = substr($Contents, 0, strlen($Contents) - 4);
       print $Contents;
       print pack('V',$Crc);
       print pack('V',$Size);
       exit;
   }else{
       ob_end_flush();
       exit;
   }
}
?>
<html>
<head>
<title>ftp-uploader - Anleitungen - Hilfe Dateine für alte und neue Versionen</title>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<link href="/inline.css" rel="stylesheet" type="text/css">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<?php include('menue.php4'); ?>
<br>
<table width="600" border="0" align="center" cellspacing="0" cellpadding="0">
 <tr>
   <td>
     <div align="center"><font color="#FFFFFF"><strong>Anleitungen zum Uploader
       Version 3.00.2</strong></font></div>
   </td>
 </tr>
 <tr>
   <td bgcolor="#FFFFFF">
     <blockquote>
       <p>Sie k&ouml;nnen die Anleitungen hier online einsehen oder auch downloaden um sie dann auf Ihrem Rechner in aller Ruhe
         zu betrachten. Besonders die Anleitung zur Version 3 enth&auml;lt viele Grafiken und Animationen.</p>
     </blockquote>
     <ol>
       <ol>
         <a href="Anleitungxp/index.html" target="_blank">Anleitung zu &nbsp;&nbsp;&nbsp;Version xp 1.4 online ansehen</a>
       </ol>
       <ol>
         <a href="Anleitung30/index.php4" target="_blank">Anleitung zu Version 3.00.2 online ansehen</a>
       </ol>
     </ol>
     <ol>
       <ol>
       <a href="files/Anleitung30.zip">Anleitung zu Version 3.00.2 downloaden</a>&nbsp;&nbsp;&nbsp;(218 kb)
       </ol>
     </ol>
   </td>
 </tr>
</table>
<?php include('footer.php4'); ?>
</body>
</html>
<?
gzdocout();
?>

Achtung. Es sieht so aus als gäbe es in dem Scrpit als erstes eine Leerzeile! Dies darf nicht sein und wird nur hier so dargestellt! Jedes Zeichen vor dem ersten <?
würde zu einer Ausgabe des Headers führen und Kompression oder Cookies unmöglich machen!

[Netizen]

Nachdem es nun endlich gelang Conny einen rasch nachvollziehbaren ...

... IMHO suboptimalen ...

... Vorschlag zu machen, möchte ich das Thema nicht unnötig weiter vertiefen. Wenn ich nicht verstanden werde, muss das nicht unbedingt an mir liegen. Sollte es doch so sein, kann ich locker damit leben.

Bitte.

n!

[Netizen]

Achtung. Es sieht so aus als gäbe es in dem Scrpit als erstes eine Leerzeile! Dies darf nicht sein und wird nur hier so dargestellt! Jedes Zeichen vor dem ersten <?
würde zu einer Ausgabe des Headers führen und Kompression oder Cookies unmöglich machen!

Es gibt auch noch ein paar Macken und Unschönheiten im Code. Darf ich gnädigerweise wenigstens drauf hinweisen oder gar Verbesserungsvorschläge (nein, wie dreist...) machen? Einem Anfänger in Sachen PHP würde ich das nämlich nicht vorsetzen wollen.

Oder fällt das dann auch gleich wieder unter Gelaber?

n!

Der Beitrag wurde von Netizen bearbeitet: 15.10.2004 - 1:42

[i.b.g]

Hallo,

ihr habt eine interessante aber auch anstrengende Diskussion in der vergangenen Nacht hier abgeliefert.

Ich bin noch voll auf Perl ausgerichtet und hatte keine Zeit mir PHP zu Gemüte zu führen. Deshalb mag meine Zwischenfrage komisch klingen.

Hätte nicht auch ein SSI-Aufruf für's erste genügt, bevor man sich derart in die Serversteuerung einschaltet? Ok, auch dann muss ich die Datei meist in *.shtml umbenennen, es sei denn alle HTML-Dateien werden nach SSI-Aufrufen durchsucht - Performaceverluste. Ich dachte nur immer, dass PHP wie Perl auch nur eine Scriptsprache ist. Ich hab für mein kleines Intranet mal so einen Textcounter geschrieben und ihn einfach per SSI eingebunden und das funktioniert.

So beim Schreiben hab ich mir wohl die Frage teilweise selbst beantwortet. Auch per SSi müsste ich an die .htaccess. Hm... Bleibt nur, ob das auch ein Weg gewesen wäre?

[Andreas]

Der Hoster darf sich darauf aber nicht verlassen und hat für ausreichend Kapazität zu sorgen.

Mit Verlaub: ziemlich beschissene Einstellung.

Netter konnte ich es leider nicht formulieren.

Andreas (keine Smilies, da bitterer Ernst)

[Conny]

....Natürlich macht das Sinn....

....Hier mal ein kleines Beispiel...

Moin Dieter, moin all!
Ok, vielen Dank.
Habe die Code übernommen und werde mal was ausprobieren.
Testergebnisse werde ich Euch natürlich zeigen!

cu
Conny

[Conny]

So, neugierug wie ich bin, habe ich es sofort ausprobiert .
Eine HTML Datei http://www.kh-ruppert.de/home.htm
gesplittet in:

• auswahl.dat
• home.php (mit offenen kommentarzeilen, die noch wegkommen)
• fuss.dat

Ergibt als Resultat: http://www.kh-ruppert.de/home.php

Ok, bei diese Seiten ist es wohl eher banal sowas zu machen, aber für mich zum lernen reicht es ja

cu
Conny

PS. ein Nachteil hat es dann vielleicht doch; mal eben gucken wie's wird ist nicht, es sei denn, mann hat einen Server im Rechner eingebaut...

[db]

So, neugierug wie ich bin, habe ich es sofort ausprobiert  .
Eine HTML Datei http://www.kh-ruppert.de/home.htm
gesplittet in:

• auswahl.dat
  
  
  
  
  
  
  
  
  
  
• home.php (mit offenen kommentarzeilen, die noch wegkommen)
  
  
  
  
  
  
  
  
  
  
• fuss.dat

Ergibt als Resultat: http://www.kh-ruppert.de/home.php

Ok, bei diese Seiten ist es wohl eher banal sowas zu machen, aber für mich zum lernen reicht es ja

cu
Conny

Kompression fehlt noch. Einfach den ersten und letzten php-Block in die file kopieren.

Ob's funktioniert siehst Du bei Ansicht des Queltextes im Browser in der letzten Zeile.

Ideen entwickelst Du mit den neuen Möglichkeiten von alleine. Zudem gibt es reichlich PHP-Skrpte für alle erdenkliche Fälle und Probleme.

[Conny]

...Kompression fehlt noch. Einfach den ersten und letzten php-Block in die file kopieren....

..Ob's funktioniert siehst Du bei Ansicht des Queltextes im Browser in der letzten Zeile....

Oops , der erster Block war drin, ich hatte unten das

QUELLTEXT

<?
gzdocout();
?>

vergessen.

Ich hab's nachgetragen und es scheint zu funktionieren, denn nun steht unten in der Quellcode:

QUELLTEXT

<!-- Use gzip -->

Was wohl soviel heisst, daß das File 'gezipt' (komprimiert) wird.

Schön!

Conny

[db]

...Kompression fehlt noch. Einfach den ersten und letzten php-Block in die file kopieren....

..Ob's funktioniert siehst Du bei Ansicht des Queltextes im Browser in der letzten Zeile....

Oops , der erster Block war drin, ich hatte unten das

QUELLTEXT

<?
gzdocout();
?>

vergessen.

Ich hab's nachgetragen und es scheint zu funktionieren, denn nun steht unten in der Quellcode:

QUELLTEXT

<!-- Use gzip -->

Was wohl soviel heisst, daß das File 'gezipt' (komprimiert) wird.

Schön!

Conny

Ja, Conny, funktioniert. Ich hatte es bereits gesehen. :-)

Isch watsching you!

Website Watcher

[Netizen]

Der Hoster darf sich darauf aber nicht verlassen und hat für ausreichend Kapazität zu sorgen.

Mit Verlaub: ziemlich beschissene Einstellung.

Ich habe mit dem Hoster einen Vertrag und kann wohl erwarten, daß die zugesicherten Leistungen bei Bedarf erbracht werden können.

Wie eine Dumping-Mischkalkulation nach hinten losgehen kann, wenn sich die Kunden nicht wie geplant verhalten, sondern allesamt die vereinbarte Leistung auch wirklich nutzen, hat man vor Jahren recht eindrucksvoll am reihenweisen Sterben von Flatrate-Anbietern gesehen.

(keine Smilies, da bitterer Ernst)

Durchaus.

n!

[Andreas]

daß die zugesicherten Leistungen bei Bedarf erbracht werden können.

Sicher, aber aus Deinem Post war zu lesen: Ich könnte, also mache ich bis es bricht - ohne Rücksicht auf Verluste. Und das ist ziemlich beschissen.

[Netizen]

daß die zugesicherten Leistungen bei Bedarf erbracht werden können.

Sicher, aber aus Deinem Post war zu lesen: Ich könnte, also mache ich bis es bricht - ohne Rücksicht auf Verluste.

Huh? Also entweder ist das eine sehr freie Interpretation von Dir, oder ich hab mich tatsächlich so dämlich ausgedrückt ...

Natürlich lege ich es nicht drauf an, alle Resourcen bis aufs letzte auszureizen. Ein zuverlässiger Serverbetrieb ist ja in erster Linie in meinem eigenen Interesse. Allerdings bin ich auch nicht bereit, nur aus Gründen der Resourcenschonung komplett auf bestimmte Dinge zu verzichten, die für mich nützlich sind und die Arbeit erleichtern. Was Sinn macht, wird auch verwendet. (Natürlich werden dann auch des öfteren mal Skripte oder Algorithmen umgebaut und optimiert.)

n!

[Google Bot]