SVN Rev 1846

[easyuser]

Kein Black-Box/ Kein Politischer Test:

Durch die Änderungen in Rev. 1846 wird eine public_16.png als Icon verlangt.
Dieses Icon hießt allerdings visible_16.png, was nicht in $aPage['visibility'] vorhanden ist.

Durch Zeile 294 ist jedes Seiten-Icon public, egal welche Visibility es hat!
Diese is_readable Abfrage sollte raus.

[fischstäbchenbrenner]

Jo.
Notice: Undefined variable: sText in ...\admin\pages\PageTree.php on line 297

News-modul -> Kommentar hinzufügen:
Fatal error: Call to undefined method wb::page_select() in ....\index.php on line 54

[easyuser]

Jo.
Notice: Undefined variable: sText in ...\admin\pages\PageTree.php on line 297

News-modul -> Kommentar hinzufügen:
Fatal error: Call to undefined method wb::page_select() in ....\index.php on line 54

Bestätigt. APACHE 2.4.2, MYSQL 5.5.27, PHP 5.4.8.

Und ich bitte einmal darum, wenigstens diesen Community-Test Thread nicht zu löschen/verschieben.
 
Ich will nicht den Titel "Beta Tester" führen, dies habe ich dem Vereinsvorstand bereits gesagt.
Ich will lediglich, dass 2.8.4 noch weniger Bugs enthält, als es eh schon der Fall ist.

Ich für meinen Teil halte hier Kritik - die in anderen Threads auftauchen - zurück.

[badknight]

Jo.
Notice: Undefined variable: sText in ...\admin\pages\PageTree.php on line 297

News-modul -> Kommentar hinzufügen:
Fatal error: Call to undefined method wb::page_select() in ....\index.php on line 54

Ist bereits bekannt, danke

Die aktuellste Rev muss erst hoch gespielt werden - darin wurden noch einige bugs behoben

[easyuser]

In Rev. 1848 sind alle genannten Probleme behoben. Ging aber schnell - super!

[DarkViper]

Diese is_readable Abfrage sollte raus.

An den Symtomen doktern nutzt nix, wichtiger ist es, die Ursachen dafür zu beheben. 
Das ist inzwischen erledigt.
Die noch fehlenden 2 Icons sind auch ergänzt.

Notice: Undefined variable: sText in ...\admin\pages\PageTree.php on line 297

Sorry, mea culpa. Hab ich anscheinend im Halbschlaf die Ersetzung dafür vergessen. Ist auch behoben.

News-modul -> Kommentar hinzufügen:
Fatal error: Call to undefined method wb::page_select() in ....\index.php on line 54

Ist behoben. Ursache war das zirkuläre Einbinden der /index.php im news-comment Modul. Dadurch war das $wb Objekt noch eine Instanz von wb und nicht wie erforderlich von frontend. Folglich fehlten auch die Methoden aus der Klasse frontend.


Ein grundsätzlicher Hinweis:
Fehlermeldungen zum aktuellen SVN (nicht zum veröffentlichten Release) bitte NUR in den Betatester Bereich schreiben. Uns fehlt einfach die Zeit, Fehlermeldungen zu unveröffentlichten Releases  quer durch das ganze Forum zusammenzusuchen. Zusätzlich gehen sie im Forum mit der Zeit unter und sind später fast nicht wieder auffindbar.

[easyuser]

Ein grundsätzlicher Hinweis:
Fehlermeldungen zum aktuellen SVN (nicht zum veröffentlichten Release) bitte NUR in den Betatester Bereich schreiben. Uns fehlt einfach die Zeit, Fehlermeldungen zu unveröffentlichten Releases  quer durch das ganze Forum zusammenzusuchen. Zusätzlich gehen sie im Forum mit der Zeit unter und sind später fast nicht wieder auffindbar.

Wie bereits gesagt - ich (und viele andere) haben keinen Zugang.

Diese is_readable Abfrage sollte raus.

An den Symtomen doktern nutzt nix, wichtiger ist es, die Ursachen dafür zu beheben.  
Das ist inzwischen erledigt.
Die noch fehlenden 2 Icons sind auch ergänzt.

