Um schreiben oder kommentieren zu können, benötigen Sie ein Benutzerkonto.
Sie haben schon ein Benutzerkonto? Melden Sie sich hier an.
Jetzt anmeldenHier können Sie ein neues Benutzerkonto erstellen.
Neues Benutzerkonto erstellenIn allen geöffneten Dateien kannst Du wohl mit jedem vernünftigen Editor suchen, wenn auch in ungeöffneten gesucht werden soll, benutze ich bislang immer dieses Script: In Dateien suchen
Gibt aber auch unterschiedliche Editoren, die dateiürbegreifend suchen und auch suchen und ersetzen können.
das habe ich bereits getan und ich habe diverse Plugins getestet, aber bisher habe ich nichts vergleichbares gefunden.
Kenne zwar die angebotenen Plugins nicht, doch das eine oder andere sollte sich wohl schon anpassen lassen. Und falls wider Erwarten nicht, so könnte es auch ganz einfach daran liegen, dass einige ihre Plugins allein programmieren oder programmieren lassen und auch daran, dass nicht alle ihre Plugins über WP anbieten.
Aber ich bekomme es ja auch nicht hin, die farbe zu ändern wenn ich einen link im normalen text feld habe.
Dann definiere doch dafür Deine eigene Klasse in der CSS und füge die mit ein.
<a class="meinelinks" ... >Doch eigentlich hast Du unter /* =Basic structure auch gleich bei /* Body, links, basics */ wesentliche Styles.
Umlaute und spitze Klammern sind zwei Paar Schuhe. Wenn die spitzen Klammern zu einem HTML-Tag oder einem Code gehören, soll das ja nicht sichtbar ausgegeben werden und die Tags oder Codes gehören somit in den Quelltext und können nicht in einem Wysiwyg eingefügt werden. Soll der Code oder die Tags hingegen als Beispiel für eine kleine Anleitung sichtbar dargestellt werden, muss das dem Browser durch Verwendung von Entities mitgeteilt werden.
Anders sieht es mit Umlauten aus, die lassen sich zusammen mit dem Dokument konvertieren. Sehr viele Probleme beruhen hier einfach darauf, dass irgendwo bei Konvertierung, Speicherung, Auslieferung unterschiedliche Charsets benutzt werden. Zum Beispiel würde eine mit ANSI bearbeitete und gespeicherte Datei bei einer Verarbeitung oder Auslieferung als UTF-8 Dokument nur nicht darstellbare Glyphen oder sonstigen Schrott liefern.
beim Speichern jedoch werden "<" und ">" in ihre emtsprechenden HTML-Entities umgewandelt.
Was haben aber nun wieder spitze Klammern mit Umlauten gemein?
Oder wie war Deine eigentliche Frage?
Gibt es davon mal abgesehen keinen Weg, beim Umschalten von visuellen zum Texteditor das Umwandeln von Umlauten in die entsprechenden HTML-Entities zu verhindern?
Selbstverständlich gehört JS-Code und HTML in den Quelltext einer und nicht in einem Wysiwyg, Du kannst aber umgekehrt alles in der Textansicht schreiben, dadurch ersparst Du Dir den Wechsel.
Wenn Du noch mehr in den Beiträgen formatierst, dann findest Du bald nichts mehr in der CSS, weil das was Du in den Beiträgen formatierst, zusammen mit dem Text der Beiträge abgespeichert wird.
Wobei die Größe eines Plugins nicht unbedingt etwas mit den Bedarf an Speicher zu tun haben muss. Soll heißen, ein kleines Plugin kann mehr verbrauchen als ein größeres. Wie sieht es mit Deinen Einstellungen für Revisionen aus?
ich kenne WP leider zu wenig um den grossen unterschied zwischen "ich bin eingeloggt" und "bin es nicht" zu verstehen.
Kenne die Unterschiede eigentlich auch nicht so genau, doch wenn ich bei meiner Seite in den HTTP-Header schaue, dann wird eingeloggt zum Beispiel Expires: Wed, 11 Jan 1984 05:00:00 GMT ausgeliefert. Nehme mal an, um den Browser zu nötigen, eingeloggt nie aus dem Cache zu laden.
Mit gzip habe ich bisher weniger zu tun gehabt, kann somit keinen Unterschied bei mir zwischen eingeloggt und nicht eingeloggt erkennen. Sehe nur bei Deinen Seiten, dass die jeweils aufgerufene Datei hier gzip verpackt ankommt und die Seiten dadurch viel kleiner sind als meine. Werden die auch gzip verpackt ausgeliefert wenn Du eingeloggt bist?
Die Funktion _get_custom_object_labels wird in der Datei wp-includes/post.php definiert (in Zeile 1464) und warum die bei Dir undefiniert sein soll, kann ich nicht nachvollziehen. Falls einzelne Dateien beschädigt sein sollten, so könntest Du einzelne Dateien, die eine abweichende Größe besitzen, per FTP austauschen.
Die Seite selbst, die die Probleme erzeugt, habe ich mit WP selbst und dem WYSIWYG-Editor erzeugt.
In einem WYSIWYG-Editor kannst Du keinen Code einfügen, wenn dann nur in der (Quell-)Text-Ansicht. Aber selbst in der Text-Ansicht vom WP-Editor musst Du eventuell JavaScript noch in CDATA-Abschnitte einbetten. Einige Beispiele findes Du hier:
Hier das gleiche Problem, es dauert ewig, bis das erste Byte kommt.
Kann ich bei der "http://www.faustaborsani.ch" nicht bestätigen. Habe nur mal vier Seite vom Hauptmenü aufgerufen, ist nicht die schnellst Seite, doch so extrem langsam laden die Seiten halt auch noch nicht, wobei die ersten Responses jeweils nach 500 bis 700 Millisekunden eintrafen.
3,58s (onload: 2,88s)
3,9s (onload: 3,11s)
3,56s (onload: 2,81s)
3,87s (onload: 3,13s)
Beim Aufruf der "http://www.mysize.ch" traf hingegen die erste Response nach rund 21 Sekunden ein, die restlichen Dateien wurden dann zwar schneller geladen, doch 21 Sekunden, das sind halt 20,5 Sekunden zu viel.
Dafür dass Du da als Hintergrundgrafik ein 1,1 MB schweres Image verwendest, dafür war die Seite bei den ersten Aufrufen eigentlich recht zügig. Die erste Response traf bei wiederholten Aufrufen in unter 300 Millisekunden ein, was bei WP eigentlich richtig gut ist, würde ich meinen.
Ab den vierten oder fünften Aufruf fing es dann an zu lahmen und die Zeit verlängerte sich auf 28 bis 29 Sekunden.
Unabhängig davon, reduziere mal das Image, da könntest Du die Mitte, von der ohnehin nichts zu sehen ist, entfernen, denke ich mir und den Rest vielleicht noch etwas komprimieren.
Im Augenblick sehe ich bei Color oben in der Seite:
<p><span style="font-size: 14px; color: #888888;">Und unten in der CSS:
body.custom-font-enabled {
font-family: arial, Helvetica, Arial, sans-serif;
color: #6a6a6a;
}An der Ausrichtung solltest Du ebenfalls noch etwas werkeln?
ein href="ghostery.com" ist einfach kein externen Link.
Ist ja auch kein externer Verweis, da hast Du völlig recht und anders als wie bei selfhtml beschrieben, kannte ich das bis vor ein paar Monaten noch nicht. Auch in der Printausgabe von selfhtml (HTML5 Handbuch) ist da nichts anderes zu finden. War nur über diese Protokoll relative Schreibweise // erstaunt und hielt es anfänglich für einen Bug bei YouTube.
indem irre viele Sachen stehen mit denen ich aber leider nichts anfangen kann.
... Na ja, Frauen und Technik. :)
Geht Männern nicht anders, deshalb solltest Du auch nicht die irren vielen Sachen betrachten, sondern nur den Eintrag memory_limit. Zur Erleichterung benutze ich bei geöffneter Info-Seite die Suchfunktion des Browser, um schneller einen gesuchten Eintrag zu finden.
Und falls Dir dieser Link missfällt, dazu brauchst Du doch nur die beiden PHP-Zeilen innerhalb von
HTML<div class="site-info"> ... ... </div>
in der footer.php entfernen und/oder dafür Deinen eigenen Text einfügen.
Den Text kann ich im Footer aber nicht sehen...
So langsam verwirrst Du mich, bei mir sind zwei PHP-Zeilen mit den Credits, der URL und den powered by %s Angaben in der footer.php enthalten und überdeutlich wahrnehmbar. Dass Du den Text nicht lesen kannst, ist ja wohl klar, weil der ja erst über die po/mo Sprachdateien beim Parsen der Seite eingedeutscht wird und die HTML-Zeile ohnehin erst von WP-Funktionen zusammengesetzt wird.
<footer id="colophon" role="contentinfo">
<div class="site-info">
<a href="http://www.outofmymindrecords.com/">Out Of My Mind Records</a>
</div><!-- .site-info -->
</footer><!-- #colophon -->Doch ich schrieb nichts davon, dass Du nach einem leserlichen Text suchen sollst, sondern nur davon, dass Du diese beiden PHP-Zeilen entfernen und durch Deinen eigenen Copyright-Vermerk ersetzen kannst. Und wenn der nicht in alle verfügbaren Sprachen übersetzt werden soll, dann kannst Du den einfach in einer Sprache Deiner Wahl dort als HTML-Zeile notieren.
Warum soll denn "http://www.example.com/wordpress/" ausgelöst werden, wenn es sich auch so einrichten lässt, dass bei Eingabe der URL "http://www.example.com" gleich die richtige Seite geöffnet wird?
So eine Anweisung schreibt man eigentlich nicht in die htaccess, wenn die Möglichkeit besteht, die Domain auf das Verzeichnis aufschalten zu lassen. Die Hoster, die ich kenne, bieten dafür ein Formular, wo sich einstellen lässt, dass die Domain example.com auf das Verzeichnis /wordpress zeigen soll.
Alternativ könntest Du jedoch auch die Index von WP ins Root-Verzeichnis vom Webspace verschieben und dann wie bei einer Änderung der Adresse vorgehen. Das URL-Rewriting übernimmt dann WP ziemlich zuverlässig.
So, gut, danke, jetzt weiß ich schon einmal wie sich das nennt und wo es beschrieben wird.
Um mich einzumischen, erstaunlich dabei ist, dass YouTube kein HTTP-Protokoll mehr verwendet, die Verweise nur noch mit // beginnen und die Browser daraufhin das aktuelle Protokoll der Seite (http oder https) übernehmen können. Soll angeblich ein erlaubter Standard sein, nur weiß ich immer noch nicht, ob es dazu eine Spezifikation vom W3C gibt.
Beispiel:
<iframe width="560" height="315" src="//www.youtube.com/embed/..." frameborder="0" allowfullscreen></iframe>Für den Anfang einfach einmal die URL der Seite eingeben und dann den Hinweisen folgen.
20 Errors, 1 warning(s)