php-resource



Zurück   PHP-Scripte PHP-Tutorials PHP-Jobs und vieles mehr > Entwicklung > PHP Developer Forum
 

Login

 
eingeloggt bleiben
star Jetzt registrieren   star Passwort vergessen
 

 

 


PHP Developer Forum Hier habt ihr die Möglichkeit, eure Skriptprobleme mit anderen Anwendern zu diskutieren. Seid so fair und beantwortet auch Fragen von anderen Anwendern. Dieses Forum ist sowohl für ANFÄNGER als auch für PHP-Profis! Fragen zu Laravel, YII oder anderen PHP-Frameworks.

Antwort
 
LinkBack Themen-Optionen Thema bewerten
  #1 (permalink)  
Alt 15-10-2009, 19:32
Benutzerbild von onemorenerd onemorenerd
  Moderator
Links : Onlinestatus : onemorenerd ist offline
Registriert seit: Mar 2005
Ort: Berlin
Beiträge: 9.471
onemorenerd wird schon bald berühmt werdenonemorenerd wird schon bald berühmt werden
Question Pseudo-Pattern zu PCRE-Pattern und best match

Ich baue eine vom Content unabhängige Verwaltung für <title>, <meta name="keywords" ...> und <meta name="description" ...>.
Man muss zu diesen drei Dingen noch einen URL-Pfad angeben, bei dem diese Daten verwendet werden sollen. In diesem Pfad sind ? und * als Platzhalter für ein beliebiges Zeichen bzw. beliebig viele Zeichen erlaubt.

Ich habe also viele Pfade wie
Code:
user/*
user/?*/profile
user/?*/profile/*
user/?*/profile/?
und zu jedem ein Set von Title, Keywords und Description.

Bei der Ausgabe im Frontend muss ich den Pfad finden, der am besten zur aktuellen URL passt. Wie stelle ich das am besten an?

Es ist nicht so, dass ich gar keine Idee hätte. Ich sortiere absteigend nach der Länge, ersetze dann "?" durch "[^/]{1}", "*?" und "?*" durch "[^/]{1,}", sowie "*" durch "[^/]*". Die umgeschriebenen Pfade verwende ich in der durch die Sortierung vorgebenen Reihenfolge in preg_match() bis ich einen Treffer habe.
Dieser erste Treffer ist nicht zwangsläufig der einzige oder beste. Zum Beispiel wird die Sortierung das ergeben:
Code:
user/?*/profile/*
user/?*/profile/?
user/?*/profile
user/*
Das ist schon nicht optimal. Ich will eigentlich "user/?*/profile/?" zuerst, weil es mir einen längeren Treffer garantiert als "user/?*/profile/*". Deswegen benutze ich eine Callback-Funktion zum Sortieren, die alle "*" entfernt und dann nach Länge entscheidet. Damit ergibt die Sortierung wie gewünscht
Code:
user/?*/profile/?
user/?*/profile/*
user/?*/profile
user/*
Nach dem Umschreiben in PCRE-Syntax habe ich
Code:
user/[^/]{1,}/profile/[^/]{1}
user/[^/]{1,}/profile/[^/]*
user/[^/]{1,}/profile
 user/[^/]*
Jetzt gehts ans matchen.
PHP-Code:
$bestMatch NULL;
foreach (
$paths as $path) {
    if (
preg_match('§^'$path .'§'$_SERVER['REQUEST_URI'])) {
        
$bestMatch $path;
        break;
    }

Ist das überhaupt korrekt (Gegenbeispiele, Mehrdeutigkeiten)?
Wie kann ich das besser/effizienter lösen?
Mit Zitat antworten
  #2 (permalink)  
Alt 15-10-2009, 21:21
AmicaNoctis
  Moderatorin
Links : Onlinestatus : AmicaNoctis ist offline
Registriert seit: Jul 2009
Beiträge: 5.709
Blog-Einträge: 9
AmicaNoctis sorgt für eine eindrucksvolle AtmosphäreAmicaNoctis sorgt für eine eindrucksvolle Atmosphäre
Standard

Sieht imho doch ganz gut aus. Was ich noch machen würde, wäre, vor der Ersetzung der Platzhalter in RegEx noch preg_quote drauf anzuwenden, falls URL-Pfade mal nen Punkt, Klammern oder ein Dollarzeichen enthalten könnten. Die werden nämlich nicht urlencoded. Darüber hinaus enthält $_SERVER["REQUEST_URI"] auch den Query String, der ebenfalls mit einem RegEx-Zeichen anfängt, aber ich weiß nicht, inwiefern GET-Parameter bei deinen URLs überhaupt eine Rolle spielen.
Mit Zitat antworten
  #3 (permalink)  
Alt 15-10-2009, 22:29
Benutzerbild von onemorenerd onemorenerd
  Moderator
Links : Onlinestatus : onemorenerd ist offline
Registriert seit: Mar 2005
Ort: Berlin
Beiträge: 9.471
onemorenerd wird schon bald berühmt werdenonemorenerd wird schon bald berühmt werden
Standard

Den Codefetzen habe ich nur mal so aus dem Ärmel geschüttelt, damit klar wird wie ich es meine. Tatsächlich verwende ich preg_quote(). Nur nicht an dieser Stelle sondern früher, in dem Moment wo der Pfad eingegeben wird.

Das wirklich blöde an diesem Problem ist, dass man das Pferd so von hinten aufzäumen muss. Ich will zum Schluß den längsten Treffer. Die Frage ist, welches Pattern ich dafür nehmen muss.

Annahme: Lange Pattern versprechen lange Matches.
Betrachtet man nur die "einfachen" Zeichen in den Pattern, dann stimmt das auch. Aber die "magischen" Zeichen machen Probleme.

Angenommen ich habe die Pfade user/*/foo/bar und user/*/foo/*. Der erste garantiert mir einen längeren Treffer, schon allein weil er mehr "einfache" Zeichen enthält.
Jetzt matche ich das mal mit der URL user/me/foo/bar/baz. Mit dem ersten Pattern ist der Match 15 Zeichen lang. Aber das zweite, kürzere Pattern erzeugt einen längeren Match. Mööp, Annahme widerlegt.

In diesem Beispiel wars einfach, denn ein * am Ende eines Pattern expandiert halt bis zum Ende der URL. Aber das Pattern hätte auch user/*/foo/*z lauten können. Wäre immer noch kürzer als user/*/foo/bar, ich würde immernoch letzterem den Vorzug geben, es würde auch matchen und ich läge wieder daneben.