War nur ein Quick&Dirty Fix. Ich stecke nicht so tief im Code, um die Auswirkungen zu kennen - wobei das Symptom in Rev. 1847 natürlich Sinn macht.

[Stefek]

Wie bereits gesagt - ich (und viele andere) haben keinen Zugang.

Michi, ich kenne mich mit der Forensoftware nicht aus, daher weiß ich es nicht: ist es überhaupt möglich, dass dieser geschloßene Bereich ohne explizite Gruppenzuweisung und somit auch einem Eintrag unterm Avatar zugänglich ist?
Falls ja, würde ich es auch für richtig empfinden, interessierten Testern einen obligationsfreien Zugang dorthin zu verschaffen.

[badknight]

Es kann jeder Beta-Tester werden, einfach Luisehahne eine Nachricht senden und fertig..

Wenn jemand das Beta-Tester nicht stehen haben will, ist es auch kein Problem - schreibt es doch einfach in die Nachricht dazu und das Problem hat sich erledigt

[easyuser]

In Rev. 1851 wurde wohl nichts hochgeladen, außer mein Android  Chrome zeigt nichts an.

Btw schnelle Reaktion!

dann nur noch CKeditor aktualisieren. 

[DarkViper]

naja, so'n SVN ist ein Weg mit Gegenverkehr... manchmal wird auch was gelöscht..
http://project.websitebaker2.org/projects/wb28x/repository/revisions/1851

[easyuser]

naja, so'n SVN ist ein Weg mit Gegenverkehr... manchmal wird auch was gelöscht..
http://project.websitebaker2.org/projects/wb28x/repository/revisions/1851

Jo grade gesehen. Noch lustiger ist hier git. =-O

[easyuser]

Zur Revision 1860 habe ich eine kurze Frage:

Es steht im SVN-Kommentar:
"initialize and activate class Translate in /framework/initialize.php"
Allerdings finde ich in der initialize.php keinen Verweis / Instanz von Translate.

Kommt das Benutzen der drei neuen Translate-Classes noch in der 2.8er, oder ist es lediglich für späteres Freischalten in 2.9er (kann ja sein, bitte nicht wertend verstehen)?

[DarkViper]

die initialize kommt noch, genauso wie eine Doku dazu.
Die Translate ist ab der 2.8.4 aktiv. Die beiden anderen Klassen sind eigentlich nur Hilfsklassen zur Translate.
Sie können ab sofort von neuen/überarbeiteten Modulen direkt genutzt werden. Auch stellen sie eine einfachere Möglichkeit zur Übergabe der Übersetzungen an Twig zur Verfügung.

[easyuser]

Ok super - ging ja schnell!
Auf den ersten Blick sind alle Probleme mit dem Interface beseitigt (tze, warum ist mir das nicht aufgefallen....) - daher habe ich meine Beiträge auch gelöscht.
Weitere Tests dann morgen.

[easyuser]

Ich hätte noch zwei Vorschläge (einen habe ich gestern noch gelöscht...):

1.) Im Root der SVN (und damit wohl auch im Download-Paket von WB) gibt es immer mehr Dateien. Das ist natürlich super - mehr Dokus sind auf jeden Fall gut.
Allerdings werden es immer mehr Dateien. Warum nicht parallel zum "wb" Ordner im Root z.B. einen Ordner "docu" aufmachen und dort alle Dokumentations-Dateien hineinladen? Ändert ebenfalls nichts an der Vorgehensweise, nur den "wb" Ordner auf den Webspace hochzuladen. Wenn der Docu-Ordner noch nach Sprachen getrennt wäre, könnte man vielleicht sogar einmal dort eine Navigation einbauen usw. Das dann natürlich für spätere Versionen.

2.) Die Exception gestern war auf weißem Hintergrund ohne Mehr-Informationen. Ich fände es für den Admin (und sogar für den Besucher) besser, wenn man im Frontend / Backend-Template eine "exception-Seite" erstellen könnte.
Einfacher Rahmen ohne Menü usw. (weil wenn Exception sollte kein PHP mehr gebraucht werden).
Das bringt "schönere Fehler" (gut, der Fehler bleibt derselbe, aber der Rahmen drumrum) und es ist offensichtlicher, dass der aufgetretene Fehler zu WB und nicht zum Webserver gehört.
Ich weiß auch nicht ob es möglich ist in PHP, analog zu komplexen Programmiersprachen einen "Stacktrace"  (wo ist der Fehler in welcher Zeile von welchen Dateien überall aufgetreten?) in der Fehlermeldung von Exceptions mitzuliefern. Sicher gibt's auch hier Für- und-Wider. Ich fände es praktisch.

