Beiträge von Melewo

Zitat von Nadjak

Dazu mal eine andere Frage: Wie entwickelt ihr denn? Ich hatte zuerst ein lokales WP-System das ich dann auf den Server gespielt habe. Doch das war ein Riesenakt und recht kompliziert. Daher hab ich nach einiger Zeit nur noch auf dem Server entwickelt. Habt ihr da eine bessere Lösung?

Habe nunmehr 3 Installationen unter Localhost, wobei ich mir aber auch unter Localhost zusätzlich noch eine Subdomain eingerichtet hatte. Nicht wegen WP, sondern um mod_rewrite Regeln zu testen. An einer Version unter Localhost teste ich alle Veränderungen und Funktionen und lade dann nur die veränderten oder ergänzenden Dateien per FTP hoch.

Wenn die dann auch im Web zufriedenstellend laufen, ziehe ich mir das ganze Packet wieder in ein anderes Verzeichnis herunter und sichere dieses Verzeichnis mit dem letzten Bearbeitungsstand auf einer externen Festplatte.

Mache ich aber mit allen Scripts so, nicht nur mit WP.

Zitat von RaiX

Den Auslöser bzw. die Ursache des Problems kenne ich jedoch nicht.

Das wäre aber gerade wichtig herauszufinden, sonst kannst Du Deine Passwörter ändern wie Du willst und dennoch kann Deine Seite morgen schon wieder verseucht sein. Es beginnt mit einem möglichen Trojaner auf dem Computer, der Deine Zugangsdaten ausliest und sich per FTP einloggt und wo es endet, das weiß ich leider auch nicht, nur irgend ein Leck wird es wohl sein.

Es sei denn, die functions.php wurde um eigene Funktionen bereichert, das wäre etwas anderes und verständlich.

So, nun habe ich gerade noch einmal einen Test mit dem 'Opera Mobile Emulator' gemacht, da halten die pre-Bereiche ebenfalls, wie es ausschaut. Werfe einfach einen Blick auf die Beispiel-Seite, wenn die bei Dir im Browser anders ankommen sollte, bin ich sicherlich etwas geknickt. Wenn nicht, suche Dir aus meiner CSS die Regeln heraus und passe die Farben an und gut sollte es sein.

Ich arbeite nur mit dem FF unter Windows und wenn ich da mit dem Inspektor nach den Regeln suche, so zeigt der mir an, dass da noch word-wrap: break-word und hyphens von

.site-content article {
    border-bottom: 4px double #ededed;
    margin-bottom: 72px;
    margin-bottom: 5.142857143rem;
    padding-bottom: 24px;
    padding-bottom: 1.714285714rem;
    word-wrap: break-word;
    -webkit-hyphens: auto;
    -moz-hyphens: auto;
    hyphens: auto;
}

auf

.entry-content pre,
.comment-content pre {
        border: 1px solid #000000;
        background: #000080;
    color: #FFFFFF;
    font-family: Monospace, Courier New, Monaco, Lucida Console, monospace;
    font-size: 12px;
    font-size: 0.857142857rem;
    line-height: 1.714285714;
    margin: 24px 0;
    margin: 1.714285714rem 0;
    overflow: auto;
    padding: 24px;
    padding: 1.714285714rem;
}

vererbt wird. Möglich das die Browser damit etwas unterschiedlich umgehen. Weiß jetzt im Augenblick nicht einmal, wie man word-wrap in pre-Bereich verneint oder zur Not mit !important überschreibt, außer mit der Angabe 'normal'. Mit white-space wäre es wohl auch so möglich gewesen:

white-space: nowrap; 


/* oder notfalls mit */
white-space: nowrap !important;

Doch hyphens habe ich entfernt. Du könntest es mit

word-wrap: normal;


/* oder mit */
word-wrap: normal !important;

für pre probieren. Für ältere IE ist es zusätzlich wichtig, dass auch einige Anpassungen in der css/ie.css vorgenommen werden. Zusätzlich habe ich eine kleine Funktion geschrieben, die da einiges in pre-Bereichen nach meinen Vorstellungen anpasst, doch die benötigst Du zur Zeit noch nicht bei Deinen Beispielen, wie es ausschaut. Von CSS3 kenne ich bisher auch nur die Regeln, über die ich stolpere und bin kein Experte in Sachen CSS.

