Beiträge von codestyling

    Also laut der Prüfung des HTML mit

    Code
    http://validator.w3.org/check?verbose=1&uri=http%3A%2F%2Fwww.pension-fisch.de%2F%3Fpage_id%3D24

    sind <p> nicht immer geschlossen worden, die Seite ist nicht konsistent.
    Firefox ist ein bischen nörgelig, wenn die Seite nicht stimmt.
    Dem IE kann man auch kaputtes HTML vorwerfen, der versucht zu raten, was richtig sein müßte und (zer)repariert das dann.

    Ausserdem hast du riesige Bilder drin, die du auf eine kleine Größe von Browser bringen lässt. Da du nur die Breite aber nicht die Höhe angegeben hast, kann der Browser so lange die Seite nicht fertig machen, wie der die 236 kb Bild vollständig hat.

    Scollen geht schon im FireFox (bei mir 2.0.0.13) aber eben erst, wenn der Fox mit der Seite fertig ist und das dauert wegen der Fehler und Bildgrößen u.U. ein paar Sekunden, auch wenn man die Seite schon sieht.

    Vorschläge:
    1.) Das HTML der Seite korrigieren, freuen sich Browser drüber :)
    2.) Von den Bildern eine runtergerechnete Auflösung erstellen und diese verwenden (Breite und Höhe angeben!). Einen Link um's Bild machen und die große Version damit laden lassen.

    HTML
    [COLOR=Red]___[/COLOR]<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"><html

    Hi, wie in deiner normale Startseite bereits zu sehen ist, werden am Anfang immer 3 Leerzeichen ausgegeben (hab ich mal rot unterstrichen).
    Eine deiner PHP Dateien hat vor dem ersten <?php 3 Leerzeichen, weil die Datei zwangsweise in von Unicode in Ansi durch bearbeiten konvertiert wurde.
    Schau dir alle von dir modifizierten php's an und wirf die Leerzeichen raus.
    Speicher die Dateien dann Unicode und alles wird gut. :-D

    Hi,
    einerseits teilt deine Seite allen Clients (inklusive Google) mit, das der Inhalt UTF-8 (Unicode) ist, anderererseit hast du HTML encodierte Umlaute im Text.
    Wenn man UTF-8 einsetzt, dann interpretiert Browser solche Entitäten wie:
    &uuml;&#246
    ...
    nicht immer, weil ja alles Unicode ist und somit nicht nötig ist.
    Deshalb werden auch uml's in title Angaben von Images oder Links nicht korrekt bei UTF-8 angezeigt.

    Ich vermute, du hast das irgendwo "hardcore" in eine PHP Datei Text getippt und keinen Unicode Editor verwendet. Weil es pur nicht korrekt aussah, hast du die Entitäten verwendet.
    Es kann auch in den entsprechenden Post so drin sein, dann bleibt dir nichts anderes übrig, als die Posts zu editieren und
    so was wie &#246 durch ö z.B. zu ersetzen.
    Benutze einen Unicode fähigen Editor, speicher die betroffenen Files in Unicode und nimm nomale "ö" und "ü", dann klappts auch mit Google.

    PS: Den Anrisstext nimmt Google nicht zwangsläufig aus dem Header sondern kann auch auszugsweise aus dem Body sein. Wenn Google "liest", das es UTF-8 ist, wird das Gefundene 1:1 verwendet, da macht Google keine uml#s mehr zu Umlauten!

    Also wenn man sich funpic.de ein wenig durchliest (das was man überhaupt bekommen kann) und dann die Möglichkeiten dazu sieht, bietet dieser Provider Sachen an, für die man beispielsweise bei 1und1 bereits monatlich mehr als 13 € hinlegen müsste.

    Zitat
    Code
    http://www.funpic.de/webhosting_info.php
    Zitat

    MySQL Space: keine Begrenzung - außer reine Dateiablage

    Zitat

    MySQL Zugang: maximal 8 MySQL

    Preis: 0,00 € (kostenlos)

    Wenn man dann das dortige Forum liest, merkt man schnell, wo die Grenzen sind:
    - niemand darf von aussen auf Medien (Bilder/Videos) verlinken, darf man nur innerhalb
    - eine ShoutBox, die Ajax betrieben mehrmals pro Stunde refreshen sollte, ist nicht erlaubt
    - Einspielen von DB Dumps muß in Stücken zu je 1 MB geschehen sonst Abbrüche
    - usw...

    Das kollidiert nun mal spätestens mit WP 2.5 und Ajax Admin GUI und kann nicht gut gehen.
    Die Konsequenz von Verstößen ist unangekündigte Schliessung des Accounts.

    Somit würde ich einen Providerwechsel empfehlen, denn auf lange Sicht werden die Probleme nicht besser.

    Schonmal Forensuche genutzt?

    Super Antwort! Für jemanden, der mehrere tausend Post hier macht ist das ein Leistung!

    Ich bin zwar erst ein paar Tage angemeldet, aber ein paar Worte mehr schaden bestimmt nicht. Selbst in der Software Firma, in der ich arbeite, würdest du so was nicht mal als interne Mail bekommen.

    Ein offensichtlicher Noob, der ein JavaScript basierten Content offensichtlich über Widgets einfügen will, kann man doch sagen, dass das mit den verfügbaren Widgets nicht so geht, da die Javascript Tags meist rausgefiltert werden.
    Da muß man schon ein eigenes Widget in PHP schreiben oder das in die Sidebar.php des Themes direkt einkleben, wie's in der angegebenen Seite zu finden ist.

    Mag sein, das du das schon 1000 mal beantwortet hast, ich frag mich was du machst, wenn dich deine Autowerkstatt auf eine Frage zu Klappergeräuschen mit der Aussage "Schon ins Handbuch geschaut ?" stehen lässt.

    fsockopen() [<a href='function.fsockopen'>function.fsockopen</a>]: no SSL support in this build in

    Also deine Provider hat eine PHP Version laufen, in die kein SSL Support eingebaut wurde.
    Somit kann es nix werden. (Falls du noch PHP 4 benutzt, prüfe, ob dir PHP 5 bereitsteht und das da integriert ist).

    Ansonsten kannst du in:

    Code
    wp-includes\js\tinymce\plugins\spellchecker\config.php

    den zu benutzenden SpellChecker einstellen:

    Ich würde noch einen der anderen dann mal probieren (grüne Zeilen).
    Ansonsten bleibt mir nur Ammaletu beizupflichten.

    Ich weiß zwar nicht, wie das Problem zustande kommt und es wird nur an den Symptomen rumgedoktert, aber so funktioniert bei mir der TinyMCE unter Wordpress 2.5.

    Wenn in einer Datei, die ein PHP System verarbeitet, das auf UNICODE Basis arbeitet, 3 Zeichen verschwinden, hängt das damit zusammen, dass der UNICODE Kodierungsmarker, der normalerweise immer an Anfang einer Datei steht und 3 Byte groß ist, fehlt.

    Diese passiert immer dann, wenn mein eine Datei, die UNICODE ist, mit einem Editor bearbeitet, der diese zwangsweise in ANSI konvertiert.

    Wenn du z.B. ein PHP File, das selbst UNICODE ist, mit z.B. TextPad öffnest, weißt dich dieser Editor darauf hin, das UNICODE konvertiert wird. Dieser Editor kann aber auch UNICODE bearbeiten, wenn man es will.

    Nur nicht alle Texteditoren können UNICODE. Und ich habe schon einige Plugins gesehen, bei denen Release Infos oder Greeting Links als UNICODE drin waren und somit das ganze Plugin PHP Unicode ist.

    Fazit: Wenn man einen Editor benutzt, um Files zu ändern, sollte man auch einen nehmen, der UNICODE erhält, falls es drin ist.

    Hmm, da ich momentan keinen Zugriff auf den WP 2.5 Source habe, würde ich mal schätzen, dass dein Provider entweder Sockets ganz verboten hat oder zumindest den SSL Zugriff unterbunden hat (Thema: Provider protokollieren per Gesetz Zugriffe auf Servern).

    TinyMCE löst offensichtlich die Rechtschreibkontrolle mit einem Google Plugin:

    Code
    wp-includes/js/tinymce/plugins/spellchecker/classes/GoogleSpell.php

    Entweder gibt es eine Konfigurationseinstellung in diesem Plugin (oder einer der dazugehörigen Dateien) in denen man SSL abschalten kann, oder man müsste das ggf. umprogrammieren.

    Genaueres kann ich erst heut abends sagen, wenn ich den Code vor Augen hab ... :)

    Hmm das hat man dann vergessen zu kommunizieren oder? Weder im Upgrad guide noch in den changes ist davon gesprochen worden. Wieso gibt es dann das Feld im Admin-panel noch das das coding umstellen lässt. Da wäre ja dann auch überflüssig.

    Ja, und nein.
    Wenn man Encoding umstellt, hält sich WP auch per HTML Seite, Forms und Buttons dran. Nur wenn man den Visuelle Editor benutzt und AutoSave den Inhalt des Editors speichert, wird dieser per JavaScript als String erzeugt und gespeichert.
    Javascript behandelt aber alle Strings immer in UNICODE egal welches Coding die Seite hat. Deshalb kannst du per Javascript auch keinen String "Häää" in einen <a> per DOM reinschreiben, wenn der DOM im ISO Mode läuft. Dann gibst's die häßlichen Routen mit den Fragenzeichen oder solche Scherze.

    Wenn du nur den Standard Editor benutzt (Visuell abschalten) müsste auch AutoSave korrekt ISO Speichern.

    ... nur das wäre, als würde man sich mutwillig eine Hand abschneiden ...

    Versuch mal folgendes: phpMyAdmin (oder ein anderes Tool, mit dem du direkt auf die Datenbank zugreifen kannst) -> Tabelle "wp_users" -> "nice_name" in das gewünschte ändern.

    Ok, das scheint zu funktionieren. Allerdings ist mir ein "Boardmittel" lieber, das zu ändern, als das Datenbank Frontend bemühen zu müssen.
    Ich müsste also jedesmal, wenn ich einen neuen Nutzer anlege, umständlich danach in die DB "steigen", um das zu ändern, denn der nicename wird immer als bereinigte Version des login Namens automatisch gebaut, ohne das ich Einfluss auf diesen in der Admin GUI hätte.

    Es wäre ein Fortschritt, wenn das auch in der Admin GUI verfügbar wäre und zu einer Fehlermeldung beim Anlegen führt, falls die Modifikation nicht "unique" sein sollte. Denn diese Feld muß ja eindeutig sein, damit die Perma Links aufgelöst werden können.

    Somit würde ich die Möglichkeit des "nicename" für Perma Links als "nice" bezeichnen, aber letztlich ist das nur Augenwischerei, wenn man es nicht per GUI mit definieren kann, wie bei sonstigen Perma Struktur Angaben für Posts etc.

    so, es liegt wohl def. am Firefox!
    Habe neulich das update auf 2.00.13 gemacht, könnte sein, das es seit da so komisch aussieht.

    Im IE7 sieht alles normal aus!


    Ich würde im FireFox den kompletten Browsercache mal leer machen, Firefox scheint sich beim Update von .12 auf .13 am Cache zu verschlucken, wenn es um Javascript geht.

    Auch beim Einspielen von möglicherweise Javascript Bugfixes (*.js) sollte man den Browsercache leeren.

    Also für eine WP 2.3.3 DE Version, wie ich vermute am Admin Bereich, ist das zu wenig. Standardmäßig ist da deutlich mehr verfügbar. Hast du Plugins geladen, die den Editor beschränken ?
    Man kann den Editor sowohl per Plugin erweitern als auch reduzieren, ein Test der aktiven Plugins wäre ein Anfang.
    Falls dur keine Original WP als Grundlage sondern eine Distributions benutzt, die schon jemand "frisiert" hat, würd ich es mit dem Original versuchen.

    Nicht bei mir (WP 2.5 RC1.1). Weder mit noch ohne Permalinks. Ich sehe immer den "Im Blog anzeigen als"-Namen (Nickname), und der kann ruhig gezeigt werden, denn der entspricht nicht meinem Login-Namen.

    Sehen it relativ. Ich hab ebenfalls die WP 2.5 Final DE gerade nochmals sicherheitshalber getestet: nein, bei Perma Link Vergabe wird zwar der Text in der Webseite so angezeigt, wie eingestellt, der dahinter liegende Link, der alles vom Autor anzeigen soll, enthält aber weiterhin den richtigen login Namen !

    Da hat sich nix getan und somit werden tatsächlich die Login-Name durch Perma Struktur verraten !

    Eine eingebaute Umgehung ist auch bei Durchsicht der PHP Core Codes nicht verfügbar, man müsste da tatsächlich in WP Code eingreifen !

    Das liegt am Beitrag auf der Startseite. Da wurde wohl eine andere Schrift festgelegt, der entspreche Befehl aber nicht geschlossen, so dass er über die ganze Seite wirkt.

    Dem kann ich nur zustimmen.

    Line 34, Column 35: end tag for "font" omitted, but OMITTAG NO was specified. <p><font size="2" face="Arial"></p>

    Seiten kann man hiermit prüfen lassen:

    Code
    http://validator.w3.org/check?verbose=1&uri=http%3A%2F%2Funsere-hochzeit2008.de%2F

    satte 127 Fehler. Kann passieren. Was benutzt du eigentlich zum Erstellen der Inhalte und bastelst du an Templates rum ?

    Und wenn du schon dabei bist, dann schreib auch gleich dem Hersteller der internationalen Uhrzeitanzeige, das es in Deutschland sowas wie Sommerzeit gibt. (Flash ganz unten).

    Hi,
    nach Ansicht deines Blogs, habe ich gesehen, das du die Perma-Struktur selbst angepasst hast:

    Beiträge:

    Code
    http://djkee.de/index.php/update-probleme/

    Statisch:

    Code
    http://djkee.de/index.php/die-3/

    Wieso wird das index.php reinschraubt ?
    Erwartet hätte ich so was wie:

    Beiträge:

    Code
    http://djkee.de/update-probleme/

    Statisch:

    Code
    http://djkee.de/die-3/

    Kannst du einen Shot von deinen Perma-Link Vorgaben machen um zu sehen, was falsch sein könnte?

    Ich hab meine Systeme auch auf 2.5 geupdated und mußte nix ändern.
    Ich benutze

    (*) Benutzerdefiniert /%postname%
    und Kategorie und Tag-Basis sind leer.

    ... kann man mit der groben Kelle machen, muß man aber nicht.
    Ich habs umprogrammiert, weil mir bereits bei meinen Startversuchen mit Wordpress die Art der Integration des visuellen Editors ziemlich auf den Sa** gegangen ist.
    Herausgekommen ist für WP 2.3.3 ein Bugfix/Update von 4 Dateien, die zum Editor gehören und >> hier << zu finden sind.
    Wer's ausprobieren möchte, bitte sehr (eine Sicherheitskopie eurer bisherigen Dateien könnten nicht schaden, wenn es immer noch nicht so sein sollte, wir ihr das gern hättet).
    Ich habs bei mir laufen und finde, es funktioniert jetzt so wie ich mir das gedacht habe.

    PS: In WP 2.5 (frische Release seit gestern) ist alles im Argen. Beim Umschalten von Visuell nach Code gibt gar keine <p> mehr!
    Das muß ich jetzt auch erstmal umbauen, denn so geht das nicht! Code ist Code und ist in Tags gebettet, Punkt. Hat keiner zu klauen.
    Aber so wie ich es sehe, ist das nicht die Schuld von MoxieCode (TinyMCE Hersteller) sondern vom WP Team, das keine Ahnung hat, wie man den Editor richtig integriert.

    Grüsse

    Bugfix für WP 2.3.3

    Hallo zusammen, in der WP Version 2.3.3 hab ich den TinyMCE gehörig entschlackt und so in WP integriert, wie es sein sollte.
    Ein Bugfix/Patch gibt's hier zum Testen.
    Bitte die betreffenden Dateien vorher sichern, falls jemand mit dem Ergebnis wieder nicht leben kann.


    Ich teste seit heute WP 2.5 und der zeigt gar keine <p> und <div> mehr im Code View. Dort ist allerdings auch die nächste Version von TinyMCE verbaut.
    Das werde ich auch mal ansehen, was man da machen kann.