Dank für Unterstützung an WAN Gesellschaft für Werbung, Werbeagentur Man-At-Work, External - Webhosting|Webdesign|Domain, Nicole Weiß - Webstylisten.de
Druckbare Version
Dank für Unterstützung an WAN Gesellschaft für Werbung, Werbeagentur Man-At-Work, External - Webhosting|Webdesign|Domain, Nicole Weiß - Webstylisten.de
Bei Attribute ContentArticle und transContentArticle wurden die Queries auf den queryBuilder umgeschrieben und sind nun "MM 2.2 ready" - siehe https://github.com/MetaModels/core/issues/1424
Levenshtein-gestützte Suche (Ähnlichkeitssuche):
- Einstellmöglichkeit der Wortlänge (min + max), die im Index gesucht wird
- Erklärung zu den Einstellmöglichkeiten beim Attribut
- Autovervollständigung beim FE-Widget der Suche Umstellung von Mootools auf „Vanilla Script“ somit unabhängig von Mootools - Auswahl des (neuen) Templates beachten
- Autovervollständigung bei Einstellungen der Filterregel kann abgeschaltet werden und minimale Buchstabenlänge kann angegeben werden
- DB-Abfragen auf queryBuilder umgeschrieben
- alle Queries mit Tabellenpräfix damit kein Fehler bei reservierten Wörtern auftaucht
Dank für Unterstützung an DAG-Entertainment, Pfeffer & Stift und Federkiel & Friends
Hallo Zonky, ich hoffe du verzeihst die Frage.
Es mag irgendwo stehen, dann ist es mir entgangen.
Die Zielsumme des Fundraisings ist immer wieder gestiegen.
Die gesammelte Summe laut Website ist mittlerweile mehr als doppelt so hoch, wie die anfangs als Ziel angegebene Summe.
Jetzt ist das Ziel 80000 €, es waren zwischendurch schon mal 80% der Summe gesammelt, jetzt sind es nur noch 50%.
(Es gibt auch für das schon abgeschlossen Fundraising zu MM 2.1 den Effekt, dass nur noch 61% des Betrags gesammelt wurden.)
https://now.metamodel.me/de/unterstuetzer/fundraising
Du verstehst was ich meine...? Ich kann verstehen, wenn man das Ziel anpassen muss, aber was sind die Gründe dafür, dass es mittlerweile mehr als das 4 Fache des ursprünglichen Ziels ist?
Ah!- die Sachen werden gelesen, die schreibe... :D
Bei MM 2.1 war ursprünglich eine Summe von 15k geplant - dann ist noch der Umbau des DCG hinzu gekommen, aber die Sachen wurden eigentlich nicht korrekt auf der Webseite angepasst.
Ich habe mir heute nochmal die Aufzeichnungen vorgenommen und die "echten Zahlen" eingepflegt. Dabei wird von einem Stundensatz von 80€ (Netto) ausgegangen, der i.E. der Durchschnitt der beteiligten Entwickler darstellt.
Bei MM 2.1 waren es 669,5 Arbeitsstunden "über Alles" und dem gegenüber gestellt auch die Zuwendungen "über Alles" von ca. 32,8k€ - macht ~61% Finanzierung der Arbeit.
Die prozentuale Höhe der Finanzierung wurde in den News auch ab und an so erwähnt z.B. Oktober 2018
Die restlichen ~39% haben wir als Entwickler in Form von Zeit für das Projekt auf- bzw. eingebracht...
Bei MM 2.2 wurde die Zielsumme (intern) nicht fix gemacht, weil das mit überschaubarem Aufwand gar nicht möglich gewesen wäre. In unserem Ticketsystem steht die "Uhr" aktuell auf 910h und die restlichen Arbeiten sind nun überschaubar. Derzeit muss nur noch am Core gearbeitet werden - der Rest ist, wie in den News geschrieben, MM ready.
Für diejenigen, die bei den Zahlen "dicke Backen" machen, folgende Hinweise: MetaModels besteht aktuell aus ~43 Repositories - hinzu kommen der DC_General und noch ein paar aus dem CCA-Umfeld. Wenn man die Gesamtzeit auf die knapp 50 Repos verteilt, sieht dann der Aufwand dann schon mit ~20h/R schon wieder greifbarer aus. Beispiel: weil Travis keine Freiminuten mehr vergibt, wird alles auf Github-Actions umgestellt - das muss dann eben auch 43+ mal gemacht werden... Alle Queries auf queryBuilder und "strict-save" umschreiben - auch 43 mal ... usw. Zu den "unsichtbaren" Sachen sind auch viele Fixes und Features in 2.2 hinzu gekommen.
Zudem kommt bei der größe des Projekts ein nicht unbeachtlicher Teil an Projekt- und Finanzierungsmanagement + Testing + Support hinzu, der bei MM 2.1 etwa bei 34% lag.
Wir werden bei MM 2.2 sicher nicht auf die 100% der Finanzierung warten - wann wir den Cut machen, ist noch nicht festgelegt. Zudem wird ja auch schon an MM 2.3 für Contao 4.13 gearbeitet.
An der Stelle auch nochmal einen Dank an die vielen Unterstützer unseres Early-Adopter-Programms und auch der Hinweis, dass wir immer auch auf der Suche nach helfenden Köpfen und Händen sind.
Ich hoffe, ich konnte einen kleinen Einblick in (wahre) Aufwand- und Kostenstruktur geben - bei weiteren Fragen gern auf Slack oder Mumble mich/uns mal anpingen.
Gruss zonky
Danke für die Antwort und auf jeden Fall, generell danke für die ganze Arbeit von allen Beteiligten.
Ich will weder MM noch die geleistete Arbeit kritisieren.
Ich erinnere mich, dass das schon kommuniziert wurde, dass bei weitem nicht 100% der Arbeit durchs Fundraising gedeckt wurde/wird.
Es geht mir auch nicht um den Betrag an sich. Wenn es 80.000 € sind, ist es so.
Auch verstehe ich absolut, dass es schwierig ist das komplett abzuschätzen, deshalb schreibe ich auch, dass ich gewisse Anpassungen durchaus verstehe.
Aber ich hoffe auch, dass du verstehst, dass das auf der anderen Seite so wenig transparent ist. Das motiviert auch nicht (jetzt oder in Zukunft) dazu eine Summe unterhalb des EAP zu geben oder den EAP-Zugang für ein(zelne) Projekt(e) zu kaufen in der Hoffnung andere Projekte profitieren davon. Eine Aussage, 50 oder 65 % der (aktuellen) Summe wurde erreicht, verliert dann jegliche Bedeutung.
Zumindest meiner Ansicht nach funktionieren Fundraisings (mit Zielsumme) anders und man hätte das vielleicht dann anders angehen bzw. kommunizieren können (gerade wenn du schreibst intern war das von Anfang bekannt), denn so halte ich das für nicht ganz glücklich gelöst. Zumindest ich habe es auf die Art wohl missverstanden.
Vielleicht einfach als Vorschlag verstehen, das bei einem möglichen nächsten Fundraising (2.3, ...) noch mal neu zu überlegen.
Das steht aktuell nicht zur Diskussion...Zitat:
Zitat von Znrl
MM 2.2 steht seit etwa November/Dezember 2019 zur Verfügung und konnte seit dem - nach entsprechender Zuwendung - sofort eingesetz werden. Ergo: wir Programmierer sind in Vorleistung gegangen mit der "Wette", dass die Erweiterung jemand haben möchte.
Anhand der Zuwendungssumme kann man i.E. abschätzen, wieviele Live-Projekte seit der Zeit damit laufen (die "Sozialprojekte" noch mit dazu). Von daher halte ich es erstmal irrelevant, wann die Summe erreicht wird und wann nicht - eine frühere Freischaltung und dann weiteres Fixing und Features über Spenden dazu ist eine schöne Idee. Meine Erfahrung und Test verschiedene Varianten (seit ca. 2015) haben aber gezeigt, dass das so nicht funktioniert. Die Zuwendungen sind dann N U L L!
Das zeigt Dir z.B. ein Blick auf den ersten Post zum Handbuch - Blick auf die Zahlen und du siehst, was ich meine...
Im klassichen Fundrasing - erst Geld einsammeln und dann machen - wären wir aktuell für MM 2.2 auf dem Stand von etwa Anfang 2019 und hätten jetzt noch nicht eine Codezeile. Wäre das die bessere Position?
Ich sehe MM als ein Tool, welches es Freelancern oder Agenturen ermöglicht ohne Programmierung etwas in die Webseite einzubauen, was sie mit mehr Aufwand oder Fremdkosten erstellen müssten und was in den meisten Fällen den Benefit der Seite erhöht. Alles was man mit MM machen kann, kann ein guter Programmierer auch so erstellen. Zu welchem Aufwand/Kosten kann jeder für sich ausrechnen...
Welche Zuwendungssumme unterhalb der 350€ - also ein "halber Programmiertag" - hättest Du im Sinn? 200€? 100€?
Bei den Experimenten zum klassichen Fundrasing waren auch schon Beträge von 20€ dabei - Brutto! Wenn ich die Zeit für Buchung, Rechungstellung usw. abziehe, landen wir bei einer Größenordung eines kleinen Espresso. Damit kann man seine Anerkennung für einen Slider, o.Ä. zum Ausdruck bringen - aber nicht mehr. Btw: die Zuwendung bei MM 2.1 startete bei 1.000€ - später dann 500€ (für DCG).
Was ich an Feedback von den EAPlern bekomme, sind die bisher sehr zufrieden mit dem Vorgehen. Zumal bei Problemen/Bugs diese immer an Prio 1 stehen und supportet werden.
Für eine Änderung der Vorgehensweise sehe ich erstmal keine überzeugenden Argumente - aber ich/wir sind da hoffen für...
Ich glaube in manchen Punkten reden wir aneinander vorbei, ich verlange gar nicht eine frühere Freigabe oder eine Änderung beim EAP. Ihr habt euch da sicher Gedanken gemacht.
Im einfachsten Fall meine ich mit anderem Vorgehen, dass man auf eine "Zielsumme", solange man diese nicht mit einer gewissen Sicherheit sagen kann, verzichtet. (Oder eine sehr hohe nimmt, mit entsprechendem Hinweis.)
Also tatsächlich offenes "work in progress" Fundraising. Dann kann man auf der Fundraisingseite schreiben, das derzeit einfach keine Aussage zum benötigten Betrag gemacht werden kann. Also ein transparenteres Vorgehen. Dann gibt es immer noch die Möglichkeit irgendwann quasi ein "Endspurt"-Fundraising mit realistischem Ziel zu starten.
Ich hab eben den Fehler gemacht, dass ich versucht habe mit dem in Aussicht stehenden Ziel bei ein paar kleineren Projekten zu werben. Es geht hier eher um jeweils 25 bis 100 € mehr sind oft nicht drin, es sind bei mir eher Projekte im ehrenamtlichen/Hobby oder nebenberuflichen Bereich. Wenn dann beim nächsten Treffen, das Ziel vom fehlenden Betrag sogar weiter entfernt ist, als zuvor stößt das aber auf wenig Verständnis.
Natürlich hätte ich direkt hingehen sollen und nicht mit dem Fundraising sondern der generellen Unterstützung werben, oder es gar nicht erwähnen und einfach entsprechend mehr verlangen sollen.
Andere Möglichkeiten (siehe Isotope circles, perks/bundling, (kommerzielle) Lizenzen...) kann ich auch nicht einschätzen und manche würden natürlich noch zusätzliche Arbeit bedeuten. Ich weiß nicht wie viele "kleine" bzw. nicht EAP Nutzer Metamodels einsetzen und mit was man diese dazu bekommen könnte sich zu beteiligen (oder das mitzuteilen), da bist du wahrscheinlich näher dran.
Wie gesagt ich will auch nicht über die Summe oder die Art der Freigabe diskutieren. Mit überdenken, meine ich erst mal lediglich das Vorgehen, ein Ziel zu setzen und zu kommunizieren und in dem Ausmaß, wie es dieses mal vorkam, wieder und wieder zu verschieben. Ein Ziel vermittelt eben den Eindruck, dass etwas durch Erreichen abgeschlossen ist.
Ich weiß das ist jetzt sehr hypothetisch, aber was wäre gewesen, wenn jemand irgendwann während der letzten 2 Jahre den "fehlenden" Betrag überwiesen hätte, in der Hoffnung das Fundraising damit abzuschließen?
Zu A: Hintergrund der Angabe der "echten Zahlen" war u.A. die Diskussion beim Camp über Finanzierung, Projektaufschlüsselung usw.Zitat:
Zitat von Znrl
Zu B: letztendlich will der Kunde eine bestimmte Funktionalität für die Seite haben - wie Du das machst (MM oder eigenes Bundle), ist dem in den meisten Fällen egal. Also musst Du je nach Programmierwissen und Aufwandsabschätzung eine Entscheidung treffen. Das gilt auch bei Hobbyprojekten oder NGO-Seiten. Wenn keine 350€ da sind, kann man das Feature nicht haben oder muss eben warten. Die Frage die man sich selbst stellen muss ist doch, um wieviel schneller bin ich mit MM statt eine eigene Erweiterung/Bundle zu programmieren?
Meine Erfahrung und die einiger EAPler ist, bei einer Kostenaufstellung das Fundrasing nicht zu erwähnen - ist eher unverständlich/kompliziert für die meisten.
Zu C: Wechsel auf kommerzielle Lizenz geht rechtlich nicht. Letztendlich machen wir "Circle" auf etwas andere Art: wie viele berichten läuft MM 2.1 auch unter Contao 4.9 - mit gewissen Einschränkungen und ohne Support. Alle EAPler sind "inner circle" und haben die Sicherheit, dass alles läuft sowie neue Features und Support...
Zu D: Als Nachtrag oder Kompromiss zu den bisherigen Angaben ist das vielleicht besser:
Status:
Finanzierung: 50%
Code: 90%
Wie gesagt, zum Vergleich zum normalen Fundrasing war MM 2.2 seit Beginn an (11/2019) einsetzbar...
Und ja, wenn ein "weißer Ritter" für die Übernahme gekommen wäre, hätte es eine entsprechende Lösung gegeben - bisher klopften nur die "Knappen" an die Tür ;-)
Als letztes Repo wurde der Core auf queryBuilder umgebaut - immerhin 27 Dateien... also nach dem Update bitte nochmal alles checken!
Damit wurde in alle Queries ein Tabellenpräfix eingebaut und somit ist auch die Prüfung auf "MySQL reserved words" obsolet und wurde entfernt.
Zudem wurde das Template mm_filter_default sowie alle mm_filteritem_* umgebaut - Hintergrund ist das bisher invalide HTML-Markup siehe Issue #347 ggf. eigene Templates anpassen.
Es tut mir leid, dass ich jetzt doch noch mal antworte, ich hoffe ich verursache damit Drama. MM ist mehr als praktisch und verdient alle Einnahmen und Hilfen.
Zu B:
Genau das mache ich, ich warte und damit habe ich auch kein Problem. Zwei Projekte wurden z.B. unter MM 1.1/2.0 gestartet und ich nutze dort jetzt 2.1 unter 4.9 mit den Bugs, die es eben gibt. Es ist da nicht immer so einfach zu sagen die 350 € sind nicht da, also geht es nicht, die generelle Entscheidung für MM wurde vor den Fundraisings getroffen.
Es geht mir aber auch wie bereits geschrieben nicht um einen Zugang.
Zu A und D:
Ist alles OK, danke für die Aufschlüsselung.
Wären von Anfang an (z.B.) 50.000 oder 80.000 € dagestanden hätte ich hier jetzt nichts geschrieben.
Vielleicht hätte es auch schon eine kurze Begründung in den News/auf der Fundraisingseite getan. "Die Zielsumme wurde angepasst, weil ... "
Für die letzte Änderung hast du es jetzt erklärt, damit sind die Zahlen mit den vorherigen natürlich nur bedingt vergleichbar. Solche Infos wären natürlich direkt auf der Fundraising-Website interessant.
So bleibt das mein Kritikpunkt. Nicht der Stand jetzt, sondern der Weg dort hin.
Es wird Geld eingesammelt und da denke ich bedarf es etwas Transparenz. Wenn du schreibst intern wurde das anders kommuniziert als nach außen, ist das in meinen Augen eben nicht transparent und das Fundraising mit Zielsumme irgendwie irreführend. Immerhin stehen auch hier im Thread Aussagen, wie 50% oder 68% erreicht, was sollen wir sonst aus solchen Aussagen zukünftig schließen?
Wie geschrieben, die Summe stand zum Start nicht fest nicht fest und die bisherige MM-Webseite ist für sowas nicht angelegt - wer Lust und Zeit hat kann uns da gern unterstützen.Zitat:
Zitat von Znrl
Ich finde, MM ist da schon sehr kommunikativ und veröffentlicht Aufwand und Einnahmen recht offen. Da der Part bei uns im Team dann doch bei mir hängen bleibt und ich auch noch andere "produktive" Sachen machen möchte, muss ich irgendwo einen Grenze ziehen. Das wars dann auch für mich zu dem Thema.
Gestern wurden nochmal eine Vielzahl an Tickets abgearbeitet bzw. eingespielt. An erster Stelle steht die neue Unterstützung der Locale-Angaben bei den Sprachen, d.h. de-CH, de-DE, en-US usw. werden nun unterstützt. Da die Umstellung recht umfangreiche Änderungen erfordert hat, bitte nach Update entsprechend testen. Eine vorhandene Spracheinstellung beim Model sollte natürlich nicht einfach geändert werden - die Sprachschlüssel in den Übersetzungstabellen ändern sich damit nicht automatisch und müss(t)en eigenständig angepasst werden. Bitte auch folgende Hinweise beachten.
Im Backend ist in der Listendarstellung nun wieder eine Überschrift zu sehen und auch der Title-Tag wird wieder befüllt.
Attribute die als Variante definiert wurden, haben in der Listenansicht der Attribute einen entsprechenden Hinweis.
Die Umstellung auf queryBuilder und Tabellen-Präfix ist abgeschlossen und die Prüfung auf "MySQL-reserved-words" wurde entfernt.
Die Templates für die Filter wurden für eine sauberes Markup umgebaut - siehe Github-Issue - ggf. eigene Templates anpassen.
... und viele kleinere Anpassungen und Fixes.
Bei Alias und translated Alias muss man beim Erstellen des Attributes nicht mehr erst 1x speichern, um bei der MCW-Attributsauswahl weitere Zeilen hinzufügen zu können...
Bei Komb-Werten und und trans-Komb-Werten muss man beim Erstellen des Attributes nicht mehr erst 1x speichern, um bei der MCW-Attributsauswahl weitere Zeilen hinzufügen zu können...
Wenn Autocomplete vom Attribut bei dem Filterwidget an ist, wird nun automatisch das Autocomplete des Browsers für das Eingabefeld abgeschaltet...
Thx @ MacKP
Dank für die Unterstützung an XIMA Media, Kuratorium Junger Film - KJDF und Paus medien
Der Bug bei den Ansichtsbedingungen ist gefixt - siehe https://github.com/MetaModels/core/issues/1465
btw: das war das letzte Issue zu 2.2 :D
Alle grundlegenden Repos aus dem CCA-Umfeld wurden released. Dazu gehört auch der DC_General (DCG) bei dem noch drei PRs eingepflegt wurden.
Dank für die Unterstützung an netcontact und Monotomic
Info zum Attrtibut(Filter)-Levenshtein:
* Das automatische Abschalten des Autosubmit bei CE/Modul-MM-Filter wurde entfernt - durch die neuen Einstellungsmöglichkeiten ist das nicht mehr notwendig
* Bei den Filtereinstellungen kann aktiviert werden, dass bei Klick auf ein Autosubmit-Eintrag das Formular gleich abgesendet wird
Nochmal der Hinweis: für das Autocomplete muss das entsprechende Template gewählt werden; das Autocomplete kann aber auch per Checkbox abgeschaltet werden
Es gab einige Fixes beim Core und Attributen...
u.A. bei den Ansichtsbedingungen für die Widgets der Eingabemaske: dort wird nun auch eine "Nicht Auswahl" z.B. eines Select- oder Tags-Parameters korrekt ausgewertet, d.h. wenn als Bedingung "Nichts" ausgewählt wurde, ist das Widget sichtbar - solange bis was ausgewählt wurde ... das erspart einen NOT-Opperator
Fixes bei Tablemulti und translated Tablemulti ("MCW") bei den Templates
beim Rating gab es einen Fix beim JavaScript - da war noch eine MooTools-Altlast bei...
Im Debugmodus wird automatisch auf die unkomprimierte Version umgestellt - wer das nicht möchte, kann das Template anpassen.
siehe Handbuch https://metamodels.readthedocs.io/de...ade-auf-mm-2-2
Dank für die Unterstützung an Paus medien, Kromosom, External IT-Solutions und Men-at-work
Dateiupload für das FrontendEditing wurde überarbeitet - nun gehen nun alle Features wie dynamische Pfade und Dateinamen sowie sind Sortierung und Thumbnaileinstellung sind als Einstelloption hinzu gekommen...
* neue Features für "Territory" und Inserttag-Verschachtelung bei "Eig. SQL" => siehe News https://now.metamodel.me/de/aktuelle...2-august-infos
Wenn ein Attribut gelöscht wird, wird nun automatisch eine ggf. angelegte Ansichtsbedingung bzw. Sortierung/Gruppierung mit gelöscht
* in der Maske von "Alle hinzufügen" der Eingabemaske gibt es nun ein Eingabefeld, um den Attributen gleich ein oder mehrere CSS-Klassen mit auf den Weg zu geben - wenn man Attribute einzeln hinzufügt, ist die Standard-CSS-Klasse "w50" - mit dem Feature kann man sich das einzelne Editieren der Attribute sparen
* wenn man beim Erstellen eines Attributes auf "Speichern und neu" klickt, wird der Attributstyp mit übernommen und ist vorausgewählt - siehe https://github.com/MetaModels/core/issues/1334
* die Angaben in der Liste/Baum der Filterregeln sind vereinheitlicht - siehe https://github.com/MetaModels/core/issues/1124
* die Links der Paginierung können um ein URL-Fragment (Sprunganker) erweitert werden - ggf. eigene Templates anpassen - siehe https://github.com/MetaModels/core/issues/1466
Die Attribute Tags und Select wurden so aktualisiert, dass ein Filter, der bei den Attributseinstellungen die Auswahl der Items eingrenzt, nun auch in der Ausgabe zündet - siehe https://github.com/MetaModels/core/issues/1114
Beispiel: Wenn man bei Attribut Tags von dem referenzierten Model nur diejenigen zur Auswahl im BE angezeigt haben möchte die "published" sind, kann man das mit einem Filter lösen. Bisher wirkte aber der Filter in der FE-Ausgabe nicht, wenn z.B. ein Item des Referenzmodels ausgewählt wurde und in der Zwischenzeit "un-published" wurde. Im BE bei der Auswahl ist das Item zwar durch den Filter weg, wurde aber im FE bisher noch ausgegeben - das ist nun gefixt.
Hintergrund ist, dass mit der Statusänderung auf "un-published" natürlich die Referenz zu dem (referenziertem) Item sich nicht in Luft auflöst, sondern noch in der DB vorhanden ist. Erst wenn das eigentliche Item neu gespeichert wird, fliegt die Referenz aus der DB. Über den Filter wird dies dennoch korrekt an das Template im FE übergeben.
* die Anzeige der Filterregeln ind der Liste/Baum wurde angepasst - siehe https://github.com/MetaModels/core/issues/1124
* Die Anzeige der Eingabemaske bei Varianten wurde angepasst - siehe https://github.com/MetaModels/core/i...ment-848226821 Bisher wurden Attribute ohne Variation in der Variant-Maske ausgeblendet. Damit konnte man dort die Werte nicht mehr sehen und das Layout wurde ggf. "zerschossen" weil entsprechende CSS-Angaben der ausgeblendeten Attribute fehlten. Nun werden diese Attribute als Readonly dargestellt.
Übersicht zu MM 2.2 inkl. Checkliste angepasst - siehe https://metamodels.readthedocs.io/de...-in-mm-22.html
vorhandene Ansichtseinstellungen per Icon sichtbar(rer) machen - das Icon ist s/w wenn es keine Ansichtsbedingungen gibt und farbig, wenn welche vorhanden
siehe https://github.com/MetaModels/core/issues/941
ggf. kann man das Feature auch für andere Icons ausweiten
Die Links "Clear-all" wurden aktuell nicht ausgegeben - das geht nun wieder...
Das geht nun wieder.Zitat:
Zitat von zonky
Allerdings gibt es jetzt einen Fehler beim Filter Umkreissuche (Bearbeiten / Aufruf / Speichern erzeugt internal Server Error):
:(Code:request.CRITICAL: Uncaught PHP Exception Error: "Call to a member function getName() on null" at /vendor/metamodels/core/src/CoreBundle/EventListener/DcGeneral/Table/FilterSetting/AbstractFilterSettingTypeRenderer.php line 257 {"exception":"[object] (Error(code: 0): Call to a member function getName() on null at /vendor/metamodels/core/src/CoreBundle/EventListener/DcGeneral/Table/FilterSetting/AbstractFilterSettingTypeRenderer.php:257)"} []
Das hat mit dem Clear-all nichts zu tun - das kommt von der Anpassung zur Vereinheitlichung der Anzeige der Filterregeln im BE... isch gugge ma ;-)
hmm... Problem soweit erkannt
in AbstractFilterSettingTypeRenderer.php Zeile 257
für eine bessere Lösung muss ich erstmal gucken...PHP-Code:($attribute ? $attribute->getName() : '*')
sollte nun auch für Filter Perimeter passen... so geändert, dass wen zwei Attribute verwendet werden, beide in der Ausgabe erscheinenZitat:
Zitat von zonky