Beiträge von Melewo

    Die class WP_Query in der Datei wp-includes/query.php enthält wohl die wichtigsten SQL-Anweisungen, nehme ich mal an. Jedenfalls ist mir nicht bekannt, ob sich WP einfach auf eine andere Datenbank als MySQL oder MariaDB aufsetzen lässt. Mit PDO sollte es eigentlich gehen, doch habe ich mich bisher dafür weniger interessiert und so sehr viel Treiber gibt es wohl bisher nicht für unterschiedliche Datenbanksysteme.

    Hier lief mal ein Test mit MySQL und WordPress, es ging um eine Grenze auszuloten, danach zu suchen hätte jetzt wenig Sinn und die Grenze würde ich in 20 Jahren nicht erreichen. MySQL und WordPress hatten keine Probleme, die Probleme kommen wohl nur durch eine aufgeblähte Verschachtelung in 1.000 Kategorien und Unterkategorien oder so.

    Eigene PHP-Dateien kannst Du entweder als Template-Dateien anlegen oder als Plugins programmieren. An den Core-Dateien solltest Du möglichst nichts verändern, sonst kommst Du aus den Änderungen nach den Updates nicht heraus. Also der "Handwagen" lässt sich durch Themes, Frameworks und Plugins erweitern.

    Es kommt halt darauf an, was Du vorhast und ob Du nicht letztendlich schneller bist, wenn Du ein eigenes Backend und Frontend entwickelst oder ein anderes CMS verwendest, welches mehr auf den Bedarf von Unternehmen abzielt. Las erst vor kurzer Zeit, dass zum Beispiel (vergesse den Namen immer wieder) so ein ERP (Enterprise Resource-Planning) sich nicht (oder nur bedingt) mit WP umsetzen lassen soll.

    Also die Domain bleibt erhalten, nur seiten-namen.html ändert sich in /beitrag-anderer-name/ oder so?

    Dann fügst Du in der htaccess vom Root-Verzeichnis, also da, wo die Domain drauf zeigt, in dieser gleich zu Anfang die Redirects ein:

    Code
    Redirect 301 /alte-seite.html     http://www.example.com/neue-seite/
    Redirect 301 /alte-besen.html     http://www.example.com/neue-besen/
    Redirect 301 /truebe-stunden.html http://www.example.com/schoenes-wetter-heute/

    Na ja, Du wirst doch ohnehin von 3.9 auf 3.9.1 updaten. Dann wechsel doch bei der Gelegenheit die beiden Verzeichnisse wp-admin und wp-includes komplett per FTP, dann sollte es doch wieder gut sein.

    Stochere jetzt nur im Dunklen, Probleme mit einem Werbeblocker würde ich nicht völlig ausschließen. Wenn Du zum Beispiel auf "Beitrag ansehen" klickst, sollte die komplette WP Adminbar im Quelltext der Seite unten eingeblendet werden, die wird dann nur in der Ansicht oben angezeigt. Also, schaue doch zuerst im Quelltext nach, ob die in den Quelltext geladen wird.

    Falls das der Fall sein sollte, könnte ein Plugin, welches vorher in die Seite geladen wird, nicht mehr richtig vom JavaScript-Code her valide sein, da alle Browser mittlerweile die "use strict" Variante bevorzugen. Letztendlich bedeutet dann ein Fehler in einem Plugin (der in Browsern der vorletzten Generation noch kein Fehler war), dass die Browser die Ausführung von JavaScript abbrechen und die unten im Quelltext eingefügte Adminbar nicht mehr sichtbar oben im Browser ausgegeben werden kann, würde ich vermuten.

    Doch mehr als eine Vermutung ist das alles nicht, nur wirre Gedanken halt, wie es möglichweise sein könnte.

    Also, der QR-Code auf einer Broschüre enthält die Binärdaten von einem Verweis von einer Webseite und wenn jemand mit einem mobilen Endgerät den Code von der Broschüre einscannt, dann öffnet der Browser von seinem mobilen Endgerät die alte Webseite?

    Da sollte eine einfache Weiterleitung in der htaccess im Root von der alten Seite genügen.

    Code
    RedirectPermanent / http://www.example-neue-domain.com/

    Nur die Registrierung einer zweiten Domain wird nicht genügen, Du wirst auch auf ein größeres Paket upgraden müssen, damit das Memory-Limit für zwei Installationen ausreichend ist, falls beide Installationen zeitgleich betrieben werden sollen. Oder die dürfen nicht irgendwie miteinander gekoppelt sein.
    Dass auf die Millisekunde genau zwei Aufrufe gleichzeitig erfolgen, kommt zwar nicht oder nur theoretisch vor, doch WP ist ja nun auch nicht gerade in unter 3 Millisekunden abgearbeitet und wenn es dann doch passiert, bedeutet es die doppelte Last, könnte ich mir vorstellen.

    dpi ist für den Druck und die wollen dazu dann noch einen anderen Farbraum (oder Farbprofil oder Farbmodell?) für Vierfarbdruck, denke ich, komme ab und an durcheinander. Du möchtest Bilder fürs Web mit 3 Farben, dann solltest Du das Deinem Bildbearbeitungsprogramm klar machen, ich denke da liegt eventuell der Fehler, dass Du eine Auswahl getroffen hast, die für den Druck und nicht für einen Screen bestimmt ist.

    Jedenfalls las ich bisher von 2 Fehlern mit WP, einmal vorher zu sehr komprimiert und einmal einen falschen Farbraum ausgewählt.

    ....also ein unsauber programmiertes Theme?


    Was hat jetzt Dein Theme damit zu tun?

    Sicherlich lassen sich Suchanfrage verändern, doch das ist recht kompliziert und wer nicht weiß wie eigene Where-Klauseln, die unterschiedliche Ansprüchen erfüllen sollen, formuliert werden, wird es eh nicht packen.

    Allgemein wird nur eine SQL-Anweisung an die Datenbank gesendet und die durchsucht dann entsprechend der Where-Klausel selbstständig den Content. Und die Where-Klausel enthält etwa folgenden Code:

    Code
    (wp_posts.post_title LIKE '%Color%') OR  (wp_posts.post_content LIKE '%Color%')

    Da sehe ich keine Unterscheidung, ob innerhalb von HTML oder nicht, die greift alles was sie findet. Also komm runter von dem Gedanken, WordPress würde Deine Datenbank durchsuchen, macht WP nicht, WP sendet nur eine SQL-Anfrage und die Datenbank durchsucht sich dann entsprechend der Anfrage selbst. Alles was Du oder ein Programmierer machen könnte, die Anfrage anders formulieren.

    Hätte dann aber den Nachteil, dass dafür wieder andere Gesuche schlechter gefunden würden. Teilweise war eine Auswahl weit verbreitet, ob genauer Wortlaut oder allgemein. Konnte dann vor dem Klick auf dem Button von einem Suchformular ausgewählt werden.

    in denen aber "Color" nicht vorkommt.


    Im sichtbaren Content und bei den Inline-Styles?
    Habe nur den Text von einem Beitrag durchsucht, in dem "Color" angeblich nicht vorkommt:

    Code
    style="color: #3b5998;[B]"[/B]


    Hätte erwartet, das WP HTML-Tags und HTML-Elemente von der Suche ausklammert, scheint wohl nicht der Fall zu sein. Sollte dann aber nur bei Style-Eigenschaften vorkommen.

    Eigentlich übergibt ja WP die Suchanfrage nur mit einem SQL-Query an MySQL und MySQL führt dann die Suche in der Datenbank auf, worauf PHP keinen richtigen Einfluss mehr hat. MySQL ist es jedoch vermutlich egal ob Color als Text im Content vorkommt oder im Content als

    Code
    <a style="color: #3b5998;[B]"[/B] ...


    nehme ich mal an.

    ich kann auch die zeile include_path.. in den beiden Dateien nicht finden.


    Kannst Du so auch nicht finden, weil es sich dabei um einen alternativen Serverpfad handelt und PHP unter diesem alternativen Serverpfad nur nach Dateien sucht, wenn diese im eigentlichen Verzeichnis nicht zu finden sind oder ein include_path angegeben wurde.

    Beispiel unter Localhost:

    Bei include scriptdatei.php würde zuerst im Arbeitsverzeichnis nach scriptdatei.php gesucht und erst wenn im Arbeitsverzeichnis unter

    "C:\xampp\htdocs\arbeitsverzeichnis\scriptdatei.php"

    nichts zu finden ist, würde PHP auch unter include_path suchen, ob sich da vielleicht diese Datei herumtreibt.

    "C:\xampp\php\PEAR\scriptdatei.php"

    Wurde etwas wirklich dort abgelegt, so findest Du include_path mit phpinfo() oder in der php.ini.

    Die Sache ist eigentlich ganz einfach. Zuerst kontrollierst Du alle im Quelltext enthaltenen Verweise zu JavaScript- und CSS-Dateien auf Erreichbarkeit und sorgst im Fehlerfall für die erforderlichen Anpassungen.

    Danach benutzt Du einen Validator wie

    http://validator.w3.org/

    um Dir alle Fehler anzeigen zu lassen und anhand der Vorschläge, die der Validator macht, zu beseitigen.

    Als Notlösung könntest Du auch erst einmal nur aus allen Verweisen wie

    Code
    [URL="http://forum.wpde.org/view-source:http://stattblatt.de/web/wp-content/themes/sb-theme/css/shThemeDefault.css?ver=3.9"]http://stattblatt.de/web/wp-content/themes/sb-theme/css/shThemeDefault.css[/URL]


    /web herausstreichen, damit die Dateien wieder erreichbar sind. Mal unter Einstellungen schauen, was da als Seiten-URL angegeben ist, /web ist jedenfalls zuviel.

    Was ich mir gerade noch dachte, Kommentare beginnen eigentlich nur mit # einer Raute, doch diese Zeilenverweise beginnen mit einer Raute und einem Doppelpunkt #: der schon seine Bewandtnis hat. Wenn nun der Code sich um drei Zeilen verändert, stimmt die zugehörige Angabe nicht mehr. Habe aber noch nicht getestet, ob das entscheidend mit ist, da der Interpreter und Compiler eigentlich alle Kommentare usw. entfernt, somit beim Parsen eh keine Zeilennummer mehr stimmt. Müsste man mal richtig testen.

    Für Vergleiche hatte ich mir mal den KDiff3 heruntergeladen und seither nicht einmal benutzt. Beim Test zeigte der aber genau, welche Zeile in Datei A nicht der Zeile in Datei B entspricht, daran kann ich mich noch erinnern.

    http://kdiff3.sourceforge.net/doc/screenshots.html

    Wenn in Folge eines Updates Änderungen in den Sprachdateien vorgenommen wurden, musst Du Deine ebenfalls erneuern. Es betrifft jedoch nur die Änderungen. Was hinzukommt, wurden einige Zeilen Code in den Dateien hinzugefügt, stimmen die Zeilennummern in den Sprachdateien nicht mehr. Sind zwar nur #Kommentare wie es ausschaut, nur verweisen diese dann nicht mehr auf die eigentlichen Codezeilen.