Ich brauche einen Algorithmus, eine Funktion, die für zwei Pattern ermittelt, welches längere Matches verspricht.
Oder einen anderen Ansatz ...


Übrigens habe ich mich von ? schon verabschiedet und * wird nun durch [^/]{1,} ersetzt. Damit kann man noch alle URLs abdecken, die in dieser Applikation auftreten und es vereinfacht die Implementierung.
Mit Zitat antworten
  #4 (permalink)  
Alt 15-10-2009, 22:35
AmicaNoctis
  Moderatorin
Links : Onlinestatus : AmicaNoctis ist offline
Registriert seit: Jul 2009
Beiträge: 5.709
Blog-Einträge: 9
AmicaNoctis sorgt für eine eindrucksvolle AtmosphäreAmicaNoctis sorgt für eine eindrucksvolle Atmosphäre
Standard

Es lässt sich einfach nicht ermitteln, welches Pattern den längsten Match verspricht. Du kannst nur die Patterns alle anwenden und alle Matches erfassen und die dann nach Länge ordnen. Oder sehe ich da was falsch?
Mit Zitat antworten
  #5 (permalink)  
Alt 15-10-2009, 22:46
Benutzerbild von onemorenerd onemorenerd
  Moderator
Links : Onlinestatus : onemorenerd ist offline
Registriert seit: Mar 2005
Ort: Berlin
Beiträge: 9.471
onemorenerd wird schon bald berühmt werdenonemorenerd wird schon bald berühmt werden
Standard

Naja ich kann zumindest die Anzahl der statischen Zeichen zu Rate ziehen

