Beiträge von codestyling

Zitat von jottlieb

Da wirst du auf Widgets verzichten müssten.

Wieso das denn ?
In WP 2.5 ist das allererste Widget, das ich auswählen kann (Design -> Widgets) ein Seiten-Widget. Ich kann Seiten ausschließen, die ich nicht haben will ansonsten werden alle gelistet gemäß angegebener Sortieroption.

Also wenn ich im Browser folgendes aufrufe, muß ich eine weiße Seite bekommen:

http://www.dumpblog.de/wp-config.php

Statt dessen bekomme ich folgendes:

[B]Internal Server Error[/B]


   File "/web/1/000/031/542/93916/htdocs/blog/wp-config.php" is writeable by group
     suPHP 0.6.2

Da stimmt was mit deiner wp-config.php nicht. Die Dateirechte sind "komisch" gesetzt und dein Provider macht was nicht, was er sollte. Komisch ist nur, das der Blog selbst, der die gleiche PHP verwendet, funktioniert.

Stell mal die Rechte der Datei auf 644. Heißt:

Besitzer: lesen (ja) / schreiben (ja) / ausführen (nein)
Gruppe: lesen(ja) / schreiben (nein) / ausführen (nein)
öffentlich: lesen(ja) / schreiben (nein) / ausführen (nein)

Das sollte Standard sein und funktionieren.

Da beides von Javascript Bibliotheken abhängig ist, kann es zu Komplikationen kommen, wenn beide nicht mit der gleichen Bibliotheksversion arbeiten.

Beispiel:
bei Prototype.js sind die Versionen ab 1.6 aufwärts nicht mehr 100 % kompatibel zu den niedrigeren Versionen.
Sollte also einer der beiden (LightBox/TinyMCE) Prototype 1.5.x benutzen der andere aber 1.6.x verwenden wollen, dann wird einer, wenn nicht beide ausfallen.

Kannst du bitte prüfen, ob die beiden eine "gemeinsame" Datei einer Bibliothek benutzen aber in jeweils einer anderen Version ?

Zitat von jayzon277

Wie verrückt war das denn bitte? Man muss doch Leerzeilen setzen können, wie man will ...

Ja, aber nur innerhalb von <?php ?> allerdings dann so viel du willst.
Aber alles, was außerhalb davon in einer php Datei steht, wird so wie es dasteht an den Browser (Client) geschickt.

Deshalb findest du z.B. auch in manchen Templates erst normalen HTML, dann ein paar PHP Anweisungen und wieder HTML.
Das ist so gemeint und soll per Design so funktionieren in der PHP Welt

Also schauen wir mal, was die upgrade.php macht und warum die Seite leer bleibt:

<?php
define('WP_INSTALLING', true);
if (!file_exists('../wp-config.php'))
    die("Die Datei <code>wp-config.php</code> scheint nicht zu existieren. Sie wird aber ben&ouml;tigt, bevor wir anfangen k&ouml;nnen. Brauchst Du weitere Hilfe? Bei <a href='http://wordpress-deutschland.org/'>WordPress Deutschland</a> findest du eine <a href='http://wordpress-deutschland.org/installation'>deutschsprachige Anleitung</a>. Eine <a href='http://codex.wordpress.org/Editing_wp-config.php'>englischsprachige Anleitung</a> findest Du bei <a href='http://wordpress.org/'>WordPress.org</a>. Du kannst die Datei <code>wp-config.php</code> auch <a href='setup-config.php'>online erstellen</a>, das funktioniert jedoch nicht mit allen Servern. Die sicherste Methode ist es, die Datei manuell zu erstellen.</p><p><a href='setup-config.php' class='button'>Konfigurationsdatei erstellen</a>");


require('../wp-config.php');
timer_start();
require_once(ABSPATH . 'wp-admin/includes/upgrade.php');


if (isset($_GET['step']))
    $step = (int) $_GET['step'];
else
    $step = 0;
@header('Content-Type: ' . get_option('html_type') . '; charset=' . get_option('blog_charset'));
?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

