Variable von Seitenlink an Template übergeben?

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-api-querystrings-uebergeben-und-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/Filter_Reference/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.

Code:

Entschuldige, aber du musst dich registrieren oder anmelden um den Inhalt sehen zu können!

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:

"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 "www.example.com/rubrik/abc/968/"
statt "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:

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:

Entschuldige, aber du musst dich registrieren oder anmelden um den Inhalt sehen zu können!

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)

PHP:

Entschuldige, aber du musst dich registrieren oder anmelden um den Inhalt sehen zu können!

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:

PHP:

Entschuldige, aber du musst dich registrieren oder anmelden um den Inhalt sehen zu können!

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:

PHP:

Entschuldige, aber du musst dich registrieren oder anmelden um den Inhalt sehen zu können!

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.