Für genau diesen Fall empfehle ich mein Plugin "WP Native Dashboard". Es ist im WordPress Repository zu finden oder auch als Download auf meiner Seite (siehe Signaturlinks)
Beiträge von codestyling
-
-
In deiner style.css des Themes ist das ein Hintergrundbild des body:
Code
Alles anzeigenbody { background:url("http://www.sonicsystem.de/wp-content/themes/atahualpa353/images/background7.png") repeat-x scroll left top #FFFFFF; color:#000000; font-family:verdana,arial,sans-serif; font-size:13px; line-height:1.5; margin:0; padding:0; text-align:center; }Da dein Headerbild höher ist, als es vorgesehen war, denn das Hintergrundbild ist 190px hoch, sitzt das nicht mehr neben dem Menü. So würde es korrekt sitzen:
Code
Alles anzeigenbody { background:url("http://www.sonicsystem.de/wp-content/themes/atahualpa353/images/background7.png") repeat-x scroll left [B][COLOR=Red]76px[/COLOR][/B] #FFFFFF; color:#000000; font-family:verdana,arial,sans-serif; font-size:13px; line-height:1.5; margin:0; padding:0; text-align:center; }... und ganz raus dann so:
Code
Alles anzeigenbody { background-color: #FFFFFF; color:#000000; font-family:verdana,arial,sans-serif; font-size:13px; line-height:1.5; margin:0; padding:0; text-align:center; }... musst ein wenig in den Codeboxen rüberscrollen, damit der Unterschied zu sehen ist :wink:
-
Kenn ich nur so (Daten sind anonymisiert):
Codedefine('DB_NAME', 'dbXXXXXXXXX'); define('DB_USER', 'dboXXXXXXXXX'); define('DB_PASSWORD', 'XXXXXXXXX'); define('DB_HOST', 'dbXXX.1und1.de[COLOR=Red][B]:3306[/B][/COLOR]'); define('DB_CHARSET', 'utf8'); define('DB_COLLATE', '');Manchmal braucht der DB_HOST bei 1und1 den Port, um zu funktionieren. Solltest diese Daten während der Einrichtung der DB angezeigt bekommen haben und ggf. im Backend von 1und1 nachlesen können.
Der Port kann (muss aber nicht) abweichen. -
-
Woher kommt das XML und in welchem Encoding liegt das vor?
Jeder valide XML hat ein encoding drin stehen und das muß man auswerten. Wenn es nicht UTF-8 ist, was ich annehme, muß man bei der Ausgabe entsprechend in UTF-8 konvertieren (oder es der XML Klasse anweisen, wenn sie es denn kann). -
WPTouch unterstützt leider keine iframe Weiterleitung. Dein WebSpace wird ja nur in einem iframe unter der gewünschten Adresse dargestellt und ist nicht direkt angesurft. WPTouch geht nur auf der direkten Domain, also auf der von funpic.
Ich kenne keine Möglichkeit, daies unter deinen Bedingungen zum Laufen zu bekommen. Einzige mir bekannte Lösung: Domain gleich WebSpace und dies ist bei dir nicht gegeben. -
Es bleibt beim guten alten Englisch.
Hast du in den AWPCP Plugin Einstellungen unter: Setting -> General Settings -> Turn On Translation File (POT)? auch angeschalten ?
Denn dieses Plugin kann seine eigene Übersetzung an und abschalten. Standard ist aus, also immer englisch. Erst wenn das angeschalten ist, funktioniert deine Sprachdatei.Dachte, du wüsstest das, wenn du das Plugin benutzt?
-
Yeap, habe ich auch pobiert.
Kurz Frage: Was drückt das jetzt aus? -
Vom Localisation-Plugin über Poedit, händischen Änderungen in der po-Datei selbst, bis hin zu allen möglichen Benennungen der Datei habe ich nun alles probiert.
Dieses Plugin hab ich getestet und es lässt sich mit meinem Localization Plugin übersetzen. Die Sprachdatei wird auch korrekt aus dem Hauptpfad des Plugins geladen. Mein Plugin erstellt eine AWPCP-de_DE.po und AWPCP-de_DE.mo Datei. Die *.mo Dateien natürlich erst, wenn du in der Editor Anzeige auf den Knopf "erstelle mo-Datei" drückst. Und in der wp-config.php sollte dann stehen:Wenn du deinen Blog mehrsprachig betreibst mit einem Plugin wie Gengoo oder qTranslate, dann muß die *.mo Datei dann umbenannt werden, denn diese Plugins wollen nur die Sprache behandeln (also 'de' statt 'de_DE') und somit muß die Sprachdatei auch dann 'AWPCP-de.mo' heißen.
Wichtig: Die Groß/Kleinschreibung der Dateinamen ist auf UNIX Servern essentiell und sollte auch so wie o.g. sein.
-
Um welches Theme geht es denn überhaupt? Kann man das irgendwo runterladen ?
-
Beginnen wir mal mit Zeile 311 (oberste):
PHP
Alles anzeigen<?php if ( function_exists("add_theme_support") ) { add_theme_support("post-thumbnails"); } [COLOR=Red][B]?> <?php[/B][/COLOR] if(function_exists('add_custom_background')) { add_custom_background(); } if ( function_exists( 'register_nav_menus' ) ) { register_nav_menus( array( 'menu_1' => 'Menu 1', 'menu_2' => 'Menu 2' ) ); } ?>Dann siehst du im Originalcode eine Leerzeile in 312 zwischen meinen roten Markierungen. Diese wird ausgegeben. Sauber sollte es so sein:
PHP
Alles anzeigen<?php if ( function_exists("add_theme_support") ) { add_theme_support("post-thumbnails"); } if(function_exists('add_custom_background')) { add_custom_background(); } if ( function_exists( 'register_nav_menus' ) ) { register_nav_menus( array( 'menu_1' => 'Menu 1', 'menu_2' => 'Menu 2' ) ); } ?> -
Das & hat im Permalink auch nichts verloren, denn es ist für die Verkettung von Parametern in der URL reserviert. Mich würde interessieren, wie du solche Links erstellt hast, denn WP würde das & aus dem Permalink enfernen.
Hast du einen Permalink "Anhübscher" als Plugin laufen ? -
-
Lässt sich die von WP grundsätzlich festgelegte Default-Konstanze nicht irgendwie auf ein anderes Theme ändern, so dass der negative "Falleback" garnicht erst eintritt (Leere Seite usw.)...?
Als Antwort zitiere ich mich mal selbst aus meinem Artikel
mit diesem hier:ZitatEinen Automatismus, wie man ihn von älteren WordPress Versionen her kennt, gibt es nun nicht mehr. Man kann allerdings jetzt selbst festlegen, was das Default Theme für den Ausfall oder für neue Unterblogs sein soll. Falls ein Theme eines Blogs ausfällt, dann muß man mindestens die Admin Seite “Design -> Themes” aufrufen, damit zum Default Theme gewechselt wird.
Wie schon gesagt, wenn das Theme defekt ist, muß man ein Mal im Backend nur die angegeben Seite besuchen und das hoffentlich nicht kaputte Default-Theme is aktiv, automatisch ist ab WP 3.0 nix mehr.
Nachtrag: Da das in meinem Blog eindeutig steht und du deine Frage sowohl hier als auch im Blog 1:1 gestellt hast, hab ich sie hier nochmal beantwortet und aus dem Blog entfernt.
-
Das is einer der Nachteile des Safe Mode den es ab PHP 6 endgültig nicht mehr gibt. Der Ordner 2010 wird mit dem Eigentümer als phprun (oder ähnlichem, also Server) erstellt und gehört nicht deinem FTP Nutzer. Somit kann man in Safe Mode dort keinen Unterordner mehr anlegen, denn das WordPress läuft sicher mit dem FTP User und kann dann kein Verzeichnis mehr in einem Verzeichnis erstellen, das jemanden anderes gehört.
-
Wenn du manuell am Theme "rumgebastelt" hast und dabei ein Fehler reingekommen ist, trifft ggf. dieser Artikel auf dich zu: http://www.code-styling.de/deutsch/weisse…ch-themewechsel
Ein kaputtest Theme führt zu einer weissen Seite, wenn das Default Theme beschädigt oder weg ist (Twenty Ten bei WP 3.0).
-
Den Media Upload Folder kann man nur in Standard-Installationen von WordPress so konfigurieren, in Multi Site Installationen ist der immer im entsprechenden Blog Directory und kann nicht wie oben angegeben eingestellt werden, die Felder gibt es schlicht in Multi Site Installationen nicht.
-
Es ist schon erstaunlich, wieviel Halbwahrheiten und Falschinformationen hier verbreitet werden! Wenn man sich die Datei der 1. Fundstelle im o.g. Eingangsbeitrag von Dateinamen her auch nur ansieht, dann stellt man fest, daß dies nur in für die Differenzanzeige für Post Revisionen in .../text/Diff.php gemacht wird. Dies ist eine 3rd party library und nur zu WordPress hinzugefügt. Gewartet wird das Diff Tool aber in einem anderen Projekt.
Die 2. Fundstelle ist die von WorkPress selbst und diese bevorzugt den Wert der Konstanten WP_TEMP_DIR, wenn er denn gesetzt ist. Ansonsten wird ermittelt, wo sich das Temp Directory befindet.
Im Normalfall ist das von Server voreingestellte Temp Directory ein geshartes Directory über alle Domains dieses Servers. Also landen temporär erstmal alle Uploads aller Kunden auf diesem Server in diesem Verzeichnis. Man kann sich sehr einfach dieses Verzeichnis komplett auflisten lassen und alle Dateien ansehen, die andere hochladen, wenn die Scripte zum Hochladen die Dateien nicht wieder ihren Müll beräumen.
Aus diesem Grund kann man seinen eigenen Temp Pfad setzen, um Dateien auch nur im eigenen Domainbereich zu behalten, es ist kein sinnloses Unterfangen deswegen sondern hat auch was mit Sicherheit zu tun.Wichtig: Wenn man das Verzeichnis aktiv durch die Konstante setzt, muß man allerdings auch gewährleisten, daß WordPress dort hin schreiben kann und die passenden Rechte gesetzt sind.
Ich persönlich bevorzuge meinen eigenen Temp Pfad, denn ersten kann ich dadurch sehr leicht sehen, ob Scripte "rumschweinen" und temporäre Dateien nicht beräumen und zweitens ich hab die hochgeladenen Dateien nur in meinem Domainspace und gebe die nicht für alle Kunden "temporär frei".
-
Findet man sehr schnell in unserer FAQ Abteilung, siehe Menüleiste oben: http://faq.wordpress-deutschland.org/server-fehler-…-auf-11-server/
-
Manuelle Menüs unterscheiden sich von automatischen Menüs dadurch, daß man alles selbst festlegen und bei Bedarf auch wieder hinzufügen muß.
Automatische Menüs stellen einfach jede Hauptseite ohne Zutun als Menüpunkt dar, wenn man eine solche veröffentlicht hat.
Wer also automatische Menüs möchte, kann den Code verwenden, den ich veröffentlicht habe. Zum Thema Einfügen in die functions.php ist die sicherste Stelle dazu, wenn man keinen Plan von PHP hat, das erste öffnende PHP Inlay zu suchen, das man daran erkennt:
Direkt danach (Leerzeichen schon noch dazwischen) funktioniert es auf jeden Fall.