Variable von Seitenlink an Template übergeben?

Zitat von dliste

Es stimmt also nicht, dass WP nur eine Variable übergeben kann, so wie ich es in der letzten Woche überall gelesen habe.

Wer hat denn so etwas geschrieben?
Im unteren Beispiel übergebe ich zum Beispiel zwei, wollte nur seit Wochen den Text ergänzen, weil es mit Einzelheiten zum besseren Verständnis noch haperte.

http://www.coder-welten.com/die-wp-rewrite-api/

Du kannst nur nicht unbegrenzt viele übergeben und die Du übergibst, müssen auch als query_vars vorhanden sein oder als neue query_vars hinzugefügt werden. Siehe erste Funktion im Beispiel, da fehlt die Beschreibung noch vollständig.

http://www.coder-welten.com/die-wp-rewrite…nd-umschreiben/

Ich hatte mich nur herausgehalten, weil ich nichts von der Sicherheit von Zugriffen auf externe Datenbanken weiß. Was verhindert da den Zugriff von Unbefugten, wie sind die Sicherheitsvorkehrungen?

Bei den meisten Hostern wird ein externer Zugriff ohnehin nicht möglich sein, denke ich mir. Für einen Webservice oder so könnte ich mir aber zum Beispiel eine Schnittstelle über WSDL oder Rest vorstellen, um eine gewisse Trennung zu erreichen. Somit sollte eigentlich auch die externe Datenbank für externe Zugriffe gesperrt werden können und die Anfrage betreffend Abrufs von Daten über ein Script mit einer Schnittstelle erfolgen, welches bei dem Hoster liegt, bei dem sich der Datenbankserver befindet. Oder so in etwa zumindest.

Die Beschreibung von der Codex-Seite ist auch nicht gerade erschöpfend.

http://codex.wordpress.org/Plugin_API/Fil…ence/query_vars

Damit WP zum Beispiel den Wert von s von der Suche verarbeiten kann, muss WP s kennen. Du übergibst /?Parameter=Wert&Parameter-zwei=Wert2 und WP muss den/die Parameter kennen, um mit dem Wert etwas anfangen zu können, es sei denn Du liest die mit $_GET aus.

$_GET["Parameter"]
$_GET["Parameter-zwei"]

Wenn Du aber zum Beispiel die Einstellung Beitragsname verwendest, geht es nicht anders, Du musst Parameter und Parameter-zwei bei WP als query_vars hinzufügen und dann eine entsprechende Rewrite Regel schreiben, um richtig darauf zugreifen zu können. Und nur so ist dann eine Übergabe möglich wie bei:

"http://www.example.com/rubrik/354/968/"

Die Seite ist besser und enthält auch vorhandene und Beispiele und wenn die vorhandenen nicht genügen, fügst Du eigene hinzu:

http://codex.wordpress.org/WordPress_Query_Vars

Hier noch etwas zur Verarbeitung:

http://codex.wordpress.org/Function_Reference/get_query_var

Nun sollte ich wohl meine eigene Beschreibungen fertigstellen, damit jemand damit anzufangen weiß.

Na ja, klar geht das auch, macht man ja bei einem anderen PHP-Script nicht anders. Nur wenn man bei einem anderen Script keinen QueryString anhängen möchte, definiert man die Rewrite-Regeln in einer htaccess. WP verwaltet aber Rewrite-Regeln selbst, deshalb muss man diese zu WP hinzufügen.

Wobei es nicht nur um ein sauberes Aussehen der URL geht, sondern auch gleich ein kleinwenig mit um die Sicherheit. Bei $_GET würde ich als Filter eine Zeichenklasse verwenden, bei Ziffern als Wert eben [^0-9], bei WP-Rewrite-Regeln oder bei sonstigen PHP-Scripts mit htaccess-Rewrite-Regeln würde ich es nicht anders machen, doch zusätzlich bereits einen versuchten Seitenaufruf

mit "http://www.example.com/rubrik/abc/968/"
statt "http://www.example.com/rubrik/354/968/"

mit Forbidden oder einer Weiterleitung auf eine Fehlerseite vereiteln. Sonst könnte da jemand zu viel experimentieren, was alles als Wert übergeben werden kann. Und versuche gibt es immer wieder, mal ein Beispiel aus meinen Statistiken:

Zitat

? 2D 64+ 61 6C 6C 6F 77 5F 75 ...

