WebsiteBaker Community Forum
WebsiteBaker Support (2.8.x) => 
Hilfe & Support (deutsch) => General Help & Support => Diskussion über WB (closed) => Topic started by: susigross on July 18, 2009, 08:52:19 AM
-
Auf der Suchergebnisseite gibt es 2 Formulare, die beide mit
<form name="search" anfangen.
Namen sollten aber eindeutig sein.
Vieleicht kann man das ja noch in Ordnung bringen.
-
Hallo,
ich habe auf der "Suchergebnisseite" im Quelltext immer nur ein Formular. Wieso hast du zwei?
Matthias
-
Ganz neue Installation, nichts geändert.
Auf der Suchergebnisseite hat man dann links das Suchformular, was immer zu sehen ist.
Außerdem hat man über den Suchergebnissen noch ein Formular mit der Erweiterung "Alle Wörter Einzelne Wörter Genaue Wortfolge"
Wieso hast du nur 1 Formular?
-
Kein richtiger Fehler, aber verbesserungswürdig (hat mich unter WB 2.7 mal einiges an Zeit gekostet):
in admin/pages/settings2.php
Zeile 171 aktuell:
if(!is_writable(WB_PATH.PAGES_DIRECTORY.'/')) {
Zeile 171 besser:
if(!is_writable(dirname($filename).'/')) {
Es ist nämlich wenig hilfreich, die Schreibrechte in einem anderen Verzeichnis zu testen als dort, wo man schreiben will.
Die Annahme, die Rechte wären identisch, trifft nicht immer zu, wie ich lernen musste.
Zeile 172 erweitert mann dann hilfreich so oder ähnlich:
$admin->print_error($MESSAGE['PAGES']['CANNOT_CREATE_ACCESS_FILE']." (FN: $filename)");
-
@Matthias,
habe das jetzt im Roundtemplate ausprobiert. Links steh tdas Scuhefeld Bei erfolgloser Suche erscheint im Contont das erweiterte Suchfeld. Also ist das 2 mal vorhanden. macht aber keine Probleme und ist vaiide oder worum gehts?
Dietmar
-
@Matthias,
habe das jetzt im Roundtemplate ausprobiert. Links steh tdas Scuhefeld Bei erfolgloser Suche erscheint im Contont das erweiterte Suchfeld. Also ist das 2 mal vorhanden. macht aber keine Probleme und ist vaiide oder worum gehts?
Dietmar
1. Passiert das auch wenn die Suche erfolgreich ist.
2. ist es nicht valide An anchor with the same name is already defined. Each anchor should be unique.
-
Getestet, keine Probleme.
Dietmar
-
Getestet, keine Probleme.
Dietmar
So benimmt sich ein Developer? [EDIT: Persönlich Beleidigung entfernt.[/EDIT by kweitzel]
-
Die Annahme, die Rechte wären identisch, trifft nicht immer zu, wie ich lernen musste.
Du meinst du hattest im Subverzeichnis der /pages/ andere Rechte? oder wo lag das Problem? Interessiert mich, so dass ich es nachverfolgen kann und mal austeste. In dem von dir beschriebenen Abschnitt geht es ja um das Umbenennen eines Title.
Obwohl die Rechte ja identisch mit der /pages/ sein
// Create a new file in the /pages dir if title changed
Dietmar
-
Hallo,
bin dann später auch drauf gekommen, dass die zweite Suchmaske ja im Template liegt. Müßten also eigentlich nur die Templates angepasst werden (und die Hilfeseiten auf den erläutert wird, wie man eine suchmaske einbindet) wenn ich das richtig sehe.
in admin/pages/settings2.php
Zeile 171 aktuell:
Code:
if(!is_writable(WB_PATH.PAGES_DIREC TORY.'/')) {
Zeile 171 besser:
Code:
if(!is_writable(dirname($filename).'/')) {
Es ist nämlich wenig hilfreich, die Schreibrechte in einem anderen Verzeichnis zu testen als dort, wo man schreiben will.
Die Annahme, die Rechte wären identisch, trifft nicht immer zu, wie ich lernen musste.
Zeile 172 erweitert mann dann hilfreich so oder ähnlich:
Code:
$admin->print_error($MESSAGE['PAGES']['CANNOT_CREATE_ACCES S_FILE']." (FN: $filename)");
Hmm, muss ich auch mal reinschauen. Ich verstehe dich richtig, dass es besser wäre nicht den Ordner in dem die pages files liegen auf schreibberechtigung en zu testen, sondern nur die Datei, die man verändern will. Wenn ich dich so richtig verstanden habe macht das durchaus sinn.
Matthias
-
Hallo Matthias,
wenn doch alle Antworten in diesem Forum so sachlich wären wie deine :-D
Zu den Schreibrechten:
Bisher wird getestet, ob man in der root Schreibrechte hat. Wenn das nicht der Fall ist, wird abgebrochen, auch wenn man gar nicht in die root schreiben will.
Es wird ja eine neue Datei angelegt (mittels create_access_file), also muß der Ordner, in den die Datei soll, das rechtemäßig erlauben.
Sicher ist es sinnvoll, daß das auch gleich in der Funktion create_access_file angepasst wird.
Zur Suchfunktion:
Wenn die zweite Suchmaske im Template liegt (wovon es ja nun ein paar hundert gibt), wäre es vielleicht einfacher, den Namen der ersten Suchmaske zu ändern?
-
wenn doch alle Antworten in diesem Forum so sachlich wären wie deine grin
Wer im Glashaus sitzt sollte nicht mit Steinen schmeissen:
So benimmt sich ein Developer? Oder ein Holzkopf?
Das geht für meinen Geschmack schon unter die Gürtellinie und gehört nicht hierher.
Gruss
erpe
-
Hallo FRank,
Ich weiss nicht, warum du die Probleme hattest. Habe mal eben ein in ein paar WB Installationen nachgeschaut. In jedem Subverzeichnis sind die selben Rechte, wie im Rootverezichnis, halt die Einstellung unter erweiterte Optionen
im Backend. Deswegen war es bisher auch nicht nötig mehr als das Rootverzeichnis abzufragen. Oder sehe ich da was verkehrt?
Dietmar
-
Hallo FRank,
Ich weiss nicht, warum du die Probleme hattest. Habe mal eben ein in ein paar WB Installationen nachgeschaut. In jedem Subverzeichnis sind die selben Rechte, wie im Rootverezichnis, halt die Einstellung unter erweiterte Optionen
im Backend. Deswegen war es bisher auch nicht nötig mehr als das Rootverzeichnis abzufragen. Oder sehe ich da was verkehrt?
Dietmar
Man kann eine Installation ja auch sicherer machen, so daß nicht überall alles geändert werden kann.
Man muß ja auch kein pages-Verzeichnis haben, sondern kann gleich in der root anfangen und für die besondere Rechte vergeben.
Ich habe es aber satt, alles in langwierigen Diskussionen 3x begründen zu müssen, nur weil jemand die naheliegende allgemeingültige Lösung nicht akzeptieren will. Wahrscheinlich werde ich mir private Patchdateien anlegen und die dann ins fertige WB 2.8 übernehmen, das schont dann meine Nerven gewaltig.
Der Patch für die Mehrsprachigkeit von WB 2.8 ist gleich fertig :-)
-
Hallo Frank,
weist du ich denke wahrscheinlich weiter als du. Wenn sich die Rechte in einem Subverzeichnis ändern, dann liegt irgendwo ein Fehler vor, entweder ein menschlicher und von WB. Ich kann natürlich alles umschiffen, indem ich das Core an alle Unzugänglichkeiten anpasse. Klar macht die Fehlersuche natürlich viel Arbeit. Aber wenn die Rechte im Sub anders sind als in der /pages/ muss man sich doch als allererstes fragen, warum.
Man kann es sich natürlcih auch bequem machen. Ist aber nicht mein Ding und sollte auch nicht vom Dev-Team so praktiziert werden. Wir wollen natürlich ein fehlerfreies System, aber nicht auf die Art und Weise.
Dietmar
-
weist du ich denke wahrscheinlich weiter als du. Wenn sich die Rechte in einem Subverzeichnis ändern, dann liegt irgendwo ein Fehler vor, entweder ein menschlicher und von WB.
Ich habe keine Lust, über deine Vermutung zu diskutieren, behalte da mein Wissen lieber für mich.
Der Fehler besteht nicht darin, dass jemand manuell die Rechte ändert, sondern darin, dass WB danach nicht mehr logisch funktioniert, sprich dass man keine Seite mehr in einem Verzeichnis anlegen kann, für das man Schreibrechte hat.
-
Genau da ist das Problem, du machst es dir zu einfach. Du willst das ja noch nicht mal ausdiskutieren, so dass wir auf einen Nenner kommen. Also hatte ich doch recht mit meiner Vermutung
Der Fehler besteht nicht darin, dass jemand manuell die Rechte ändert,
und WB soll das jetzt ausbügeln.
Könnte mich mit dem Vorschlag anfreunden, Vergleiche Rootrechte der /pages/ mit den Subs, wenn ungleich Warnung. Das wäre für mich die Lösung. So Ideen kommen dann eben bei einer Diskussion, auch wenn man manchmal aneinander vorbei redet.
Du kannst natürlich auch stur bleiben oder denkst über meinen Vorschlag nach. Das überlasse ich dir.
Wie war das mit dem Holzkopf? Lassen wir die FRage im Raume stehen.
Dietmar
-
So, jetzt ist ja wohl mehr als alles gesagt............. ...
Das sinnvollste ist doch wohl, wenn sich das DEV-Team dieser Geschichte annimmt, es intern zu Ende diskutiert und dann entscheidet, was gemacht wird.
Wenn es noch Sachargumente gibt, die der Sache dienlich sind, dann kann das hier ja noch gepostet werden.
Ansonsten solltet ihr aufhören, euch hier zu beharken. Oftmals ist es besser, wenn dann mal ein bisher unbeteiligter aber erfahrener Dritter draufschaut, der weiss, worüber da gesprochen wird.
In diesem Sinne einen schönen Tag noch.
Gruss
erpe
-
Hallo Frank,
auch wenn du nicht mehr antworten willst, muss ich dir Recht geben, das da Handlungsbedarf besteht. Habs gerade mal durchgetestet und ein paar Rechte verändert. WB sagt ist alles ok, legt aber nichts an und das ohne Fehlermeldung. Werde da mal weiter verfolgen.
Trotzdem danke für die Anregung.
Dietmar
-
Hier ist noch ein Bug, Diskussionen darüber bitte ohne mich:
https://forum.WebsiteBaker.org/index.php/topic,13754.msg91513.html#msg91513 (https://forum.WebsiteBaker.org/index.php/topic,13754.msg91513.html#msg91513)
-
Noch etwas unschönes was die Usability betrifft:
Man legt einen neuen Benutzer an, klickt auf Hinzufügen und bekommt die Meldung, das Passwort wäre zu kurz.
Schlecht dabei
- Man erfährt nicht, wie lang das PW sein muss
- alle anderen Eingaben zum neuen Benutzer werden gelöscht, man muss also von vorne anfangen
-
Hallo Frank,
Stimmt, dass hatte mich auch schon gestört und habe es auf meine Feature List gesetzt, dass inputs direkt bei der Eingabe zu validiert werden. Werde dies für die WB 2.9 anregen.
Dietmar
-
Hallo Frank,
Stimmt, dass hatte mich auch schon gestört und habe es auf meine Feature List gesetzt, dass inputs direkt bei der Eingabe zu validiert werden. Werde dies für die WB 2.9 anregen.
Dietmar
Schade, der Bug, dass alle Felder gelöscht werden, wurde ja erst in 2.8 eingebaut. Da hätte ich erwartet, daß er bis zum endgültigen Release auch wieder ausgebaut wird, und nicht erst in 2.9
-
Hallo,
Schade, der Bug, dass alle Felder gelöscht werden, wurde ja erst in 2.8 eingebaut. Da hätte ich erwartet, daß er bis zum endgültigen Release auch wieder ausgebaut wird, und nicht erst in 2.9
Sicher, dass das nicht auch in der 2.7 schon so war? Kannst du das auch nochmal checken?
Matthias
-
Hallo
bin mir ziemlich sicher, dass das schon immer so war.
Habe mich auch schon öfter darüber geärgert.
Gruss
erpe
-
Och, Leudde, nu werdet doch nich immer gleich so emotional. :| Man kann sich ja mal aufregen, mach ich auch, aber letztlich helfen tut es dann doch nie. Als Developer kann man schon mal etwas die Nerven verlieren, wenn sich auf einmal die Anforderungen und Meldungen vermehren wie die Tribbles. :-D Aber sich dann zu streiten, hilft auch nicht weiter. Notfalls einfach 'nen Tag drüber schlafen... hoppla, ich meinte natürlich 'ne Nacht :-D
-
bin mir ziemlich sicher, dass das schon immer so war.
Hab's grad nochmal mit 2.7 getestet, ist dort definitiv auch so. (Egal ob man auf [Zurück] klickt oder den [Back]-Button des Browsers benutzt.)
-
Och, Leudde, nu werdet doch nich immer gleich so emotional.
:?
-
Bezog sich auf die Seite 1.
-
Es war bereits in allen Versionen davor. Was ich auch als störend empfinde, in den Gruppenrechten, der Button zurücksetzen sollte auch auf die Module angewandt werden.
Ist auch noch nie so gewesen.
Wenns noch mehrere Vorschläge für Verbesserungen gibt, immer ran damit. Auch wenn man mal ein bisschen hinterfragen muss. Es wird sich mit allem beschäftigt. Ob das Ein ode rAndere sinnvoll ist umszusetzen wird dann jeweils im Dev-Team ausdiskustiert.
Ich bin immer dafür, Fehler die ein Anwender machen könnte, vorher abzufangen. Ich entscheide das aber nicht alleine. Dafpr haben wir ein Team was demokratisch entscheidet.
Dietmar
-
Noch ein sicher alter Bug, über den ich soeben erstmalig gestolpert bin:
Backend - Einstellungen - SMTP-Passwort
Wenn das Passwort ein "<" enthält, werden nur die Zeichen davor im Feld wbmailer_smtp_passw ord der settings-Tabelle gespeichert.
Da Passwörter mit solchen Zeichen in der Praxis vorkommen, wäre es schon schön, wenn WB in der Lage wäre die auch zu speichern.
-
Noch ein sicher alter Bug, über den ich soeben erstmalig gestolpert bin:
Backend - Einstellungen - SMTP-Passwort
Wenn das Passwort ein "<" enthält, werden nur die Zeichen davor im Feld wbmailer_smtp_passw ord der settings-Tabelle gespeichert.
Da Passwörter mit solchen Zeichen in der Praxis vorkommen, wäre es schon schön, wenn WB in der Lage wäre die auch zu speichern.
Hm ... ok, habe das mal im DevForum mit reingestellt ...
Der Grund dahinter ist die Funktion "strip_tags", die einfach nach dem "<" alles abschneidet.
Testweise kannst Du ja in Zeile 141 den "wbmailer_smtp_passw ord" mit in das $allow_tags_in_fields array mit aufnehmen:
<?php
$allow_tags_in_fields = array('website_header', 'website_footer','wbmailer_smtp_password');
?>
Hm ... jetzt werden alle Zeichen übernommen ... habe allerdings keine Ahnung wie SMTP mit den Entities, sprich
mit "<", dann in Passwörtern umgeht. Könnte einen //Seiteneffekt// haben ...
Gruß
Aldus
-
Hallo Aldus,
man muss wohl außerdem die Zeile 48 der index.php wie folgt ändern:
if ($setting_name == 'wbmailer_smtp_password') {
$setting_value = $setting['value'];
} else {
$setting_value = htmlspecialchars($setting['value']);
}
Ein Passwort darf nun mal nicht verändert werden, damit es funktioniert.
An der Stelle ist nun mal auch wirklich kein böser Userinput zu erwarten, da ja das Feld nur der Admin schreiben darf.
-
Hallo Frank
Hm ... da würde ich lieber einen Einzeiler draus machen, dann verbiege ich die Zeilennummern nicht so
derbe und bin das Klammerngeraffele los:
<?php
$setting_value = ( $setting_name != 'wbmailer_smtp_password' ) ? htmlspecialchars($setting['value']) : $setting['value'];
?>
Hm ... ich schau noch mal
Gruß
Aldus
-
Boah, Aldus... So fiese Sachen machst Du?!? Sowas in eine Zeile?!? :-o