[DarkViper]

1.) Im Root der SVN (und damit wohl auch im Download-Paket von WB) gibt es immer mehr Dateien.
...

Das PDF hab ich nur da rein gepackt, damit's jeder mitbekommt. Auf Dauer sollen die ganzen Dokufiles ins Redmine rein. Ist nicht sinnvoll, das Installationspaket damit auch noch aufzublasen.

2.) Die Exception gestern war auf weißem Hintergrund ohne Mehr-Informationen. Ich fände es für den Admin ...

Erweiterte Meldungen(incl. Trace) gibt's mit DEBUG = 1
Die 'Schönheitsfehler' werden noch bereinigt, da das Exceptionhandling erst noch im Aufbau ist.
Die Meldungen selbst werden jedoch weiterhin direkt im Ex-handling fest gecoded.
Warum? Wurde eine Exception geworfen, dann ist irgendwas mächtig schief gegangen und ich kann mich nicht mehr darauf verlassen, dass alles, was zur schön aufbereiteten Anzeige per Template etc. benötigt wird, noch funktioniert.

[cwsoft]

SVN 1869
Keine Neuinstallation möglich. Fehlermeldung von install/save.php:
Fatal error: Class 'Translate' not found in framework\initialize.php on line 283

Nach auskommentieren oder voriges einbinden der Klasse Translate in initialize.php läufts.

[DarkViper]

SVN 1869
Keine Neuinstallation möglich. Fehlermeldung von install/save.php:
Fatal error: Class 'Translate' not found in framework\initialize.php on line 283
Nach auskommentieren oder voriges einbinden der Klasse Translate in initialize.php läufts.

Bin dabei das seltsame Verhalten des Autoloaders in verbindung mit der /install/save.php zu ergründen.
Innerhalb von WB.Frontend oder -Backend treten diese Fehler nicht auf.
Denke, dass ich zum Frühstück eine Lösung habe.

[cwsoft]

Denke, dass ich zum Frühstück eine Lösung habe.

Scheint Du hast die Lösung mit REV 1870 gefunden - danke

[easyuser]

@Werner:
Danke für die Infos!

Ich dachte hier eher an eine "warning.html" ohne PHP als an Templateengine bei der Exception-Behandlung. Also ein Template kann eine "exception.html" mitliefern (wie-auch-immer), und da drinnen werden dann exceptions angezeigt. Ob das allerdings den Aufwand wert ist weiß ich nicht. Du hast natürlich Recht - eine Exception sollte gar nicht erst auftreten.

Nur so eine Frage:
Es gibt ja mit jQuery UI einen netten Datepicker - auch mit Zeitwahl: http://trentrichardson.com/examples/timepicker/
Ist es geplant, den mitgelieferten, doch recht angestaubten Datepicker im Backend (also für Zeiten) auszuwechseln?

Ansonsten mache ich gerade mit / für Rev 1870 ein Modul (jsAdmin mit jQuery), sieht bisher alles reibungslos aus.

Gerade der neue Seitenbaum ist codetechnisch ein Quantensprung - das Dickicht wurde zumindest etwas gelichtet. Wobei es natürlich viel anders zu entdecken gibt wie das komplett neue Backend-Theme-Handling.
Das mit der neuen Translation habe ich trotz Lesen des .PDFs nicht wirklich verstanden (das Raster schon, nur wie es in der Praxis angewandt wird), hier sollte einfach bei Gelegenheit ein Beispiel-Modul erstellt werden.

[DarkViper]

@Werner:
Es gibt ja mit jQuery UI einen netten Datepicker - ...

Durch die konsequente Umstellung auf Twig wird es in Zukunft (von Seiten des Core) überflüssig, derartiges mitzuliefern. Das ist dann reiner Bestandteil des jeweiligen Templates. Also wesentlich mehr Freiheiten und Unabhängigkeit für die Designer.
Wobei wir natürlich im Standard-Template/Theme was passendes mitliefern.

