Installationskatastrophe

[evaki]

Nachdem ein Anwender die aktuell auf der Downloadseite verfügbare v2.12 beim Hoster installieren wollte, gab's nur "Müll" als Ergebnis. Habe dieses Archiv mal lokal versucht zu installieren, mit dem gleichen Ergebnis, nämlich Fehlermeldungen und fehlende Funktionen. Man bekommt den Eindruck, daß das eigene System komplett verhunzt ist. Da ich den ganzen Mist nicht durchexerzieren wollte, habe ich eine frühere Version installiert, und siehe da, keine Probleme. Auch alles andere auf unserem und meinem System läuft wie gehabt.

Um jetzt keine endlose Diskussion führen zu müssen, möchte ich nur darum bitten, die aktuell downloadbare Version zu überprüfen.  Die ein oder andere Bestätigung von den aktiven Helfern würde auch genügen.

MfG. Evaki

p.s. Ich bin mir übrigens trotz aller gemeldeten Fehler nicht ganz sicher, ob -weil ich keinen EInblick auf den KundenServer habe- das alles seine Richtigkeit hat. Der kurze Ausflug in meine Systeme sagt auch noch nicht allzuviel aus, da wird u.U. viel übersehen ("auf die Schnelle"). Möchte nur sicher gehen, daß alles Ok ist oder auch nicht, bevor ich da u.U. viel Zeit investiere.

[evaki]

Na, noch 'ne weitere Info bekam ich soeben:
error.log:
Wed, 07 Nov 2018 17:45:13 +0000 [E_WARNING] \framework\functions.php:[408]  from \framework\functions.php:[685] make_dir "mkdir(): Invalid argument"

Das geschieht anscheinend, wenn er eine neue Seite anlegen möchte.
Frage mich gerade wie er die erste Seite hinbekommen hat.
Alles sehr merkwürdig.
MfG. Evaki

[Gast]

aktuelle ZIP-DL-Version hatte ich am letzten Wochenende von dort geladen und unter PHP 7.2.11 ohne Probleme installiert

eben noch mal für dich sowohl ZIP wie auch gz-Version runtergeladen und installiert

Beide Versionen der WB 2.12.0 gehen ohne Probleme

Ein Fehler beim mk_dir() ist aber eher ein Berechtigungsproble m, analog dem Installer, der schreibt da nämlich eine log-Datei ins var-Verzeichnis und bricht im Falle des Falles dann mit halber Installation ab

[evaki]

Berechtigungsproble m dachte ich auch dran, ist ja auch naheliegend.
Doch komischerweise trat das dann auch unter Windows auf (oder nur dort? -hab nicht weiter gefragt). Das deutet somit dann auf all den installierten Schutzkram hin, der da  möglicherweise was "verbiegt".   

Ist schon mal mehr als gut, daß WB als Verursacher ausgeschlossen werden kann.
Das erspart einem einiges an "Sucharbeit", danke.
Kann ich ja beruhigt schlafen, und mich auf den "Saukram" einstellen.
MfG. Evaki

[astricia]

Ich habe die 2.12.0 rc81 mehrfach bei verschiedenen Hostern installiert - ohne diese beschriebenen Probleme. Es wäre vielleicht hilfreich zu wissen, bei welchem Hoster diese Probleme auftreten. Kann mich erinnern, dass ich z.B. mal letztes Jahr bei einem Projekt ein Problem hatte, weil der Server nur SQL strict zugelassen hat... vielleicht liegt es daran?

[Gast]

Kann mich erinnern, dass ich z.B. mal letztes Jahr bei einem Projekt ein Problem hatte, weil der Server nur SQL strict zugelassen hat... vielleicht liegt es daran?

Nein, definitiv nicht, solang es WebsiteBaker und die im Paket mitgelieferten Module betrifft.
Ich arbeite lokal und auch bei einigen Kunden im Mysql-Strict-Mode, wäre aufgefallen

[evaki]

Habe jetzt ganz pragmatisch die Untersuchung des Umfelds unterlassen, und  das Projekt des Anwenders auf einem (schon länger) funktionierenden Account installiert. Von dort aus kann er nun ohne Panik weiter an seiner Site arbeiten, und auf die nächste WB-Version warten.
Somit hat er nun die Möglichkeit in Ruhe die Fehlersuche zu starten. 