user/*/foo/bar => 13
user/*/foo/*z => 11

und die Pattern danach sortiert durchprobieren. Sobald ich einen Match habe, kann ich dessen Länge ermitteln und alle Pattern, die weniger statische Zeichen haben als dieser Match, brauche ich gar nicht mehr zu testen.
Damit würde sich sozusagen die Liste der noch testenden Pattern immer weiter verkürzen, je längere Matches sich finden.
Mit Zitat antworten
  #6 (permalink)  
Alt 15-10-2009, 22:50
wahsaga
  Moderator
Links : Onlinestatus : wahsaga ist offline
Registriert seit: Sep 2001
Beiträge: 25.236
wahsaga befindet sich auf einem aufstrebenden Ast
Standard

Zitat:
Zitat von onemorenerd Beitrag anzeigen
Angenommen ich habe die Pfade user/*/foo/bar und user/*/foo/*. Der erste garantiert mir einen längeren Treffer, schon allein weil er mehr "einfache" Zeichen enthält.
Du bräuchtest für so einen Fall eine Art KI, die erkennt, dass das erste Muster einen Sonderfall des zweiten darstellt.

Dann könntest du alle "besten" Treffer des zweiten Musters ermitteln (ich nehme an, dass möglicherweise mehr als eine Adresse dieses Kriterium erfüllen kann), und dann unter denen schauen, ob einer davon das spezielle, erste Pattern erfüllt.

Zitat:
Aber das Pattern hätte auch user/*/foo/*z lauten können. Wäre immer noch kürzer als user/*/foo/bar, ich würde immernoch letzterem den Vorzug geben, es würde auch matchen und ich läge wieder daneben.
Aus der Länge eines Patterns auch nur irgendeinen Rückschluss darauf ziehen zu wollen, wie speziell oder allgemein es nun matched, halte ich für ein Ding der Unmöglichkeit.

Zitat:
Ich brauche einen Algorithmus, eine Funktion, die für zwei Pattern ermittelt, welches längere Matches verspricht.
S.o., halte ich für kaum machbar.
In dem Moment, wo du Informationen darüber gewinnen willst, bist du mindestens schon beim Parsen des regulären Ausdrucks, vielleicht schon dabei ihn auf einen bestimmten Text anzuwenden ...
__________________
I don't believe in rebirth. Actually, I never did in my whole lives.
Mit Zitat antworten
  #7 (permalink)  
Alt 15-10-2009, 22:52
AmicaNoctis
  Moderatorin
Links : Onlinestatus : AmicaNoctis ist offline
Registriert seit: Jul 2009
Beiträge: 5.709
Blog-Einträge: 9
AmicaNoctis sorgt für eine eindrucksvolle AtmosphäreAmicaNoctis sorgt für eine eindrucksvolle Atmosphäre
Standard

Zitat:
Zitat von onemorenerd Beitrag anzeigen
die Liste der noch testenden Pattern immer weiter verkürzen, je längere Matches sich finden.
Das klingt sinnvoll.
Mit Zitat antworten
  #8 (permalink)  
Alt 16-10-2009, 00:17
Benutzerbild von mermshaus mermshaus
 Registrierter Benutzer
Links : Onlinestatus : mermshaus ist offline
Registriert seit: Jun 2009
Beiträge: 451
mermshaus wird schon bald berühmt werden
Standard

Wenn ich das richtig verstanden habe, sieht die Umformung zum Beispiel so aus:

