WBCE CMS – Way Better Content Editing.
You are not logged in.
@mrbaseman Danke für die Erläuterungen. Wir werden uns das so bald wie möglich anschauen.
Sorgen sind wie Nudeln: man macht sich meist zu viele.
Offline
Ich hoffe doch, dass es nicht zu größeren Problemen mit meiner Version kommt. Ich muss allerdings gestehen, dass ich mir doch nicht mehr ganz so sicher bin, das Problem komplett verstanden zu haben. Ich konnte allerdings bisher nicht mit https testen, Vielleicht spielt das doch auch noch eine Rolle, die ich noch nicht verstanden habe.
Ich habe inzwischen auch Zweifel daran, dass die Rückersetzung überhaupt noch notwendig ist. Selbst wenn man die Email-Adresse in Klartext in einem Dropdown-Feld anbietet, dann ersetzt der Output Filter in WBCE 1.3 nur die Beschriftung, lasst aber die Email-Adresse im Wert des Feldes der an den Server zurückgesendet wird unangetastet. Vielleicht ist der Outputfilter mittlerweile so gut, dass eine solche Rückersetzung die hier wohl Probleme gemacht hat gar nicht mehr erforderlich ist. Dann wäre die 1.3.14 voll funktionsfähig.
Ich muss nochmal über andere mögliche Szenarien nachdenken, bei denen Email-Adressen durch den Outputfilter laufen und somit verändert zurückgeliefert werden könnten. Und ich muss schauen, ob ich nicht doch eine Seite mit https auf WBCE 1.3 umgestellt bekomme.
Edit: Tippfehler im Post korrigiert
Last edited by mrbaseman (05.12.2017 23:14:25)
Offline
ich habe gerade noch eine weitere Diminsion dieses Problems entdeckt:
Ich hab auf meinem Server eine Datei WB_PATH.'/modules/output_filter/filter-routines.php' als Überbleibsel einer älteren Installation liegen. Mit WBCE 1.3 wird hingegen eine Datei WB_PATH.'/modules/output_filter/filter_routines.php' ausgeliefert. Die liegen bei mir beide im Verzeichnis. mpForm lädt aber die mit dem Bindestrich, und zwar nur dann, wenn keine Funktion namens executeFrontendOutputFilter() existiert. In dieser (alten) Datei steht aber folgendes:
<?php
/**
*
* @category modules
* @package output_filter
* @author Christian Sommer, WB-Project, Werner v.d. Decken
* @copyright WebsiteBaker Org. e.V.
* @link http://websitebaker.org/
* @license http://www.gnu.org/licenses/gpl.html
* @platform WebsiteBaker 2.8.3
* @requirements PHP 5.3.6 and higher
* @version $Id: filter-routines.php 1626 2012-02-29 22:45:20Z darkviper $
* @filesource $HeadURL: svn://isteam.dynxs.de/wb_svn/wb280/branches/2.8.x/wb/modules/output_filter/filter-routines.php $
* @lastmodified $Date: 2012-02-29 23:45:20 +0100 (Mi, 29. Feb 2012) $
*
*/
/* --- this is a wrapper for backward compatibility only --- */
$sModuleDir = str_replace('\\', '/', dirname(__FILE__)).'/';
if (file_exists($sModuleDir.'index.php')) {
require($sModuleDir.'index.php');
}
und die index.php wiederum enthält
<?php
// no directory access
header("Location: ../index.php",TRUE,301);
und so weiter. Wenn die Webseite also eine gewisse Geschichte hinter sich hat und vor ein paar Jahren (lastmodified im Header Kommentar sagt 2012, bei mir ist die Datei von 2015) mal ein Update erfahren hat, dann passiert ein Redirect Verzeichnisebene um Verzeichnisebene nach oben.
Diese alte Datei sollte man in die Liste der zu löschenden Dateien im Update-Skript aufnehmen.
Offline
Diese alte Datei sollte man in die Liste der zu löschenden Dateien im Update-Skript aufnehmen.
Wenn ich mich nicht täusche wurde die alte Datei drinnen gelassen, um Kompatibilität zu älteren Modulen zu gewähren.
Wenn ich dich richtig verstanden habe müsste man nur in der index.php eine eine redircet (nur für das cms) auf filter_routines.php hinzufügen oder?
Offline
ah ja, so weit hatte ich gar nicht gedacht:
<?php
if(defined('WB_PATH')) {
// index.php is included explicitly
require('./filter_routines.php');
} else {
// no directory access
header("Location: ../index.php",TRUE,301);
}
Das würde vermutlich ein Stück weit zur Lösung des konkreten Problems beitragen. Man müsste aber auf jeden Fall prüfen, wo die index.php überall eingebunden wird und aus welchen Gründen. Wir verlassen uns hier gerade auf den Inhalt einer Datei, die vielleicht in einer älteren Version noch im System rumgammelt. Wenn diese index.php sonst nirgends eingebunden wird und ausschließlich zum Schutz des Verzeichnisses da liegt, dann kann man drüber nachdenken, auf obige Version umzustellen.
Offline
Habe gerade mal im Master auf Github nachgesehen.
die filter-routines.php und index.php enthalten:
<?php
//Classic compatibility fix
//no direct file access
if(count(get_included_files())==1) die(header("Location: ../index.php",TRUE,301));
include_once(filter_routines.php);
Im 1.3.0 Release steht der Code noch nicht drinnen, wir planen gerade einen 1.3.1 release.
Offline
ah, include_once ist natürlich an der Stelle weit besser als require. Und offenbar hat sich da in der Zwischenzeit schon mal jemand Gedanken drüber gemacht. Prima.
Offline