WBCE CMS – Way Better Content Editing.
You are not logged in.
Hallo,
da ich gerade die Lösung für ein merkwürdiges Verhalten beim Einbinden von Styles mit der Insert-Klasse gefunden habe, wollte ich es hier kundtun.
Wenn die o.a. Fehlermeldung (in der Debug-Console und in der Quellcodeansicht) beim Einbinden von Files (Styles) über das Template (index.php, prepare.php) erscheint, die Files aber korrekt eingebunden werden, dann kann es daran liegen, dass der Templatename dem Sitenamen entspricht.
Zumindest war die Meldung nach dem Umbenennen des Templatenamens weg.
Also: Templatename = Sitename = Fehlermeldung bei InsertCssFile()
Wieder etwas dazu gelernt.
Viele Grüße
klawin
Egal wie du es machst, du machst es falsch! Also mache es!
Offline
D.h. wenn bei den Grundeinstellungen als Website-Titel "irgendwas" hinterlegt ist und das Template "irgendwas" heißt, kommt es zu dem Problem?
Hm, das ist sicherlich kein beabsichtigtes Verhalten.
Kannst Du mal den von Dir verwendeten Code posten?
Sorgen sind wie Nudeln: man macht sich meist zu viele.
Offline
Hallo Florian
... wenn bei den Grundeinstellungen als Website-Titel "irgendwas" hinterlegt ist und das Template "irgendwas" heißt...
nein, es sind glücklicherweise nicht die Grundeinstellungen. Es ist vielmehr der Teil der URL, der zufällig mit dem Name des Templates identisch ist.
Und sehr wahrscheinlich tritt es nur in der besonderen Situation hier auf. Das WebRoot des Apache zeigt auf ein Verzeichnis, in dem sich dann (je Site) erstmal ein Unterverzeichnis befindet. In diesem Unterverzeichis ist dann das 'root' der jeweiligen WBCE-Instanz. Und mein Templatename war identisch mit dem Namen vom Unterverzeichnis.
Also eine Site wird dann so aufgerufen localhost/wbcetest/. Und wenn das Template dann auch 'wbcetest' genannt wurde, taucht dieser Fehler auf.
Hier zunächst mal die Stelle im Template-Code, die den Aufruf macht:
I::insertCssFile (array (TEMPLATE_DIR.'/fonts/sourcesanspro.css',
WB_URL.'/include/font-awesome/css/font-awesome.css',
TEMPLATE_DIR.'/icons/icons.css',
TEMPLATE_DIR.'/template.css'),'HEAD BTM-');
Dadurch, dass der Verzeichnisname (das WBCE-Root) identisch mit TEMPLATE_DIR ist, meckert dann die Funktion _checkAndReplaceFileLoc (in Insert.php) berechtigterweise rum. Gut dabei ist, dass die Insert's dann trotzdem stattfinden und alles super ist.
Genau genommen ist diese Abfrage (Zeile 945 in Insert.php) dafür verantwortlich:
$bAbsoluteInternalUrl = (strpos($sFileUrl, WB_URL) !== false);
Wenn ich das jetzt so lese fällt mir auf, dass es ja auch bei 'normalen' Installationen zu diesem Verhalten führen kann. Also wenn man das Template von wbce.org auch wbce.org nennt :-)
Aber wer macht sowas schon - Außer ich, in diesem Falle.
Viele Grüße
Klaus
Egal wie du es machst, du machst es falsch! Also mache es!
Offline
Genau genommen ist diese Abfrage (Zeile 945 in Insert.php) dafür verantwortlich:
$bAbsoluteInternalUrl = (strpos($sFileUrl, WB_URL) !== false);
Wenn ich das jetzt so lese fällt mir auf, dass es ja auch bei 'normalen' Installationen zu diesem Verhalten führen kann. Also wenn man das Template von wbce.org auch wbce.org nennt :-)
Aber wer macht sowas schon - Außer ich, in diesem Falle.
Viele Grüße
Klaus
Hallo Klaus,
danke für den Bugreport und Lösungsansatz.
Ich kann den Bug allerdings nicht reproduzieren.
Gruß,
Christian
“Success is the progressive realization of a worthy ideal.” ― Earl Nightingale
Offline
Hallo Christian,
Ich kann den Bug allerdings nicht reproduzieren.
Das ist eine gute Nachricht. Dann ist es wahrscheinlich nur hier, in dieser besonderen Konstellation, aufgetaucht.
Viele Grüße
Klaus
Egal wie du es machst, du machst es falsch! Also mache es!
Offline
Mich würde der erscheinende Fehlerbericht trotzdem interessieren. Den hast Du nicht genannt.
Oder hieß es im Frontend einfach I::insertCssFile - Class Insert Report: File "xyz" can not be found.
Oder wo?
Gruß,
Christian
“Success is the progressive realization of a worthy ideal.” ― Earl Nightingale
Offline
die Ausgabe der Fehlermeldung erfolgt in der Debug-Console (F12) des Browsers. Ich habe das nur zufällig gesehen.
Da die Dateien ja trotz dieser Fehlermeldung einwandfrei eingebunden werden, ist mir das vorher nicht aufgefallen.
Ach ja, in der gerenderten Seite stehen natürlich die Aufrufe für die Consolenausgabe drin. Aber auch die tun ja zunächst nicht weh.
Viele Grüße
Klaus
Last edited by klawin (08.06.2020 18:45:37)
Egal wie du es machst, du machst es falsch! Also mache es!
Offline
Ich kann's nicht reproduzieren.
Aufruf: http://localhost/spielwiese/
Template heißt "spielwiese"
Mecker von der Class Insert:
console.error('Class Insert report: File "http://localhost/spielwiese/var/custom.css" can not be found')
Den gleichen Error krieg ich aber auch mit jedem anderen Template ...
... nein in Europa verwenden wir beim Programmieren nicht € statt $ ...
Offline
Den gleichen Error krieg ich aber auch mit jedem anderen Template ...
Könntest du schauen was passiert wenn man folgendes hat:
Aufruf: http://localhost/localhost/localhost.php
Template heißt "localhost"
Wenn dass funktioniert, hat es was mit Linux oder der Hosting Plattform zu tun.
Offline
@colinax:
wo soll das "localhost.php" herkommen?!?
Auch bei
Aufruf: http://localhost/localhost/
Template heißt "localhost"
kein anderer Fehler, selbst wenn man das z.B. "main.css" in "localhost.css" umbenennt.
Und die angemeckerte "var/custom.css" ist ja berechtigt, da wirklich nicht vorhanden.
... nein in Europa verwenden wir beim Programmieren nicht € statt $ ...
Offline
@colinax:
wo soll das "localhost.php" herkommen?!?
von der Zielseite als Beispiel (um jeden Teil der URL zu überprüfen):
localhost/pages/die-firma/kontakt.php --> http://localhost/localhost/localhost/localhost.php
Aber ich glaube dass ich bei solchen Test-Theorien ins zu extreme abgleite
Offline
Also eine Seite "localhost.php" hatte ich tatsächlich auch angelegt --> macht nix.
Das einzige was ich nicht ausprobiert habe, das "pages"-Verzeichnis umzubenennen. Das war mir dann doch irgendwie "zu blöd"
... nein in Europa verwenden wir beim Programmieren nicht € statt $ ...
Offline
colinax
Das hier:
console.error('Class Insert report: File "http://localhost/spielwiese/var/custom.css" can not be found')
kommt vermutlich von Modul Frontend Final CSS, wenn es installiert, aber noch kein zugehöriges Stylesheet angelegt wurde.
Sorgen sind wie Nudeln: man macht sich meist zu viele.
Offline
Der Fehler ist nur eine kleine Unschönheit in der Debug-Console im Browser. Auch wenn die Meldung 'not found' lautet, werden alle Resourcen korrekt eingebunden. Insofern ist das eher nur kosmetisch. Und wenn man das Template nicht wie das 'Spielwiesen'-Verzeichnis nennt, ist es ja wieder ok.
Möglicherweise liegt es tatsächlich nur an meiner Konfiguration hier. Hier mal Zusammengefasst die Details. Vielleicht kann man es dann besser nachvollziehen:
- Webserver Apache auf localhost
- WebRoot ist /var/www/
- WBCE darin in einem Unterverzeichnis 'wbcetest' im Web-Root (Die 'Spielwiese')
- Alias auf dieses Verzeichnis ist ebenso 'wbcetest'
- der Path dahin ist: /var/www/wbcetest
- die Web-URL zur Startseite lautet: http://localhost/wbcetest/
- Beispiel für einen Seitenaufruf: http://localhost/wbcetest/pages/das-template/tabellen.php
Nun der Test:
Templatename ist 'wbcetest' (Path: /var/www/wbcetest/templates/wbcetest) -> Fehlermeldung
Templatename ist 'klawinver' (Path: /var/www/wbcetest/templates/klawinver) -> Keine Fehlermeldung
Ist hier jederzeit nachvollziehbar, durch einfaches Umschalten auf das jeweilige Template.
Die Fehlermeldungen erscheinen nur in der Debug-Console des Browsers:
Class Insert report: File "/wbcetest/templates/wbcetest/template.css" can not be found
Class Insert report: File "/wbcetest/templates/wbcetest/template.js" can not be found
Und natürlich auch in der Quellcodeansicht:
<link rel="stylesheet" href="/wbcetest/templates/wbcetest/template.css" type="text/css" id="css_template__wbcetest"><script id="script_5edf1387ef5af">
/* Class Insert */
console.error('Class Insert report: File "/wbcetest/templates/wbcetest/fonts/sourcesanspro.css" can not be found')
</script>
<script id="script_5edf1387ef5f8">
/* Class Insert */
console.error('Class Insert report: File "/wbcetest/templates/wbcetest/icons/icons.css" can not be found')
</script>
Alle angemeckerten Resourcen werden dennoch korrekt eingebunden!
Gruß
Klaus
Egal wie du es machst, du machst es falsch! Also mache es!
Offline
Hab's versucht, konnte es aber auch nicht reproduzieren.
Hab es sogar so versucht:
http://localhost/localhost/templates/localhost/localhost.css
Offline
Hab es sogar so versucht:
http://localhost/localhost/templates/localhost/localhost.css
die Dateien über die URL im Browser direkt aufzurufen funktioniert. Denn intern funktioniert es ja auch, trotz der Fehlermeldung. Die Meldung wird zwar ausgegeben, es funktioniert aber trotzdem.
Die von mir angesproche Meldung kommt beim Aufruf einer 'normalen' Seite aus dem Menü.
Sobald das Templateverzeichnis identisch mit dem ersten Verzeichnis der Instanz (Spielwiese) ist, meckert er im Debugwindow vom Browser.
Möglicherweise ist diese 'Spielwiesen' - Installation der Grund. Also mit einem Unterverzeichnis unterhalb vom WebRoot.
Gruß
Klaus
Last edited by klawin (15.06.2020 14:16:29)
Egal wie du es machst, du machst es falsch! Also mache es!
Offline
Class Insert report: File "/wbcetest/templates/wbcetest/fonts/sourcesanspro.css" can not be found
Wird die Fehlermeldung wirklich so angezeigt, meine wird so angezeigt:
Class Insert report: File "http://localhost/templates/localhost/css/omponents.css" can not be found
Kannst du mir zeigen wie die Zeile mit define WB_URL bei dir in der config.php aussieht?
Last edited by colinax (15.06.2020 21:25:18)
Offline
Wird die Fehlermeldung wirklich so angezeigt...
Ja. Ohne Protokoll, da es auf einem lokalen Apache läuft.
In der config.php ist WB_URL so angegeben:
"/wbcetest"
Egal wie du es machst, du machst es falsch! Also mache es!
Offline
Könntest du bitte mal schauen was passiert wenn du das Protokoll selbst hinzufügst?
Ich habe so die Vermutung dass durch das fehlende Protokoll ein pseudo CORS / Mixed Content erzeugt wird. Der Browser prügelt dir das Protokoll rein (da er ohne nicht kann) die Dateien werden aber über einen relativen Pfad aus dem BS geladen, dadurch gibt's technisch gesehen zwei Quellen die Logik verarbeitet nur eine, dein Browser erkennt den relativen Pfad des BS und läd die Dateien trotzdem.
Denn ich bekomme deine Fehlermeldung (mehr oder weniger) nur wenn ich die WB_URL in der config.php manipuliere und dass Protokoll entferne.
Offline
Könntest du bitte mal schauen was passiert wenn du das Protokoll selbst hinzufügst?
kann ich heute abend ausprobieren.
Müsste ich dann ja so angeben, richtig?
"http://localhost/wbcetest"
BTW: Wie macht ihr es eigentlich mit den 'Spielwiesen'? Jede Installation ein eigenes Web-Root? Immer umschalten?
Gruß
Klaus
Egal wie du es machst, du machst es falsch! Also mache es!
Offline
Wenn ich nach den Pfad Angaben aus #14 ausgehe, dann eher so:
"http://wbcetest"
Einfach ausprobieren wie auf welche Änderung reagiert wird.
Ich verwende zum Testen XAMPP, da es identisch funktioniert wie ein echter Server.
Prinzipiell hab ich immer nur eine TE am laufen für ein Problem, wenn ich ein anderes Problem angehe immer mit einer frisch installierten WBCE Installation.
Natürlich gehen auch mehrere Installationen parallel oder untereinander/ineinander alla
"http://localhost/installation1", "http://localhost/installation2", "http://localhost/installation1/installation2" oder ich könnte neben localhost die 127.0.0.1 verwenden dadurch wäre es sogar möglich im selben root zwei Installationen zu haben (wobei immer davon abgeladen wird die 127.0.0.1 zu verwenden).
Offline
Ich habe hier verschiedene Installationen auf localhost, die ich einfach über http://localhost/name_der_installation aufrufe.
Zum einen immer eine (mit der Zeit dann komplett "kaputt-gespielte") Spielwiese die von Zeit zu Zeit mal neu aufgesetzt wird, dann halt die aktuelle Development-Version und Versionen um spezielle Sachen auszuprobieren (MYSQL-Strict, etc), sowie lokale Kopien von Live-Seiten an denen grade (oder immer mal wieder) gestrickt wird.
Die Installationen haben alle eine leicht modifizierte config.php
define('WB_URL', 'http://'.$_SERVER['SERVER_NAME'].'/99-spielwiese');
Dadurch kann ich sie statt mit localhost auch mal - wenn ich z.B. gezielt was mit Handy oder Tablet testen will - von "ausserhalb" über die lokale IP meines Arbeitsrechners erreichen ohne erst was ändern zu müssen.
... nein in Europa verwenden wir beim Programmieren nicht € statt $ ...
Offline
klawin
Die Installationen haben alle eine leicht modifizierte config.php
define('WB_URL', 'http://'.$_SERVER['SERVER_NAME'].'/99-spielwiese');
Dadurch kann ich sie statt mit localhost auch mal - wenn ich z.B. gezielt was mit Handy oder Tablet testen will - von "ausserhalb" über die lokale IP meines Arbeitsrechners erreichen ohne erst was ändern zu müssen.
Danke für diese Idee. Ich fahre ein ähnliches Szenario und werde es bei mir gleich heute Abend auf Deinen Vorschlag umstellen.
Egal wie du es machst, du machst es falsch! Also mache es!
Offline
Einfach ausprobieren wie auf welche Änderung reagiert wird.
define('WB_URL', 'http://wbcetest');
Klappt nicht, weil ja der Servername localhost fehlt.
define('WB_URL', 'http://localhost/wbcetest');
Das hat geklappt. Der Fehler ist damit weg. Deine Vermutung mit dem gemischten Kontent war richtig.
Angeregt durch die Antwort von bernd, nutze ich jetzt für alle 'Spielwiesen' diese Variante:
define('WB_URL', 'http://'.$_SERVER['SERVER_NAME'].'/wbcetest');
Vielen Dank für alle Hinweise und der Gewissheit, dass nun alles wieder gut ist.
Viele Grüße
Klaus
Last edited by klawin (16.06.2020 17:13:45)
Egal wie du es machst, du machst es falsch! Also mache es!
Offline
bernd, colinax
Nur zur Ergänzung:
http://wbcetest müsste funktionieren wenn man wbcetest in der hosts-Datei (unter Linux /etc/hosts, unter Win ???) an die 127.0.0.1 bindet.
Ist mir persönlich (vor allem bei vielen lokalen Installationen) aber einfach "zu dumm"
... nein in Europa verwenden wir beim Programmieren nicht € statt $ ...
Offline