1.) Wenn er die wp-config.php nicht finden kann, dann würde er eine Meldung von sich geben, also muß die da sein.

2.) Nun wird versucht im Unterverzeichnis wp-admin/includes/ die upgrade.php reinzuladen. Solltest du dein admin Verzeichnis umbenannt haben, dann wäre hier vermutlich kommentarlos Schluss -> weiße Seite.
Sollte es jedoch diesen Pfad und die php geben, geht's weiter.

3.) Wenn get_option nicht geht, "stirbt" der Prozess schon wieder kommentarlos, sollte nur dann passieren, wenn es gravierende DB Probleme gibt. -> weiße Seite.

Sollte all das nicht zutreffen, muß im Seitenquelltext mindestens der DOCTYPE stehen.

Wenn dein Blog als Surfer funktioniert aber als Admin nicht, gehe ich davon aus, das du den Admin Ordner umbenannt hast. Das ist in 2.5 nicht mehr möglich, weil wie zu sehen "hart" kodiert.

Hab's nachgestellt !
Wenn ich in meiner wp-config.php nach dem letzten ?> 2 Zeilenumbrüche mache, bekommen ich genau die 1 Leerzeile vor dem DOCTYPE, die du auch in deinen Webseiten hast.

Also schau mal deine php Dateien durch, ob die am Ende nach dem letzten ?> Zeilenumbrüche haben. Ein Umbruch hat nicht gereicht aber 2 :mrgreen:

Zitat von Putzlowitsch

Es gibt Feed-Templates? Wie sieht denn sowas aus?

Uups. Das ist doch gar nicht in der offiziellen Version drin.
Ist einer meiner Beta Erweiterungen von WP, die dazu da ist, erweiterte Analysen des Abholers der Feeds zu machen und bestimmte IP's, Useragents und sonstiges ggf. mit "speziellen" oder gar keinen Inhalten zu versorgen.

Ich editier mal schnell die Punkteliste :oops:

Könnt ihr mal den Seitenquelltext der weißen Seite posten, damit man rausbekommen kann, wie weit der in der /wp-admin/install.php kommt ?
(rechte Maustaste -> Quelltext anzeigen)

Ich kann es verstehen, das alles so sein sollte, wie gedacht.
Nur leider ist das ziemlich schwierig, wenn man keinen Zugriff auf das System hat

Folgende Fragen hab ich noch:

1. Gibt es dein Theme irgendwo zum Runterladen ?
2. [del]Gibt es in deinem Theme ein Feed Template ?[/del]
3. Hast du außer den Theme Dateien irgendwelche Dateien verändert ?
4. Hast du unter Einstellungen -> Verschiedenes "Die veraltete my-hacks.php-Datei unterstützen." angehakt ?

Wenn alles so ist, wie du zusammengefasst hast, dann bleibt ja fast nur das Theme oder die my-hacks.php übrig.

Unter Umständen ist eines deiner Plugins selbst dafür verantwortlich, weil durch pures Vorhandesein (aktiv geschaltet) bereits bei der Initialisierung der WP Core's, noch bevor der Feed ausgegeben wird, das Plugin was ausgibt.

... und noch was, dein Blog liefert Ansi encodierte Feeds aus, obwohl im Feed steht, er wäre UTF-8 Unicode.
Du hast mit Sicherheit ein altes Ansi Blog (iso-latin-1) nicht korrekt auf Unicode laufen.
Wenn du auf Ansi bleiben willst (musst) stell das in der wp-config ein.
Oder bring alles auf Unicode.

Alles in die Index.html und zwar so:

<html>

<head>
<title>Frequently Asked Questions zum Studiengang ISE</title>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<script language="JavaScript">
if (top.frames.length > 0) top.location.href = self.location.href;

function ByeWin() {
//hier deinen Fenster code rein
}
</script>
</head>

<frameset rows="90,*,25" framespacing="0" frameborder="no" border="0" onunload="ByeWin()">
<frame src="top.html" name="nav" noresize scrolling="no">
<frame src="start.html" name="content">
</frameset>
<noframes>