Code:
(pseudo)   user/* <=> user/[^/]{1,}   (PCRE)
Angenommen, ich verhaue mich da jetzt nicht völlig, dürfte der PCRE-Ausdruck keine Unterverzeichnisse matchen. Aber passt das zu dem folgenden Zitat?

Zitat:
Angenommen ich habe die Pfade user/*/foo/bar und user/*/foo/*. Der erste garantiert mir einen längeren Treffer, schon allein weil er mehr "einfache" Zeichen enthält.
Jetzt matche ich das mal mit der URL user/me/foo/bar/baz. Mit dem ersten Pattern ist der Match 15 Zeichen lang. Aber das zweite, kürzere Pattern erzeugt einen längeren Match. Mööp, Annahme widerlegt.

In diesem Beispiel wars einfach, denn ein * am Ende eines Pattern expandiert halt bis zum Ende der URL.
Matcht das Sternchen nun Verzeichnisse?

Und wie passen #5 und #3 zusammen? Im Beispiel in #3 liefert doch das Pattern mit weniger statischen Zeichen das längere Match.
Mit Zitat antworten
  #9 (permalink)  
Alt 16-10-2009, 00:25
AmicaNoctis
  Moderatorin
Links : Onlinestatus : AmicaNoctis ist offline
Registriert seit: Jul 2009
Beiträge: 5.709
Blog-Einträge: 9
AmicaNoctis sorgt für eine eindrucksvolle AtmosphäreAmicaNoctis sorgt für eine eindrucksvolle Atmosphäre
Standard

Zitat:
Zitat von mermshaus Beitrag anzeigen
Im Beispiel in #3 liefert doch das Pattern mit weniger statischen Zeichen das längere Match.
Du hast vollkommen Recht. Ich nehme mein "Das klingt sinnvoll." beschämt zurück
Mit Zitat antworten
  #10 (permalink)  
Alt 16-10-2009, 01:44
Benutzerbild von onemorenerd onemorenerd
  Moderator
Links : Onlinestatus : onemorenerd ist offline
Registriert seit: Mar 2005
Ort: Berlin
Beiträge: 9.471
onemorenerd wird schon bald berühmt werdenonemorenerd wird schon bald berühmt werden
Standard

Nein, bleib mal dabei. Es ist sinnvoll.

@mermshaus: Ich entschuldige mich, bei diesem Beispiel habe ich mich geirrt. Um es klarzustellen: Ein * im Pseudo wird zu [^/]{1,} im PCRE. * matcht also nur bis zum nächsten Slash. Ich überlege sogar, ob * nich generell von einem bis zum nächsten Slash matchen sollte. Aber bisher hätte ich davon keine Vorteile.

Diese Tatsache ist es übrigens auch, die mich auf eine weitere Idee brachte. Dazu komme ich gleich. Vorher noch ein Wort zu
Zitat:
Zitat von wahsaga Beitrag anzeigen
Aus der Länge eines Patterns auch nur irgendeinen Rückschluss darauf ziehen zu wollen, wie speziell oder allgemein es nun matched, halte ich für ein Ding der Unmöglichkeit.
Mir geht es ja nur um ganz spezielle Pattern. So speziell, dass ich glaube, man könnte aus allen Pattern einen Baum konstruieren und mit einer geeigneten Metrik die Güte von Pattern miteinander vergleichen. Aber das ist mir zu kompliziert, vor allem weil sich bestimmte Mehrdeutigkeiten prinzipiell nicht auflösen lassen, soweit ich das sehe.

Nun zu meiner neuen Idee: Sie stützt sich auf die Tatsache, dass * für alles außer / steht. Ich gruppiere alle Pfade nach der Anzahl enthaltener Komponenten, konkret nach substr_count($path, '/').
Vorm Matching bestimme ich die Anzahl der Komponenten in der URL. Und ich brauche schon mal die Pattern(gruppen) alle nicht mehr, die mehr Komponenten haben als die URL. Denn wenn ein Pattern mehr Slashes enthält als das Subject, kann es gar nicht matchen.

Und es kommt noch besser: Sobald ein Pattern aus einer Gruppe matcht, muss ich nur noch diese Gruppe durchprobieren. Alle Pattern aus den anderen Gruppen matchen entweder gar nicht oder kürzer.

Soweit so gut. Jetzt suche ich noch nach einer Möglichkeit, um nicht alle Pattern in einer Gruppe probieren zu müssen. Meine einzige Idee dazu ist ein Präfixbaum.
Mit Zitat antworten
  #11 (permalink)  
Alt 16-10-2009, 01:51
AmicaNoctis
  Moderatorin
Links : Onlinestatus : AmicaNoctis ist offline
Registriert seit: Jul 2009
Beiträge: 5.709
Blog-Einträge: 9
AmicaNoctis sorgt für eine eindrucksvolle AtmosphäreAmicaNoctis sorgt für eine eindrucksvolle Atmosphäre
Standard

Zitat:
Zitat von onemorenerd Beitrag anzeigen
Sobald ein Pattern aus einer Gruppe matcht, muss ich nur noch diese Gruppe durchprobieren. Alle Pattern aus den anderen Gruppen matchen entweder gar nicht oder kürzer.
Dazu müsstest du erstmal klären, was in deinem Falle so eine Gruppe ist und wodurch sie sich auszeichnet.

Das mit dem Präfixbaum (wenn ich es nicht falsch verstehe) ist doch wieder so eine Sache, die sich nicht entscheiden lässt, ohne die konkreten Subjektstrings zu kennen. Es kann ganz zum Schluss immer noch ein */foo/*/bar kommen.

Da es ja um den passendsten Pfad geht und du sinnvollerweise die Anzahl der Komponenten (N) als erstes berücksichtigst, wäre das ein Grund sich ansonsten vom Kriterium der statischen Länge des Patterns zu verabschieden. Damit ist dann vollkommen egal, wieviele konkrete Zeichen ein * matcht, weil es ja trotzdem nur eine von N Pfadkomponenten ist. Dabei gehe ich davon aus, dass Pfadkomponenten atomar sind und nicht unterschiedlich spezifische Einteilungen derselben Basisentität darstellen, z. B.
/ball/
/ball-rot/
/ball-gepunktet/
/ball-rot-gepunktet/
In diesem Fall würde das nicht mehr hinhauen, aber ich gehe mal davon aus, dass du deine Pfadnamen besser gewählt hast.

Wenn du mir bis hier hin zustimmen kannst, bringe ich jetzt noch die Spezifität ins Spiel, wie wir sie aus CSS kennen: Eine *-Komponente ist dabei weniger spezifisch als eine konkret benannte. Nachdem du also alle Patterns aussortiert hast, die eine abweichende Anzahl Komponenten haben, könntest du die übrigen nach substr_count($pattern, "*") sortieren und das erste nach dieser Sortierung matchende Pattern wäre dann der beste Treffer hinsichtlich der Spezifität. Das könnte man dann noch nach Position im Pfad gewichten, so dass z. B. "/*/*/foo/" eine höhere hat als "/bar/*/*/", weil Pfade nach hinten hin ja eh meistens spezieller werden. Damit kannst du wie in CSS ganz allgemein anfangen und dich dann sukzessive zu Sonderfällen vorarbeiten.