Danke für die Rückmeldungen, die diese Vorgehensweise ermöglicht hat.
MfG. Evaki

[evaki]

Wir haben uns zusammengesetzt - von wegen  "in Ruhe die Fehlersuche..." - und uns daran gemeinsam erneut versucht.
Mit mehreren Paketen bzw Zusammenstellungen (z.B. Fixes) wurden auf ein und demselben Account diverse Installationen vollzogen.

Alle zeigten nach der Installation (in ROOT) den selben Fehler. Man kann Seiten anlegen, angezeigt wird jedoch nur die oberste im Baum, die anderen bleiben weiß.
phperror.log:

Code: [Select]

[09-Nov-2018 18:29:26 Europe/Berlin] PHP Warning:  require(../index.php): failed to open stream: No such file or directory in /home/www/doc/123456/nixda.de/www/x3.php on line 8
[09-Nov-2018 18:29:26 Europe/Berlin] PHP Fatal error:  require(): Failed opening required '../index.php' (include_path='.:/usr/local/php-7.2/lib/php') in /home/www/doc/123456/nixda.de/www/x3.php on line 8x3.php bleibt weiß. Der Admin hat dann mal testweise required 'index.php' eingesetzt, und siehe da

Habe dann auch mal bei meinen eigenen Installationen geschaut. Die liegen alle nicht in ROOT.
Experimentieren bzw. das (Un)Glück herausfordern wollte ich nun aber auch nicht.

Tja, wat nu?
Der Anwender ("Klein Admin") hat nun ein Problem.
MfG. Evaki

[hgs]

So ganz verstehe ich das Fehlerbild noch nicht
Habe gerade mal eine Seite x3 angelegt, diese wird ohne Probleme angezeigt.

Welche php-Version wird eingesetzt?
Was meist du mit

Alle zeigten nach der Installation (in ROOT) den selben Fehler. Man kann Seiten anlegen, angezeigt wird jedoch nur die oberste im Baum, die anderen bleiben weiß.

?
gibt es den Ordner /pages nicht?

[evaki]

gibt es den Ordner /pages nicht?

So ist es.

So, nochmal von vorn:
1.) Installation OK
2.) Optionen > Erweiterte Optionen > Seitenverzeichnis /pages gelöscht
3.) Seite hinzufügen: Alle meine Entchen
4.) Aufruf der Seite: h ttps://domain.de//alle-meine-entchen.php = NIX, bedeutet weiß -ohne Templateansicht
5.) Aufruf der Seite: h ttps://domain.de  = OK -Ansicht mit Template
6.) Im BE unter Optionen ist nun Seitenverzeichnis: /

Weitere Seiten anzulegen erspare ich mir, da Resultat bekannt.
php_errors.log:

Code: [Select]

[10-Nov-2018 09:07:11 Europe/Berlin] PHP Warning:  require(../index.php): failed to open stream: No such file or directory in /home/www/doc/12345/domain.de/www/alle-meine-entchen.php on line 8
[10-Nov-2018 09:07:11 Europe/Berlin] PHP Fatal error:  require(): Failed opening required '../index.php' (include_path='.:/usr/local/php-7.2/lib/php') in /home/www/doc/12345/domain.de/www/alle-meine-entchen.php on line 8

Beim selben Hoster, anderer Account, liegt die WB-Installation im Unterverzeichnis. Dort funktionierts, und  domain.de// ist dort auch nicht zu sehen.

MfG. Evaki

[Gast]

Da hast du uns aber schön aufs Glatteis geführt, vielleicht sollten wir mal ein paar Begriffe definieren

Root - entspricht dem Document Root des Servers, auch Stamm- oder Wurzelverzeichnis. Englische Bezeichnung ist Root. Es ist, in einfachen Worten, auf einem Webserver das oberste, von "außen" zugängliche Verzeichnis. Alles weitere dazu hier in Wiki.
"Installation im Root" bedeutet demnach nichts anderes als das die Startdatei des Projekts in diesem Root liegt und nicht etwa in einem Unterverzeichnis.
Davon unabhängig ist es in WB möglich, den Pfad des Seitenverzeichnisse s anzupassen. In diesem Seitenverzeichnis (Standardeintrag: /pages) werden die sogenannen Accessfiles hinterlegt. Warum und wieso ist WB-Geschichte, da muß man wohl Ryan fragen. Ich erinnere mich aber, das zu dieser Zeit der WB-Entwicklung andere Systeme wie Joomla ebenfalls solch Ordner in den Links hatten, vielleicht war es auch eine Frage der Ordnung. Egal...
Entfernt man das Seitenverzeichnis in den WB-Option, liegen diese Accessfile im WB-Root, das kann, muß aber nicht gleich dem Root des Servers sein. Mein Online-Testinstallationen liegen z.b. in der Struktur /web/wb/wb212/ - das heißt im Ordner wb212 ist auch mein WB-Root, aber eben nicht der Root des Servers

