WebsiteBaker Community Forum
WebsiteBaker Support (2.8.x) => 
Hilfe & Support (deutsch) => General Help & Support => Diskussion über WB (closed) => Topic started by: ruebenwurzel on January 18, 2011, 06:35:20 AM
-
Hallo,
mache mal das Thema auch auf deutsch auf, es gibt ja im Englischen ein gleichlautendes. Bin gerade am Testen der RC5 und nehme dieses Thema zum Anlass das niederzuschreiben, was mir an Fehlern auffällt.
Zunächst mal nur eine Kleinigkeit. Bei den Erweiterungen - Sprachen fällt auf, dass die Entities nicht mehr richtig dargestellt werden (CS, FR ...). Das sollte wieder korrigiert werden.
Denke es hängt damit zusammen, dass ich explicit nicht UTF8 verwende sondern halt ISO..... Es handelt sich um Seiten die von früheren WB Versionen upgedated wurden. In früheren Zeiten waren Darstellung und Suche ja leider nur Mit den entsprechenden charsets möglich. Das ist jetzt ja Gott sei Dank Vergangenheit (spätestens ab 2.9), aber viele langjährige WB-Nutzer werden wohl dasselbe Problem haben, dass die alten Seiten halt nicht UTF8 sind. Und solange eine Konvertierung nicht da ist (wird wohl für 2.8.2 nie kommen), sollte die Darstellung von nicht UTF8 Installationen wie bisher fehlerfrei möglich sein.
Gruß
Matthias
-
Gut, dann haben wir halt noch ein paar mehr Threads- sollten wir allerdings auch die alten schließen, sonst gibt's ja nur noch Chaos, wir haben dann ja jetzt schon vier für die RCs von 2.8.2.
Dann sollte es aber auch einen Eingangsbeitrag geben, wie im alten am Schluss - sonst beteiligt man keine neuen Benutzer.
So - im Anhang gibt es eine (nach Rechtschreibfehlern!) korrigierte DE.php.
Darin sind aber keinerlei Umlaute usw. ausgeschrieben - ISO-Fehler sollte daher woanders zu suchen sein.
Da es ja jetzt /include/idna_convert gibt wäre gut zu wissen, ob das auch bei Sprachdateien greif und wenn ja, was es da genau macht. So ganz schlau werde ich aus der idna_convert nämlich nicht, wird sie ja nirgends aufgerufen.
Irgendwie scheint mir das aber nur ein Domainnamen-Ummodler zu sein (wer um alles in der Welt nun auch Umlaut-Domains benutzen will, außer bei der Pressemeldung vor einigen Jahren dass es jetzt möglich ist, ist mir das nicht untergekommen). Ob man so etwas spezielles nun in der include mitliefern sollte sei dahingestellt - aber entweder benutzen oder halt wie bisher nicht.
[gelöscht durch Administrator]
-
Eine Kleinigkeit, die mich speziell nervt, ist dass die Redirect-Zeit (beim Speichern usw) wieder auf Minimum 1500 gestellt werden muss. Alles kleiner bedeutet: kein Redirect. Das nervt.
Generell würde ich ja sagen: Bei success: sofort redirect, bei error: kein redirect.
Dass das Pages-Verzeichnis jetzt zwingend beschreibbar sein muss, macht mir auf etlichen Sites Probleme, nämlich dort, wo es auf leer ("") steht und ich _nur_ en/ und de/ habe. Da kann ich keine Seiten anlegen, wenn das Root nicht beschreibbar ist.
-
Hallo,
Darin sind aber keinerlei Umlaute usw. ausgeschrieben - ISO-Fehler sollte daher woanders zu suchen sein.
Das Problem sind nicht die Sprachdateien an sich. Das wird schon alles im Frontend richtig ausgegeben und zu 99,9% auch im Backend. Lediglich auf der Erweiterungen - Sprachen Seite gibt es Darstellungsfehler wenn man sich die installierten Sprachen anschauen oder ändern will. Da muss wieder ein htmlspecialchars oder sowas eingebaut werden in den Dateien in admin/addons/languages.
Matthias
-
@Chio
Eine Kleinigkeit, die mich speziell nervt, ist dass die Redirect-Zeit
Steht auf der ToDo Liste, Vorschlag
- -1 bedeuted ausgeschaltet,
- Valider Wert 0 - 10000
- Größer 10000 wird der Timer auf 0 gesetzt
@Chio
Dass das Pages-Verzeichnis jetzt zwingend beschreibbar sein muss
Musste immer schon beschreibbar sein, habe bis zur 2.6 nachgeschaut.
Da wir auf der WB Homepage auch bereits auf 2.8.2 umgestellt haben, Testseite angelegt und keine Probleme, wurde mit Filemode 644 ohne Probleme angelegt
Ansonsten bitte mehr Infos
Dietmar
-
Ich habe etliche Seiten, die mit WB 2.8.2 nicht mehr funktionieren, weil das Root der Domain NICHT beschreibbar ist. Vielleicht bin ich der einzige, kann ja sein.
Man muss sich aber auch fragen: Warum wird das überhaupt überprüft? Das passiert bei der Installation, dann sollte das eigentlich klar sein.
-
Ich habe jetzt bei mir nachgeschaut, Doc_root Rechte steht auf 745. Ordner innerhalb werden mit 755 und Files mit 644 angelegt.
Sprich mit deinem Hoster. Ich kann dir nur versichern, dass es schon immer abgeprüft wurde. Schau mal selber im SVN in die vergangenen Versionen.
Dietmar
-
Man muss sich aber auch fragen: Warum wird das überhaupt überprüft? Das passiert bei der Installation, dann sollte das eigentlich klar sein.
Leider ist das auch nach der Installation nicht klar, da es so seltsame Programme wie z.B. FileZilla gibt, mit denen sich Rechte jederzeit nachträglich ändern lassen.
Und weist ja selbst aus Erfahrung, dass User immer erst die Rechte von Verzeichnissen und Dateien wahllos ändern, bevor sie es evt. mal mit ihrem Adminzugang versuchen wenn irgendetwas nicht funktioniert. [/sarkasmus off] :wink:
-
Also wenn ich mich recht erinnere, habe ich auf manchen sites auch deswegen den Core gepatcht in einer älteren WB-Version. Es gibt garantiert einen alten Thread hier im Forum, wo über das Problem diskutiert wurde.
Meine Meinung:
- Natürlich müssen die Schreibrechte für das Verzeichnis, in das geschrieben werden soll, überprüft werden.
- Es ist sinnlos, die Schreibrechte eines weiter übergeordneten Verzeichnisses zu prüfen, weil das völlig irrelevant für den Schreiberfolg im Unter-Unterverzeichnis ist. Der User könnte ja auch die Schreibrechte für das Unterverzeichnis verstellt haben, aber nicht für root, und dann bringt die Überprüfung in root 0 Punkte.
Werner, es gibt doch eigentlich kein Argument gegen eine solche Realiserung, oder?
Ich kann das gerne machen, weil bei meinem Provider habe ich das Problem auch :-)
-
Solange es rein um das Anlegen/Löschen untergeordneter Seiten geht ist das durchaus machbar.
Probleme werden aber auftreten, sowie eine Seite auf Level 0 geändert, gelöscht oder gar hinzugefügt werden soll. Ebenso beim automatischen, rekursiven Neuaufbau der Accessfiles, wenn wenn irgendwo eine Datei fehlt und die Pagesverwaltung daraufhin den Neuaufbau anstößt, sowie die entsprechende Seite neu abgespeichert wird.
...grummel... Waschmaschine kaputt...
-
Leider ist das auch nach der Installation nicht klar, da es so seltsame Programme wie z.B. FileZilla gibt, mit denen sich Rechte jederzeit nachträglich ändern lassen.
Äh, eben nicht unbedingt habe hier PHP als Apachemodul laufen das heist Dateien die von WB angelegt werden laufen unter unter einem anderen Benutzer als die per FTP eingespielten.
Da ist es dann garnicht so einfach mal die Rechte wieder zu ändern.
Vielleicht mal auf einem Server testen auf dem PHP als Apachemodul läuft.
Was ich nicht verstehe ist das dem pages Verzeichniss die Rechte entzogen wurden, denn nach der Installation wahren sie ja wohl gesetzt. Ich verstehe einfach nicht den Sinn warum man das machen sollte.
-
Vielleicht mal auf einem Server testen auf dem PHP als Apachemodul läuft.
Das Problem ist leider allzugut bekannt.... aber es wird daran gearbeitet.. ;-)
Was ich nicht verstehe ist das dem pages Verzeichniss die Rechte entzogen wurden, denn nach der Installation wahren sie ja wohl gesetzt. Ich verstehe einfach nicht den Sinn warum man das machen sollte.
Dem /pages/ wurden keine Rechte entzogen, es wurde nur in die DocumentRoot 'verlegt'. Verschiedene Admins haben eben lieber Links wie http://example.com/startseite.php anstatt http://example.com/pages/startseite.php.
Normalerweise kein Problem, solange der Provider bei einem unter apache2modul laufenden Server dem www-run nicht die Schreibrechte für DocumentRoot entzieht.
Bei derartiger Konfiguration gibt es nur 2 Möglichkeiten:
- einen Webspace nehmen, der diese Probleme nicht bereitet... bzw. auf fast/CGI umschalten
- jedes Unterverzeichnis in DocumentRoot erst mal per FTP anlegen und passende Rechte vergeben, bevor www-run da was reinschreiben kann.
-
Hallo,
Bei derartiger Konfiguration gibt es nur 2 Möglichkeiten:
- einen Webspace nehmen, der diese Probleme nicht bereitet... bzw. auf fast/CGI umschalten
- jedes Unterverzeichnis in DocumentRoot erst mal per FTP anlegen und passende Rechte vergeben, bevor www-run da was reinschreiben kann.
Hätte da noch eine dritte Variante anzubieten. Bin auch bei einem Provider (allinkl) bei dem Apache als Modul läuft. Dennoch ist es da recht einfach Seiten ins "root" zu bekommen ohne in Konflikt mit den Rechten zu kommen. WB wird einfach in ein Unterverzeichnis des Server-roots gelegt (z.B. in das Verzeichnis "wb"), in der Konfiguration zu diesem Webspace (bei allinkl die KAS-Oberfläche) ändert man den Zeiger auf die Domäne dann auf dieses Verzeichnis. Fertig.
Matthias
P.S.
Kann auch angewendet werden wenn man parallel zu einer alten Seite eine neue mit WB anlegen will. Da kann man die alten Seiten unverändert lassen, die neuen WB Seiten in einem Unterverzeichnis komplett fertig machen und am Tag X dann einfach den Zeiger und (bei WB 2.8.x) in der config.php den Pfad ändern und alles ist gut.
-
- LightTPD (win32)
- MySQL 5.1.35
- PHP 5.3.4
- WB RC5
Bitte Direktzugriff (Client) auf modules/admin.php unterbinden.
(für'n richtigen Satz hab' ich i.M. keine Zeit )
-
Das mit dem Verschieben der /pages in Webroot war mir so noch nicht bekannt, das mit den Unterverzeichnissen scheint mir da ne gute Lösung wenn man keinen eigenen Server nutzt.
Zumal man ja von Seiten Websitebakers keinen Einfluss auf diese Schreibrechte hat.
Dann währe es wohl tatsächlich besser nur das aktuelle Verzeichniss zu überprüfen in das geschrieben werden soll, und beim Verschieben eben wieder prüfen kann ich am Zielort schreiben.
Den nicht bei jedem Hoster hat man eine der drei Optionen um im Webroot Schreibrechte zu bekommen.
Zusätzlich beugt das Überprüfen beim Verschieben auch gleich Manipulationen vor bei denen vielleicht etwas wohin verschoben wird wo es nicht hingehört.
-
Hallo,
der Administrator kann bei RC 5 seine Angaben unter "Einstellungen" nicht ändern. Das Passwort wird grundsätzlich abgelehnt ("Das alte Passwort, das Sie angegeben haben, ist ungültig"). Versucht man, ein Neues einzugeben, erscheint zudem die Meldung
Warning: preg_match() [function.preg-match]: Compilation failed: missing terminating ] for character class at offset 3 in /.../admin/preferences/save.php on line 104
CMS Version 2.8.2.RC5
Revision 1394
Admin version 1.4
PHP 5.2.9
Grüße
-instantflorian.
-
Das kann ich nicht nachvollziehen.
Hast du irgendwelche ungewöhnliche Sonderzeichen im Passwort?
Schon mal mit einer sauberen Neuinstallation versucht, gibt es da das gleiche Problem?
-
für rev 1398 kann ich das nicht bestätigen, außer bei der Zeitzone.
passwortänderung auch möglich. danach erscheint meldung wie im bild.
[gelöscht durch Administrator]
-
Sehen diese Zeilen anders aus als
$pattern = '/[^'.$admin->password_chars.']/';
if( preg_match($pattern, $new_password_1) )
??
-
ich habe lediglich einige dinge bestätigt, andere nicht und seine fehlermeldung wohl überlesen.
problem damit?
ß-taste kaputt?
-
Hallo,
es ist eine Neuinstallation, und das allermerkwürdigste ist, dass die Passwortänderung dann trotz der Fehlermeldung klappt. Fehler tritt auch auf, wenn ein einfaches PW ohne Sonderzeichen eingegeben wird.
Grüße
-instantflorian.
-
Werner hat das gefixt in r1412
-
keine meldung mehr nun nach 1412. :-)
zeitzone bleibt immer auf standard.
-
Das ist fein, dann warte ich mal auf RC6 :-D
-
Hallo,
habe mit dem RC5 Rev 1394 ein kleines Problem entdeckt:
Wenn man versucht, im FCKEditor ein Bild mit einem WBLink zu versehen, erscheint die Fehlermeldung "Bitte zuerst einen Text markieren, der verlinkt werden soll!".
Kann das jemand bestätigen oder liegts an meiner Installation?
Edit: Eben gesehen, das Problem bestand in der 2.8.1 mit FCK 2.9.4 auch schon, hat also nichts mit RC5 per se zu tun...
-
Wenn man versucht, im FCKEditor ein Bild mit einem WBLink zu versehen, erscheint die Fehlermeldung "Bitte zuerst einen Text markieren, der verlinkt werden soll!".
Ja, das ist schon länger so. Je nach Browser gibt es mal die, mal jene Zicken.
Anderes Problem:
Servereinstellungen -> Zugriffsrechte:
Die Einstellungen werden nicht gespeichert und nicht übernommen.
Ist für mich kritisch, weil sich der Server weigert, Seiten anzuzeigen, die NICHT auf 644 stehen, also alle neu angelegten.
[edit] ICh habs jetzt per MyPHPAdmin umgestellt; das funktioniert, die Dateien werden auch richtig angelegt.
-
Die Idee in der Sprachdateien ç und ähnliches einzubauen ist zwar nicht schlecht, es führt aber zu Probleme bei der Darstellung der entsprechende Texten.
Anstelle von Français sehe ich Fran&ccdil;ais, dies ist nicht gerade lesbar.
Die Html Entities sollten beim Upgrade in den Zeichensatz des Seite übersetzt werden (UTF-8, ...). Ferner ist zu beachten, dass mittlerweile das utf-8 von alle Browser die html 4 beherrschen verstanden wird und dass xhtml es als Default vorsieht.
-
Nach einige kleinen Untersuchungen sieht es so aus, dass die Dateien wb/languages/??.php in ISO-8859-1 kodiert werden müssen damit Zeichen wie ç oder ähnliches richtig in der Datenbank übernommen werden, auch wenn das Zeichensatz UTF-8 ist. Dies bedeutet, dass das Upgrade / Install Script eine Umwandlung vornimmt. In der Datei LV.php steht u. a. $language_name = 'Latviešu' (auch bei 2.8.1) dies wird aber nicht umgewandelt.
Korrekturen sind im Verfahren notwendig.
-
Vielen Dank an alle die testen, Fehler in der Sprachauswahl in SVN 1435 ist gefixt, desweiteren wurde mit der SVN 1436 ein Update der jquery zu Version 1.5.1 and jQuery UI zu Version 1.8.10 vorgenommen
Dann noch zur Info, zwischendurch ist wegen Kundenaufträgen die Fertigstellung der 2.8.2 liegen geblieben. Zur Zeit wird wieder am Installer gearbeitet. Sobald dieser fertig und getestet ist, können von euch abschliessende Test durchgeführt werden.
Tut uns leid wegen der Verzögerung, aber ihr habt bestimmt Verständnis, dass auch Entwickler ihre Miete zahlen müssen.
Dietmar
-
Hallo,
schön, dass die Arbeit wieder aufgenommen wurde.
Tut uns leid wegen der Verzögerung, aber ihr habt bestimmt Verständnis, dass auch Entwickler ihre Miete zahlen müssen.
Ich denke die meisten haben. Aber schaut doch für die Zukunft wo ihr euch die Arbeit mit Community Mitgliedern teilen könnt. Und auch, dass Beiträge einfließen.
Vielleicht helfen auch >kleinere Schritte< dabei, die Community Zufriedenheit wieder nach oben zu schrauben.
Stefek
-
Du hast da vollkommen recht. Nur leider sit es so, das nur ganz Wenige teamfähig sind. Will das ja auch verstehen. wenn man gewwöhnt ist immer alles alleine zu entscheiden. Aber so läuft das in einem Projekt nicht. Dann brauchtst du keine Temaleader.
Deswegen deine Anregung mit dem Branch wird unser nächstes Top Thema sein.
Dietmar
-
Ich verstehe wie Du meinst.
Natürlich ist es schwer leute zu finden, die "teamfähig" sind, wenn man aber vorher nicht definiert, was man unter Teamfähigkeit versteht.
Es darf einfach nicht eine Bauchentscheidung sein, wer und ob jemand teamfähig ist.
Ich denke noch nicht einmal, dass das Problem die Teamfähigkeit ist, sondern vielmehr der Überblick über das Projekt.
Jemand der gut mit Bewegung umgehen und sie gut handhaben kann ohne sofort bei jeder nicht planmäßigen Abweichung verwirrt zu werden kann auch mit Leuten umgehen, die scheinbar unfähig sind.
Geduld muss sein.
Aber so, wie wir mit euch aus dem Dev Team Geduld haben sollen, solltet ihr auch mit den scheinbar unbeholfenen Versuchen beizutragen Geduld haben, die hier in regelmäßigen Abständen von verschiedenen Community Mitgliedern versucht werden.
Und das wäre für mich auch die Funktion eines Teamleaders.
Denn leiten kann nur, wer genug Ruhe und Ausgeglichenheit hat, um nicht bei jeder Abweichung in alle Richtungen zu Schießen.
Teamfähigkeit spielt dabei kaum eine Rolle.
Ich bin selbst ein ziemlicher Eigenbrötler. Gesellig zwar, aber für mich muss ein Team nicht aus Leuten bestehen die alle die gleichen Klamotten tragen und ihre Haare in die selbe Richtung kämen. Bin kein Söldner.
Die Kraft liegt in der Vielfalt.
Und im Willen auch mal was neues auszuprobieren.
Freut mich übrigens die Sache mit den Branches.
LG,
Stefek
-
Ich schlage vor, sobald letztendlcih das Forum umgestellt ist, ein Off-Topic Thema über Mitarbeit in einem Team zu eröffnen. Ich persönlich finde es interessant was sich jeder darunter vorstellt.
Für alle die keinen SVN Client ihr Eigen nennen. hier der Link für den Download der aktuellen
WebsiteBaker 2.8.2 RC5 Rev1436 (http://www.websitebaker2.org/modules/download_gallery/dlc.php?file=116&id=1300345273)
Viel Spass beim Testen
Dietmar
-
@Stefek:
Das war sehr diplomatisch formuliert, ich befürchte nur, der Adressat hat es nicht kapiert ;-)
Was für Teamarbeit immer Gift ist, sind Leute, die darunter verstehen "Ihr macht was ich sage, auch wenn es dafür keine sachlichen Argumente gibt."
Schönen Tag noch.
-
@FrankH: willst du nur provozieren oder auch konstruktiv kommunizieren?
Eine Frage zu Droplets.
Spricht etwas dagegen die Super-Geile-Version-1.5.1 zu installieren bzw. ein Upgrade von 1.04 darauf zu machenn?
Gruß
dbs
-
nein es spricht nichts dagegen. Warum sollte es.
Dietmar
-
Warum sollte es.
Weil es auf Version 1.03 aufbaut.
-
Nach Upgrade von 1287 auf 1436 ist kein Speichern mehr möglich:
Sicherheitsverletzung!! Zugriff wurde verweigert!
Egal ob in Optionen oder ein Seitenabschnitt. Es war nur 1x Backend geöffnet.
Hab ich was vergessen/verpasst?
edit: betrifft FF,
nicht IE9 oder Chrome.
-
Natürlich ist es schwer leute zu finden, die "teamfähig" sind, wenn man aber vorher nicht definiert, was man unter Teamfähigkeit versteht.
Es darf einfach nicht eine Bauchentscheidung sein, wer und ob jemand teamfähig ist.
Jep, natürlich nicht. Das grundlegende Problem an WB ist nur, dass zu wenige Leute da sind die wirklich etwas tun und zu viele Barrieren bzw. Motivation in der Organisation liegenbleibt.
Oder halten wir es mit dem Slogan einer großen Firma: "Nicht die Hierarchie, sondern die beste Idee zählt."
Wenn das bei 3000 Mitarbeitern funktioniert, wird es das auch bei 30. :wink:
-
Das grundlegende Problem an WB ist nur, dass zu wenige Leute da sind die wirklich etwas tun
Die Abhilfe dafür liegt aber nicht nur darin, darüber zu sprechen und einen Off-Topic Bereich zu öffnen.
Meiner Meinung nach ist das sehr ON-Topic.
Ich weiß nicht was wichtiger ist, als Leute für die Mitarbeit an einem OS Projekt zu begeistern und ihre Arbeit Sach- und Fachgerecht ins Projekt einfließen zu lassen.
Dazu gehört doch nur, die verschiedenen Beitragstypen zu sondieren und die Arbeit im Auge zu behalten.
Und ja, einen Plan und den Wunsch nach Wachstum sollte man im Voraus mitbringen.
Ich finde also dass es weder mit Teamfähigkeit, noch mit zu wenig darüber geredet oder zu wenigen Leuten zu tun hat.
Die Leute hängen doch alle hier rum.
Das sind übrigens die, die am meisten stänkern.
(Eben weil sie nicht richtig geleitet/gehandhabt -- oder zu Deutsch -> behandelt -- wurden.)
Genau, zu wenige Leute tun wirklich was. Schon mal am "Warum" gearbeitet?
Stefek
-
Schon mal am "Warum" gearbeitet?
Deswegen ja auch ein eigenes Thema. Hier geht es doch um 2.8.2 Test. Diese Diskussionen gehören hier eh nicht hin. Dies sollte auch der letzte Post bezüglich Teamfähigkeit sein.
Jeder weitere Post der nicht die 2.8.2 RC Test betrifft, wird ab sofort gelöscht werden.
Dietmar
-
Du hast selbst von Teamfähigkeit angefangen... :roll:
Jeder weitere Post der nicht die 2.8.2 RC Test betrifft, wird ab sofort gelöscht werden.
Jo, ich hol dann schon mal den Kamm (https://forum.WebsiteBaker.org/index.php/topic,20547.msg142403.html#msg142403) raus. :mrgreen:
-
"Herr Doktor, alle ignorieren mich."
"Der Nächste bitte."
-----------------------------------------------------
Sicherheitsverletzung!! Zugriff wurde verweigert!
Nach Upgrade von 1287 auf 1436 ist kein Speichern im FF möglich. (Chrome, IE9 OK)
Nur 1 Tab geöffnet.
Woran kann es liegen?
-
Ich hatte dieses Problem nach dem FireFox update auf Version 3.6.15 auch. War ich erstmal glücklich drüber, dachte könnten jetzt mal Ursachenforschung betreiben. Tagsspäter und bis heute ist das Problem nicht mehr aufgetaucht. Ob dies durch ein Addon verursacht wird? Möglcih.
Wir wissen einfach nicht warum der FireFox dies verursacht. Bei allen anderen B rowsern gibt es diese Probleme nicht. Suche mal nach einer Lösung wo der Fehler nicht laufend auftritt. Unmöglich.
Dietmar
-
Zum Thema Sicherheitsverletzu ng wenn mehrere Tabs geöffnet werden. Ich arbeite auch mit mehreren Tabs. Ich habe mir angewöhnt das Fenster zuletzt zu öffnen wo ich speichern will.
Wir wollen und werden uns aber dazu noch was einfallen lassen. weil das einfach lästig und umständlich ist.
Dietmar
-
noch was einfallen lassen. weil das einfach lästig und umständlich ist.
Doch schon? Na besser spät als nie... :-D
Es muss doch zwischen "Offen wie ein Scheunentor" und "ich sperr den Admin aus" noch einen Mittelweg geben. :?
-
Ob dies durch ein Addon verursacht wird? Möglcih.
Wohl eher nicht, da auch im abgesicherten Modus nichts geht.
Na denn bin ich mal gespannt wann es sich bei mir von selbst erledigt.
-
Vielleicht hilft das:
Auf dem gleichen Server habe ich noch eine reine WB 2.8.2.
Nach Aktualisierung auf Rev. 1436 ist dort Speichern kein Problem im FF.
Demnach liegt es eher am Upgrade als am FF.
Werde das nochmal wiederholen.
-
Wir haben zwischenzeitlich mit DBS über skype noch ein paar Sachen getestet und festgestellt, dass es doch ein Problem mit FF gibt.
Morgen wissen wir evtl mehr. Es laufen noch Tests.
Dietmar
-
Hallo,
getestet: die Rev 1436 hat weiterhin das "Sicherheitsverletzu ng"-Problem, nicht nur mit FF, sondern auch mit Chrome. Möglicherweise hat es etwas mit dem CK Editor und dem Einfügen von Bildern zu tun. Mit dem FCK 2.9.5 *scheint* es zu klappen.
VG
-instantflorian.
-
die Rev 1436 hat weiterhin das "Sicherheitsverletzu ng"-Problem, nicht nur mit FF, sondern auch mit Chrome.
in den optionen kannst du speichern ohne sicherheitsverletzu ng?
ich kann z.b. einen user löschen, aber keinen neuen anlegen.
in chrome (10.0.648.151) habe ich keine probs.
-
Hallo dbs,
Mit Firefox Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.2.15) Gecko/20110303 Firefox/3.6.15 unter Win XP)
Benutzer anlegen/löschen geht, Optionen ändern auch. Habe jetzt auch etliche Zeit Seiten neu angelegt, Abschnitte hinzugefügt usw., keine Probleme gehabt.
Ergänzung: Verwende das Argos-Backendtheme
VG
-instantflorian.
-
Meine Probs bestehen nur mit Win7 + FF 3.6.15
Unter XP ist alles OK.
-
Firefox 4 Final:
Nach Update von WB 2.8.1 auf 2.8.2 (1439) gibt es keine Speicherprobleme mehr im FF. :-)
-
sorry for english here :)
I noticed rc5 rev 1440 on project server, where can I download it ?
-
someone ? :)
-
You need svn-client like tortoise or simular
then fetch the latest svn with your svn client
Have fun,
John
-
http://project.websitebaker2.org/projects/WebsiteBaker/files
http://www.websitebaker2.org/en/download/latest-version.php
-
I went on those links, but there is a svn 1436(from middle of the march), and I saw latest is 1440..
I will try with svn client..
cheers
-
Be very carefull, these are development versions. No guarantee that it will not format your disks.
Alfa, Beta, RC versions are believed to be working meant for testing. SVN versions are for developing.
-
Mit der Rev. 1441 gibt es einen "Lizenzverstoß" (zumindest wäre es einer, wenn nicht abgesprochen ist mit dem Autor bzw. wenn es interessiert).
http://project.websitebaker2.org/projects/WebsiteBaker/repository/revisions/1441/diff/branches/2.8.x/wb/modules/jsadmin/info.php
Zur Info: JSAdmin war ein Modul zu 2.6er Zeiten, das in das 2.7er Paket übernommen wurde.
Speziell geht es um die Lizenzvereinbarung:
* Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
-
@Testör,
jsadmin braucht YahooUI library
kann das gleiche nicht met jquery?
John
-
@Testör,
jsadmin braucht YahooUI library
kann das gleiche nicht met jquery?
John
Ja und Nein. Die Logik von YahooUI und jQuery sind stark unterschiedlich. Dazu ist das HTML des Seitenbaumes zu komplex, dass jQuery (das ein "gutes" und "logisches" HTML-Gerüst voraussetzt) einfach so funktioniert.
Der Seitenbaum (also /admin/pages/index.php, aber auch andere PHP-Dateien) müsste von Grund auf neu geschrieben werden. Dann könnte man mit jQuery, aber auch MooTools oder YUI mit wenigen Zeilen eine ordentliche Drag&Drop-Funktion einbauen.
Mit der momentanen Logik ist der Seitenbaum selbst sehr langsam, und mit Drag&Drop erst recht sehr langsam. Es gibt zwar Versuche, dies zu verbessern, doch grundlegend kann die Logik des Seitenbaumes nicht verändert werden, sonst würde man das ganze CMS kaputt machen. Und natürlich Upgrades nahezu unmöglich machen.