Beiträge von Ammaletu

    Also ich fange mal mit dem letzten Punkt an: Ich denke nicht, dass eine größere Zahl an Artikeln Probleme macht. Es kann aber sein, dass manche Admin-Interfaces damit Probleme bekommen. Du solltest also ab und an schauen, ob es irgendwo im Backend Probleme gibt. Ggf. hier melden und dann findet sich da sicher eine Lösung.

    Was Probleme machen kann, falls Du auch viele statische Seiten hast, ist die Permalinkstruktur. Du solltest dann unbedingt sicherstellen, dass die URLs der Beiträge eine ID oder ein Datum enthalten und nicht nur aus domain.tld/artikel-slug bestehen. Siehe: http://ottopress.com/2010/category-…idered-harmful/
    Wenn ich das gerade richtig verstehe gilt es nur für Seiten, nicht für Artikel, aber es schadet sicher nicht, das gleich richtig einzurichten.

    Also nur zur Erklärung: Nach den FTP-Daten fragt WP, wenn Apache mit einem anderen Benutzer läuft und deswegen die per PHP gezogenen Dateien einem anderen Benutzer gehören würden. Dann zieht WP die Daten lieber per FTP, um die Dateizugehörigkeit entsprechend setzen zu können. Wenn das bei Dir nicht geht, liegt es vielleicht daran, dass dieser FTP-Zugriff auf den eigenen Server nicht klappt? Ging das denn früher schon mal bzw. waren da die FTP-Daten nötig?

    Zitat

    Meine Frage ist, wie speichere ich nun die Sachen, und vorallem WO (welcher Abschnitt) inder post.php wird das gespeichert.

    Das speicherst Du am besten als Benutzerdefiniertes Feld. Eigene Spalten in der Tabelle würde ich wenn irgend möglich vermeiden, das macht auf lange Sicht nur Probleme.


    Zitat

    Kann man mit dem Plugin die Daten speichern OHNE, die post.php modifizieren zu müssen?

    Sicher, auch wenn ich Dir gerade nicht sagen kann, wie. Frank Bültge hat mal ein Beispiel-Plugin für genau diesen Zweck geschrieben, und ich nehme an, dass da u.a. auch die Speicherung drin stehen sollte:
    http://bueltge.de/wordpress-plug…schreiben/1086/


    Zitat

    Die Felder habe ich auch über js ins Formular geschleust :wink:

    Auch das sollte eigentlich über entsprechende Hooks und Filter gehen. Ich denke nicht, dass Du da auf JavaScript zurückgreifen musst. Kannst Du Dir aber sicher ebenfalls an verlinktem Beispiel abschauen.

    Ansonsten gibt es noch die Custom Post Types, die das ganze eventuell einfacher machen. Dafür muss man dann wieder andere Dinge einstellen, Aufnahme in de Feed zum Beispiel.

    Die meta-Zeile gibt etwas in die Seite aus. WordPress muss aber geladen werden, bevor irgendeine Ausgabe erfolgt (auch kein Leerzeichen oder Zeilenumbruch), sonst kann es keine HTTP-Header mehr schicken.

    WP so einzubinden wäre doch aber sowieso nicht sehr sinnvoll, oder? Jeder Link in der WP-Seite würde ja nicht auf Deine übergeordnete Seite führen sondern auf WP direkt. Was willst Du denn genau erreichen? Anzeige eines Menüs über/neben dem Blog?

    Schon das allererste Google-Suchergebnis führt Dich zu der Syntax für WP_DEBUG:

    PHP
    define('WP_DEBUG', true);

    Ergänze das mal und schaue, ob dann eine verwertbare Fehlermeldung kommt.

    Und ja mit 'Update manuell beenden' meinte ich die gewünschte WP-Version per FTP drüberzuspielen und ggf. das Upgrade durch einen Login am Backend anzustoßen.

    Ob Dein Provider generell Probleme mit PHP hat kannst Du ja ganz einfach testen, indem Du eine leere PHP-Datei mal nur mit

    PHP
    <?php phpinfo(); ?>

    füllst und aufrufst. Aber schau erst mal nach der WP_DEBUG-Ausgabe.

    Ich nehme an, das ist historisch so gewachsen. Ich stelle mir das so vor:

    * Angefangen hat alles mit dem Benutzernamen.
    * Dann hat man Felder für Vor- und Nachname gemacht, für etwas förmlichere Blogger. Ist aber kein Pflichtfeld, braucht ja nicht jeder.
    * Dann konnte man aussuchen, welchen Namen man anzeigen wollte, per DropDown (öffentlicher Name).
    * Und am Ende kam jemand auf die Idee, eine Möglichkeit zu schaffen, den Login zu verbergen. Dafür ist dann das Nickname-Feld da: Als Pflichtfeld muss da also immer was stehen, so dass man das beim Öffentlichen Namen vor dem Login auswählen kann. Der steht da zwar zur Auswahl, aber es wird sicher der Nickname präferiert, denke ich.

    Kann natürlich auch ganz anders gewesen sein, ich hab für solche Details kein gutes Gedächtnis und schaue sehr selten in das Nutzerprofil. ;-)

    Zitat

    Beim Anzeigen eines Artikels spielt der Spitzname doch eh keine Rolle, sondern dort wird der öffentliche Name angezeigt

    Der öffentliche Name kann auf eines von mehreren Feldern gesetzt werden (Login, Nickname, Vorname, Nachname, Vorname+Nachname). Wie gesagt, gäbe es den Nickname nicht, würden die meisten Leute das auf ihrem Login lassen, nehme ich an.

    Nein, das kann der Hoster einrichten wie er möchte (oder eben auch nicht bei vielen). Wenn Du die php.ini oder den Apachen direkt bearbeiten kannst, kannst Du Dir das natürlich auch selber einstellen.

    Darüber hinaus gibt es wie gesagt die WP_DEBUG-Konstante, welche normalerweise die Anzeige von Fehlern am Bildschirm bewirkt. Das könnte jetzt immer noch Aufschluss geben, zumindest darüber welche Dateien fehlen/kaputt sind, aber es zeigt Dir nicht rückwirkend die Fehler vom Update an, nur deren Folgen, die sich aktuell auswirken.

    Es ist Dein Server. Das solltest Du eigentlich wissen, ob und wenn ja wo Fehler geloggt werden. ;-) Ist ggf. eine Frage für den technischen Support des Hosters. Generell hilft die WP_DEBUG-Konstante in der wp-config.php weiter, aber damit kannst Du nun natürlich auch nicht nachträglich Fehler des fehlgeschlagenen Updates loggen.

    Also die simpelste Variante wäre sicherlich, einen Abschiedsbeitrag zu schreiben und deutlich auf die neue Adresse hinzuweisen. Feed-Leser müssten dann eben den neuen Feed abonnieren. Dessen Link kannst Du ja in dem Beitrag sinnvollerweise gleich anbieten.

    Ob es eine technische Weiterleitungsmöglichkeit von Blogspot auf externe Seiten gibt, bezweifele ich etwas, kann aber natürlich sein.

    Error 500 ist nur ein Sammelbegriff für eine Vielzahl an Fehlern. Ohne die eigentliche Fehlermeldung kann man da nicht viel zu sagen. Probier mal WP_DEBUG mit Wert true in wp-config.php zu definieren, dann wird beim Aufruf vielleicht was angezeigt. Davon abgesehen wäre der nächste logische Schritt, das Update manuell zu Ende zu führen, wenn es automatisch nicht geht.

    Installieren im Sinne von "in den Themes-Ordner legen" kannst Du so viele Themes, wie Du möchtest. ;-) Mit einem Plugin wie dem "Theme Switcher" kann das dann z.B. auch vom Nutzer ausgewählt werden. Man kann das aber auch selber machen, wenn man es z.B. je Kategorie ändern möchte oder so. Wobei es ggf. sinnvoller wäre, das innerhalb eines Themes zu machen und nur die Kategorie anders zu stylen. Kommt auf den genauen Einsatzzweck an.

    Wenn Du eine Testinstallation hast, kannst Du es ja einfach mal rausnehmen (jedenfalls wenn es vom Theme und nicht direkt von einem Plugin eingebunden wird) und schauen, ob das zu JavaScript-Fehlern führt.

    jQuery wird allerdings mittlerweile von sehr vielen Plugins genutzt, einfach weil es so unheimlich praktisch ist. Es sollte eigentlich auch nicht nennenswert groß sein, denn es wird ja sicher gepackt ausgeliefert und nicht in der größeren Entwicklerversion!?

    Ich würde dann eher schauen, ob daneben noch andere Libraries genutzt werden. Es macht keinen Sinn jQuery *und* Prototype *und* Scriptaculous einzubinden. Ich habe das bei mir z.B. auf jQuery gekürzt, indem ich die Original-Lightbox durch einen jQuery-basierten Lightbox-Klon ersetzt habe. Das spart auf einen Schlag mehrere JavaScripte und etwa 150 KB ein. Nur mal als Beispiel.