Geändert von AmicaNoctis (16-10-2009 um 02:54 Uhr)
Mit Zitat antworten
  #12 (permalink)  
Alt 16-10-2009, 03:54
Benutzerbild von onemorenerd onemorenerd
  Moderator
Links : Onlinestatus : onemorenerd ist offline
Registriert seit: Mar 2005
Ort: Berlin
Beiträge: 9.471
onemorenerd wird schon bald berühmt werdenonemorenerd wird schon bald berühmt werden
Standard

Eine Gruppe ist eine Menge von Pseudo-Pattern mit gleicher Anzahl Slashes. Das sieht zum Beispiel so aus:
Code:
0 = array('foo', 'x', '*')
1 = array('foo/*', 'foo/bar', 'x/y', 'x/z')
2 = array('foo/*/baz', 'foo/bar/baz', 'x/y/z', 'x/y/*')
4 = array('foo/*/baz/*/foo', 'foo/bar/baz/*/foo', 'x/y/z', 'x/y/*')
Der Präfixbaum für die Gruppe 2 sähe so aus:
Code:
<root>
+- foo
|  +- bar - baz
|  `- * - baz
`- x - y
       +- z
       `- *
Wenn ich das Subject x/y/z bekomme, zerlege ich das in die Komponenten x, y und z. Dann wird ausgehend von <root> das Kind x gesucht, von dort aus y und schließlich z.

Würde ich das so umsetzen, bräuchte ich überhaupt keine PCRE mehr. Aber auch wenn ich nur das erste Zeichen jedes Pseudo-Pattern zur Subgruppenbildung benutze, reduziert sich die Zahl der in Frage kommenden Pattern erheblich und es wären maximal zwei Array-Lookups mehr - einer für das erste Zeichen aus dem Subject und falls es keine solche Subgruppe gibt, ein weiterer nach *.

Die Subgruppen sähen so aus:
Code:
0 = array(
    'f' => array('foo'),
    'x' => array('x'),
    '*' => array('*'))
1 = array(
    'f' => array('foo/*', 'foo/bar'), 
    'x' => array('x/y', 'x/z'))
...
Für ein Subject aus zwei Komponenten könnte ich die Gruppen 2 und 4 (s.o.) schon komplett ausschließen. Ich beginne also mit Gruppe 1.
Das erste Zeichen des Subject sei ein b. Da es keine Subgruppe b in Gruppe 1 gibt und auch keine Subgruppe *, kann ich Gruppe 1 auschließen und mache weiter mit Gruppe 0.
In Gruppe 0 gibt es ebenfalls keine Subgruppe b, aber eine Subgruppe *.
Ich probiere alle Pattern aus dieser Subgruppe um herauszufinden, welches den längsten Match erzeugt. Weil die Subgruppe nun gerade aus nur einem Pattern besteht, kann ich mir das sogar sparen.

Zumindest für die häufigsten Subjects, nämlich die kurzen, kann ich so mit nur einem substr_count() und ein paar isset() die Anzahl der in Frage kommenden Pattern von einigen hundert auf weniger als ein Dutzend reduzieren.

Geändert von onemorenerd (16-10-2009 um 04:13 Uhr)
Mit Zitat antworten
  #13 (permalink)  
Alt 16-10-2009, 04:27
Benutzerbild von onemorenerd onemorenerd
  Moderator
Links : Onlinestatus : onemorenerd ist offline
Registriert seit: Mar 2005
Ort: Berlin
Beiträge: 9.471
onemorenerd wird schon bald berühmt werdenonemorenerd wird schon bald berühmt werden
Standard

Zitat:
Zitat von AmicaNoctis Beitrag anzeigen
In diesem Fall würde das nicht mehr hinhauen, aber ich gehe mal davon aus, dass du deine Pfadnamen besser gewählt hast.
Ich wähle die Pfadnamen nicht. Das macht ein Redakteur bzw. sie werden aus Überschriften, Benutzernamen usw. generiert.
Mit Zitat antworten
Antwort

Lesezeichen

Stichworte
pcre url


Aktive Benutzer in diesem Thema: 1 (Registrierte Benutzer: 0, Gäste: 1)
 

Ähnliche Themen
Thema Autor Forum Antworten Letzter Beitrag
Active Record Pattern/Mapper Pattern stf]Daywalker Off-Topic Diskussionen 0 28-02-2006 13:52
pattern x4th PHP Developer Forum 2 24-02-2006 12:34
OS pattern schlimmerfinger PHP Developer Forum 2 05-12-2004 18:05
[REGEX] Referenzen in PCRE-Pattern MaxPayne PHP Developer Forum 2 15-10-2004 08:49
preg_match_all + Pattern IsoLizer PHP Developer Forum 2 14-04-2003 13:41

Themen-Optionen
Thema bewerten
Thema bewerten:

Forumregeln
Es ist Ihnen nicht erlaubt, neue Themen zu verfassen.
Es ist Ihnen nicht erlaubt, auf Beiträge zu antworten.
Es ist Ihnen nicht erlaubt, Anhänge hochzuladen.
Es ist Ihnen nicht erlaubt, Ihre Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are an


PHP News

ebiz-trader 7.5.0 mit PHP7 Unterstützung veröffentlicht
ebiz-trader 7.5.0 mit PHP7 Unterstützung veröffentlichtDie bekannte Marktplatzsoftware ebiz-trader ist in der Version 7.5.0 veröffentlicht worden.

28.05.2018 | Berni

Wissensbestand in Unternehmen
Wissensbestand in UnternehmenLebenslanges Lernen und Weiterbilden sichert Wissensbestand in Unternehmen

25.05.2018 | Berni


 

Aktuelle PHP Scripte

PHP Server Monitor

PHP Server Monitor ist ein Skript, das prüft, ob Ihre Websites und Server betriebsbereit sind.

11.09.2018 Berni | Kategorie: PHP/ Security
PHP WEB STATISTIK ansehen PHP WEB STATISTIK

Die PHP Web Statistik bietet Ihnen ein einfach zu konfigurierendes Script zur Aufzeichnung und grafischen und textuellen Auswertung der Besuchern Ihrer Webseite. Folgende zeitlichen Module sind verfügbar: Jahr, Monat, Tag, Wochentag, Stunde Folgende son

28.08.2018 phpwebstat | Kategorie: PHP/ Counter
Affilinator - Affilinet XML Produktlisten Skript

Die Affilinator Affilinet XML Edition ist ein vollautomatisches Skript zum einlesen und darstellen der Affili.net (Partnerprogramm Netzwerk) Produktlisten und Produktdaten. Im Grunde gibt der Webmaster seine Affilinet PartnerID ein und hat dann unmittelb

27.08.2018 freefrank@ | Kategorie: PHP/ Partnerprogramme
 Alle PHP Scripte anzeigen

Alle Zeitangaben in WEZ +2. Es ist jetzt 21:31 Uhr.