Grundsätzlich ist WB so ausgelegt, das es nie nach oben über das eigene Installationsverzei chnis hinaus kann und schon garnicht über den Document Root des Servers und ich erinnere mich, das wir dieses Verhalten gerade im Bezug der Entfernung des /pages Eintrages im Rahmen der WB 2.11 sehr intensiv getestet haben. Was die Nachfolgerversionen betrifft, kann ich nicht sagen, ob das nochmals geändert wurde

Die Informationen, das das /pages-Verzeichnis entfernt wurde, hätte ich gern eine Woche früher gehabt. Es geht mich zwar nichts mehr an, aber wenn es da ein Problem gibt, wird es die nächste WB-Version auch betreffen und dann sollte es gelöst sein, bevor eine 2.12.1 erscheint

[Gast]

Mit diesen neuen Informationen (Arbeit ohne /pages-Verzeichnis)  ist das Verhalten bestätigt, Cannot create Folder, Fehlermeldung wie oben

[Gast]

Lösung ist recht einfach, betrifft aber die 2.12.1 genauso.
Dietmar wird es sehen, framework/functions.php // Zeile 685, der Slash

[evaki]

Bei "Root" hatte ich vorausgesetzt, daß das über http erreichbare document-root des Server (und nicht Server-root) gleich dem WB-root ist, bzw. dies auch so verstanden wird.
Aber gut, nun ist es trotz Verständigungsprobl emen klar, worums geht.
Schön, daß Du es nachvollziehen konntest, und auch den Übeltäter benennen kannst. 
Wie lange sich das so schon verhält, weiß ich nicht. "Früher" wäre es mir recht schnell aufgefallen, da ich selbst alles ohne /pages installiert habe.
Alles wird gut 
MfG. Evaki

Bei mir liegen die Zeilen "etwas anders"

Code: [Select]