Bei mir sieht es zumindest so aus und ich sah bisher noch keine Unterschiede in den drei Browsern, die ich zur Kontrolle benutze:

.site-content article {
...
}
/* Entfernt -webkit-hyphens:auto;  -moz-hyphens:auto; hyphens:auto; */


.entry-content pre, .comment-content pre {
    background-color:#f8f7ea;         /* neu */
    border:1px solid #e2e2e2;         /* alt ededed */
    color:#000;                       /* alt 666    */
    font-family:Consolas, Monaco, Lucida Console, monospace;
    font-size:12px; font-size:0.857142857rem;
    line-height:1.2;                  /* alt 1.714285714 */
    margin:24px 0; margin:1.714285714rem 0;
    overflow:auto; padding:24px; padding:1.714285714rem;
}

Hier sind 3 unterschiedliche Varianten aufgeführt, wie Du das bewerkstelligen kannst. Suche Dir eine Variante aus:

https://faq.wpde.org/wordpress-url-aendern/

Zitat von Monika

naja es ist 1und 1

Ich habe zwar keine Seiten bei 1&1 zu liegen, weiß aber, dass die eigentlich recht gute Hilfe-Seiten für derartige Probleme haben:

WordPress installieren und Häufige Fehlerquellen bei Skripten

Möchte nichts Falsches schreiben, doch die Meldung halte ich für einen Fehler, da jQuery v1.10.2 eigentlich aktuell ist, aktueller als als jQuery v1.2.3 auf jeden Fall wohl, würde ich mal sagen. Da ich mich bei Versionen heute schon einmal irrte, lese Dir das mal lieber allein durch:

http://blog.jquery.com/2013/07/03/jqu…2-0-3-released/

Das liegt wohl nur an Deiner CSS. Für pre-Bereiche verwendest Du overflow:auto, was erst einmal richtig ist, doch eventuell ärgert das white-space: pre-wrap und verhindert bei zu wenig Platz, dass overflow:auto richtig greift. Habe es aber nicht getestet.

Zitat von Nadjak

Beim googeln hab ich dann gefunden das man in der Kategiebasis "." oder "./" (ohne Anführungszeichen) eintragen soll, damit die category im Link nicht doppelt auftaucht. Doch das ist bei mir ja nicht der Fall. Auch wenn ich die Zeichen eintrage, erhalte ich die gleiche 404-Fehlermeldung.

Im Web benutze ich ja WP erst seit vier Wochen, vorher hatte ich nur eine Version unter Localhost für gelegentliche Tests, somit weiß ich viele Einzelheiten (noch) nicht. Doch da ich mir gerade die 3.6 unter Localhost installierte, fiel es mir auf. Ich benutze keine Kategorie-Basis und lasse diese Felder völlig leer, so dass die Standardwerte verwendet werden. Wenn Du die nicht leer lässt, so müsste wohl die Basis mit in der URL vom Link erscheinen.
Monika und Ingo sollten sich damit besser auskennen, doch hast Du das mit oder ohne Basis getestet und war da ein Unterschied in der URL zu erkennen oder nicht?

@ Dunkelangst

Nun gut, so kann man ein Problem zuweilen auch lösen, ist vielleicht auch besser so, wenn der Aufwand nicht zu groß war.

@ Putzlowitsch

Ich danke Dir, habe ich doch gleich einmal ausprobiert. Das sollte wohl die entsprechende Regel sein.

[category/(.+?)/?$] => index.php?category_name=$matches[1]

Und in $matches[1] sollte dann ein Treffer vorhanden sein, wie bei dieser Zeile von der wp-includes/rewrite.php, wobei diese Zeile jetzt nicht unbedingt die richtige zu sein braucht, doch etwas in der Art.

if ( preg_match("!^$match!", $request_match, $matches) ) {

Falls ich das bisher richtig verstanden habe. Da blicke ich jetzt kaum durch und für einen normalen Einsteiger sind das entfernte Welten.

Zitat von Dunkelangst

Wie kann ich die Rules herausfinden und ggf. mit meinen zwei Blogs vergleichen, die keine Probleme machen?

Na die Grundeinstellung ist doch wohl immer gleich, nur mit oder ohne Verzeichnis. Die beiden Konditionen besagen so viel wie, wenn es sich bei der aufgerufenen URL weder um ein existierendes Verzeichnis, noch um eine existierende Datei handelt, soll WP die Verteilung übernehmen.

#Bei Installation im Root:


RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]