Gehe davon aus, dass die Lücken mit Prozentzeichen aufgefüllt waren, welche der Filter aussiebte. Mit einer vernünftigen Rewrite-Regel würden die halt bereits vor einem Filter entschärft. Und ich habe schon genügend gesehen, die jeglichen Filter für $_GET vergessen hatten.

Bleibe mal hier im Forum, lässt sich hier besser darstellen als in einer PN und wenn ich jetzt poste, weiß keiner warum. Es gibt unterschiedliche Möglichkeiten, einige verwenden gern die Funktion strip_tags. Ich schreibe es lieber so, wobei es dann je nach Aufgabe angepasst werden muss. Bei Deinem Vorhaben könnte es etwa so aussehen und alles Wesentliche geht denke ich aus den Kommentaren hervor.

<?php
// Variablen bekanntmachen und mit einem Anfangswert belegen
$id = false;
$to = false;


/* Moegliche Werte fuer den Parameter to durch
   Komma getrennt notieren, Groß- und Kleinschreibung
   beachten
 */
$to_arr = array('Winterland',
                'Sommerland',
                'Morgenland',
                'Abendland',
                'Schlaraffenland'
                );


/* Pruefe, ob der Parameter id übergeben wurde und
   einen Wert enthält
 */
if (isset($_GET['id']) and !empty($_GET['id'])) {
    $id = $_GET['id'];
    // Entferne alles außer Ziffern
    $id = preg_replace("/[^0-9]/", "", $id);
}


/* Pruefe, ob der Parameter to übergeben wurde und
   einen Wert enthält
 */
if (isset($_GET['to']) and !empty($_GET['to'])) {
    $to = $_GET['to'];
    /* Entferne alles außer Buchstaben (ohne
       Umlaute), Unterstriche und Bindestriche
     */
    $to = preg_replace("/[^a-zA-Z_-]/", "", $to);
    // Pruefe ob Wert fuer to im Array enthalten ist
    if (in_array($to, $to_arr, true) == false) {
        /* Falls der Wert fuer to nicht im Array
           enthalten ist, so to auf false setzen
           oder einen Ersatzwert zuweisen oder 
           exit verwenden
         */
        $to = false;
    }
}


?>

Ließe sich noch alles in eine Funktion packen, doch das braucht nicht unbedingt zu sein bei einfachen Listings.

Hier braucht Dir nichts peinlich zu sein. In WP einzusteigen, wenn man etwas mehr möchte, als nur ein fertiges Theme unverändert zu benutzen, ist nicht einfach. Immer wenn ich denke, ich wüsste schon recht viel, kommt ein Tiefflug mit unsanfter Landung.

Und das andere, so lange es Beispiele wie dieses (war jetzt nur das erste welches ich fand)

Welcome <?php echo $_POST["name"]; ?><br>
Your email address is: <?php echo $_POST["email"]; ?>

http://www.w3schools.com/php/php_forms.asp

gibt, wo die Ausgabe nicht einmal mit echo htmlspecialchars($_POST["name"]) zumindest etwas abgesichert wird, wundert mich eh nichts. Denen sollte so etwas peinlich sein, nicht Dir. Wobei denen braucht das auch nicht unbedingt peinlich sein, weil Beispiele eigentlich nur das Prinzip verdeutlichen sollen, nur von vielen dann als Codeschnipsel übernommen werden.

Muss mich korrigieren, hatte nur den Text nicht beachtet, die Seite enthält ja eine Sicherheitswarnung und zwei Seiten weiter kommt dann auch ein Beispiel, wie die Ausgabe abgesichert werden kann.

Jetzt müsste mir das eigentlich peinlich sein, nicht gleich soweit gelesen zu haben:

function test_input($data)
{
  $data = trim($data);
  $data = stripslashes($data);
  $data = htmlspecialchars($data);
  return $data;
}

http://www.w3schools.com/php/php_form_validation.asp

Und noch ein oder zwei Seiten weiter dann Beispiele, wie bereits der Eingang abzusichern und zu filtern ist:

$name = test_input($_POST["name"]);
// check if name only contains letters and whitespace
if (!preg_match("/^[a-zA-Z ]*$/",$name))
  {
  $nameErr = "Only letters and white space allowed";
  }

http://www.w3schools.com/php/php_form_url_email.asp

Also doch richtig gut die Seite für einen ersten Überblick, falls nicht alle nur soweit die Seite betrachten, wie ich beim ersten Aufruf.