Gerade der neue Seitenbaum ist codetechnisch ein Quantensprung - das Dickicht wurde zumindest etwas gelichtet.

Das ist erst der erste Schritt. Als nächstes wird er noch gestrafft und auf Twig ausgerichtet. Die Darstellung liegt dann zu 100% beim Templatedesigner.

Das mit der neuen Translation habe ich trotz Lesen des .PDFs nicht wirklich verstanden (das Raster schon, nur wie es in der Praxis angewandt wird), hier sollte einfach bei Gelegenheit ein Beispiel-Modul erstellt werden.

Die Übersetzungen aus den Haupt-Sprachdateien stehen jetzt schon automatisch zur Verfügung. Einfach nur die Instanz von Translate holen und daraus die Texte abrufen.
z.B.:
normal im PHP
$oLang = Translate::getInstance();
echo $oLang->TEXT_CANCEL;
oder im Template eben:  {{ Translate.TEXT_CANC EL }} zu deutsch etwa: "übersetze: TEXT_CANCEL"
Bei Modulen ist es durch die vielen unterschiedlichen Einsprungpunkte etwas komplexer(zumindest in der 2.8er Serie) Aber ich denke, dass Daniel(badknight) auch dafür etwas im Hilfebereich der HP einbauen wird.
Ab 2.9 wirds einfacher, da hier der Core die komplette Sprachverwaltung übernehmen kann und sich der Modulautor diesbezüglich um nichts mehr kümmern muss(ausser Übersetzungen bereitstellen).

yep, es gibt noch viel zu tun...  mach mer weiter

[easyuser]

Abermals danke für die Ausführungen. Twig ist natürlich eine gute Wahl.  


Ich habe noch einen Bug, sicher ein Spezialfall:
- Zu einer Section gibt es keinen WYSIWYG-Datensatz in mod_wysiwyg.
- Ich kann wie gewohnt die Seite im Backend / Frontend aufrufen und speichern.
- Beim Speichern kommt der Hinweis "Erfolgreich aktualisiert".
- In der Datenbank ist nichts zu finden.

Vorschlag:
- Prüfe ab, ob Ziel-Datensatz vorhanden ist
- Wenn ja -> Wie gehabt
- Wenn nein -> Versuche Datensatz anzulegen (ist letztendlich ja nur Page_id, Section_id, content & text)
[[OffTopic: Warum eigentlich PAGE_ID? Über die Section-ID bekomme ich doch immer die PAGE-ID. Redundante Infos nach meinem Verständnis.]]
- Wenn auch das Fehlschlägt ->Gebe Fehlerhinweis, nicht Erfolgshinweis.

Die Supporter später werden's danken.  

[DarkViper]

Abermals danke für die Ausführungen. Twig ist natürlich eine gute Wahl.  

Ich habe noch einen Bug, sicher ein Spezialfall:
- Zu einer Section gibt es keinen WYSIWYG-Datensatz in mod_wysiwyg.
- Ich kann wie gewohnt die Seite im Backend / Frontend aufrufen und speichern.
- Beim Speichern kommt der Hinweis "Erfolgreich aktualisiert".
- In der Datenbank ist nichts zu finden.

sollte in der neuen Version eigentlich behoben sein.

[[OffTopic: Warum eigentlich PAGE_ID? Über die Section-ID bekomme ich doch immer die PAGE-ID. Redundante Infos nach meinem Verständnis.]]

Das sind uralte Altlasten noch aus der Anfangszeit. Wir haben das bisher bewusst nicht bereinigt, da das Auswirkungen in alle Module hat. Im Ganzen gibt es da noch ein paar mehr dieser Problemchen.

[easyuser]

Das sind uralte Altlasten noch aus der Anfangszeit. Wir haben das bisher bewusst nicht bereinigt, da das Auswirkungen in alle Module hat. Im Ganzen gibt es da noch ein paar mehr dieser Problemchen.

Jo denke ich mir...

sollte in der neuen Version eigentlich behoben sein.

Leider nein. Revision 1872, frisch gezogen, upgrade-script ausgeführt, ist es weiterhin der Fall.