Beiträge von Putzlowitsch

    Bei mir schon, da ich in der Lage bin, das Error-Reporting einzustellen. Hilft alles nichts, ist ein Fehler. Punkt. :roll:

    Echt? Wieso sollte ein Leerzeichen nicht in einem String erlaubt sein und entsprechend einen Parse-Error erzeugen. Ich habe in PHP schon viele Strings mit Leerzeichen drin geschrieben und noch nie eine Parse-Error erhalten, selbst mit Error-Reporting ALL oder so. :)

    Gruß
    Ingo

    Ne nee, ist schon in Ordnung. :)

    Ein wirklicher Streit ist das ja nicht, nur der Austausch unterschiedlicher Ansichten und Meinungen. Und wie gesagt, das mit dem Shortcode von formateins hat mir ja ein paar Denkanstöße gegeben. In der Regel bringt so eine Diskussion, mag sie noch so kontrovers sei, letztendlich die Sache doch oft voran.

    Zu dem Problem. Ich habe das Plugin nur mit WP Version 3.5.1 getestet. Welche Wordpress-Version verwendest Du denn?

    Gruß
    Ingo

    Michi91 hat die richtige Lösung schon gebracht. Innerhalb eines Strings, der als Begrenzer einfache Anführunsgzeichen hat, müssen diese maskiert werden. So z.B. an der Stelle:

    Code
    $items .= '... onblur="this.placeholder = [B]\[/B]'suchen...[B]\[/B]'" ...';


    Vor und nach dem 'suchen...'.

    Das Leerzeichen im add_filter führt zwar dazu, daß die Sache selbst nicht funktionieren wird, erzeugt aber keinen PHP-Parse Error.

    Gruß
    Ingo

    So, habe nun die Version 0.20 des "123 PrePage"-Plugins fertig. Es verwendet einen Shortcode und POST-Variablen, aber ganz ohne Cookies geht es halt nicht. Oder sagen wir mal so, die Cookies vereinfachen doch vieles.

    Ist zwar vermutlich nicht das, was sich formateins vorgestellt hat, aber die Idee mit dem Shortcode hat mich weiter gebracht, auch wenn ich ihn nun auf der vorgeschalteten Seite verwende. :)

    Und so funktionierts:
    Auf der vorgeschalteten Seite (AGB) wird an der gewünschten Stelle der Shortcode [prepage_button] eingefügt. Der Text kann in den Plugin-Optionen oder direkt im Shortcode als Parameter button_text festgelegt werden. Das Mini-Formular und der Button können über die Classen prepage_form und prepage_button angepaßt werden.

    In den Plugin-Optionen werden die Seiten-ID der vorgeschalteten Seite und die IDs der zu schützenden Seiten (mit Komma getrennt) eingetragen.

    Das passiert nun:
    Der Nutzer kommt auf eine geschützte Seite, hat aber noch keine Verifikations-Cookie. Es wird ein Seiten-ID-Cookie gesetzt und er wird auf die vorgeschaltete Seite weitergeleitet. Hier muß er nun den Bestätiguns-Button drücken und gelangt an Hand des Seiten-ID-Cookies auf die vorhergehende Seite. Er bekommt das Verifikations-Cookie verpaßt und kann nun bis zum Ablauf des Cookies (Voreinstellung: 30 Tage) alle geschützten Seiten aufrufen.

    http://schnurpsel.de/wordpress-plugins/123-prepage/

    Noch Fragen? :)

    Gruß
    Ingo

    ...
    Die Shortcode-Plugin-ich-mach-mal-eine-Seite-dicht existiert natürlich nicht - warum sollte ich das Erstellen?
    ...


    Na weil wir uns hier im Bereich "Plugins und Widgets" befinden, der TE deshalb eher eine fertige Lösung als eine Anleitung zum selbst programmieren sucht und weil Du eine netter Mensch bist. :)

    ...
    Hab jetzt keine Lust mehr - insbesondere nicht, wenn $_POST ja so leicht zu manipulieren ist...


    Ach komm, nu sei mal nicht eingeschnappt. ;) Ich habe ja nicht gesagt, daß $_POST so leicht zu manipulieren ist. Ich habe nur festgestellt, das es nicht schwerer oder leichter als bei Cookies geht.

    ...PS: Mit dem Login zum Online-Banking bist Du angekommen, deswegen :roll:


    Ich wollte damit eher auf das meiner Meinung nach unterschiedliche, erforderliche Sicherheitsniveau hinweisen. War vielleicht mißverständlich formuliert. Beim Banking-Login sind da sicher höhere Anforderungen zu stellen, als beim Abnicken einer AGB. Allerdings weiß ich nicht, worum es da beim TE wirklich geht. Insofern kann man da keine pauschale Aussage machen.

    Andererseits hat mein Plugin tatsächlich noch eine Mangel, das gebe ich zu. Der Nutzer bekommt die vorgeschaltete Seite nur angezeigt und muß nicht aktiv ein Häkchen oder sowas setzen, daß er den AGB zustimmt. Wäre was für die Version 0.20 oder so.

    Gruß
    Ingo

    Schau mal meine Beiträge durch - findest Du noch eine ganze Menge mehr... ;)

    Genau das ist es ja, was mich etwas verwundert. Viele Deiner Beiträg sind ja wirklich hilfreich und so verstehe ich nicht, daß Deine Antworten ab und zu für mich eben nicht in dieses Bild passen.

    Gut, bei zwei Sachen, ich denke Du weißt, was ich meine, hatte ich mich doch im Ton vergriffen. Ich war da noch etwas von den "Beiträgen" von FragSelten angefressen (wo ist der eigentlich abgeblieben?). Dafür entschuldige ich mich. Ich habe in den letzten Tagen versucht, sachlich zu bleiben und hoffe, das ist mir weitestgehend gelungen.

    Oh Mann, das ist jetzt aber off-topic, mußte aber mal raus.

    Gruß
    Ingo

    Wahrscheinlich eher, als alles 08/15-mäßig durchzukauen und was fertiges vor die Füße zu werfen. Lösung ja, aber nix verstanden. Top!

    Ja klar doch, es gibt ja nur Programmierer auf der Welt, schmeißt alle Wordpress-Plugins weg und die Themes gleich hinterher, soll sich doch jeder alles selber machen. Fertige Sachen verwenden, pahh! :)


    Wundert mich nicht - defensives Programmieren ist nicht jedermanns Sache.


    Das ändert nichts daran, das POST-Variablen genau so zu manipulieren sind, wie Cookies, da kannst Du noch so defensiv programmieren, wie du willst. Also gibt es per se keinen Vorteil einer POST-Variable, mißtrauen mußt Du denen genau so wie Cookies.

    Vielleicht googelst Du mal zu dem Thema AGB und deren rechtliche Verbindlichkeit ein wenig (huch, keine Erklärung, nur eine Andeutung). Nur als Hinweis: bei einem Login muss man keine AGB's akzeptieren...


    Auch Deine POST-shortcode-Lösung, wie auch immer sie funktionieren mag, garantiert nicht, daß der User die AGB ließt. Ich sehe immer noch keinen wirklichen Vorteil Deiner Lösung, sie ist weder sicherer, noch rechtsverbindlicher noch weniger manipulierbar noch sonst irgendwas, außer, daß sie nicht existiert nicht. :roll:
    Und um Logins (toller Hinweis) ging es hier gar nicht, oder habe ich was übersehen.

    Gruß
    Ingo

    Daß ein Bild frei im Netz zugänglich ist, also irgendwo auf einer Webseite angezeigt wird, heißt nicht, daß es auch frei verwendet werden kann. Oder was meinst Du mit "frei zugänglich"?

    Selbst die Angabe eines Copyright-Vermerkes ist nicht unbedingt ausreichend. Bei Verwendung von Bildern immer nachfragen und sich ggf. bestätigen lassen, daß diese verwendet werden dürfen. Alles andere kann problematisch werden.

    Gruß
    Ingo

    Vielleicht, weil ich nicht immer alles bis in Detail erkläre?...

    Genau da liegt das Problem, mit Andeutungen ist hier niemandem geholfen.
    Aber momecko kann sich jetzt bestimmt mit Deinen Hinweisen irgendwas selbst zusammenzimmern. :)

    Und das POST-Variablen nicht, oder sagen wir mal schwerer als Cookies zu manipulieren sind, ist mir auch neu.
    Außerdem geht es hier nicht um das Login für ein Onlinebanking oder Ähnliches. Um den Aufruf der AGB-Seite zu umgehen, ein Cookie manipulieren, ja klar. Eine wirklich hohe kriminelle Energie muß man da schon haben. :)

    Gruß
    Ingo

    Da haben wir den Salat! :)
    Hast Du doch noch beide Plugins aktiv?
    Ich sehe jetzt nämlich zweimal im Header die Einträge für Meta-Description und Rel-Canonical.

    Also wie gesagt, am besten Du entscheidest Dich für eines der Plugins, deaktivierst und löschst das andere. Welches nun das bessere ist, kann ich nicht sagen, ich verwende keine SEO-Plugins.

    Gruß
    Ingo

    Da bei der Seite keine Permalinks eingeschaltet sind, gehören auch die WP-Rewrite-Rules nicht in die .htaccess-Datei rein.

    Das Verhalten ist allerdings sehr merkwürdig. Jeder zweite Seitenaufruf funktioniert. Also erst kommt der Fehler 500, wenn man die Seite dann aktualisiert, wird sie angezeigt. Aktualisiert man nochmal, kommt wieder der Fehler 500, beim nächsten Aktualisieren wird sie wieder angezeigt usw.

    Das kann eigentlich nicht direkt etwas mit der .htaccess zu tun haben, ich würde eher auf ein Plugin tippen.

    Außerdem ist mir aufgefallen, daß die WP-Installation eigentlich im Unterverzeichnis /wordpress/ liegt. Wenn ich mir aber ein paar Google-Treffer ansehe, führt der Link direkt auf die Domain (mit Parameter z.B. ?page_id=2).

    Wurde da in letzter Zeit etwas veränder?

    Gruß
    Ingo

    Die Frage ist ja, werden die Pingbacks nicht gesendet oder kommen sie nicht an?

    Die von mir genannte Option bezieht auf auf des Versenden der Pingbacks, also von der Seite, wo Du den Link im Artikel setzt. Die von Dir genannten Option bezieht sich auf den Empfang eines Pingbacks, die muß natürlich auf der Seite/dem Artikel, wo der Link hinzeigt, aktiv sein.

    Es kann auch noch technische Probleme geben, falls der Webhoster keine ausgehenden Verbindungen erlaubt.

    Liegen den alle Deine drei Seiten beim selben Webhoster?

    Gruß
    Ingo

    ... Ich erwarte von eiem SEO Plugin eigentlich nur, dass die Seite über google gefunden wird - wenn jemand z.B. eine Physiotherapie in einem bestimmten Ort haben möchte. ...

    Das wird so aber auch nicht funktionieren. Ein Seo-Plugin schafft quasi nur die technischen Voraussetzungen, das Google die Seite gut indexieren und und den Suchindex aufnehmen kann. Die sogenannten OnPage-Faktoren sind aber nur ein kleiner Teil der Optimierung.

    Wichtig sind natürlich auch für den Nutzer intessante Inhalte und auch immer noch Links von anderen Seite zu Deiner Seite. Das kann ein SEO-Plugin nicht leisten.

    Du könntest ja z.B. hier mal einen Link zu Deiner Seite posten, dann könnte man gucken, ob technisch alles in Ordung ist. :)

    Gruß
    Ingo

    Es gibt bei Einstellungen › Diskussion die Option

    Zitat

    [x] Versuche jedes in Artikeln verlinkte Weblog zu benachrichtigen


    Ist diese Option eingeschaltet? Wenn nicht, werden auch keine Pingbacks (automatische Trackbacks) verschickt.

    Gruß
    Ingo