WebsiteBaker Community Forum
WebsiteBaker Support (2.8.x) => 
Hilfe & Support (deutsch) => General Help & Support => Diskussion über WB (closed) => Topic started by: testör on December 20, 2010, 09:45:45 AM
-
Ich fang mal an, was in der 2.8.2 meiner Meinung nach enthalten sein sollte:
- Weiteres Durchsehen von bereits gemachten Änderungen des vorherigen 2.8er Strangs und evtl. einpflegen.
- FCKEditor sollte entfernt / ersetzt werden. 2011er Browser unterstützen diesen nicht mehr, vorrangig IE9 und FF4. FCKEditor wird nicht mehr erneuert, daher gibt es mit modernen Browsern keine vernüftige Demofunktion mehr, sowie das "übliche Überblick Verschaffen" von Leuten über CMS fällt flach, wenn kein Text mehr eingegeben werden kann.
- Module wie Droplets, Show_Menu2 usw. auf neuesten Stand bringen.
- jQuery usw. auf neuesten Stand bringen.
-
Ich mache mal weiter:
- Sicherheitslücken beseitigen (wenigstens die vielen, wo das ohne großen Aufwand möglich ist.)
-
Ging problemlos, was ich auf den ersten Blick sehe.
Zu "neuestes jQuery rein": Ich hab vor ein paar Tagen bei einer Site auf die neueste Version aufgerüstet - das machte ganz schön Ärger. Viele Plugins waren nicht mehr ganz kompatibel und mussten ebenfalls upgedated werden. Die widerum brauchen aber plötzlich andere Parameter. Ich hab ganz schön herumschauen müssen, bis wieder alles so halbwegs lief...
-
Hallo,
mein Wunsch:
Updatescript (2.7 => 2.8.2) fixen, sofern noch nicht geschehen
Und ja, FCK raus und CKEditor rein
Viele Grüße
-instantflorian.
-
Hallo,
dadurch, dass der Ordner [root]/admin/images entfernt wurde, funktioniert die Darstellung der Icons in einigen Modulen nicht mehr.
Klar, es ist die "Verantwortung" der Modulautoren, sich darum zu kümmern, die THEME_URL richtig zu setzen.
Aber: dieser Ordner wurde ohne richtige Bekanntmachung entfernt und zwar nach dem der 2.8.x schon lange draussen war.
Es wäre gut, diesen Ordner als Fallback in der 2.8er Reihe noch drin zu haben.
Gruß,
Stefek
-
Sind statt neuer Features erstmal alle Fixes in der RC2, wäre das schon viel, und eine Frage stellt sich danach: Wer arbeitet die Liste (wo ist diese) ab, um zu prüfen, ob die angegebenen Bugs nun auch beseitigt sind? Ohne systematisches Vorgehen ist der Test für die Tonne.
Bei SM2 ist noch eine Frage offen (https://forum.WebsiteBaker.org/index.php/topic,20282.msg137168.html#msg137168)
-
Sind statt neuer Features erstmal alle Fixes in der RC2,
neue Features kommen nicht rein, nur die Fixes. Da müsst ihr mir einfach vertrauen. Hab da schon mein eigenes Konzept.
admin/images wird wieder eingefügt, macht Sinn, wurde ja bereits in 2.8.1 vergessen zu entfernen.
Bei SM2 ist noch eine Frage offen (https://forum.WebsiteBaker.org/index.php/topic,20282.msg137168.html#msg137168) Jetzt nicht mehr
Dietmar
-
Zu "neuestes jQuery rein": Ich hab vor ein paar Tagen bei einer Site auf die neueste Version aufgerüstet - das machte ganz schön Ärger. Viele Plugins waren nicht mehr ganz kompatibel und mussten ebenfalls upgedated werden.
Das kann ich bestätigen. Vor allem der Sprung auf 1.4.4 hat vielen Plugins weh getan. Trotzdem macht es Sinn, die Uralt-Version von jQuery im Core zu aktualisieren.
-
So, eine erste Teststaffel mit 2.8.2 Rev. 1354. Neuinstallation.
Server: PHP 5.2.9, phpinfo: http://dd6126.kasserver.com/infophp.php
Installation
- Website Baker -> WebsiteBaker (einfaches Suchen & Ersetzen)
Seite erstellen
- WYSIWYG, Keine übergeordnete, Öffentlich
- Beim Anlegen der Zugangsdatei im Verzeichnis /pages ist ein Fehler aufgetreten (Ungenügende Zugangsrechte)
- Siehe nach FTP: Keine Datei angelegt. Allerdings Ordner "posts" mit index.php vorhanden. => Schreibrechte vorhanden, da dieser nicht hochgeladen wurde.
- Sowohl Menüpunkt als auch in Seitenübersicht Seite vorhanden.
- "Abschnitte verwalten" -> Kein Abschnitt angelegt.
- Wenn erste Seite überhaupt: Abschnitt anlegen, Seite vorhanden (wohl, da index.php hochgeladen).
Sofern Übergeordnete Seite vorhanden:
Warning: mkdir() [function.mkdir]: Permission denied in /www/htdocs/***/framework/functions.php on line 212
Vermutung:
Da Ordner 777, aber Besitzer FTP-User wird "pages" Ordner nicht korrekt übertragen. Ebenso alle anderen (Module, Template, Media, Tmp, usw.) sind auf FTP-User. Modulinstallation, Templateinstallatio n und Medien (Ordner & Dateiupload) allerdings fehlerfrei.
2.8.1er Installationen auf selbem Server fehlerfrei. Die Ordner müssen wie in 2.8.1 und vorhergehend auf PHP-User automatisch umgestellt werden.
Deutsche Frontend-Registrierung:
- E-Mail Betreff "Deine WB Logindaten ...", allerdings E-Mail selbst formal. Vorschlag: "Ihre Logindaten".
- Kein Link zur Installation - WB_URL wäre sinnvoll einzubauen.
- Fehlermeldung nach Registrierung im Frontend
Strict Standards: date() [function.date]: It is not safe to rely on the system's timezone settings. Please use the date.timezone setting, the TZ environment variable or the date_default_timezo ne_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'Europe/Berlin' for 'CET/1.0/no DST' instead in /www/htdocs/***/include/phpmailer/class.phpmailer.php on line 1632
Strict Standards: date() [function.date]: It is not safe to rely on the system's timezone settings. Please use the date.timezone setting, the TZ environment variable or the date_default_timezo ne_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'Europe/Berlin' for 'CET/1.0/no DST' instead in /www/htdocs/***/include/phpmailer/class.phpmailer.php on line 1636
-
Noch etwas zu Installation & Login:
/install/safe.php, Zeile 770 ff.
"MAX_ATTEMPS" => "50",
[...]
"MIN_USERNAME_LEN" => "2",
"MIN_PASSWORD_LEN" => "2",
/account/login.php, Zeile 52 ff.
"MAX_ATTEMPS" => "3",
[...]
"MIN_USERNAME_LEN" => "2",
"MIN_PASSWORD_LEN" => "2",
/admin/login/index.php, Zeile 42 ff.
"MAX_ATTEMPS" => "3",
[...]
"MIN_USERNAME_LEN" => "2",
"MIN_PASSWORD_LEN" => "2",
Alles ändern zu:
"MAX_ATTEMPS" => "3",
[...]
"MIN_USERNAME_LEN" => "3",
"MIN_PASSWORD_LEN" => "6",
Benutzernamen sollten mind. 3 Zeichen, Passwörter mind. 6 Zeichen (eher mehr) lang sein. Zudem sind unterschiedliche Handhabungen von Max_Attemps nicht sinnvoll.
Bei der Neuerstellung natürlich noch eher anpassen:
/account/signup2.php, Zeile 44 ff.
if(strlen($username) < 3) {
$wb->print_error($MESSAGE['USERS']['USERNAME_TOO_SHORT'], $js_back, false);
}Hier ein "< 4".
Bei der Install wird keinerlei Zeichenbeschränkung vom Adminnamen bzw. Passwort verlangt. Hier sollte unbedingt auch Benutzername minimum 3 Zeichen, Passwort min. 6 Zeichen zutreffen.
Sinnvoller wäre natürlich alles zentral, aber das ist was für 2.9.
Nachteil natürlich: Benutzer die angemeldet sind können nicht mehr sich einloggen. Es werden nur wenige sein, aber die "gefühlte" Sicherheit ist zumindest höher. Hier muss dann der Admin Hand anlegen.
-
Nachteil natürlich: Benutzer die angemeldet sind können nicht mehr sich einloggen. Es werden nur wenige sein, aber die "gefühlte" Sicherheit ist zumindest höher. Hier muss dann der Admin Hand anlegen.
Deswegen mein Vorschlag, den index login nicht verändern sondern nur die save.
Dietmar
-
Trotzdem macht es Sinn, die Uralt-Version von jQuery im Core zu aktualisieren.
Zurzeit ist jquery 1.4.2 eingebunden. Frage an die Community, ob auf die 1.4.4 upgedated werden soll.
Dietmar
-
Nachteil natürlich: Benutzer die angemeldet sind können nicht mehr sich einloggen. Es werden nur wenige sein, aber die "gefühlte" Sicherheit ist zumindest höher. Hier muss dann der Admin Hand anlegen.
Deswegen mein Vorschlag, den index login nicht verändern sondern nur die save.
Dietmar
Ja, für die 2.8xer besser. Sollte dann aber überall angepasst sein (in der preferences ist es auf jeden Fall, User & Groups weiß ich gerade nicht).
Trotzdem macht es Sinn, die Uralt-Version von jQuery im Core zu aktualisieren.
Zurzeit ist jquery 1.4.2 eingebunden. Frage an die Community, ob auf die 1.4.4 upgedated werden soll.
Dietmar
Würde ich auf jeden Fall. Evtl. jQuery noch als 1.4.2er jquery-min142.js mitliefern - aber die wird kaum einer benutzen, daher lieber ganz raus und aktuell. Ebenso jQ UI.
-
Zu "neuestes jQuery rein": Ich hab vor ein paar Tagen bei einer Site auf die neueste Version aufgerüstet - das machte ganz schön Ärger. Viele Plugins waren nicht mehr ganz kompatibel und mussten ebenfalls upgedated werden.
Das kann ich bestätigen. Vor allem der Sprung auf 1.4.4 hat vielen Plugins weh getan. Trotzdem macht es Sinn, die Uralt-Version von jQuery im Core zu aktualisieren.
jQuery Upgrade prinzipiell ja.
Ob das jetzt dann gleich die 1.4.4. ist, steht dabei noch auf einem anderen Blatt. Klar, für alle, die sich mit jQuery auskennen und intensiv damit arbeiten wäre das kein größeres Problem.
WB wird jedoch nicht ausschließlich von jQuery-Cracks genutzt, sondern von sehr vielen Anwendern, die sich auf eine volle Funktionalität verlassen und selbst nicht in der Lage sind, die notwendigen Anpassungen durchzuführen. Es darf nicht passieren, dass diese Nutzer nach einem Upgrade im Regen stehen und ihre Plugins etc. plötzlich nicht mehr funktionieren.
Daher mein Vorschlag:
- Upgrade auf die letzte Version (evt. 1.4.3 ?) unter der die Plugins noch stabil laufen.
- Überarbeiten aller Plugins, so dass sie ohne Anpassungen auf 1.4.4 lauffähig sind
- nach einer gründlichen Testphase dann upgrade auf 1.4.4
Es spricht absolut nichts dagegen, dass die jeweils neueste Version installiert wird, jedoch sollte vorher zwingend sichergestellt sein, dass sich daraus für 'normale' User keine Probleme ergeben.
-
Nachtrag zu Frontend Registrierung. Rev. 1354 (es gibt schon Rev. 1355 - ich finde es übrigens wirklich super, dass FrankH wieder aktiv mitarbeitet und es so jemand gibt, der mehrere Augen auf die Sicherheit hat).
Wird alles angelegt, E-Mail verschickt usw.
Aber zu den Strict standards: date() Meldungen gibt es unten im Template noch folgendes (nicht gesehen, da schnell wieder weg ist):
Notice: Undefined property: wb::$page_id in /www/htdocs/***/framework/frontend.functions.php on line 477
Fatal error: Call to a member function fetchRow() on a non-object in /www/htdocs/***/framework/frontend.functions.php on line 481
Template ist Standard-Round, URL /account/signup.php.
-
E_DEPRECATED Fehler werden wir für die 2.8.x noch weitestgehend beseitigen,
E_STRICT Meldungen jedoch nicht mehr unbedingt.
Ab der 2.9.x ist jedoch das verhindern von E_DEPRECATED Pflicht (Core und Module) und E_STRICT nach Möglichkeit ebenso.
-
Es darf nicht passieren, dass diese Nutzer nach einem Upgrade im Regen stehen und ihre Plugins etc. plötzlich nicht mehr funktionieren.
genau.
aber wer sagt, dass mit jquery 1.4.3 alles ganz genau so läuft wie mit der vorgänger-version.
im prinzip ist das ein fall für einen patch. wer es braucht, patcht. vor allem kann derjenige dann auch wieder auf eine ältere version patchen, falls es nicht läuft.
klingt wie bei einem modul :-D
-
E_STRICT Meldungen jedoch nicht mehr unbedingt.
Soweit ich erinnere gab es in den mitgelieferten Modulen (auch in 2.8.1) keine strict-Fehler mehr
E_DEPRECATED Fehler zu beseitigen ist schon länger überfällig. Zumindest im Core und in den mitgelieferten Modulen sollte derartiges in 2.8.2 nicht mehr drin sein. (war ja auch schon wech)
Den Rest müssen schon die Modulautoren "auf die Reihe kriegen". PHP 5.3 ist ja nun schon lange genug "auf dem Markt"
-
Daher mein Vorschlag:
- Upgrade auf die letzte Version (evt. 1.4.3 ?) unter der die Plugins noch stabil laufen.
- Überarbeiten aller Plugins, so dass sie ohne Anpassungen auf 1.4.4 lauffähig sind
- nach einer gründlichen Testphase dann upgrade auf 1.4.4
Es spricht absolut nichts dagegen, dass die jeweils neueste Version installiert wird, jedoch sollte vorher zwingend sichergestellt sein, dass sich daraus für 'normale' User keine Probleme ergeben.
Die "nicht im Forum aktiven WB-Nutzer" und auch ich danken für diese Gedankengänge. WB's Stärke soll hoffentlich bleiben, dass nicht nur sehr aktive Insider damit viel erreichen können.
-
aber wer sagt, dass mit jquery 1.4.3 alles ganz genau so läuft wie mit der vorgänger-version.
im prinzip ist das ein fall für einen patch. wer es braucht, patcht. vor allem kann derjenige dann auch wieder auf eine ältere version patchen, falls es nicht läuft.
patchen können evt. die User hier im Forum, die sich ausgiebig mit jQuery beschäftigen. Der 'Otto-Normalverbraucher' kann das nicht. Für den ist die jQuery-Funktionalität ein Bestandteil des Komplettsystems und wenn er dieses upgraded, erwartet er dass auch diese Funktionen ohne weiteres Rätselraten funktionieren.
Anwender != Codierer != Programmierer ==> assoziiert mit dem Begriff Java(script) allerhöchstens eine Ferieninsel... oder eine Kaffeebohne. 8-)
Was die Version angeht, die habe ich bewusst freilassend mit ? angegeben. Das sollte Aufgabe der jQ-Spezis sein, dafür zu sorgen dass die jeweiligen Updates/Upgrades stabil laufen .... ohne zusätzliche Patches ....
@Hans Werkzeugkiste:
den 'alten' Zustand werden wir die nächsten Wochen vollends wiederherstellen (soweit noch nicht geschehen)
-
Naja, bei jQuery Sprung von 1.3.2 (WB 2.8.0) auf 1.4.2 (WB 2.8.1) hat sich auch keiner beschwert. Warum soll jetzt genau der Sprung auf 1.4.4 so große Probleme bereiten? Wenn wirklich, dann lässt man es halt beim Alten - so alt ist 1.4.2 nun wirklich nicht. Ist auch wurscht - wer auf Nummer sicher gehen will bindet einfach die jQ Datei extern ein. :evil: Übrigens ist 1.4.3 http://blog.jquery.com/2010/10/16/jquery-143-released/ der "Übeltäter".
Wo wir gerade bei JavaScript sind: FCKEditor sollte wenn er beibehalten wird mind. auf 2.6.6 upgedatet werden.
Zudem: "Fatal Error" hat nichts mit E-Deprecated zu tun. Wollte es nur sagen. Das ist ein ganz anderes Kaliber, und da ist wohl ein eindeutiger Fehler irgendwo. Denn einen Fatal Error sieht jeder, egal welchen Errorlevel man gerade hat.
-
Ich meine da sollte uns Bianca etwas zu sagen können.
Dietmar
-
So damit jeder die gleiche Version testet, haben wir soeben dir 2.8.2 RC2 zum Download freigegeben. Jetzt geht es an die nächsten Fixes.
@Michael
schick mir bitte mal deine Datenbank, bekomme den Fehler mit Anlegen von untergordneten Seiten nicht reproduziert
Dietmar
-
1356 Media-Ordner:
argos_theme: es ist ein Unterschied ob ich Bilder per FTP oder per Media hochlade.
Die Vorschaufunktion zeigt die Farben stark reduziert bei Bildern die über Media hochgeladen wurden.
Auch die Funktion um die Größe der hochgeladenen Bilder zu begrenzen, liefert dann nur Bilder mit geschätzen 16 Farben, aber das Resizing funktioniert (egal ob nur Breite als Wert angegeben wurde oder beides).
-
@Michael
schick mir bitte mal deine Datenbank, bekomme den Fehler mit Anlegen von untergordneten Seiten nicht reproduziert
Ist wie gesagt nur auf Servern, wo PHP nicht in CGI läuft, also FTP / PHP User Unterschied macht - All-Inkl ist hier wohl der übliche. Es gibt natürlich einen Weg drum herum, aber genügend Leute haben halt solche Webspaces.
Werde noch mal mich versichern und dann dir eine Nachricht zukommen lassen.
Edit: Achja -bitte einen Blick auf https://forum.WebsiteBaker.org/index.php/topic,20331.msg137428.html#msg137428
Der Fix zur Validierung von E-Mails in der class.wb.php wäre evtl. auch was.
-
Rev 1357:
Anlegen einer Seite führt zu
Fatal error: Call to a member function checkFTAN() on a non-object in /www/htdocs/***/admin/pages/modify.php on line 27
Neue Installation. Alte Fehler, komischerweise kommt erst die erfolgreiche Bestätigung nach Seitenerstellung.
Anmerkung: Keine alten Fehler - alles wunderbar bei selben Server mit selbem FTP und selber Datenbank. :? Sprich: Dateien werden brav angelegt, dafür halt Ftan. Dietmar hat Mail.
So, noch mehr in Rev 1357:
Pages geht praktisch nicht mehr. Ich spreche von der Seitenübersicht admin/pages/index.php:
1.) Siehe oben.
2.) Klick auf "Optionen" / Verschieben / Löschen der Seiten-> Die Seite konnte nicht gefunden werden
Laut FTP wurde die Accessdatei aber brav mit Code angelegt:
<?php
$page_id = 1;
require("../config.php");
require(WB_PATH."/index.php");
?>3.) Klick auf "Abschnitte verwalten" -> Parse error: syntax error, unexpected '.' in /www/htdocs/***/admin/pages/sections.php on line 249
4.) An alle URLs werden "&" angehängt, also http://***/admin/pages/sections.php?page_id=2&
-
Achja - momentan sind's noch 84 Issues http://project.websitebaker2.org/projects/WebsiteBaker/issues . Wenn sich 8 Leute zusammenraufen hat jeder 10 Issues. Es macht eh keinen Sinn nach 2.8.2 noch welche stehen zu haben - 2.9 wird eh anders und alles, was in 2.8.2 nicht drinnen ist kommt in 2.8.x auch nicht mehr rein, sofern bekannt.
-
Wo kann ich denn die RC2 Laden?
Nur SVN oder habt Ihr auch nen direkten DL ?
-
Auf der Download Seite (http://www.websitebaker2.org/en/download.php)
Dietmar
-
ahhh , ok , hatte auf http://project.websitebaker2.org/ geschaut.
-
ahhh , ok , hatte auf http://project.websitebaker2.org/ geschaut.
Dann lieber gleich die Profis fragen: http://twitter.com/search?q=WebsiteBaker :evil:
Nicht hauen!
-
So, noch mehr in Rev 1357:
Pages geht praktisch nicht mehr. Ich spreche von der Seitenübersicht admin/pages/index.php:
Man soll halt nach ner Feier nicht mehr arbeiten :-(
Wird leider nicht vor heute abend, dass ich mich drum kümmern kann.
-
Pages geht praktisch nicht mehr. Ich spreche von der Seitenübersicht admin/pages/index.php:
kann ich bestätigen, aber erst nach neuinstall. nach update gings noch.
rev wird noch als 1356 angezeigt.
kein problem mehr wegen media: bilder hochladen und anzahl der farben bzw. vorschaubildchen.
-
Man soll halt nach ner Feier nicht mehr arbeiten :-(
Wird leider nicht vor heute abend, dass ich mich drum kümmern kann.
Ist doch nicht schlimm - ist eine SVN, da können auch ohne groß Worte zu verlieren Revisions dabei sein, die eine Bedienung unmöglich machen. Dafür testen wir's ja auch.
-
Hallo,
hab grad die RC2.1 getestet. Da geht das Anlegen der Seiten wieder und auch der FCKEditor ist up to date. :-D
Matthias
-
danke, klappt. CMS Version 2.8.2.RC2 Revision 1359
wo hast du die angabe 2.1 her?
also um aktuell zu beliben muss man sich an die svn halten und nicht an die rc2 im downloadbereich?
-
nochmal media: mit jpg keine probleme,
aber png werden grausig dargestellt als thumb und dadurch auch als hover,
wenn man das bild resizen lässt beim upload, dann ist alles grausig.
-
wo hast du die angabe 2.1 her
Ist die Vorbereitung für die RC3, sonst kommen wir durcheinander. Ist zurzeit ne Menge zu fixen. Wollen ja auch nicht unbedingt jeden Tag die RC erhöhen. Können wir natürlich machen, wenn euch das nichts ausmacht. Ist zwar keine offzielle Bezeichnung, aber wir brauchen einen Bezugspunkt.
Die Datei gibt es auf der Projektseite
Dietmar
-
aber png werden grausig dargestellt als thumb
Ja, da suche ich auch noch eine andere Lösung als die mit overlib.js. Vorschläge willkommen.
Voraussetzungen
Sollte thumbs on the fly erzeugen und Mouseover Image anzeigen.
Dietmar
-
Die Datei gibt es auf der Projektseite
boah, mir wird schwindelig. :-D
es gibt dateien in branches die ich mit tortoise aktualisiere, es gibt ein download auf der projektseite, es gibt ein download auf der downlaodseite.
ich schätze projektseite ist das richtige von den richtigen.
-
boah, mir wird schwindelig
Wenn Dir schon schwindelig wird wo Du ständig am Ball bist wie soll es da anderen gehen. Nach einem Tag nicht am PC habe ich den Überblick auch verloren, stelle so nebenbei fest das es eine RC2 gibt, das SVN sich geändert hat und hier und da noch andere Downloads rum schwirren.
Nur der Profi beherrscht das Chaos.
Ist es nicht möglich einen ordentlichen Ankündigungs-Thread zu führen wo man immer auf dem Stand der Dinge ist wenn man den verfolgt?
-
Ich finde das Chaos schade, gerade weil ich gestern noch einige Mails zu Dietmar geschickt hab, wo ich gerade das Bemängelt habe - aber jut, so isses.
Zum Image Resize: Sowas macht man mit PHP, nicht mit JavaScript. Ein gutes Framework dazu gibt es hier: http://phpthumb.gxdlabs.com/
Den Mouseover kann man ganz einfach machen, indem man auf das Erstellte Thumb verweist. Overlib wird seit 2005 nicht mehr aktualisiert. Sogar das geht ohne JavaScript: http://www.dynamicdrive.com/style/csslibrary/item/css-popup-image-viewer/P10/
-
Damit auch Freude aufkommt: SM2 Version 4.9.5 ist auch janz frisch aufm Tisch.
-
Damit auch Freude aufkommt: SM2 Version 4.9.5 ist auch janz frisch aufm Tisch.
Jo. Allerdings bitte wieder PHP 5.2.2 in den Header aufnehmen.
http://project.websitebaker2.org/projects/WebsiteBaker/repository/revisions/1360/diff/branches/2.8.x/wb/modules/show_menu2/index.php
-
Ist doch nicht schlimm - ist eine SVN, da können auch ohne groß Worte zu verlieren Revisions dabei sein, die eine Bedienung unmöglich machen.
dazu wikipedia
Ein Release Candidate (RC) (auf Deutsch: Freigabekandidat), gelegentlich auch als Prerelease (auf Deutsch etwa: Vorabveröffentlichu ng) bezeichnet, ist eine abschließende Testversion einer Software. Darin sind alle Funktionen, die die endgültige Version der Software enthalten soll, schon verfügbar (sogenannter feature complete), alle bis dahin bekannten Fehler sind behoben. Aus dem Release Candidate wird vor der Veröffentlichung die endgültige Version erstellt, um einen abschließenden Produkttest oder Systemtest durchzuführen. Dabei wird die Qualität der Software überprüft und nach verbleibenden Programmfehlern gesucht.
-
Ist doch nicht schlimm - ist eine SVN, da können auch ohne groß Worte zu verlieren Revisions dabei sein, die eine Bedienung unmöglich machen.
dazu wikipedia
Ja, allerdings ist in "Release Candidate" kein V enthalten und zudem kein großes S und kein großes N, da sollte selbst der Internetausdrucker drauf kommen, dass das nicht dasselbe ist wie eine SVN.
-
Waru, sih überh'upt noch an S+andards halten?
Ohne ist das Leben doch viel aufregender.
Janz schön schräg hier.
-
Um was geht es denn hier?
Um den Test der RC2 oder um einen SVN Test?
Bis jetzt ergab sich mir der Eindruck das hier die RC2 getestet werden soll und nicht eine SVN Version und dann ist Deine Aussage schlichtweg falsch.
Ich finde das Chaos schade,
Trägst aber durch Deine Aussagen noch dazu bei.
-
Um den Test der RC2 oder um einen SVN Test?
Es steht geschrieben RC2
Da es sich aber aufgrund des Zustands um eine SVN handelt. darf sich jeder was aussuchen:
Canon oder Fundi kann noch nicht einmal die Frage lauten.
Wer's pragmatisch mag, macht die Augen zu und durch.
-
Um was geht es denn hier?
Bevor du wiedermal deinen Senf abliefern musstest um das Testen von WB 2.8.2 RC, die es hier gibt: http://www.websitebaker2.org/de/download/neueste-version.php
Es gibt die Version RC und die Version RC2, fertig. Ich möchte zeitnah testen und achte daher nicht auf RCs - aber das muss mir keiner nachmachen. Aber wenn du so fleißig mit dem Testen bist, dann lass deine Ergebnisse doch hören von der RC2.
-
Der "Fehler" liegt doch aber viel weiter vorne, wenn man da wikipedia zu Rate zieht:
http://de.wikipedia.org/wiki/Entwicklungsstadium_%28Software%29
Darin sind alle Funktionen, die die endgültige Version der Software enthalten soll, schon verfügbar (sogenannter feature complete), alle bis dahin bekannten Fehler sind behoben.
Solange im Projekt noch 75 Bugs stehen
http://project.websitebaker2.org/projects/WebsiteBaker
braucht man gar keinen RC rausgeben.
Dazu gehört auch, dass alle Module, die mit ausgeliefert werden sollen, auf dem neuesten Stand sind, oder eben dem Stand, den man auch veröffentlichen will.
Wenn da so weiter praktiziert wird, dann ist nicht nur Chaos, sondern dann wird die Version 2.8.2 schlechter sein als die 2.8.1.
Und die letzen verbliebenen Tester sind dann auch noch vergrault.
Und von den Ankündigungen für einen RC auch auf der Homepage will ich gar nicht reden. Da scheint im Moment ja eh eine sprachliche Unterscheidung Einzug gehalten zu haben.
Und auch da gilt: weniger ist mehr. Wenn man drei Sprachen nicht pflegen kann, muss man wohl etwas tun.
Auf alle Fälle sollte Englisch "führende" Sprache sein, wenn man international sein will.
Offenbar wird das bei den Offiziellen ja anders beurteilt.
Schade.
-
Anbei als .zip der PHPMailer für PHP 5. WB 2.8.2 unterstützt ja nur > 5.2, daher kann man den "modernen" verwenden. Klappt bei mir wunderbar. Einfach /include/phpmailer austauschen.
[gelöscht durch Administrator]
-
das modul droplets lässt sich hier nicht updaten auf version 1.51. belibt immer bei der alten.
1.51 sollte standard sein.
das enthaltene droplet lorem ist veraltet, meldet undefinierte variable blocks. da gibts schon was neueres, ohne das man anzahl blocks angeben muss.
-
Jetzt will ich doch grade mal die Motivation derer loben, die hier grade an der Arbeit sind und anbieten das ich zum testen einen Webspace mit PHP als Apache Modul zur Verfügung stellen kann wenn es gebraucht wird .
Leider kann ich grade nicht gut testen, da ich im Krankenhaus sitze und drauf warte Vater zu werden.
Die erbärmliche GPRS Leitung die ich hier habe spuckt grade male 36k aus :-(
Wenn der Webspace mit PHP als Apachemodul gebraucht wird PM an mich.
Achso, die Meckerfritzen mit dem Versionstick bitte einfach löschen.
-
Ich meine da sollte uns Bianca etwas zu sagen können.
Hab ich doch schon.
Im Übrigen würde ich dann nur wieder sagen, daß jQuery als Modul installiert werden sollte, nicht als include, und das will ja wieder keiner hören. Ich stelle in Kürze ein solches - nur jQuery Core und UI, ohne jQueryAdmin - zur Verfügung.
Edit: jQuery und jQuery UI als Library Modul ohne die Funktionalität von jQueryAdmin gibt's jetzt hier: http://www.websitebakers.com/pages/libs/lib_jquery.php
Probleme mit der Alpha bitte bevorzugt im jQuery Showroom Forum.
Das Modul ist für die Verwendung mit dem neuen LibraryAdmin Modul vorbereitet, erfordern dieses aber nicht zwangsläufig. Die dafür enthaltenen Komponenten sind sehr klein und stören nicht weiter.
-
das modul droplets lässt sich hier nicht updaten auf version 1.51. belibt immer bei der alten.
Das gilt für alle Module, die eine dreiteilige Versionsnummer haben. (Also wie Droplets v1.0.2) Das ist ein grundsätzlicher Fehler, der mal behoben gehört.
-
... Das gilt für alle Module, die eine dreiteilige Versionsnummer haben. (Also wie Droplets v1.0.2) Das ist ein grundsätzlicher Fehler, der mal behoben gehört. ...
Ist im neuen Upgrader der 2.9.x bereits behoben. Wird vermutlich Mitte/Ende nächster Woche kommen, wenn mir Job und Familie wieder etwas mehr Zeit lassen.
-
Die Verwendung von WB_URL scheint mit nicht unbedingt sinnvoll zu sein.
Mein Rechner kann nur über ipv6 Bzw. über ein Gateway welches die IPv4 Anfragen/Antworten zur/vom ipv4 Rechner weiterleitet.
Da die URL für der Zugriff aus dem Internet anders lautet als für den lokalen finktionniert das ganzes nicht.
Auf WB_URL sollte verzichtet werden!
-
Da dürfte wohl ein kleines Missverständnis oder aber eine Fehlkonfiguration des Gateways vorliegen.
Eine URL z.B.: http://www.example.com/ hat absolut nichts mit IPv6/IPv4 zu tun.
Erst ein DNS-Server wandelt die 'human readable' URL in die zugehörende IP um.
Wäre es anders, wäre ja plötzlich kein IPv6-Server mehr über seine Domain erreichbar.
-
Die Verwendung von WB_URL scheint mit nicht unbedingt sinnvoll zu sein.
Mein Rechner kann nur über ipv6 Bzw. über ein Gateway welches die IPv4 Anfragen/Antworten zur/vom ipv4 Rechner weiterleitet.
Da dürfte wohl ein kleines Missverständnis oder aber eine Fehlkonfiguration des Gateways vorliegen....
Der Gateway wird von Sixxs.org betrieben und er leitet nur HTTP Anfragen/Antworten weiter. Wenn im Html Code "http://www.example.org/media/bild.jpg" steht, wird diese Datei vom Server mit Name www.example.org geholt und nicht von "[ipv6-alias].ipv4.sixxs.org". Würde anstelle von
"http://www.example.org" "" in WB_URL stehen gäbe es kein Problem (ich habe in der config.php Datei WB_URL korrigiert es ist aber nicht im Sinn des Erfinders solche Korrekturen zu erzwingen.
An manche Stellen mag eine URL OK sein aber nicht an alle.
Grüße,
Jean-Jacques
-
Ähhh,
Der Gateway wird von Sixxs.org betrieben und er leitet nur HTTP Anfragen/Antworten weiter. Wenn im Html Code "http://www.example.org/media/bild.jpg" steht, wird diese Datei vom Server mit Name www.example.org geholt und nicht von "[ipv6-alias].ipv4.sixxs.org". Würde anstelle von
"http://www.example.org" "" in WB_URL stehen gäbe es kein Problem
Also wenn ich die sehr unklaren Aussagen richtig verstanden habe meinst Du relative Links funktionieren, absolute nicht? Und deswegen hast du WB_URL auf "" gestellt?
Wenn dem So ist, ist definitiv etwas mit deiner Verbindung zum Internet nicht in Ordnung.
Wer befindet sich jetzt eigentlich hinter dem Gateway, Du oder Dein Webserver?
(ich habe in der config.php Datei WB_URL korrigiert es ist aber nicht im Sinn des Erfinders solche Korrekturen zu erzwingen. An manche Stellen mag eine URL OK sein aber nicht an alle.
Wenn Du oder dein Webserver sich in einem seltsamen internen Netzwerk befinden ist es garantiert nicht Aufgabe eines CMS die Einschränkungen dieses Netzes zu kompensieren. Und relative sowie absolute Links sind ganz normaler Bestandteil der allermeisten HTML Seiten. Also soll sich das ganze Internet an deine speziellen Probleme anpassen?
Zum Schluss noch was erfreuliches, soweit ich die DEFs verstanden habe wird WB 2.9 verstärkt auf relative Links setzen.
-
Ich wohne in ein Ort weit ab von jeder DSL Anschluss. Deswegen werden wir von ein kleinen Provider versorgt, welches natürlich Port-Weiterleitungen u.s.w. nicht unterstützt. Damit bin ich auf ein Tunnel angewiesen. IPv6 über Sixxs ist dafür die Lösung. Wenn auf mein Rechner aus den IPv4 Netz zurückgegriffen wird, muss ein von Sixxs gehaltenen Gateway bemüht werden.
Das Effekt mit der in der Quelle enthaltenen URL (http://...) wird sich in Zukunft, da IPv6 neben IPv4 erst mal ko-existieren wird, des öfteren bemerkbar machen. Interne Links sollten immer als absoluten (/media) oder relativen Pfad (media) angegeben werden.
Auch unter einen reinen IPv4 Betrieb können Nebeneffekte auftreten. Angenommen, dass die Präsenz sowohl unter http://example.uk wie unter http://beispeil.de erreichbar ist, sollten alle Anfragen an der richtige URL gerichtet werden.
In mod_multilingual lang function.php steht beispielsweise;
function get_page_url( $langPageArray )
{
global $database;
$return_value = strtolower(WB_URL.PAGES_DIRECTORY.'/'.strtolower(LANGUAGE).PAGE_EXTENSION);
Dies sorgt für eine Umschaltung von z. B. example.uk nach beispiel.de !
-
Jetzt wird das Bild langsam klarer. du mußt aber zugeben das ist keine alltägliche Lösung.
Du hast sicherlich auch die Forensuche genutzt und dabei festgestellt das diesen Problem bei noch keinem anderen aufgetreten ist . Leider ist es bei so etwas speziellem ziemlich schwer sich ein Bild zu machen ohne genaue Informationen.
Deswegen weiter nachgefragt:
Ihr befindet euch hinter den Konstrukt aus Provider und Tunnel, wo steht der Webserver?
Der Provider unterstützt keine Portweiterleitung.. ., aber er muss doch normales Internet unterstützen, sonst wär es doch kein Provider? Also ganz normales Http Protokoll?
Kurze Klarstellung,
Absolute URL/Pfad: http://meinedomain.com/bilder/schoenesbild.jpg
Relative URL/Pfad : /bilder/schoenesbild.jpg
Wenn also z.B. Bilder in der Seite über eine absolute URL aufgerufen werden werden Sie nicht angezeigt aber über eine relative werden sie geladen? Wenn dem so ist, müsste das Problem auch bei anderen Seiten Auftreten.
Wenn ein kleiner Eingriff in eine Config Datei das Problem löst , wo ist dann das Problem?
Mit WB_URL = "" funktioniert WB auch ganz brauchbar? Ich glaube Chio hat letztens noch irgendwo gepostet das er das auch macht weil er keine lust hat im WYSIWYG Editor die Pfade immer von Hand auf relativ umzustellen.
----------------------------------------------------------------------------------------
Zu deinem IP4 Beispiel, das ist eigentlich eine andere Baustelle.
Zuerst mal wenn eine Seite unter mehreren Domains erreichbar ist , geht man normalerweise hin und erstellt eine .htaccess Datei in der man alle diese Domains mit einem 301 Redirect auf die Hauptdomain weiterleitet (Das geht auch mit PHP). Einer der Hauptgründe ist damit die Suchmaschinen nicht glauben sie hätten mehrere Seiten mit gleichem Inhalt vor sich und dann anfangen die Seiten abzustrafen. Ein Weiterer ist , das viele CMS die nicht explizit für Multidomainbetrieb ausgelegt sind es nicht besonders mögen wenn sie unter mehreren Domains angesprochen werden, und dann im günstigsten Fall das gleiche tun wie WB und alle Links auf die Hauptdomain verweisen.
Bei WB kann man wenn man Ihn Multidomain tauglich haben möchte auch folgendes in die config.php eintragen:
define('WB_PATH', dirname(__FILE__));
define('WB_URL', "http://$_SERVER[SERVER_NAME]");
define('ADMIN_PATH', WB_PATH.'/admin');
define('ADMIN_URL', "http://$_SERVER[SERVER_NAME]/admin");Mit noch ein paar weiteren kleinen Tricks kann man WB dann auch beibringen bei jeder Domain was anderes Anzuzeigen. Aber prinzipiell kann man WB dann von einer beliebigen Domain aus aufrufen, und er bleibt auch da.
Wenn dein Problem eine fehlende Möglichkeit zur 301 Weiterleitung ist kann ich dir auch kurz die entsprechenden PHP Zeilen raussuchen, sowas mußte ich letztens noch verwenden.
Und nochmal gesagt, mit 2.9 soll dann alles weitestgehend auf relative Pfade umgestellt werden.
Nachtrag: Schon mal geschaut ob bei euch Mobiles Internet verfügbar ist, teurer als Normales ist es auch nicht mehr wirklich und die Geschwindigkeit ist auch nicht schlecht. Und bei Problemfällen kann man auch noch mit einer Richtantenne nachhelfen.
-
du mußt aber zugeben das ist keine alltägliche Lösung.
Es ist kein Lösung es ist ein problematisches Netzaufbau.
Du hast sicherlich auch die Forensuche
Nachgeschaut habe ich nicht, erst das Problem erkannt und gefixt dann gepostet.
Ihr befindet euch hinter den Konstrukt aus Provider und Tunnel, wo steht der Webserver?
Der "server" ist mein Rechner. Von Zeit zur Zeit publiziere ich etwas für ein oder mehreren Bekannten, z.B. Aufbau eine zukünftige Internet Seite.
Der Provider unterstützt keine Portweiterleitung.. ., aber er muss doch normales Internet unterstützen, sonst wär es doch kein Provider? Also ganz normales Http Protokoll?
Port-Weiterleitung bedeutet, dass der Router am DSL Anschluss Anfragen (von außen) die an ein bestimmten Port ankommen an ein dedizierte Adresse (Rechner) weiterleitet. An sonsten ist der Provider nicht wirklich eine Firma wir T-Kom. 1und1, ... Er versorgt mehrere Dörfer per WLAN. Natürlich ist das Netz so geschützt, dass eine Interaktion mit den Nachbar nicht möglich ist.
Kurze Klarstellung,
Absolute URL/Pfad: http://meinedomain.com/bilder/schoenesbild.jpg
Relative URL/Pfad : /bilder/schoenesbild.jpg
Klarstellung:
URL : http://meinedomain.com/bilder/schoenesbild.jpg
Absoluten Pfad : /bilder/schoenesbild.jpg
Relative Pfad : bilder/schoenesbild.jpg
Das 2.9 auf Pfade (nicht falsch genannten "relative URL") hatte ich vernommen.
Ich befasse mich seit einige Jahren mit IPv6 und verfolge was da alles passiert. Heise hat seine Seiten auf Dual Stack umgestellt. Einige Arbeiten waren aber, damit es Tadel los funktioniert, notwendig. Nach meine Erfahrungen können URL zu Probleme führen wenn eine Seite sowohl über
IPv6 wie über IPv4 erreichbar sind und dafür eine anders lautende URL Besitzen (www.beispiel.net, ipv6.beispiel.net). Die Verwendung von URL innerhalb von WB basiert wahrscheinlich auf Bequemlichkeit.
Nachtrag: Schon mal geschaut ob bei euch Mobiles Internet verfügbar ist, teurer als Normales ist es auch nicht mehr wirklich und die Geschwindigkeit ist auch nicht schlecht. Und bei Problemfällen kann man auch noch mit einer Richtantenne nachhelfen.
Geht leider nicht so gut, der Empfang ist am Wohnort sehr berauschend (zu geringen Empfangspegel). Außerdem erhält das Empfangsteil eine private Adresse (10.xxx.xxx.xxx). ich müsste wieder ein Tunnel aufbauen.
-
Warum nicht gleich so deutlich. Dann hätte die Antwort direkt geheißen wird in schon 2.9 dran gearbeitet , 2.8.2 bekommt das Standardmäßig nicht mehr da eigentlich nur Bugfix Release.
Die Verwendung von URL innerhalb von WB basiert wahrscheinlich auf Bequemlichkeit.Eher darauf das der Core richtig alt ist und ursprünglich mal dazu gedacht war mal irgendwie fix ne Seite zu machen, das die Devs im Moment ziemlich mit Sicherheitslücken beschäftigt sind und vor allem darauf das noch niemand außer Dir damit ein Problem hatte. :lol: Darum schlage ich vor das du dir mal die 2.9 vornimmst und wenn du da noch Restbestände dieser Art findest, die Patches gleich an Luisehahne schickst :-D
Meine persönliche Meinung ist, Deine Verbindung ist für Serverbetrieb schlicht ungeeignet.
Die Lösung über einen ipv6 Tunnel zu gehen ist wunderschön kreativ aber im höchsten Maße experimentell. Besorge Dir doch einfach für 2-5 Euro im Monat einen Webspace, ja selbst die meisten Freespace Provider sollte ausreichen.
Was passiert eigentlich wenn Du "[ipv6-alias].ipv4.sixxs.org" also die Adresse unter der der Außenstehende deine Seite erreichen soll in der der WB_URL einträgst?
-
Meine persönliche Meinung ist, Deine Verbindung ist für Serverbetrieb schlicht ungeeignet.
Die Lösung über einen ipv6 Tunnel zu gehen ist wunderschön kreativ aber im höchsten Maße experimentell. Besorge Dir doch einfach für 2-5 Euro im Monat einen Webspace, ja selbst die meisten Freespace Provider sollte ausreichen.
Ich habe nie geschrieben, dass mein Rechner ein Server ist, bestenfalls "Server". Das Angebot richtet sich nicht an der Allgemeinheit aber sporadisch an bestimmte Personen. Ein Webspace ist mit Sicherheit auch nicht die Lösung. Für 2-5 Euro habe ich nur ein virtuellen Bereich und kein Server bei dem ich alles machen kann was ich will, zudem dürfte IPv6 bei solche Angebote nicht erhältlich sein und ich will auf jeden Fall auch eine IPv6 Erreichbarkeit haben.
-
Einer der Hauptgründe ist damit die Suchmaschinen nicht glauben sie hätten mehrere Seiten mit gleichem Inhalt vor sich und dann anfangen die Seiten abzustrafen.
Die Internetseite meiner Gemeinde ist zu erreichen über [www].xxx.eu [www].xxx.de [www].xxx.com. Innerhalb des Angebotes werden URL nur für externe Angebote verwendet. Die Suchmaschinen kommen damit klar, sie scannen nicht alle Domäne aber jeweils nur 1.
-
[OT]
Ganz ehrlich, einen "Server" oder Server mal eben so zu Hause stehen zu haben für ein Internetangebot ist mehr als fragwürdig. Finanziell lohnt sich das nie. Was ist, wenn der Strom ausfällt, die Festplatte abraucht oder man in den Urlaub fährt? Dann kommt dazu die Hardware, der Stromverbrauch... Und gescheite V-Server (muss ja kein physischer Rootserver sein) gibt's für 7-15 Euro / Monat. Gar nicht davon zu sprechen, dass die Transferraten in ganz anderen Ligen spielen. Und IPv6 ist ein so heißes Thema, da möchte ich lieber erst gar nicht drüber reden, weil das egal in welchem Forum grundsätzlich immer in sog. "Flamewars" endet.
[/OT]
-
Könnt Ihr den Scheiss in einem anderen Thread abhandeln.......... ..
Es hat nichts, aber auch nichts mit WB zu tun, außer, daß eine nicht ordnungemäßes Fowrwarding oder Adress Transl. oder Tunnel oder der Serverbetrieb oder DNS oder sonstiges hausgemachtes Problem am nicht funktionierenden Betrieb beteiligt ist.
Es sind mittlerweile zig Threads mit diversen Anliegen bzgl 2.8.2 offen.
Kommt jetzt auch noch das Zumüllen dazu?
Forenoberpenner und Zwangsneurotiker kümmern sich doch sonst um jeden Scheiß.
-
Alle 2.8.2er Threads dicht machen, einen einzigen mit gescheitem Eingangspost aufmachen / weiterführen, fertig. Es gibt noch einige Anregungen und Probleme, die mittlerweile verloren gegangen sind.
Und bitte nicht mergen. Hans>NUL ist ja wieder da. :evil:
-
Hans>NUL ist ja wieder da.
<offtopic>
Man weiß noch nicht ob's die gespaltene Persönlichkeit oder das Tourette-Syndrom war. Jedenfalls ist es immer der andere. Das kennen gesunde Deutsche auch, oder sind die alle krank?
Außerdem: "Das muß man doch in D. noch sagen dürfen" :-D
Aber mit dem "Rauslassen/Ausflippen" soll es jetzt auch wieder gut sein. Bin wieder ganz brav.
</offtopic>
-
[OT]
Ganz ehrlich, einen "Server" oder Server mal eben so zu Hause stehen zu haben für ein Internetangebot ist mehr als fragwürdig.
[/OT]
Ich gebe Dir rechts, ein richtigen Server daheim ist fragwürdig wenn die Voraussetzungen nicht angemessen sind. Mein "Server" dient zur Entwicklung und das Begutachten eine Korrektur ist schneller geschehen wenn das Sichern einer Datei und der erneuten Aufruf eine Seite im Browser
geschieht. Das Hochladen, ... würde mehr Zeit in Anspruch nehmen. Bei sehr sporadische Zugriffsnotwendigke it auf den Rechner ( vielleicht 1x jede 2 Monate) ist die Lösung durchaus angebracht zumal die Seiten nicht öffentlich sind.
Das Thema war eigentlich die Verwendung von Hart kodierte URL anstelle von Pfade (die fälschlicherweise als relative URL hier genannt wurden). Ein Fall wo so etwas auch zu Problemen führen kann ist wenn eine besuchte Seite vom Browser aus gespeichert wird, der Besucher hat eine teure Internetverbindung, speichert einige Nachrichten-Seiten zur späteren Begutachtung und schließt die Verbindung. Wenn die css Dateien, etwaige Bilder nur über URL erreichbar sind, wird der Anwender nur unvollständige Informationen erhalten (Browser file::///heruntergelade-nachrichten/nachricht1.html). In WB 2.9 wird es wie von DarkViper geschrieben und laut momentanen SVN Code besser. Bei der Version 2.8.2 werden nach wie vor, intern, URL verwendet.
-
Und die letzen verbliebenen Tester sind dann auch noch vergrault.
Wer testet denn hier überhaupt?
Habe den Eindruck, daß hier nichts passiert -im Gegensatz zu früheren Versionen.
Da ich i.M. noch keine Zeit habe, hat heute mal einer meiner Anwender mit SM2 "rumgespielt"
Nach seinem Eindruck funktioniert das Teil nicht richtig, speziell in den Kombinationen mit dem xhtml-Flag.
Vielleicht kann das ja jemand mal checken, also nicht nur [a][menu_title] sondern auch [ac][menu_title] sowie mit .........[a][menu_title] [/a]</span>
Auf frühere Fehlermeldungen und Anregungen (target/menu-titel/page-titel) zu SM2 wurde bisher auch nicht reagiert.
Mir drängt sich auf, daß derartige Threads nur noch als Labertonne aufgemacht werden, damit's 'nen bewegten Eindruck macht.
Der ursprüngliche Thread allein für Testergebnisse wird überhaupt nicht mehr frequentiert.
Stattdessen Verzettelei. Prima, macht weiter so.
-
Wer testet denn hier überhaupt?
Meine WebsiteBaker.net läuft komplett auf der neuesten svn der 2.8.2, es gibt eine weitere online sowie eine locale Testinstallation.
Meine Ergebnisse gehen jedoch direkt per Skype ins "Headquarter".
Ob sie hier in solchen Threads untergehen oder ob ich sie meinem Friseur erzähle hat ungefähr den gleichen Effekt. :-D
-
Auf frühere Fehlermeldungen und Anregungen (target/menu-titel/page-titel) zu SM2 wurde bisher auch nicht reagiert.
Wurde sehr wohl, ist aber OffTopic, da 2.9.dev - 2.8.2 ist nur die Fehlerbereinigung wie wir alle wissen.
Lassen wir doch endlich mal bitte SM2 so stehen wie es ist und machen in der nächsten Version etwas erweitertes - ist ja nicht mehr zum Aushalten mit den Verschlimmbesserung en an SM2 - kein Wunder, dass immer wieder Stimmen lautwerden die sagen "Ich nehm lieber das alte Show_Menu, da weiß ich wenigstens was ich hab". Das Ding (also sm2) läuft bei 99,5% aller Anwender wie am Schnürchen, warum sollte man wegen 0,5% die anderen alle mit dem Ofenrohr ins Gebirge gucken lassen.
Und im übrigen wär's evtl. sinnvoll, einmal wirklich die anderen Threads dichtzumachen und einen, wo wirklich nur Vorschläge / Bugreports reinkommen mit Stand RC5. Eigentlich sollte so etwas ja gleich im Bugtracker stattfinden (Übersicht ist das Thema) anstatt in einem Forum, aber egal.
-
Wie so oft laberst Du am Thema vorbei, anscheinend ganz mit Absicht. So doof kann man nicht wirklich sein.
Die früheren, wie die jetzt gemeldeten möglichen Fehler, beziehen sich auf die aktuelle Version von SM2 und auf WB 2.8.2
Wir befinden uns doch in "WebsiteBaker 2.8.2 RC - Tests und Vorschläge", oder?
Außerdem wird die aktuelle SM2-Version in WB 2.8.2 UND 2.9 verwendet und mitgeliefert.
Die Laberei um "...99,5% aller Anwender wie am Schnürchen" ist auch ein sich wiederholendes Beispiel Deiner etwas kruden Wahrnehmung. Erst mit der Entwicklung von WB 2.8.2 hin zu WB 2.9dev wurden die neue SM2-Versionen herausgegeben. Dieses SM2 existiert somit überhaupt nicht in den aktuell laufenden WB 2.8.1-Installationen, außer man hat sich eines -wegen des xhtml-Flags- aus 2.9.dev gezogen. Die neuen Flags wurden von diesen "99,5%" also überhaupt nicht getestet. Die gemeldeten Ungereimtheiten bzw. Fehler bezogen sich aber ausschließlich auf die neuen Flags.
Nur ein oder zwei Optionen/Flags des SM2 werden in WB 2.8.2 (gegenüber 2.9dev) genutzt, so zumindest mein momentaner Wissensstand, die man nutzen könnte. Diese scheinen nach Aussagen im Forum oder auch anderen Rückmeldungen aber nicht "wie gewünscht" zu funktionieren. Ob nun Fehler oder "nur" Kommunikationsbedar f, für eine Klärung war bisher das Forum da und nicht der Bugtracker.
Man könnte es also beim "alten SM2" aus WB2.8.1 belassen, oder den Kommunikationsbedar f bzgl. der neuen Version decken, wenn denn überhaupt noch jemand daran interessiert ist. Der Eindruck vom Störenfried User kommt mttlerweile -auch bei mir- sehr gelegen her.
Alternative, falls SM2 nicht wie gewünscht funktioniert: Eine eigene leicht abgeänderte Version für WB 2.8.2 verwenden.
Den Kommentar zum Rest Deiner Nachricht erspare ich mir, da Du selbst beim aktuellen Chaos von zig Threads zu WB2.8.2 ff involviert bist. Einen Dialog mit Dir führen zu wollen, ist längst abgeschrieben. Erzähl es Deinem Friseur un jut is.
-
Laut meinem Wissensstand lautet die Changelog der 2.9.5er Show_menu2
4.9.5 (28 Dec 2010, 2.8 Rev. 1360)
Added [tooltip].
4.9.3 (23 Jul 2010, 2.8 Rev. 1313)
Adding install.php, upgrade.php for manual installion of show_menu2.
4.9.2 (23 Jul 2010)
Introducing SM2_XHTML_STRICT and SM2_NO_TITLE. Adding [menu_icon_0], [menu_icon_1 and [page_icon]. New conditional replacement "target".
4.9.1 (11 Apr 2010, 2.8 Rev. 1313)
Remove unneeded code for WB < 2.7
4.9 (10 Aug 2009)
Partially redacted the change introduced in 4.8. Now hidden pages are shown when active only if the SM2_SHOWHIDDEN flag is supplied. The default behaviour should be the same as 4.7
(Es war nicht einfach, das zusammenzusuchen, aber kommt ja in den nächsten Tagen auf die offizielle Webseite).
Wo kann man also SM2_XHTML_STRICT, SM2_NO_TITLE, [menu_icon_0] usw. nicht benutzen? Wer es einbaut in den PHP-Code kann es doch - wie gehabt - benutzen, oder irre ich da? Und für neue Felder in den Seitenoptionen hab ich schon genug ausführliches im 2.9er Forum geschrieben, da ich den Gang "mehr ist mehr" für grundsätzlich falsch halte.
-
Dank für die erarbeitete Liste
Aus der Erinnerung der PM mit DEV:
Einige Flags sind erst in WB 2.9 nutzbar, sollen aber die Nutzung unter WB2.8.1/2 nicht stören (abwärtskompatibel)
Ab 4.9.2 (23 Jul 2010) waren die entsprechenden Flags über die wir hier reden verfügbar.
SM2_XHTML_STRICT/SM2_NO_TITLE soll in WB2.8.1/2 nutzbar sein, wobei hier (WB-Versionsabhängig 2.8.0-2.8.1 [inkl. 2.8.2r1468]) Fehler/Konflikte/Ungereimtheiten auftreten sollen.
Da nicht nur ich selbst sondern auch andere User auf diese (ich selbst habe es nur mit einer einzigen WB-Version getestet) gestoßen sind, wäre das ausgiebige Testen (Kombinationen) wünschenswert.
Da aber SM2 zu den nicht gerade geliebten Testobjekten zählt, wird es wohl schwierig.
Leider geht bei mir z.Z. gar nix mehr; keine Sec.Audits, keine Modul-Checks, absolut nix.
Erst im Februar wird es wieder ein Zeitfenster geben -ja wir sind im All
-
Leider geht bei mir z.Z. gar nix mehr; keine Sec.Audits, keine Modul-Checks, absolut nix.
Erst im Februar wird es wieder ein Zeitfenster geben
Das ist aber schade :-o
Ich habe nun erst mal alle gemeldeten Sicherheitslücken gefixt, und es wird nicht lange dauern, bis es die RC6 gibt, die dann auch wirklich ein echter Release Candidate ist. Da werden natürlich jede Menge engagierter Tester gebraucht.
-
Ein User meldete mir noch einen schwerwiegenden Bug.
Wenn man im Medien Ordner einen Ordner löscht und kurz darauf (oder während dessen?) den Back-Button des Browsers betätigt, wird der nächste Ordner in der Reihe gelöscht.
Ich habe es aus Zeitmangel nicht geprüft.
Vielleicht hat jemand ein paar Ordner, an denen er es ausprobieren will :-D
Gruß,
Stefek
-
Ein User meldete mir noch einen schwerwiegenden Bug.
Wenn man im Medien Ordner einen Ordner löscht und kurz darauf (oder während dessen?) den Back-Button des Browsers betätigt, wird der nächste Ordner in der Reihe gelöscht.
das sollte sich mit dem Einbau der FTAN erledigt haben, da die u.A. auch Kommandowiederholun gen verhindert.
-
Ich verstehe.
Danke für die schnelle Erklärung.
Gruß,
Stefek
-
Das ist aber schade
Bis Februar is ja nicht mehr lang hin, und "so zwischendurch" gab es immer wieder mal 'nen Abend oder Kaffeenachmittag, der sich nutzen ließ. Einen möglicherweise letzten RC im Schnelldurchlauf zu verabschieden kann es aber auch nicht sein, auch wenn's juckt :roll:
Bei derartigen Verlautbarungen/Versuchungen regt sich das gesunde Mißtrauen :evil:
So'n Sec.Audit kann übrigens nicht die Sicherheitslücken aufdecken, die sich mit der Verwendung irgend eines Moduls ergeben. Die Teile prüfen auf externe Einflußmöglichkeite n inkl. unter maroder Serverumgebung, aber nicht auf hausgemachte Türöffner oder Nachschlüssel.
Eine Codeanalyse wäre der Hit, die aber kaum jemand wird bezahlen können, wobei sowas auch ein rein akademisches Anliegen sein kann und der Praxis dann nix bringt. Ist bei IT'lern wohl kaum anders als in anderen Fachbereichen. Möglich ist auch, daß jemand meint, der Fußboden im Elfenbeinturm müßte mal wieder gefegt werden. :-D
-
Ein echter Audit vom Profi kostet halb so viel wie der neue A1 - natürlich die Vergünstigungen für OpenSource usw. eingerechnet.
Wie schon mal gesagt - wenn es eine "echte" RC gibt kurz vorher anhalten, wirkliche Statements raushauen so viel es gibt und dann wirklich herangehen "es wird nichts mehr geändert, außer ein fundamentaler Fehler ist vorhanden". Dafür natürlich mind. 7 Tage, besser 10 warten.
Ganz sinnvoll wäre hierfür ein Plan wie ihn z.B. Mozilla hat: https://wiki.mozilla.org/Releases/Firefox_4.0b8 (Ich gebe zu, dass die viel reden und ihn alle zwei Jahre mal einhalten, aber das muss man dann ja nicht kopieren).
-
, dass die viel reden ..., aber das muss man dann ja nicht kopieren.
der ist richtig gut...you make my day
-
So wie im Moment Stand der Dinge ist, wird die kommende RC6 die letzte vor stable sein, wenn nicht noch fundamentale Fehler festgestellt werden. Wir prüfen gerade nochmal, ob die Liste von Secunia durchgearbeitet ist.
Bis zur RC6 dürfte es nicht mehr lange dauern. Wir halten euch auf dem Laufenden.
Dietmar
-
Eine Codeanalyse wäre der Hit, die aber kaum jemand wird bezahlen können,
Ja bezahlt wir hier nichts, aber deswegen habe ich mir den Code trotzdem angeschaut und auf diesem Wege auch eine ganze Reihe Löcher gefunden, die keiner gemeldet hat. Wobei ich mir sicher bin, daß da noch welche sein können, weil ich auch nicht jede Zeile angesehen habe.
-
Was noch fehlt sind upgedatete Sprachdateien (Norwegisch, Russisch und Deutsch).
Zudem gibt's in der DE.php auch noch
$MESSAGE['GENERIC_WEBSITE_LOCKED'] = 'Diese Seite ist für Wartungsarbeiten vorübergehend geschlossen';
Das "ü" sollte bestimmt ein HTML-Charakter sein - sonst gibt's nur Probleme.
Zudem würde ich vorschlagen, vor einer "letzten" RC den Bugtracker komplett auf 0 herunterzubringen.
Dafür gibt's eine neue Resolution "booked for 2.9" - vorgemerkt für 2.9.
Ganz nebenbei gibt's übrigens auch neue Sprachdateien wie z.B. Romanian (Rumänisch) im Sprachen-Unterforum. Es muss nur gesagt werden, dass Interesse besteht an den Sachen (das Gegenteil wäre auch töricht), dann kann man die gerne testen und anpassen.
Und zu guter Letzt denke ich ist es ja "beschlossen", dass die Installation und das Argos-Theme noch etwas angepasst wird, oder? Nur halt als Vormerkung.
-
Nachtrag:
Macht es Sinn, die Werte " " und "/ " bei WB-Optionen -> Medienverzeichnis auszuschließen?
Auch mit der Revision 1409, die ja die Medien-Sicherungen von hal9000 beinhaltet kann man wieder alles löschen von WB.
Ich würde vorschlagen, dass man die Ordner
- "Gar keinen" (also leer und /)
- "/modules"
- "/templates"
- "wb_pages" (also per Standard eben /pages)
- "/framework"
- "/admin"
- "/account"
- "/include"
nicht erlaubt als Werte - ebenso nicht ../, sollte das möglich sein (auf meinem Testserver gibt's Errors, aber man weiß ja nie).
-
Zudem würde ich vorschlagen, vor einer "letzten" RC den Bugtracker komplett auf 0 herunterzubringen.
Dafür gibt's eine neue Resolution "booked for 2.9" - vorgemerkt für 2.9.
dazu sollte(n) ich/wir erst mal vorhandene Tickets ändern können:
1 von 1 ausgewählten Tickets konnte(n) nicht gespeichert werden: #nnnn
zumal da >50% dieser Tickets als Bug eingetragen wurden, obwohl es eindeutig Features sind.
auch ist eine ganze Reihe längst erledigt, kann von mir/uns nur nicht geschlossen werden (wegen genau dem Speicherfehler im System)
Solang der Fehler nicht behoben ist, taugt der Bugtracker maximal als besserer Schmierzettel aber nicht als Arbeitswerkzeug und wird deshalb höchstens als kleine Merkhilfe gewertet und hat keinerlei Aussagekraft über den Zustand des SVN.
-
Also ich weiß nicht so wirklich, wo dieser Bug bisher auftritt - bislang ist das die Fehlermeldungskateg orie "Hilfe ich hab PHP 5.2 aber ins admin komm ich net rein, bitte helfen!" Daher sollte es schon ein paar mehr Angaben (woanders) geben. Redmine ist auch nur von Menschen gemacht & eingerichtet, wir warten noch auf E.T. :wink:
Wobei es der hier http://www.question-defense.com/2010/04/16/redmine-error-moving-issue-between-projects-failed-to-save-1-issue-on-1-selected sein könnte.
-
Der Bug tritt auch auf, wenn man einen alten Eintrag bearbeiten will.
Dann sagt er, daß das Feld Autor Pflichtfeld wäre, das gibt es aber gar nicht :|
-
Der Bug tritt auch auf, wenn man einen alten Eintrag bearbeiten will.
Dann sagt er, daß das Feld Autor Pflichtfeld wäre, das gibt es aber gar nicht :|
Danke - wird gerade behoben. Leider ist beim Umzug von trac auf Redmine einiges zum Vorschein getreten (Unmengen von Spam z.B.), sodass hier nur rigoroses Löschen geholfen hat, die Datenbank auf ein Erträgliches Maß zu reduzieren. Darunter fielen auch viele Autoren-IDs - da aber trac kein wirkliches Benutzermanagement hatte, sind die wild herumgefolgen und teilweise hatte ein Autor auch 20 Accounts. Nun werden einfach alle offenen Tickets dem "admin" User zugeschrieben - geht nicht großartig anders, und geht auch nur in PHPMyAdmin. 8-)
Noch ein kleiner Kniff für Redmine: Schreibt man #1077 wird zum Ticket verlinkt, schreibt man r1077 wird zur Revision verlinkt. Klein, aber oft durchaus hilfreich (sollte auch im SVN-Kommentar klappen).
So - der Tracker sollte nun wieder klappen. Wenn nicht bitte (am Besten per PM oder so) genau das Ticket / URL angeben wo Fehler sind angeben.
-
@FrankH
Ja bezahlt wir hier nichts, aber deswegen habe ich mir den Code trotzdem angeschaut
<offtopic>
1.) Ich darf -kostenlos- die Testumgebung einer Firma nutzen -aber eben nicht alles. Codeanalyse ist ein Brocken, bei dem es dann auch Kompetenz in PHP bedarf. die weit über das Vermögen Sequenzen etc sortieren und einordnen zu können hinausgeht; die besitze ich nicht, weshalb es dann teuer werden dürfte.
2.) Code anschauen und auf Sicherheitsanforder ungen hin zu überprüfen war schon lange überfällig. Dass es endlich jemand gemacht und koordiniert hat ist "werri prima" und mehr als das....
</offtopic>
-
So - Bugtracker ist in Bereinigung und bislang sollte auch kein Fehler aufgetreten sein.
Kann jemand mal bitte wie in einem vorherigen Thread gewünscht erklären, was genau /include/idna_convert ist und warum man das braucht und wie es funktioniert, obwohl es nirgends aufgerufen wird?
-
Kann jemand mal bitte wie in einem vorherigen Thread gewünscht erklären, was genau /include/idna_convert ist und warum man das braucht und wie es funktioniert, obwohl es nirgends aufgerufen wird?
IDNA-Convert wird in wb::validate_email($email) benötigt, um auch Umlautdomains erfassen zu können. Wird auch explizit nur in dieser Funktion nachgeladen um das System nicht unnötig zu belasten.
-
Kann jemand mal bitte wie in einem vorherigen Thread gewünscht erklären, was genau /include/idna_convert ist und warum man das braucht und wie es funktioniert, obwohl es nirgends aufgerufen wird?
IDNA-Convert wird in wb::validate_email($email) benötigt, um auch Umlautdomains erfassen zu können. Wird auch explizit nur in dieser Funktion nachgeladen um das System nicht unnötig zu belasten.
Ah ok, da ist sie... Aber ist das nicht ein wenig stark mit Kanonen auf Spatzen geschossen? Na gut... Dann wäre die Frage, ob man nicht generell URLs / Domains (also auch www.meineümläutdöma in.xyz) damit abfängt. Gerade wurde ein Issue http://project.websitebaker2.org/issues/937 nämlich geschlossen.
-
Ach du meinst er meinte das?
Ich dachte eher an so was: http://www.viart.com/what_are_friendly_urls.html
-
Ah ok, da ist sie... Aber ist das nicht ein wenig stark mit Kanonen auf Spatzen geschossen? Na gut... Dann wäre die Frage, ob man nicht generell URLs / Domains (also auch www.meineümläutdöma in.xyz) damit abfängt. Gerade wurde ein Issue http://project.websitebaker2.org/issues/937 nämlich geschlossen.
Das ganze hat absolut nichts mit SEO oder sonstigen 'Modeerscheinungen' zu tun.
die Klasse soll einfach aus einer Unicode-Emailadresse wie z.B. günter.möller@русски.ru
den entsprechenden Punycode ( xn--gnter-kva.xn--mller-jua@xn--h1adreak.ru ) erzeugen , der dann relativ einfach(da keine nationalen Sonderzeichen mehr, sondern nur noch pures ASCII) mit einer Regexpression auf Gültigkeit überprüft werden kann.
Das ist auch die gleiche Technik, die Browser anwenden, da das Internet in der Adressierung (DNS-Server im speziellen) keine nationalen Sonderzeichen kennt, sondern nur Punicode. (ganz grob beschrieben)
-
Ehm - Domainnamen mit nicht
englischen lateinischen Zeichen haben erstmal rein gar nichts mit SEO zu tun, sondern halt mit vorhanden sein oder nicht (irgendeiner kam halt mal auf die glänzende Idee, dass man das einführen sollte, und leider ist das sogar offiziell - aber wie man sieht, macht das ja nichtmal vor E-Mails halt). Auch Domainnamen werden doch irgendwie überprüft, oder? Denn Domainnamen / URLs sind ja zwingend Teil der E-Mail-Adresse.
-
Jep, werden Sie. Deswegen ja der Part mit der umwandlung in Punycode, weil die Regex sonst nicht mehr wartbar gewesen währe. Lustigerweise sind da mehr viel Zeichen im Domainnamen erlaubt als im Mailpart.
-
Hallo,
hab grad die aktuellste SVN Version (1417) am testen. Die neu eingeführte Warnmeldung beim Verlassen von Seiten nervt und zwar aus drei Gründen:
1.) Sie kommt immer, egal ob man was geändert hat oder nicht.
2.) Javascript und Entities geht nicht, alle Sonderzeichen werden falsch dargestellt (in ISO... charset)
3.) Die Möglichkeit des Deaktivierens dieser Meldung in den erweiterten Optionen wurde (vermutlich versehentlich) wieder aus den settings.htt der backend templates rausgenommen.
Grundsätzlich würde ich auch die Option begrüßen, die einem nach gemachten Änderungen daran erinnert, dass man die doch bitte erst speichern möchte. Aber bitte nur dann. So wie es jetzt ist, dass man permanent dieses Hinweisfenster wegklicken muss (auch wenn man gar nix geändert hat) ist das nix. Nervt einfach.
Gruß
Matthias
-
Is fixed in Rev 1418. Tks for your information, we remove it and set it in our Todo list for 2.9.0.dev
Sorry for all trouble
Dietmar
Ist gefixt in Rev 1418. Danke für die Information. Wir setzen das auf die Vorschlagsliste für die 2.90.dev
Hoffe ihr verzeiht uns die Unannehmlichkeiten
Dietmar
-
Hallo,
danke,
nur der Vollständigkeithalb er, vielleicht sollte es man auch aus der install/save.php, admin/settings/index.php, languages/DE.php und languages/EN.php wieder rausnehmen. Führt sonst zur Verwirrung.
Matthias
-
Betr. Warnmeldung beim Verlassen von Editorseiten:
Für die 2.9 liegt jetzt ein Konzept als Erweiterung des WYSIWYG-Modules in der Schublade, so dass es bei praktisch jedem eingesetzten Editor funktioniert.
Andere Seitentypen (Form etc.) werden nicht berücksichtigt. Ein klein wenig Selbstverantwortung sollte man einem User schon abverlangen können, auch wenn es dem derzeitigen Trend widerspricht, Verantwortung grundsätzlich auf andere abzuwälzen.
-
Hallo Matthias,
Zur Info.
Im upgrade-script hatten wir es rausgenommen. Die Install wird ja noch komplett mit neuem Design ersetzt. Deswegen hatten wir da extra nichts gemacht. Sprachdateien denke ich dran.
Dietmar
-
Hallo,
Für die 2.9 liegt jetzt ein Konzept als Erweiterung des WYSIWYG-Modules in der Schublade, so dass es bei praktisch jedem eingesetzten Editor funktioniert.
... Die Install wird ja noch komplett mit neuem Design ersetzt. Deswegen hatten wir da extra nichts gemacht. Sprachdateien denke ich dran.
Vielen Dank für die prompte Rückmeldung. Sehe schon, auf die Devs ist halt doch Verlass. Und sowohl der Ausblick auf die Warnmeldungen bei 2.9 als auch die Integration von stefeks Installer stimmen mich in freudige Erwartung.
Matthias
-
Ehrlich gesagt finde ich es sehr, sehr schade, dass das sinnvolle Feature wieder draußen ist - wenn es denn möglich wäre zu deaktivieren stellt man es per Standard auf deaktiviert und jeder darf zufrieden sein. :wink: Nur ein paar kleine Änderungen und es wäre doch was gewesen.
Wobei - benutzt man einen modernen Browser sollte das auch kein Problem mehr sein, weil die ja in ihrer History auch nach Absturz die Texte in der Regel (!) wiederherstellen können.
Und mal ehrlich: Den Satz mit die Unannehmlichkeiten hab ich nicht gelesen, wer eine SVN aktiv benutzt ist sowas von selber schuld, der muss mit allem rechnen, nur nicht mit einer Entschuldigung, wenn die Datenbank unwiderruflich den Nil runtergeflossen ist. :-D
-
Also wenn SVN in einer aktiven Testphase nicht mehr zum Testen gebraucht werden kann man sich den ***** SVN + Test auch sparen. Bisher war das anders. Aber anscheined ist sowieso alles anders, da ich z.B. trotz Zusage immer noch keinen Zugang zur Entwicklerseite (Sicherheit bei Modulen etc) habe. Wer soll den Quatsch noch ernst nehmen?
[EDIT by kweitzel]
-
Also wenn SVN in einer aktiven Testphase nicht mehr zum Testen gebraucht werden kann man sich den Scheiß SVN + Test auch sparen. Bisher war das anders. Aber anscheined ist sowieso alles anders, da ich z.B. trotz Zusage immer noch keinen Zugang zur Entwicklerseite (Sicherheit bei Modulen etc) habe. Wer soll den Quatsch noch ernst nehmen?
Ich hab leider heute meine Glaskugel vergessen, daher weiß ich weder auf was du anspielst von vorne bis zur Mitte noch was überhaupt gemeint sein soll.
Zur r1392: Ich stelle gerade viele Seiten ein. Man merkt, dass FTans greifen - öffnet man z.B. wie ich es doch immer gerne mache (da die Seitenübersicht 5-10 Sekunden braucht zu laden) während dem Laden der Seite einen Link in den Pages und führt danach das Hinzufügen einer Seite aus (als Beispiel, bei anderen ebenso) wird das verwehrt. Ich finde das positiv - die kleine Einschränkung ist keine wirkliche und man sieht einfach, dass es greift.
Ich hoffe inständig, dass die "Verweichlichung" wie hier http://project.websitebaker2.org/projects/WebsiteBaker/repository/diff?rev=1404&rev_to=1403 das ganze nicht verwässert - das wäre grundlegend falsch.
-
Also wenn SVN in einer aktiven Testphase nicht mehr zum Testen gebraucht werden kann man sich den S**** SVN + Test auch sparen. Bisher war das anders. Aber anscheined ist sowieso alles anders, da ich z.B. trotz Zusage immer noch keinen Zugang zur Entwicklerseite (Sicherheit bei Modulen etc) habe. Wer soll den Quatsch noch ernst nehmen?
Als erstes nimmst Du Dir jetzt mal Deinen Post vor und entfernst ein Wort daraus. Du hattest bereits die erste Warnung (privat). Das hier ist die 2te Warnung!
Und dann ... wer hat Dir wann was mit Zugängen zu welchen Teilen der WebsiteBaker Seiten zugesagt?
Gruß
Klaus
-
Nun wollte ich aber erst noch die Tests machen, was mir als Beitrag schon mehr als wichtig ist, also mich nicht jetzt schon abschießen (lassen) -wenn es zu vermeiden ist.
Danach aber werde ich persönlich, da Du Dich m.E. reichlich weit aus dem Fenster lehnst.
Du nervst nämlich schon zu lange.
-
Ich hoffe inständig, dass die "Verweichlichung" wie hier http://project.websitebaker2.org/projects/WebsiteBaker/repository/diff?rev=1404&rev_to=1403 das ganze nicht verwässert - das wäre grundlegend falsch.
Das hat nichts mit verwässern zu tun, sondern nur mit der Tatsache, dass die sofortige Aktivierung eine Änderung in praktisch allen Modulen erzwingen würde. Daher ist der Einsatz der IDKEY an dieser Stelle derzeit nur vorbereitet, nicht jedoch aktiviert. Die Aktivierung erfolgt erst, wenn die modifizierte Modulschnittstelle verfügbar ist, die dann dafür sorgt, dass bei 'alten / bisherigen' Modulen keine Fehlfunktion mehr auftritt.
-
Du nervst nämlich schon zu lange.
Dass Du auf eine einfache Bitte eines Moderators solch einen Flash back gibst, nervst aber um so mehr.
Zumal weil Du zunächst persönlich per PM gebeten wurdest.
Gewöhn Dir ein paar Manieren an, Hans.
Das sag ich Dir als Foren User. Testen schön und gut, aber man muss sich nicht ständig diese Launen von Dir auch noch reinziehen. Hilfe ist was anderes.
Stefek
-
Eine 7 Tage Schreibsperre wurde verhängt.
-
Danke..
Teste Grade mal den Upgrade von 2.8.1 auf 2.8.2 rc5
Das erste was mir so auffällt ist das zwar eine Datei INSTALL vorhanden ist , aber keine Info wie ein Upgrade auszuführen ist. Würde Vorschlagen einfach noch eine Datei UPGRADE hinhufügen.
Vielleicht mit folgendem Inhalt:
-------------------------------------------------------------------------------
UPGRADE
Warning:
Only use this package to upgrade a 2.8.1 Version of WebsiteBaker or you may get some unexpected results.
First step :
Backup your installation and database!
Second step:
Copy the Content of the wb folder right into your installlation folder and run the upgrade script.
To run the upgrade script just call it whith your favourite browser:
http://yourdomain.com/upgrade-script.php
Thats it
-------------------------------------------------------------------------------
Und wenn man schon Kleinigkeiten listet , in der Readme den Hinweis auf die UPGRADE Datei nicht vergessen.
Später mehr ...
-
Gleich noch ne Frage hinterher, die config.php muß für ein Upgrade auch überspielt werden ?
Doch eigentlich nicht oder ?
-------------------------------------------------------------------------------
UPGRADE
Warning:
Only use this package to upgrade a 2.8.1 Version of WebsiteBaker or you may get some unexpected results.
First step :
Backup your installation and database!
Second step:
Copy the Content of the wb folder right into your installlation folder and run the upgrade script.
DO NOT OVERWRITE YOUR EXISTING config.php !!!
To run the upgrade script just call it whith your favourite browser:
http://yourdomain.com/upgrade-script.php
Thats it
-------------------------------------------------------------------------------
Ansonsten läuft das Upgrade problemlos durch keine Fehlermeldungen nichts.
Apache als Modul , Php aktuelle Version .
-
Gleich noch ne Frage hinterher, die config.php muß für ein Upgrade auch überspielt werden ?
Ein Upgrade auf 2.8.2 ändert nichts an der config.php.
Nur aufpassen, dass die bestehende beim Einspielen per FTP mit der leeren aus dem Installationspaket nicht versehentlich überschrieben wird. (falls kein Backup existiert)
-
Hatte ich mir schon gedacht, deswegen:
DO NOT OVERWRITE YOUR EXISTING config.php !!!
Wenn man es nicht dabei schreibt wird es garantiert jemand falsch machen :roll:
-
Hallo,
hab grad die aktuellste SVN Version (1417) am testen. Die neu eingeführte Warnmeldung beim Verlassen von Seiten nervt und zwar aus drei Gründen:
1.) Sie kommt immer, egal ob man was geändert hat oder nicht.
2.) Javascript und Entities geht nicht, alle Sonderzeichen werden falsch dargestellt (in ISO... charset)
3.) Die Möglichkeit des Deaktivierens dieser Meldung in den erweiterten Optionen wurde (vermutlich versehentlich) wieder aus den settings.htt der backend templates rausgenommen.
Grundsätzlich würde ich auch die Option begrüßen, die einem nach gemachten Änderungen daran erinnert, dass man die doch bitte erst speichern möchte. Aber bitte nur dann. So wie es jetzt ist, dass man permanent dieses Hinweisfenster wegklicken muss (auch wenn man gar nix geändert hat) ist das nix. Nervt einfach.
Gruß
Matthias
Nun das Deaktivieren hat funktioniert. Von jemandem mit gesundem Menschenverstand hätte ich erwartet, daß er fordert, daß das entfernte Teil wieder eingebaut wird, aber nicht daß der Rest auch noch entfernt wird.
Sicher war das Teil noch entwicklungsfähig. Stelle aber nun fest, daß es besser ist, die Zeit mit was anderem zu verbringen als etwas nützliches für WB zu entwickeln, was dann andere wieder ausbauen.
Nun verstehe ich auch, dass die Probleme mit der Entwicklerfluktuati on hier hausgemacht sind.
-
Ich les da nicht, daß der Rest auch entfernt werden soll. Sondern lediglich, daß die Meldung nur kommen soll, wenn man wirklich was geändert hat. Sollte ja nicht sooo schwierig sein. :roll:
-
Hallo,
nochmals im Klartext:
1.) Eine Funktion die einem vor Verlassen einer Seite daran erinnert, dass man die Änderungen speichern sollte, ist längst überfällig und sollte auch zeitnah umgesetzt werden.
2.) Eine Funktion, die einem bei jedem Verlassen einer Seite oder einer Section mit ner Meldung nervt, das man doch bitte die Änderungen speichern sollte, obwohl man nix geändert hat, und die noch dazu nicht richtig dargestellt wird, braucht kein Mensch.
Wenn das Dingens ausgereift ist, rein damit, aber erst dann.
Sieh es lieber als Ansporn, das Dingens fertig zu machen. Du hast inzwischen soviel für WB gemacht, was wirklich Klasse ist, da wirst du doch wegen der Kleinigkeit nicht den Bettel hinschmeißen.
Gruß
Matthias
-
Die Entwickler sollten einfach mal, wenn etwas in der SVN ist, es auch länger drin belassen. Anscheinend gibt's die Meinung "die SVN muss laufen" was Unfug hoch drei ist, weil die SVN ein reiner Entwicklerspielplat z ist.
Wenn etwas nach wenigen Stunden wieder rauskommt ist das natürlich ziemlich schlecht. Wenn einer sagt "mag ich net" heißt es doch noch lange nicht, dass 50 andere es testen und eben weil sie es gut finden nichts sagen.
-
Also wenn ich das richtig im Ohr habe sollte die 2.8.2 ein reines Bugfix-Release ohne neue Funktionen / Features sein.
Die hier angesprochene Meldungsfunktion wäre aber doch ein neues Feature oder nicht? ;-)
-
Also wenn ich das richtig im Ohr habe sollte die 2.8.2 ein reines Bugfix-Release ohne neue Funktionen / Features sein.
Die hier angesprochene Meldungsfunktion wäre aber doch ein neues Feature oder nicht? ;-)
Ja und? Dann müssen wir aber wieder viele Features rauswerfen, die in der 2.8.2 dazu gekommen sind, z.B. show_menu2. Man kann sich aber auch quer ins Bett legen und sich dann beschweren, es sei zu kurz.
-
1.) Eine Funktion die einem vor Verlassen einer Seite daran erinnert, dass man die Änderungen speichern sollte, ist längst überfällig und sollte auch zeitnah umgesetzt werden.
2.) Eine Funktion, die einem bei jedem Verlassen einer Seite oder einer Section mit ner Meldung nervt, das man doch bitte die Änderungen speichern sollte, obwohl man nix geändert hat, und die noch dazu nicht richtig dargestellt wird, braucht kein Mensch.
Ich stimme mit Matthias überein.
Aber es gibt noch mehr dazu.
Vor allem, wenn es sich um die WYSIWYG Abschnitte handelt, gibt es gewiß eine bessere Lösung.
Das gegenwärtige (2.8.1 und kleiner) Szenario ist, dass wenn ich eine Seite mit mehreren WYSIWYG Abschnitten habe und in den Editiermodus der Seite mit den Abschnitten gehe, alle Abschnitte OFFEN stehen. Soll heißen -> alle Wysiwyg Abschnitte zeigen ihren Editor, den Save und den Cancel Button.
Das ist eine Quelle für mehr Ärger als dass man mal nicht Speichert und woanders hingeht.
Weil - die User geben hier und da mal was ein, drücken auf einen der [Speichern] Buttons und nur dieser wird gespeichert.
Eine einfache Abhilfe hat bereits vor etwa 2 Jahren ein User mit dem Namen lousou76
https://forum.WebsiteBaker.org/index.php/topic,12988.0.html
Die von ihm gestartete Umfrage sagt eigentlich alles.
Und das einzubauen ist nun wirklich kein Hexenwerk.
Und, wenn dann eine der WYSIWYG Sections "AUF" ist, kann keine weitere geöffnet werden, bis sie geschloßen wurde und dann macht die Notification, "Please save before... blabla" auch Sinn, sobald eine der Sections offen ist.
Gut, für andere Module weiß ich nicht.
Aber bei denen gibts ja meistens keine direkten Eingabefelder in der modify.php
Übrigens, die oben verlinkte Lösung hat zusätzlich den Vorteil, dass die ganzen Editoren nicht sofort geladen werden, was die Ladezeit sparsamer gestaltet.
Hat mir schon damals gefallen das Ding und ich fand es schade, dass es "irgendwie untergegangen" war.
Gruß,
Stefek
-
Hallo,
-offtopic-
Also wenn ich das richtig im Ohr habe sollte die 2.8.2 ein reines Bugfix-Release ohne neue Funktionen / Features sein.
Die hier angesprochene Meldungsfunktion wäre aber doch ein neues Feature oder nicht? ;-)
Muss da Maverik Recht geben. Entweder hält man sich dran, dass 2.8.2 keine neuen features enthält oder nicht. Jahrelang wurde hier in der communitiy gemeckert, dass es keine klaren Richtlinen bezüglich der Weiterentwicklung von WB gibt. Jetzt gibt es welche (bitte jetzt hier keine Grundsatzdiskussion starten, threadthema bitte beachten), da sollte man sich dann auch dran halten.
.. Eine einfache Abhilfe hat bereits vor etwa 2 Jahren ein User mit dem Namen lousou76
https://forum.WebsiteBaker.org/index.php/topic,12988.0.html ...
Beides zusammen, dass man nur eine section bearbeiten kann + der Hinweis beim Verlassen das Speichern nicht zu vergessen, das wär richtig gut. Bin auch einer der geschädigten, die auf Seiten mit mehreren section schon gemachte Änderungen verloren haben, weil sie den verkehrten speichern Button gedrückt haben. Das Ganze ist wohl aber eher was für 2.9 und hat deswegen in diesem thread eigentlich nix mehr verloren.
-offtopic Ende-
Happy Baking
Matthias
-
Muss da Maverik Recht geben. Entweder hält man sich dran, dass 2.8.2 keine neuen features enthält oder nicht. Jahrelang wurde hier in der communitiy gemeckert, dass es keine klaren Richtlinen bezüglich der Weiterentwicklung von WB gibt.
Ach komm Matthias, du weißt doch am Besten, dass immer gemeckert wird, egal was getan wird.
Dann streitet man sich eben drum, was ein Feature ist. Ich sage dann "SecureForm" ist ein Feature und ebenso "[tooltip] in SM2, und schon ist die 2.8.2 tot diskutiert und kommt am St.-Nimmerleinstag heraus.
Und würde man sich streng an einmal gesagte "Richtlinien" halten, dürfte es die 2.8.2er gar nicht geben - es sollte sie ja eine Zeitlang gar nicht geben, sondern nur Patches für die 2.8.1er. Aber jetzt hat man einmal die Chance, wieder die Community nach langer Zeit wieder mit einzubinden und das wird jetzt auch wieder angezweifelt. Manchmal fragt man sich schon, was Statler und Waldorf dazu sagen würden.
-
Macht fertig die Kiste.
Was fehlt denn da noch?
Am schlimsten finde ich das "Feature", keine mehrere Fenster vom Backend mehr auf haben zu können.
Und ja, gemeckert wird fast immer.
Zu fast jedem Anlass.
Es ist sowie so ein Wunder, dass WB noch lebt :-D
Möge dieses Wunder lange aufrecht erhalten werden.
:wink:
Stefek
-
Das CSRF Problem muss auf jeden Fall gelöst werden es kommen immer mehr Hacks raus die genau darauf aufsetzen und die werden zum Teil mit anderen Techniken gemixt so das sie immer unangenehmer werden.
Das ist halt alles nicht so ganz einfach, bei ein paar Gesprächen mit Viper haben wir festgestellt das im Endeffekt 3 Möglichkeiten existieren.
1. Wir lassen das so wie es ist und erhalten gute Sicherheit aber verlieren eine ziemlich oft benutzte Technik um mit WB komfortabel zu arbeiten. Eventuell gibt es da auch noch Probleme mit Multipage Forms
und dem Back Button.
2. Wir erweitern die Sicherheitsklasse so, das sozusagen eine FTAN Verwaltung eingebaut bekommt die verschiedene TANs für verschiedene Seiten erlaubt und diese Verwaltet. Dabei müssen aber noch fragen geklärt werden wie: Was passiert wenn ein Fenster lange offen bleibt , oder wenn es geschlossen wird ohne das das Formular versendet wurde.
Diese Variante würde gleiche Sicherheit, aber einen fast vollständig erhaltenen Komfort bedeuten, man würde nur noch Probleme mit dem Back Button haben, und wenn man die gleiche Seite in 2 Fenstern bearbeiten will(man muss sich dann für ein Fenster entscheiden in dem man Änderungen speichert).
Der Nachteil ist das das schon eine Relativ komplexe Lösung ist, die durchaus noch ein wenig Zeit beanspruchen würde.
3. Wir nehmen ein vereinfachtes TAN System bei dem die TANs eine gewisse Lebensdauer haben (12h).
Das hat den Vorteil, das der Komfort voll erhalten bleibt. Aber die Sicherheit wird fragwürdiger.
Um genauer zu sein ist Viper grade dabei das noch mit einigen anderen Sicherheitsexperten zu besprechen. Tatsache ist das andere CMS , z.B. Wordpress das genauso nutzen. Allerdings heißt das natürlich noch lange nicht das es auch sicher ist.
Rein Theoretisch müsste das bei Angriffen über gefakte Webseiten ausreichen, aber die Angrifsvektoren werden immer bunter. Über Browserlücken, fehlerhafte HTML Anzeigen im Mailprogrammen aller Arten ist es eventuell möglich an die FTAN zu kommen und dann den Angriff zu starten.
Hier besteht also noch Klärungsbedarf.
Ich denke Wenn die Sicherheitsexperten die Lösung für vertretbar halten währe Lösung 3 das Mittel der Wahl für die 2.8.2 und Lösung 2 währe geeignet für 2.9.0.
Das Problem ist halt das solche Probleme erst auftauchen wenn intensiv getestet wird und dann oft erst mal Forschung betrieben werden muss um andere Lösungsansätze zu finden oder um bestehen auf Ihre Sicherheit hin abzuklopfen. Dazu kommt noch das alleine das Thema CSRF unglaublich komplex ist und man sich tagelang damit beschäftigen kann, von den weiteren Sicherheitsfragen mal völlig abgesehen.
-
Wer die Reeperbahn in Hamburg besucht setzt sich dem Risiko aus das ihm etwas passieren kann . Trotz Ordnungsmacht und Sicherheitsvorkehru ngen. Das gleiche kann ihm aber auch auf einem großen Hauptbahnhof passieren.
Wer das Internet besucht und darin auch noch arbeitet geht das gleiche Risiko ein.
Wer mit dem Auto fährt lebt mit dem Kompromiss das ihn der Gurt und die Airbags schützen, er verzichtet auf feuerfesten Anzug und Helm.
Man sollte die Kirche im Dorf lassen und kann bzw. sollte dem Individuum Mensch nicht alles abnehmen, eine gewisse Eigenverantwortlich keit und das Benutzen der brain.exe sollte Bedingung sein.
Somit sollte auch hier ein gesunder Kompromiss aus Komfort und Sicherheit gefunden werden.
-
Und wer eine Software benutzt, wo Leaks herumschwirren im Netz schreit als erster, dass die Software Mist ist.
So, dann haben das Thema auch abgehakt.
OnTopic zu NorHei: Wenn wirklich Lösung 3 sind 12 Stunden übertrieben. Normalerweise sind "7200 Sekunden" sinnvoll, aber warum nicht per Benutzereingabe in der Administration änderbar? Jeder Session werden eine gewissen Zahl (max. sagen wir 20) Tans zugeordnet und jeweils nach der eingegebenen Zeit, aber spätestens mit den ablaufen der Session gelöscht. Die Session selber sollte ein Maximum von 6 oder besser einstellbaren Stunden bekommen.
-
Na das mit mehreren TANs hate ich ja auch schon angefangen einzubauen in rev1357 - das wurde aber auch wieder restlos entfernt.
Übrigens soll noch ein bekanntes Scherheitsloch in der 2.8.2 drin bleiben:
Für den Mediaordner wird eine viel zu kurze Blacklist statt Whitelist verwendet, d.h. jeder, der da was hochladen kann, kann ausführbare Dateien hochladen und ausführen und damit den kompletten Server übernehmen. Es sei denn der Installateur macht sich kundig, welche Dateiendungen überhaupt auf seinem Server ausführbar sind und trägt die alle in die Liste ein, was aber mindestens 90% des Zielpublikums nicht auf die Reihe bringen werden. Oder wer von Euch weiß auf Anhieb, welche Scriptsprachen sein Apache überhaupt unterstützt und welche Dateiendungen in jeder Sprache akzeptiert werden?
-
Ui, das ist aber ein böses Löchlein, dabei sollte das doch mit Leichtigkeit zu Patchen sein.
-
Ui, das ist aber ein böses Löchlein, dabei sollte das doch mit Leichtigkeit zu Patchen sein.
Nein. Es wird erst mit 2.9 erledigt, das wurde schon sehr oft gesagt.
-
Gibts irgendwelche Gründe dafür ? Das muss doch eine Kleinigkeit sein?
OnTopic zu NorHei: Wenn wirklich Lösung 3 sind 12 Stunden übertrieben. Normalerweise sind "7200 Sekunden" sinnvoll, aber warum nicht per Benutzereingabe in der Administration änderbar? Jeder Session werden eine gewissen Zahl (max. sagen wir 20) Tans zugeordnet und jeweils nach der eingegebenen Zeit, aber spätestens mit den ablaufen der Session gelöscht. Die Session selber sollte ein Maximum von 6 oder besser einstellbaren Stunden bekommen.
War nur die Beispielzeit aus Wordpress. Und einstellbar wäre am besten ist richtig.
-
Gibts irgendwelche Gründe dafür ? Das muss doch eine Kleinigkeit sein?
Es wird gegen eine ungeschriebene Regel verstoßen die heißt: Keine Datenbankänderungen (wo ja eine gebraucht wird, um auf 2.8.2 überhaupt upzudaten) in Minor-Versionen. Das wird keiner verstehen, aber es ist halt so.
-
Hmmm... Filterfunktion umkehren, eingetragene Dateiendungen ändern .. keine Änderung an der DB...
-
Hmmm... Filterfunktion umkehren, eingetragene Dateiendungen ändern .. keine Änderung an der DB...
Ja sehe ich auch so, aber andere sehen es halt anders. Und wenn ich es korrigiere, machen sie das wieder rückgängig, das hab ich ja nun gelernt.
Aber ich kann mir ja dann für den Hausgebrauch eine 2.8.3 machen :-)
-
Ja sehe ich auch so, aber andere sehen es halt anders. Und wenn ich es korrigiere, machen sie das wieder rückgängig, das hab ich ja nun gelernt.
Wenn schon, dann bitte vollständige Sätze:
Ja sehe ich auch so, aber andere sehen es halt anders. Und wenn ich es, entgegen der Absprachen, ohne Rücksprache mit dem DEV-Team eigenmächtig korrigiere, machen sie das wieder rückgängig, das hab ich ja nun gelernt.
-
Dann bitte jetzt in Absprache korrigieren und seid lieb zueinander . Und wir alle freuen uns dann über die verschwundene Lücke :-)
-
Hallo,
wollte mal fragen, ob das "Superfeature", dass man eine WB Installation nur einmal in seinem Browser anzeigen kann irgendwie korrigiert wurde.
Wann können wir mit dem 2.8.2 rechnen?
Das sah für mich um die Jahreswende so aus, als wenn es sich nur noch um Stunden handeln sollte.
Gruß,
Stefek
-
Ich hatte unlängst das Problem, dass bei einer 2.8.2 RC5 Site sehr häufig das Speichern nicht funktioniert hat und dass das Cookie verloren ging (Sorry für die laienhafte Ausdrucksweise): Im Backend konnte ich eine "private" Seiten noch bearbeiten, mit Klick auf "Anzeigen" hatte ich plötzlich keine Berechtigung mehr.
WB_URL war auf "/kunde" (Unterverzeichnis, kein http:// + Domain) eingestellt.
Ärgerlich war, dass es zu 90% funktioniert hat - aber restlichen 10% waren sehr nervig.
-
Wenn du dich mit SVN auskennst würde ich empfehlen die Aktuelle SVN mal zu versuchen. Da sollte das eigentlich behoben sein.
-
Lol , erst hieß es um Weihnachten rum, dann Ende Januar, ich wette das dauert noch ein halbes Jahr.
Minimum. :-P
-
Eigentlich war es schon für Ende März (letzten Jahres) angekündigt.
-
Hab gestern als SVN Version 2.8.2.RC5 Revision 1433 geladen und installiert. Install lief ohne Probleme. Nachdem ich einiges hier gelesen habe, stelle ich mir vor allem 2 Fragen:
1) Ist es noch empfehlenswert 2.8.1 für ein Projekt zu verwenden (Sicherheit)?
2) wie sieht die Roadmap für 2.8.2 und 2.9 derzeit aus?
Aktuelle Aussagen der DEVs habe ich leider keine gesehen und so steigt die Unsicherheit wieder.
Ein stabiles Update in den nächsten 6 Wochen könnte vielleicht eine Frischzellenkur für das Projekt bewirken. Ich verfolge das ganze seit fast einem Jahr und seither hat es kein Core-Update mehr gegeben.
LG
-
Eventuell läuft dieses Forum jetzt auch unter WB 2.8.2??
Beim Versuch zu antworten bekam ich erst mal das:
Sitzungs-Check fehlgeschlagen. Bitte loggen Sie sich aus und versuchen Sie es erneut.
Einen Logout-Button fand ich nicht, wildes Herumklicken half aber.
1) Ist es noch empfehlenswert 2.8.1 für ein Projekt zu verwenden (Sicherheit)?
Definitiv nicht.
Vor 10 Monaten (im Mai 2010) wurde ein riesiges Sicherheitsloch gemeldet (anonymer User kann sich Vollzugriff verschaffen), und das hat aus der 2.8.1 (aktuell wird die Rev 1287 vom Aug 2010 angeboten) noch keiner rausgemacht, wobei der Aufwand, das zu tun, nur die Änderung von 2 Zeilen Code erfordert. Man bastelt lieber parallel an 2 neuen Versionen 2.8.2 und 2.9 und lässt die Community mit einem ziemlich unsicheren System im Regen stehen.
Ich wurde gebeten, mich für 2.8.2 um die gemeldeten Sicherheitsprobleme zu kümmern und hatte diese Dez+Jan innerhalb einiger Tage auch fast beseitigt. Nachdem meine Änderungen aber mehrfach (teils absichtlich, teils "versehentlich", weil die Bedienung eines SVN ja soo kompliziert ist) von Luisehahne wieder entfernt wurden, habe ich mich dazu entschlossen, die Arbeit an dem Projekt erst mal ruhen zu lassen.
Leider kann man momentan nicht sagen, daß das Projekt in guten Händen wäre. Im Gegenteil, 10 Monate lang als Verein wissentlich eine hochgradig unsichere Software anzubieten ist in meinen Augen nicht gemeinnützig, sondern fast schon kriminell.
-
Was die Roadmap betrifft, bei der 2.8.2 SVN fehlt noch ein neuer schöner Installer, an dem ist Viper jetzt drann. Dann wird er sich möglicherweise nochmal kurz die Secure Form Klasse vornehmen weil sich doch etliche darüber beschwert haben, das man nicht mehr problemlos in mehreren Fenstern arbeiten kann.
Kann aber auch sein das das als Patch nachgeliefert wird.
Leider war vor allem Viper in letzter Zeit ein wenig überlastet mit Brötchen verdienen.
1) Ist es noch empfehlenswert 2.8.1 für ein Projekt zu verwenden (Sicherheit)?
Ganz klar: JEIN
Wenn du nur vertrauenswürdige Benutzer hast ist die Gefahr sehr gering.
Wenn Benutzer sich einfach registrieren können solltest du definitiv die SVN benutzen, die habe ich hier auch schon im Produktiv Einsatz. In der SVN sind meines Wissens nach alle diese Lücken gepatcht. Wenn jemand mit SVN Probleme hat stelle ich hier auch gerne einen Snapshot zur Verfügung.
@Frank
Deine Patches wurden entfernt weil sie nicht den Erwartungen entsprachen (Was jetzt KEINE Aussage über die Qualität deiner Patches ist!) und Du sie wohl ohne vorheriges Testen und ohne Absprache ins SVN hochgeladen hast . Ich vermute mal das das an fehlerhafter Kommunikation lag. Auf jeden Fall fände ich es Sinnvoller wenn Du einfach mal zum Telefonhörer oder zu Skype greifen tätest und die Sache direkt mit Viper oder Luise klären würdest. (Du kannst auch gerne erst einmal mich kontaktieren und mach dann den Vermittler.) Das hier wieder und wieder im Forum zu Posten führt doch zu nichts.
-
@Frank
Deine Patches wurden entfernt weil sie nicht den Erwartungen entsprachen ... und Du sie wohl ohne vorheriges Testen und ohne Absprache ins SVN hochgeladen hast .
Ich kann beim besten Willen nicht nachvollziehen, wie so eine Lappalie so viel Wind aufwirbeln kann.
Auf der einen Seite die Erwartung, wie es richtig sein soll auf der anderen Seite der gute Wille, beizutragen.
Ich verstehe nicht, wo die Schwierigkeit ist, sich in der Mitte zu treffen.
Und ich verstehe auch nicht, warum man kein System mit Branches einführen kann.
Warum alles direkt ins SVN übernehmen?
So kommen wir nie dahin, sinvolle Entwicklungen im Testbetrieb zu begutachten, um sie anschließen in eine Subversion einfließen zu lassen.
Stefek
-
Ich kann beim besten Willen nicht nachvollziehen, wie so eine Lappalie so viel Wind aufwirbeln kann.
Auf der einen Seite die Erwartung, wie es richtig sein soll auf der anderen Seite der gute Wille, beizutragen.
Ich verstehe nicht, wo die Schwierigkeit ist, sich in der Mitte zu treffen.
Mangelnde Kommunikation .... :-(
-
Ich kann beim besten Willen nicht nachvollziehen, wie so eine Lappalie so viel Wind aufwirbeln kann.
Auf der einen Seite die Erwartung, wie es richtig sein soll auf der anderen Seite der gute Wille, beizutragen.
Ich verstehe nicht, wo die Schwierigkeit ist, sich in der Mitte zu treffen.
Mangelnde Kommunikation .... :-(
Oder anders ausgedrückt: Perfektionismus. :wink:
-
Nachtrag: Die Patches sind sogar alle noch drin nur einige zusätzliche Änderungen die nicht abgesprochen waren sind rausgeflogen.
-
Wenn du nur vertrauenswürdige Benutzer hast ist die Gefahr sehr gering.
Das ist gelogen (vielleicht auch versehentlich, weil das Wissen fehlt). Verbreitung von Halbwahrheiten scheint sich hier ja immer mehr durchzusetzen, nur bei Sicherheitslücken sollte man sich so was verkneifen.
Man braucht nicht angemeldet zu sein, um die Site übernehmen zu können, wenn bestimmte nicht unwahrscheinliche Voraussetzungen zutreffen.
@Frank
Deine Patches wurden entfernt weil sie nicht den Erwartungen entsprachen
Interessante Behauptung. Dann frage ich mich, wieso Dietmar mich mehrmals gebettelt hat, ich sollte meine gepatchten Dateien nochmal überprüfen und meine Patches wieder einspielen, weil er sie beim gedankenlosen Kopieren zwischen 2.9 und 2.8.2 überschrieben hat?
Wenn ein Patch in einer svn-Revision erst mal nur zu 95% funktioniert, hat man 2 Möglichkeiten: Man verbessert ihn in der nächsten Revision (deswegen ist das svn nicht für Produktiveinsatz gedacht) oder man entfernt ihn wieder restlos.
Leute mit gesundem Menschenverstand werden wahrscheinlich die erste Variante wählen...
Ich will hier aber keine dreckige Wäsche waschen, sah es nur als notwendig an, etwas klar zu stellen.
Damit ist das Thema hier im Forum für mich beendet, es sei denn, jemand stellt unwahre Behauptungen im Zusammenhang mit meiner Arbeit auf.
-
Lieber Frank
Deine Ausdrucksweise zeigt sehr eindeutig das dich irgendwas in der Zusammenarbeit mit dem Dev Team sehr verärgert oder verletzt hat. Allerdings ist es auch schwierig auf einen Post wie deinen Letzten angemessen zu reagieren (vor allem weil dieser voller Beleidigungen steckt) Ich kann dir nur nochmal anbieten lass uns das im persönlichen Gespräch klären.
Ansonsten währe vielleicht darauf hinzuweisen das Du die öffentliche Diskussion selber gewählt hast und wenn du weiterhin diesen Ton anschlägst du deine fachliche Kompetenz nur selber entwertest. :-(
-
Mit der deutschen Sprache im Allgemeinen und der Semantik im Besonderen scheint in diesem Forum mittlerweile mehr als nur einer Probleme zu haben. Das sich beleidigt fühlen wird -wie es gerade genehm ist- einer Beleidigung gleichgesetzt. Falsche Tatsachenbehauptung en könnte man beanstanden. Schmähkritik ist jedenfalls keine zu sehen, Justiziables schon gar nicht.
Da ich selbst aus dem Forum wg. angeblicher Beleidigung ausgeschlossen wurde, war mir mein Kommentar hierzu doch wichtig. Ansonsten bleib' ich wie gehabt draußen, da ich mich selbsternannten Hausmeistern, ohne jegliche Qualifizierung in der Moderation, nicht weiter aussetzen werde. Dafür ist mir das Niveau nun doch zu unterirdisch.
Trotzdem einen schönen Tag noch.
-
Das ist gelogen (vielleicht auch versehentlich, weil das Wissen fehlt). Verbreitung von Halbwahrheiten scheint sich hier ja immer mehr durchzusetzen, nur bei Sicherheitslücken sollte man sich so was verkneifen.
Gell, Frank, jetzt lernst Du es am eigenen Leibe kennen, wie das so läuft...
-
Manchmal braucht es einfach nur die richtigen Themen, um wieder Schwung ins Forum zu bringen!
:evil: