Beiträge von codestyling

    Anbei ein kleines Plugin (kannst je gern umbenennen), das alle Links in einer Seite, deren href auf png | jpg | gif enden, in einem Popup darstellen.
    Um die Größen korrekt automatisch zu ermitteln, müsste ich mehr Zeit reinstecken in die Entwicklung, wäre aber machbar.

    In dieser Version ist deshalb die Größe der Öffnung halbautomatisch:

    HTML
    <a href="/media/bug.jpg" alt="500|300" title="was auch immer">TEST BILD</a>

    Im alt Attribute musst du Breite und Höhe als erstes mit | getrennt angeben, dann wird das Fenster in dieser Größe geöffnet.
    Wenn das nicht geht bei dir, dann im javascript des Plugins wieder feste Wert weiterhin benutzen.

    Bei diesen Zusatzwünschen und möglichen Blockierung der Popup Windows durch Popup Blocker, wäre es vermutlich eine bessere Option, eines der Plugins zu verwenden, die Bilder in div overlays darstellen.
    So was wie Gallery Plugins usw.

    Ich selbst benutze diese Plugins allerdings nicht, denn ich habe keine Gallerien. Allenfalls ein Bild, das ich gezoomed in einem div als Overlay haben will. Dafür hab ich eigene Scripts, die allerdings etwas Ballast mit sich bringen, denn das ist nicht das Einzige, was ich mit Scripts mache.

    Wenn du dennoch auf der window.open( Variante bestehts, dann kann ich dir das Script bereitstellen. Aber Freude macht das dann den Besuchern deiner Seite nicht, denn der Popup Blocker wird da u.U. eingreifen.

    hmm, wenn du WP auf der neuen Domain aufgesetzt hast und einen kompletten SQL Dump (vorher manuell gepatched) eingespielt hast,
    kann es sein, das deine ID's verschoben worden.

    Hast du den SQL Dump so erstellt, das er die existierenden Tabellen droppen und neu erstellen soll, bevor importiert wird ?
    Nur so kannst du ID 222 im alten Blog auch wieder auf ID 222 im neuen Blog haben.
    Wenn nicht (da ID ein auto-increment Spalte ist), führen die bisherigen Einträge im neuen Blog (selbst wenn sie gelöscht wurden) dazu, das alte ID 222 jetzt z.B. neue ID 234 ist.

    Da Thumbnails nur bei Hochladen generiert werden (laut Code) und nachher nur per ID gesucht bzw. default ausgegeben wird, kann so das Thumb evtl. nicht gefunden werden.

    Falls du von der alten Domain noch ein SQL Dump machen kannst, das die Drop und Erstellungsanweisung mit enthält, dann deine Patches machst und das importierst, sollte es funktionieren.

    Ich weiß nicht, ob ich das gut finden soll, wenn sogar auf der Impressum Seite der Hauptdomain Werbe Popups aufgehen, 1000nde Cookies gesetzt werden und XSS Zugriffe versucht werden ([COLOR=Red]uncaught exception: Die Erlaubnis für den Aufruf der Methode Location.toString wurde verweigert[/COLOR]).

    Sehr seriös sieht mir das nicht aus, aber das sollte wohl das WPD Team beurteilen.

    Das ist ein Problem, mit dem sich javascript Programmierer befassen müssen.
    Laut HTML Spezifikation ist ein tbody Vorschrift, jedoch behandeln das diverse Browser unterschiedlich.

    Allerdings verstehe ich nicht, weshalb du deine CSS dann anpassen müsstest, denn die Style Kaskaden für table tr td {....} funktionieren nach wie vor, auch wenn da ein tbody drin ist.

    Hallo,

    es gibt da einige Möglichkeiten, das zu automatisieren. Da du sowieso Javascript voraussetzt, ist es unnötiger Rechenaufwand, die Fenster auf dem Server reincodieren zu lassen. Das kann auch ein weiteres Script auf dem Client erledigen und verringert deine Serverbeanspruchung.

    Allerdings müsste man wissen, ob du immer nur jpg oder auch andere Bildformate benutzt, welche WP Version du einsetzt und ob das für alle <a> gilt, deren href auf ein Bild verweist.

    Der Vorteil in clientseitigen Bearbeitung (per Script) liegt in der weiterhin gegebenen Validierung und für Leute, die kein Javascript angeschaltet haben, in der Benutzung der Links, die dann trotzdem funktionieren sollten (könnte man ja noch einen target='_blank' reinmachen).

    Du kannst die o.g. Informationen hier posten oder mir eine PM schicken, dann kann ich dir die max. 10 Zeilen JS Code anpassen und bereitstellen.

    Also wenn du schon an der .htaccess rumspielst, dann sind 2 Sachen zu beachten:
    1.) setze deine Änderungen niemals in die WordPress Sektion rein, denn diese wird neu generiert, wenn du in den Einstellungen änderst und du verlierst deine Modifikation!
    2.) Bei Weiterleitungen mußt du schon sagen, das sie enden soll.

    Somit stoppt das zumindest erstmal und kann durch Änderungen im WP Backend nicht mehr entfernt werden, aber das, was du eigentlich damit beabsichtigst, ist nicht evtl. immer noch nicht gelöst.

    Was willst du eigentlich mit den Umschreibung von Benutzernamen erreichen ?
    Warum willst du die überhaupt umschreiben ?

    Die Fehlermeldung sagt aus, das WordPress bereits begonnen hat, Teile der Webseite an den Client weiterzugeben (mal einfach formuliert).
    Das passiert z.B. wenn deine single.php schon so was wie

    PHP
    <?php get_header(); ?>


    ausgeführt hat und du erst danach den Captcha Code eingebaut hast.
    Dieser mußte aber das allererste deine single.php sein, denn nur hier kann noch ein Cookie gesetzt werden, da noch keine Seitendaten produziert wurden.

    Wenn der Fehler auch dann noch auftritt, wenn es als Erstes drinsteht, spielt eines deiner aktiven Plugins nicht mit und gibt schon was aus. Dann muß du alle Plugins erstmal deaktivieren (bis auf dein Captcha Plugin) und Eins nach dem Anderen aktivieren, um zu prüfen, welcher der Übertäter ist.

    Das hat immer rechtliche Hintergründe.
    Man kann zu Beispiel dpa Meldungen (Deutsche Presseagentur) verwenden, wenn man sich an die Bedingungen hält, die dafür gelten.
    Man sollte so etwas immer im Kontakt mit der Content-Quelle abklären, in dem man eine E-Mail hinschickt und fragt, wie man das benutzen darf.
    Wenn man dann eine Antwort schwarz auf weiss hat (gleich mit Mail Header ausdrucken!), dann ist man rechtlich auf der sicheren Seite.

    In Bezug auf Suchmachinen Indizierung kommt man leicht in die Problemzone "doppelter Content", den die Suchmachine abstraft. Eine 1:1 Übernahme (was anderes kann ein Automat ja erstmal nicht) empfiehlt sich daher nicht.
    Wenn man nachbearbeitet, wird das besser, aber man muß dann trotzdem alles durchgehen und kann das auch von Hand "einkleben", bevor man es umschreibt.

    Ich sehe da erstmal wenig Vorteile, Auszüge aus Feeds anderer Seiten stehen da auf einem anderen Blatt.

    Vorsicht!

    Die Domain "[COLOR=Red]www . meineadresse . de[/COLOR]" ist eine offiziell registrierte Domain bei der Denic und gehört jemanden.
    Diese aus Dummyzwecken hier einzusetzen, kann Beschwerden des Besitzers nach sich ziehen, wenn der sich durch die Besucher dieses Forums beeinträchtigt fühlt, die alle diese Links anklicken!

    Bitte entweder die korrekte, eigene URL angeben (hilft sehr viel mehr als ein Phantasie URL) oder eine, die nicht öffentlich ist, wie "[COLOR=Green]http://www.will-ich-nicht-sagen.test/bla-seite[/COLOR]".

    Das ist ein Bug, den es schon seit einigen Versionen immer mal wieder gibt!
    Das Verfahren von wpautop (automatische Paragraphen erstellen) funktioniert meiner Meinung nach mehr als nur suboptimal!
    Immer wieder gibt es diese Bug's, dass bestimmte Eingaben mit <p> umschlossen werden, die es nicht sollten oder es entstehen halboffene <p>, die dann letztlich alle die Validität vom HTML verletzen.

    Ich hab's kurz nachgestellt:

    Code
    <p>dsfsdlfg</p>
    <hr />
    [B][COLOR=Red] dsflg</p>[/COLOR][/B]
    <p>dfölg</p>

    Das liegt an WordPress, ob es jetzt wieder der Editor ist, der wieder mal fehlerhafte regular Expressions benutzt oder im Backend, wenn die Paragraphen erstellt werden, müsste man mal wieder rausfinden.

    Wenn man Windows Live Writer nicht benutzt, dann kann man die Datei /wp-includes/wlwmanifest.xml auch löschen. Wenn es jemand abrufen will, gibt's dann eine 404 Seite.

    Warum sollte ich das überhaupt löschen ?

    Es outet sich damit eine WordPress Installation, auch wenn man es ihr sonst nicht ansehen würde. Es soll ja Betreiber geben, die nicht sofort die "Hosen runterlassen" wollen :)

    Nebenwirkungen: Windows Live Writer geht nicht mehr mit dem Blog, sonst keine.

    Die Entfernung der Links (wie in den vorgenannten Post) ist ebenfalls zur kosmetischen Bereinigung der Existenz von WordPress nötig, aber ob es sinnvoll ist, sei mal dahingestellt...

    Nein, im FireFox ebenfalls:

    Code
    Class is not defined
    http://www.pensiona.de/wp-content/plugins/mbox/js/js.php
    Line 43

    Dein mbox Plugin braucht MooTools (siehe js Header: Based on Mootools v1.11) und das wird nicht geladen.
    Damit kann mBox nicht funktionieren.

    Sehr halbherzige Sache, guggst du hier: :mrgreen:

    Code
    http://johannes-ruthenberg.de/blog/wp-includes/wlwmanifest.xml

    Kann man abrufen, jederzeit!
    Übrigens überprüfe ich gerade, ob es Nebenwirkungen hat auf Kommentare, Pingback's oder Postback's, wenn man das entfernt. Kann noch etwas dauern, durchforste den WP Code gerade.

    hmm, also der Code hat schon ein paar Jahre auf dem Buckel :-D
    Jetzt weiß ich auch, was du meinst. Die Eingaben, die der Benutzer machen kann für die Beschriftung der Eingabefelder ist ja gerade aus Ermangelung einer *.mo Übersetzung gemacht worden und weil man so z.B. Webseite gegen Skypename austauschen kann.
    Allerdings geht das dann nicht mehr in Japanisch, Chinesisch oder sonstwas anzuzeigen, denn du hast ja nur diese eine Wahl, wie das beschriftet wird.

    Wenn du das schon als Basis für einen Umbau nehmen willst, solltest du überlegen, ob man Wahlfreiheit erlaubt, oder ob man feste Dropdown Listen anbietet, deren Inhalte per *.mo Datei bereits feststehen.
    Dann kann man keine Beschriftungen mehr eingeben, sondern nur noch wechseln. Was nicht vorhanden ist und jemand braucht, könntest du als nächste Version bereitstellen.

    Was mir noch auffällt ist, das dieses
    1.) Plugin offensichlich register_globals braucht, was nicht immer geht und u.U. ein Sicherheitsproblem ist,
    2.) Das Formular ohne Javascript nicht richtig (oder gar nicht) geht,
    3.) ich mir nach flüchtiger Durchsicht nicht sicher bin, ob das Spam-sicher genug ist.

    PS: Die Verbesserung im vorigen Post bezog sich auf den Plugin Ordner, der somit frei wechselbar wäre (aber eben nicht für dieses Plugin, weil das auch wieder hart codierte Pfade nutzt).

    Was kann ich denn da machen?


    Wie wär's mit einem Link zum ursprünglichen Source des Plugin's, den du benutzt? Ohne die Ursprungsquelle, muß ja nicht WP Plugin Store sein, wird's schwer, sich was vorzustellen, wenn man das Plugin gar nicht kennt :-D

    PHP
    load_plugin_textdomain('intouch', PLUGINDIR . '/intouch/');


    Ich mag "fest verdrahtete" Pfade gar nicht! Ich möchte pro Plugin, das was auf sich hält, immer noch selbst entscheiden können, wie dessen Pfad lauten soll.
    Für mich sind Plugin's, die nicht damit zurecht kommen, das man ihren Pfad umbenennt, einfach nicht tolerant genug geschrieben und unflexibel.
    Es gibt öfter Kollisionen bei zig Tausend Plugins in der Welt, das jemand den gleichen Pfad für ein Plugin gewählt hat, den ein anderes schon benutzt, dann muß man das einfach umbenennen können.

    PHP
    load_plugin_textdomain('intouch', PLUGINDIR."/".dirname(plugin_basename(__FILE__)));

    Wenn man den Plugin Base Name benutzt, kannst du das Verzeichnis des Plugin's umbenennen, wie du lustig bist, es funktioniert immer.

    Dazu kennt WordPress die Funktion is_user_logged_in() um zu prüfen, ob man eingeloggt ist oder nicht.

    Damit könnte man in der index.php deines Themes dann als Erstes so was machen wie:

    PHP
    <?php
    if (is_user_logged_in()) {
       require_once("die-andere-index-seite.php");
       exit;
    }
    ?>

    Alle nicht eingeloggten Besucher bekommen dann die normale index.php generiert (der Rest der php Datei).