#Bei Installation in einem Verzeichnis:


RewriteEngine On
RewriteBase /verzeichnis/
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /verzeichnis/index.php [L]

Ist in diesem Fall die höhere Endzahl die ältere, zumindest in diesem 5.2 Zweig?
Ich meine jetzt sind wir irgendwo bei PHP größer 5.5 oder so, doch mit PHP größer 5.3 lässt es leben.

Ich weiß jetzt nicht wie groß der Versionsunterschied ist, doch sind es ja beides nicht mehr die neusten Versionen:

Zitat

Die Weiterentwicklung und der Support von PHP 5.2 ist seit Anfang 2011 eingestellt, die letzte Version 5.2.17 kann jedoch weiterhin heruntergeladen werden.

https://de.wikipedia.org/wiki/PHP

Weiß nur, bei 5.2.17 betrug die Ladezeit im Mittel 3,5 Sekunden, nach der Umstellungen 1,6 Sekunden. Ob dass der Hoster das von sich aus so machte, um die Kunden zum Wechsel zu verleiten, die Server mit den älteren Versionen etwas lahmen ließ, keine Ahnung. Dem steht gegenüber, dass alle anderen Seiten, die zum Webpaket gehören, nicht merklich lahmten.

Welche PHP Version steht zur Verfügung, PHP kleiner Version 5.2.4?

Nur eine Zwischenfrage, weil ich gerade in einem anderen Thread darüber stolperte.
Welche PHP steht zur Verfügung, kleiner PHP Version 5.2.4?

Du verwendest nun die Version 3.6 und vorher?

Ab der WP-Version 3.5.2 wurde bereits die PHP Version 5.2.4 vorausgesetzt für eine fehlerfreie Funktionsweise. Dein Server verwendet aber noch 5.2.17.

X-Powered-By: PHP/5.2.17

5.2.17 hatte ich auch in den ersten Tagen und da der Server mit dieser PHP Version im Zusammenspiel mit WP lahmte, hatte ich mich an den Support vom Hoster gewendet und auf eine neuere PHP-Version umstellen lassen. Ich will nicht sagen, dass es damit zusammenhängt, doch möglich wäre es ja schon.

Egal wie und wo ich es installiert habe, ob in einer Testumgebung oder im Web, bei mir sieht es immer so aus:

http://www.example.com/beitragsname/
http://www.example.com/category/name-der-kategorie/


http://www.example.com/wordpress/beitragsname/
http://www.example.com/wordpress/category/name-der-kategorie/

Du bist aber nicht der einzige hier mit diesem Problem:

http://forum.wpde.org/konfiguration/…-kategorie.html

Du bist schon einmal nicht ganz allein mit dem Problem, wie es ausschaut:

http://forum.wpde.org/konfiguration/…kategorien.html

Na ja, warum sollte er da ein Plugin installieren, meine Einstellungen sehen nicht anders aus mit "Beitragsname" und bei mir funktionieren die Kategorien auch ohne Punkt oder Strich einfach mit

http://www.example.com/category/name-der-kategorie/

Und bei anderen funktionieren die nicht. Die Frage ist doch, warum sie bei einigen anderen nicht funktionieren.

Habe mal nach #0f2490# gesucht, wobei die meisten Seiten bereits gesäubert waren. Bei einer Seite hat aber mein Virenscanner angeschlagen und das Öffnen der Seite verweigert. Die Meldung war:

Virus: Script.Packed.IFrame.C

Und wenn ich das bei Virustotal richtig verstehen sollte, was nicht zu sein braucht, versteckt der sich in einer Datei wie output.13150328.txt bei einer Größe von 44.7 KB (45783 bytes). Ob das alles so stimmt, keine Ahnung, so oft beschäftige ich mich damit nicht.

Somit könnte es zumindest nicht schaden, mal nach so einer Datei Ausschau zu halten. Und wenn alles gesäubert ist, der Frage nachgehen, wo der Schwachpunkt liegt.

Du hast doch, so wie es ausschaut, noch keinen Artikel in der Standardkategorie Allgemein veröffentlicht oder doch? Wenn Du aber eigentlich Alltag als Standardkategorie benutzt, im Feed sieht es zumindest so aus, dann stelle die doch einfach mal als Standardkategorie ein. Vielleicht ist der Spuk dann ja bereits vorbei. Weiß es zwar nicht genau, doch versuchen würde ich es einmal.