function create_access_file($filename,$page_id,$level)
{
    global $admin, $MESSAGE;
    // First make sure parent folder exists
    $parent_folders = explode('/',str_replace(WB_PATH.PAGES_DIRECTORY, '', dirname($filename)));
    $parents = '';
    foreach($parent_folders as $parent_folder)
    {
        if($parent_folder != '/' AND $parent_folder != '')
        {
            $parents .= '/'.$parent_folder;
            $acces_file = WB_PATH.PAGES_DIRECTORY.$parents;
            // can only be dirs
            if(!file_exists($acces_file)) {
                if(!make_dir($acces_file)) {
                    $admin->print_error($MESSAGE['MEDIA_DIR_NOT_MADE']);
                }
            }
        }
    }
    // The depth of the page directory in the directory hierarchy
    // '/pages' is at depth 1
    $pages_dir_depth = count(explode('/',PAGES_DIRECTORY))-1;
    // Work-out how many ../'s we need to get to the index page
    $index_location = '';
    for($i = 0; $i < $level + $pages_dir_depth; $i++) {
        $index_location .= '../';
    }Wo steht der Bösewicht?
Jedenfalls habe ich zumindest den ursprünglichen mkdir-Fehler nachvollziehen können.

[Gast]

ich habe durchaus Kunden, Bekannte oder Forumsuser, die ohne dieses /pages-Verzeichnis arbeiten, auch mit 2.12, aber das waren durchweg alles ältere Versionen, die upgedatet wurden
Nach meiner Kurzrecherche müßte es alles ab WB 2.11 betreffen

Dietmar ist informiert - für mich ist jetzt Wochenende

[evaki]

Hatte nochn Nachtrag drangehängt, tschuldigung

[evaki]

Kann vielleicht ein Entwickler mitteilen, was konkret an welcher Stelle geändert werden muß?
Von (m)einem Anwender würde eine schwere Last fallen (der wollte schon WP -Schrei...), der ist nämlich nach drei Tagen Bastelei "fäddisch".
MfG. Evaki

In diesem Zusammenhang noch'n Nachtrag:
Install unter Win
Installiert in Doc/WB-root ohne Pages, aber noch keine Seite angelegt.
Ein Speichern im BE unter Optionen ergibt:

Code: [Select]

"created: [Sat, 10 Nov 2018 13:06:11 +0000]
Sat, 10 Nov 2018 13:06:37 +0000 [E_NOTICE] \framework\class.wb.php:[882] from \admin\settings\save.php:[295] wb->isAllowedRootFolder "Undefined offset: 0""

[dbs]

Wahrscheinlich bezieht sich Zeile 685 auf die 2.12.1.
In 2.12.0 wäre es dann Zeile 681.

Hab aber noch nichts von Dietmar gehört, weiß deshalb noch nichts zum anderen Problem.

[evaki]

        if($parent_folder != '/' AND $parent_folder != '')
Korrektur:
        if($parent_folder != '/' AND $parent_folder != '')
        {
            $parents .= '/'.$parent_folder;
            $acces_file = WB_PATH.PAGES_DIREC TORY.$parents;
Den Slash rausschmeißen?
Sobald "foreach" etc. irgendwo drin steckt, blockiere ich innerlich.
Werde mir das irgendwann abgewöhnen müssen, sonst klappt dat nich mehr midde Logik.
MfG. Evaki

[evaki]

Antwort #18 hätte ich mir sparen können. Weiß man aber erst, wenn man sich doch auf ein bisschen Code einläßt.
Tja, dann hoffe ich mal, daß es in den nächsten Tagen bzw. vielleicht nächste Woche eine Problemlösung gibt. Der gute Mann (Anwender) hat ja noch mit seinem Projektaufbau zu tun.
Ein schönes Wochenende wünsche ich allen aufmerksamen Beteiligten.
MfG. Evaki

[Luisehahne]

Tja, dann hoffe ich mal, daß es in den nächsten Tagen bzw. vielleicht nächste Woche eine Problemlösung gibt. Der gute Mann (Anwender) hat ja noch mit seinem Projektaufbau zu tun.
MfG. Evaki

Wird es definitiv geben, bin dabei und Danke an alle für die Meldung. Blicke im Moment nur nicht durch, um welche WB Version es sich handelt.

Dietmar

[evaki]

Bei den diversen Versionen handelte es sich um v2.12.0.
Mal ohne Fix, mal mit ein paar und mehr, mal mit allen.
MfG. Evaki
     

[Luisehahne]

ZUR INFO!

Sollte gefixt sein, Tests laufen, der Fix kommt dann aber erst mit der in Kürze erscheinden WB 2.12.1

Dietmar

[evaki]

Hab' auch nochmal lokal bei mir geguckt.
Version 2.10 war noch OK. Danach klappte es wohl nicht mehr.
Mich wundert es doch sehr, daß wir alle in der langen Zeit nie von diesem Fehler etwas gelesen haben.
Installieren die meisten wohl mit default-Einstellungen. -heftig

Da wird sich aber jetzt jemand ganz doll freuen. Na, ich natürlich auch, da ich ja noch meine Dienste für eine gute Sache eingebracht habe (IDN-Domain), und dort auch die Website im doc-root sein soll.

Danke für die PM.
MfG. Evaki

[evaki]

Soeben mal unter Windows laufend. (Fix r171)
"Nackte" Neuinstallation -kein Upgrade.
Doppelslash weg. Das Anlegen weiterer Seiten funktioniert auch, inkl. WYSIWYG, doch der Aufruf übers Menu (hab mal zwei Seiten hinzugefügt) liefert dann bei beiden zusätzlichen Seiten

Code: [Select]

Warning: require(../index.php): failed to open stream: No such file or directory in S:\rs\html\datenschutzerklaerung.php on line 8
Fatal error: require(): Failed opening required '../index.php' (include_path='.;\PHP\PEAR;\PHP') in S:\rs\html\datenschutzerklaerung.php on line 8 resp. impressum

Da hakts noch wie gehabt. 

Muß ja nicht unbedingt noch heute sein -so auf Teufel komm raus
MfG. Evaki