Beiträge von Ammaletu
-
-
Ohne Dich entmutigen zu wollen, aber die Tatsache, dass Du diese Frage stellst, sagt mir, dass Du aktuell nicht genug weißt, um WordPress wirklich selber hosten zu können. Überlege bitte kurz, ob ein gehostetes Blog z.B. bei wordpress.com, nicht die bessere Alternative ist. Ist nicht fies gemeint, aber um WP selber zu hosten, Updates einzuspielen und ggf. mit Sicherheitsproblemen umzugehen muss man schon ein gewisses technisches Verständnis mitbringen. :-)
Ansonsten: Du lädst WordPress normalerweise auf Deinen Rechner runter, entpackst die zip-Datei und änderst die wp-config. An diesem Punkt liegen die Daten auf Deinem Rechner und Du hast die volle Kontrolle darüber, ob Du sie schreibgeschützt machst oder nicht. Und danach halt per FTP auf den Server übertragen. Wenn ich raten müsste, würde ich sagen, Du hast die Datei direkt aus dem zip-Archiv geöffnet, und da hinein kann WordPad die Datei halt nicht zurückspeichern. Falls das so war einfach entpacken, kopieren, umbenennen und Daten anpassen.
-
Gibt es da nicht einen offset-Parameter? Schau mal im Codex nach.
-
Zitat
@ Ammaletu
das wäre sicherlich möglich und ich sag jetzt einfach mal ja, wenn wir uns für DF entscheiden :wink:Danke, würde mich freuen. Sag ggf. per PN Bescheid.
ZitatAber das klingt ja erstmal ganz gut, kannst du was zu dem Mailserver und Webmailer sagen ?
Der sollte schon eine gute Uptime haben, da der Mail Verkehr wichtig ist und zuverlässig funktionieren muss.Ich kann da natürlich als normaler Kunde keine Zahlen nennen. Probleme sind mir bisher jedenfalls nicht aufgefallen. Der Spam-Filter ist recht gut, aber das klappt ja bei vielen Anbietern mittlerweile gut. Zur Uptime kannst Du natürlich mal den Support fragen, andererseits wird wohl kein Anbieter wirklich zugeben, wenn die nicht so dolle sein sollte. ;-) Was eventuell weiterhilft ist ansonsten, mal im DF-Forum ein oder zwei Reseller-Kunden anzuschreiben. Die müssten ja theoretisch zur Uptime der Server viel eher was sagen können.
Ich kann jedenfalls nur sagen, dass DF auf mich immer einen sehr professionellen aber freundlichen Eindruck macht, und ich habe in beiderlei Hinsicht schon andere Provider erlebt. ;-)
Wenn man etwas googelt, findet man einzelne Berichte, dass DF wohl ab und an auf Spam-Blocklisten gelandet ist. Das scheint aber alles schon etwas her zu sein und kommt hoffentlich nicht mehr vor. Auch da wäre es vielleicht schlau, einen DF-Reseller mal nach seinen Erfahrungen zu fragen. Wenn man im DF-Forum in ein paar Threads schaut, findet man schnell sehr aktive Reseller, die sicher gerne weiterhelfen mit Infos.
-
Die verlinkte Funktion sollte eigentlich passen. Das erste Argument ist die ID des Beitrags, das zweite der Key des Custom Feldes. Heraus kommt ein Array, glaube ich, außer Du setzt den dritten Parameter auf true, dann ein String. Was passt daran nicht? :-)
-
-
Zitat
Hatte gehört das domain-factory sehr gut sein soll, aber da verlasse ich mich lieber auf eure Erfahrungen
Genau das hätte ich Dir jetzt auch empfohlen. Ich mache mit meinem Webspace nichts zu krasses, aber meine Seiten laufen bei DF seit Jahren ohne jede Probleme. Speziell beeindruckt mich der freundliche Support und auch das sehr hilfreiche Kundenforum. Wenn Du spezielle Anforderungen hast, die von den Standard-Paketen nicht abgedeckt werden oder Hilfe bei der Auswahl des Tarifs brauchst, kannst Du Dich sicher auch einfach an den Support wenden. Das ist für Dich vielleicht auch schon mal ein schöner Test, wie gut da die Kommunikation klappt.
P.S.: Mal ganz frech gefragt: Falls Du Dich für DF entscheidest, würdest Du meine Auftragsnummer eintragen beim Bestellen, dass ich Dich geworben habe? :-)
-
Dann schaue doch bitte in die Logdatei auf dem Server, worin der Server Error besteht. Raten bringt da nicht viel. ;-) Wo die Datei liegt, hängt von Deinem Provider ab. Bei DomainFactory liegt das bei mir z.B. auf der obersten Ebene in einem logs-Ordner (errors.log oder so ähnlich, habe länger nicht reingeschaut). Einfach mal per FTP umschauen.
Es wird dann vermutlich daran liegen, dass im Apache noch etwas nicht richtig eingestellt ist, könnte ich mir vorstellen.
-
Ja, das gehört in die .htaccess rein. So wie WordPress das auch schon macht. So in etwa "wenn nicht domain1, dann Weiterleitung". Das erfasst dann auch die Variante mit oder ohne "www". Falls Du es Dir aus einer WordPress-htaccess nicht ableiten kannst, sag Bescheid, dann schreibt Dir das hier sicher auch jemand im Detail auf. Aber es gibt dazu auch schon x Threads im Forum, denke ich, such mal nach "Weiterleitung" oder so.
-
Prinzipiell ändert sich da eigentlich nicht viel, außer vielleicht der Speicherort der Upload-Dateien. Im Ordner wp-content/uploads liegen nur wenige Sachen, wie etwa Header-Bilder. Die regulären Uploads liegen in wp-content/blogs.dir. Diesen Ordner beim Backup-Erstellen also immer mit sichern.
Den Schritt, alle Plugins zu deaktivieren, würde ich ehrlich gesagt auch überspringen, wenn es keinen konkreten Grund dafür gibt. Da man ja manche Plugins fürs ganze Netzwerk aktiviert und andere nur für einzelne Blogs, wäre das ja sonst schon eine ganz schöne Aktion.
-
Wenn ich mich gerade richtig erinnere werden die verschiedenen Tools von wp.com unter dem Namen "JetPack" zusammengefasst. Ob dieses spezielle nun dabei ist musst Du probieren, ansonsten gibt es da ja genug Plugins. ... Ah ja, hier: http://wordpress.org/extend/plugins/jetpack/
-
Wenn Du die URLs in den Einstellungen geändert hast und danach die Permalinks speicherst, sollte WP eigentlich von sich aus die .htaccess in den Unterordner legen, denke ich. Wenn die Seite über yyy.de aufgerufen wird, welches ja auf den wordpress-Unterordner zeigt, ist über diese URL die .htaccess im Oberordner nicht mehr erreichbar und würde also auch nicht ausgewertet werden. Die alte .htaccess kann dann weg. Denke ich jedenfalls, aber nagel mich nicht dauf fest, ist schon spät heute. ;-) Im Zweifelsfall einfach mal ausprobieren und die Dateien vorher per FTP sichern, damit es ggf. zurückgedreht werden kann.
-
Zitat
nun lass ich von meinem Webhoster die Domain "yyy.de" auf "xxx.de/wordpress" umleiten
Falls "umleiten" nicht irgendeine Form von Weiterleitung oder iFrame-Trick heißt, sondern ein echtes Draufschalten auf dieses Verzeichnis, dann sollte es eigentlich so gehen, wie Du es gemacht hast: Im WP-Backend beide Einstellungen auf die neue Domain ändern. Danach auf jeden Fall auch de Permalinkstruktur (unverändert) neu abspeichern, da in der .htaccess ja der nun nicht mehr in der URL enthaltene Unterordner drinsteht. Und dann muss das eigentlich gehen. Eventuell mal den Browser-Cache umgehen mit Strg+F5.
-
Ich rate mal: Wenn Du eine Unterkategorie anzeigst, dann gibt category_has_children() false zurück und die Sub-Navigation wird deshalb nicht angezeigt. :-)
-
Entweder ein Plugin oder das Theme wird da an der Query der Seite manipulieren und dabei den Parameter unterschlagen, nehme ich an. Schritt eins sollte sein, herauszufinden wo genau das passiert. Also z.B. kurz auf ein anderes Theme wechseln und schauen, oder das ein oder andere Plugin mal kurz deaktivieren.
-
Die Fehlermeldung ist wirklich eindeutig: In Zeile 2 der functions.php steht ein Doppelpunkt, wo er nicht hingehört. So komplex kann diese Zeile nicht sein, dass sich die Ursache nicht finden lässt, wenn Du schon Änderungen an der Datei vornimmst. ;-)
Wie Shadow schon schrieb, muss WP ja irgendwie auf den Server gekommen sein. Nutzt Du eine vom Hoster vorinstallierte Version? Aber selbst da solltest Du doch Zugriff auf den Webspace per FTP haben, oder nicht? Falls Nein bitte den technischen Support Deines Hosters, den Ordner des Themes umzubenennen, dann schaltet WP automatisch aufs Standard-Theme um (Twenty Eleven müsste das dann sein, denke ich). Ansonsten eben per FTP verbinden, runterladen, berichtigen, wieder raufladen. Falls Du Firefox benutzt, würde ich die FireFTP-Erweiterung empfehlen, aber es gibt auch genug StandAlone-FTP-Programme, Filezilla etc.
-
Ich glaube, das Problem ist recht simpel: Du loggst Dich nicht auf der Domain ein, auf der die Seite läuft. Irgendwie ist da was falsch konfiguriert.
Zur Erklärung: Das Loginverfahren ist Cookie-basiert, und Cookies werden immer für eine Domain gespeichert. Jede Seite ist aber in der Regel über mindestens zwei Domains zu erreichen: http://www.steilwaende.at und steilwaende.at. WordPress schick Besucher immer zu der Seite, die in den Backend-Einstellungen eingetragen ist, entweder mit oder ohne www.
Wenn Du Dich auf http://www.steilwaende.at einloggst, leitet die Antwort auf steilwaende.at weiter. Selbst wenn Du Dich auf der einen Domain erfolgreich eingeloggt hast, bist Du beim Aufruf der anderen natürlich nicht eingeloggt und kriegst entsprechen die Loginmaske zu sehen. Und dann Endlosschleife.
Ich denke, Du solltest mal direkt in der Datenbank schauen (phpMyAdmin), was als Seiten-URL und Blog-Adresse in der wp_options-Tabelle eingetragen ist und das ggf. auf die gleiche Form bringen (beides mit oder beides ohne www). Findest Du das oder brauchst Du da weitere Infos.
Ich hoffe, dass es daran liegt, denn so ganz im Detail steige ich gerade nicht durch, was da eigentlich schiefläuft und wieso das Login-Formular auf eine andere Adresse postet als mit der es aufgerufen wurde. Aber mit etwas Glück war es das ja schon.
-
Probier mal, ob Dir die Quelltext-Ansicht vielleicht mehr liegt. Wenn man viel Code postet, wird man mti TinyMCE in der Regel nicht glücklich und schaltet ihn aus. Das kannst Du in Deinem Nutzerprofil machen.
-
Dann läuft bei Dir vermutlich ein schlecht/gar nicht konfiguriertes Cache-Plugin. Das, oder Dein Browser cacht das (mal Str+F5 probiert?).
-
Kannst Du Dir nicht über die "Passwort vergessen"-Funktion ein neues schicken lassen?