<body></body>

</noframes>
</html>

Aber schön ist das nicht, fühlt sich wie Werbe-Popup an und könnte von Popup Blockern einfach unterdrückt werden. Also verpufft die Wirkung vermutlich.

Und der Fenster öffnen Code ist nicht korrekt, da gibts bei SelfHTML was zum nachlesen.

Hi,

dieses Forum ist nicht primär auf die Lauffähigkeit von XAMPP spezialisiert, nur weil WordPress auch drauf läuft.
Ein XAMPP für Windows Forum findest du hier, dort solltest du aber englisch können.

Aber ich hab noch Ideen. Ich hab mal das K2 Theme runtergeladen.
Header.php:

<?php
    // Load localizatons
    load_theme_textdomain('k2_domain');


    // Load our scripts
    wp_enqueue_script('k2functions');


    if (get_option('k2rollingarchives') == 1) {
        wp_enqueue_script('k2rollingarchives');
    }


    if (get_option('k2livesearch') == 1) {
        wp_enqueue_script('k2livesearch');
    }


    if ((get_option('k2livecommenting') == 1) and ((is_page() or is_single()) and (!isset($_GET['jal_edit_comments'])) and ('open' == $post-> comment_status) or ('comment' == $post-> comment_type) )) {
        wp_enqueue_script('k2comments');
    }
?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

Wenn eine dieser Funktionen auch nur irgend was ausgibt, verschiebst du deinen DOCTYPE um die Ausgabe, was in deinem ausgelieferten Quelltext ja passiert.

Es muß allerding auch keine dieser Routinen sein, sondern irgend eines deiner Plugins kann in der Startphase (initiales Laden) seinen "Mund" nicht halten und gibt Leerzeichen aus.
Schalte mal alle Plugins aus und prüfe dann, denn der Admin Bereich lädt ebenfalls alle Plugins aber nicht deine Header.php.
Deshalb tippe ich auf irgend ein oder mehrere Plugins.

Zitat von Lou_Cipher

Ihr habt alle eure wp-config überschrieben vermute ich. wp-config-sample.php hättet ihr von neuen wp 2.5 ordner entfernen müssen vor dem upload.
http://wordpress-deutschland.org/installation/:mrgreen:

Avatar und Inhalt des Posts passen gut zusammen ...

... man kann eine wp-config.php nicht mir einer wp-config-sample.php überschreiben, es sein denn man benennt die vorher um.
Der Sinn ist ja gerade der, das man seine alte Konfiguration behalten kann und die neue Version einspielen kann, ohne die Konfiguration zu verlieren.

Zum eigentlichen Problem bin ich noch am Forschen, ich werd das mal versuchen, in meinem "Labor" nachzustellen :mrgreen:
Lösung kommt, wenn's bei mir auch so endet.

---TEST RESULTAT------------------------------------------------------------------------------------

Also was auch immer ich anstelle mit meiner Ausgangsdatenbank und einem WP 2.3.3 System, ich kann dieses Problem nicht nachstellen, wie es beschrieben wurde.
Was mir gelungen ist,
- die Domain ganz totzulegen
indem ich die alte Konfig mit einer neuen Konfig (wp-config.php) ersetzt habe, in der ich allerdings die korrekten DB Zugangsdaten aus der alten eingegeben hatte.
"Vergessen" hatte ich jedoch, daß mein Wordpress nicht mit dem Standardprefix arbeitet:

$table_prefix = 'wp_'; // Nur Zahlen, Buchstaben und Unterstriche bitte!

Das führt dazu, das dann nix mehr ging, aber ist sicher nicht das, was bei euch passiert.
Ansonsten konnte ich mich auf den Kopf stellen, wenn ich mich an die bekannten Anleitungen halte, gehts danach immer.

Ich hab aber noch zwei Vermutungen:
1.) Das Patchen der DB aufgrund der schieren Menge möglicher, enthaltener Posts, Kategorien und Tags dauert viel länger als das PHP erlaubt ist.
-> dann müßte aber das Update einmal angelaufen sein und erst danach der Login (oder ganze Blog) nicht mehr gehen, weil DB kaputt.
2.) Das Blog läuft nicht aus dem Root der Domain sondern in einem Unterordner.
-> das hab ich bisher nicht getestet.

Zitat von Putzlowitsch

Tschuldigung, hatte mich vertan. Ich meinte nicht Strg+"Neu laden", sondern Shift+"Neu laden". Damit wird alles neu geladen, ob nun HTML, Bilder, CSS oder Javascript. Das kann man sehr schön mit Live-HTTP-Headers verfolgen, auch ein nützliches Tool für Entwickler

Stimmt für den Fall, das die JavaScripts direkt gefragt werden.
Bei TinyMCE (zumindest in der 2.3.3 Version, kann im Moment nicht nachschauen, ob bei 2.5 auch), werden aber die Scripts per

wp-includes\js\tinymce\tiny_mce_gzip.php

ausgeliefert.
Diese entscheidet, ob sie neu zippen muß, was rein kommt und vor allem, ob eine gecachte Platten Version stattdessen auszuliefern ist.
Die macht es zwar (noch) nicht am Zeitstempel fest, aber hier bekommt man u.U. nicht immer alles wie man denkt.

Da WP 2.5 ja auch das Cookie Format umgestellt hat, empfiehlt sich jedoch ein Clear bzw. die Cookies zu löschen.
Ist ja nur nach einem Upgrade sinnvoll, und Benutzer anderer Browser haben diesen Luxus nicht, da brauchts eine verlässliche Lösung...

Und was LiveHeader angeht erschlägt das FireBug.png ebenfalls gleich mit, Zeitmessung, Dateigrösse und Inhaltsanzeige inclusive.

Zitat von redcat63

Kann es sein, dass der Firefox automatisch eine neue Version installiert?

Von FireFox 1.x zu FireFox 2.x wurde die JavaScript Engine in FireFox erneuert und (ge)bugfixed, wenn man so will ist der JavaScript Interpreter neu.

Mit der kommenden FireFox 3.0 ist der Interpreter nochmals erneuert worden und wird in weiteren Versionen (3.0 noch nicht ganz klar) auf der Technology von Adobe Action Script (also dem Interpreter von Flash) drastisch beschleunigt.

So wie man WP updated sollte man auch mit FireFox verfahren, dann hat man die wenigsten Probleme.

Zitat von redcat63

Es ist nicht die, sondern eine von vielen Grundausstattungen...

Hi Elke,

hatte ich auch so nicht gemeint
jeder nimmt nur das, was er braucht, war nur eine allgemeine Aussage, sonst hätte ich "die" unterstrichen :mrgreen:

Zitat von Putzlowitsch

Kann man nicht beim Firefox einfach des Neuladen mit Strg+"Neu laden" erzwingen?
Muß man nicht immer gleich den gesamten Cache löschen.

Das gilt zwar für HTML, nicht aber für Stylesheets und Javascripts.
Das cachen Browser sehr viel länger und fragen das gar nicht mehr nach, wenn sie's einmal haben. (hängt auch von den Servereinstellungen mit ab)

Opera cached sogar HTML länger als man war haben will und holt das auch nicht immer ab, selbst bei reload nicht.

Deshalb ist ein Löschen des Browsercaches in Bezug zu JavaScript und auch CSS Dateien im Upgrade Fall immer die beste Wahl.

Ich würde auch mal versuchen den Browsercache und die Cookies zu löschen, denn mit WP 2.3.3 -> WP2.5 hat sich auch das Cookieformat geändert und möglicherweise wirst du abgewiesen wegen eines Cookies der alten Version.
WP2.5 denkt, du bist schon ein angemeldeter Benutzer, aber dann stimmt doch was mit dem Cookie nicht.

Dein Blog ist falsch aufgesetzt, man findet jetzt den Admin bereich hier
Blogname › Anmelden.

Hast du alle Files in den Hauptordner der Domain entpackt ?