WE 9 - Initalisierung schlägt fehl

Fragen zum Erstellen von Templates für webEdition.
mediavantis
Senior Member
Beiträge: 238
Registriert: Do 16. Feb 2012, 12:51

WE 9 - Initalisierung schlägt fehl

Beitragvon mediavantis » Mo 31. Aug 2020, 10:58

Liebe Forumsgemeinde,

bei WE 9 hat sich ja einiges geändert. Unter anderem klappt die Initialisierung in Bezug auf das Schreiben eines Objektes via Frontend Formular nicht mehr, wie bisher.

Das folgende Konstrukt führt - wie in der Versionshistorie dokumentiert - zu einem Fehler

Code: Alles auswählen

<?php
$obj_id = $we_object['edit_objekt']->ID;
	$obj = new we_objectFile();
	$obj->initById($obj_id);
	$obj->setElement('Bundesland01',$bundesland01); 
?>
Wenn ich nun gemäß Dokumentation den Script wie folgt ändere

Code: Alles auswählen

<?php
$obj_id = $we_object['edit_objekt']->ID;
	$obj = new we_contents_objectFile();
	$obj->initById($obj_id);
	$obj->setElement('Bundesland01',$bundesland01); 
?>
erhalte ich die Fehlermeldung "Argument 1 passed to we_contents_base::initByID() must be of the type int, null given"
Will heißen, ich benötige einen integren Wert.
Ich habe nun schon einige Änderungen durchexerziert, leider ohne Erfolg, weshalb ich für eine Hilfe dankbar wäre....

NilSole
Senior Member
Beiträge: 303
Registriert: Mi 27. Mär 2019, 15:28

Re: WE 9 - Initalisierung schlägt fehl

Beitragvon NilSole » Mo 31. Aug 2020, 12:30

Die Fehlermeldung besagt auch, dass du gar keinen Wert für ID (null) eingibst.

Code: Alles auswählen


<?php
// Sicher, dass es edit_objekt und nicht edit_object ist?
$obj_id = $we_object['edit_objekt']->ID;
	$obj = new we_contents_objectFile();
	$obj->initById($obj_id);
	// Bei setElement muss jetzt am Ende ein Buchstabe für den Typ angehängt werden, etwa S (tring)
	$obj->setElementS('Bundesland01',$bundesland01); 
?>


mokraemer
Senior Member
Beiträge: 3619
Registriert: So 8. Aug 2010, 01:23
Wohnort: Mainz

Re: WE 9 - Initalisierung schlägt fehl

Beitragvon mokraemer » Mo 31. Aug 2020, 13:18

btw setElement ist deprecated!

@NilSole: der Buchstabe sollte nicht direkt den Typ, sondern die Speicherart wiedergeben. Es würde nichts bringen bspw. ein verknüpftes Objekt als setElementS zu setzen. Evtl. machen wir hier für die Objekte auch mal echte Setter nach Typ; das wäre hier wirklich sinnvoller.

Wer setElement* nutzt, sollte den Quelltext von WE kennen und sich auch bei Updates nicht beschweren; das ist NICHT vorgesehen!
webEdition-Kern-Entwickler

mediavantis
Senior Member
Beiträge: 238
Registriert: Do 16. Feb 2012, 12:51

Re: WE 9 - Initalisierung schlägt fehl

Beitragvon mediavantis » Mo 31. Aug 2020, 13:21

@Marc
und was ist die Alternative?

mediavantis
Senior Member
Beiträge: 238
Registriert: Do 16. Feb 2012, 12:51

Re: WE 9 - Initalisierung schlägt fehl

Beitragvon mediavantis » Mo 31. Aug 2020, 13:24

@Marc
Wenn man ein völlig "neues" WE codet und es veröffentlicht - und manches nicht mehr so geht, wie es bisher in vielen Installationen umgesetzt und auch hier im Forum und auch in der Doku entsprechend beschrieben wurde, sollte die Änderungen auch dementsprechend und vollständig dokumentieren.

Es bringt nichts, wenn man schreibt, was nicht mehr geht, sondern man sollte auch entsprechend Alternativen aufzeigen!!!!!!
Insofern fühle ich mich persönlich angegriffen und auch völlig alleine gelassen. Das macht mich gerade wirklich ärgerlich!

ThomasGoebe

Re: WE 9 - Initalisierung schlägt fehl

Beitragvon ThomasGoebe » Mo 31. Aug 2020, 13:34

Auch wenn setElement nicht offiziell freigegeben ist, so ist es mangels einer echten API doch bisher oft die einzige Möglichkeit gewesen, Anforderungen überhaupt oder performant umzusetzen. Daher @marc ihr wisst doch auch, dass so was viel genutzt wird. Also dokumentiert doch bei solch gravierenden Änderungen schlicht ein paar Beispiele oder führt (endlich?) eine echte PHP API ein, mit der solche Aufgaben updatesicher umgesetzt werden können.

mediavantis
Senior Member
Beiträge: 238
Registriert: Do 16. Feb 2012, 12:51

Re: WE 9 - Initalisierung schlägt fehl

Beitragvon mediavantis » Mo 31. Aug 2020, 13:38

Bleibt zu hoffen, dass die 8.1.3 - wenn sie denn mal kommen mag, nicht auch schon so umgebaut ist....
Dann kann ich round about 20 Webseiten in die Tonne klopfen

ThomasGoebe

Re: WE 9 - Initalisierung schlägt fehl

Beitragvon ThomasGoebe » Mo 31. Aug 2020, 14:13

mediavantis hat geschrieben: Mo 31. Aug 2020, 13:38 Bleibt zu hoffen, dass die 8.1.3 - wenn sie denn mal kommen mag, nicht auch schon so umgebaut ist....
Das wird sicherlich noch in der "alten" Systematik sein. Da wäre ich unbesorgt. Nachdem ich mir einiges angesehen habe, werde ich viele Seite auch noch bei der letzten 8er lassen müssen. Der Umstellungsaufwand ist dann echt enorm.

WBTMagnum
webEdition Partner
webEdition Partner
Beiträge: 1825
Registriert: Di 7. Mär 2006, 16:50
Wohnort: Wien
Kontaktdaten:

Re: WE 9 - Initalisierung schlägt fehl

Beitragvon WBTMagnum » Mo 31. Aug 2020, 15:20

mediavantis hat geschrieben: Mo 31. Aug 2020, 13:24@Marc
Wenn man ein völlig "neues" WE codet und es veröffentlicht - und manches nicht mehr so geht, wie es bisher in vielen Installationen umgesetzt und auch hier im Forum und auch in der Doku entsprechend beschrieben wurde, sollte die Änderungen auch dementsprechend und vollständig dokumentieren.

Es bringt nichts, wenn man schreibt, was nicht mehr geht, sondern man sollte auch entsprechend Alternativen aufzeigen!!!!!!
Insofern fühle ich mich persönlich angegriffen und auch völlig alleine gelassen. Das macht mich gerade wirklich ärgerlich!
Soweit ich weiß, werden die Änderungen auf der Seite Wichtige Informationen für Entwickler (sh. Version 9.0.0 (Barrhorn)) dokumentiert.

Es wird eigentlich auch immer darauf hingewiesen, dass direkte Abfragen per PHP zwar möglich sind, aber nicht empfohlen werden - weil die Funktionen eben Änderungen unterliegen und bei Update nicht garantiert werden kann, dass sie noch (gleich) funktionieren.

Eine stabile API wäre sicherlich wünschenswert, muss halt aber auch erst umgesetzt werden.


Liebe Grüße,
Sascha

mokraemer
Senior Member
Beiträge: 3619
Registriert: So 8. Aug 2010, 01:23
Wohnort: Mainz

Re: WE 9 - Initalisierung schlägt fehl

Beitragvon mokraemer » Mo 31. Aug 2020, 15:30

wir haben eine echte API: we-Tags!
Es wurde schon immer überall beschrieben, das die Funktionen eben internen Änderungen unterliegen - das haben wir von Anfang an so kommuniziert. Selbst auf der alten we:devedge stand das so.
Wir haben fast auf jeder Konf dazu appelliert Tags zu nutzen und auch solche im Zweifel zu schreiben!
Und um das nun mal richtig zu stellen, wir machen das nicht um Leute zu ärgern, sondern um Fehler und Probleme durch Typisierung in den Griff zu bekommen. Das hätten wir gerne schon viel früher gemacht, aber erst PHP 7 und auch die neuen MySQL Versionen geben uns die Möglichkeit so viel wie möglich abwärtskompatibel anzubieten.
In WE 8 und davor hält dich keiner davon ab z.B. mittels

Code: Alles auswählen

$obj->setElement('objFeld',"mein böser ?><?php Kode");
einigen Unsinn in die Felder zu schreiben. In dem Fall würde das früher einfach implizit zu "0" in der DB; sinnvoller Weise soll aber bereits die DB und auch WE hier einen Fehler melden und das Speichern gar nicht erst zulassen, wenn die Daten nicht zu dem Feld passen.

Unter https://www.webedition.org/de/dokumenta ... collapse-0 haben wir ja auch eine Liste von Funktionen die wir zurückportiert haben, damit man also in 8.1.2 und folgenden bereits in Hinblick auf WE 9 Umstellungen machen kann. Die Liste entspricht dem, was uns so aufgefallen ist und kann ergänzt werden, wenn wir etwas gemeldet bekommen.
webEdition-Kern-Entwickler

mediavantis
Senior Member
Beiträge: 238
Registriert: Do 16. Feb 2012, 12:51

Re: WE 9 - Initalisierung schlägt fehl

Beitragvon mediavantis » Mo 31. Aug 2020, 16:18

@WBTMagnum
Soweit ich weiß, werden die Änderungen auf der Seite Wichtige Informationen für Entwickler (sh. Version 9.0.0 (Barrhorn)) dokumentiert.
Das ist schon richtig, aber ich muss bemängeln, dass hier erstens nicht alles dokumentiert ist, was nicht mehr geht, sondern zweitens auch noch die Alternative fehlt!

@mokraemer
In WE 8 und davor hält dich keiner davon ab z.B. mittels
CODE: ALLES AUSWÄHLEN

$obj->setElement('objFeld',"mein böser ?><?php Kode");
einigen Unsinn in die Felder zu schreiben. In dem Fall würde das früher einfach implizit zu "0" in der DB; sinnvoller Weise soll aber bereits die DB und auch WE hier einen Fehler melden und das Speichern gar nicht erst zulassen, wenn die Daten nicht zu dem Feld passen.
Das ist doch so nicht zutreffend.
Wo ist in dem Feld
$obj->setElement('ProfilStadt01',$stadt01);
ein böser PHP Code. Das Feld "ProfilStadt01" ist ein exakt so definiertes Feld in der Klasse und die Daten würden sehr wohl zum Feld(typ) passen. Wie soll ich das auch anders bewerkstelligen, wenn ich z. B. verschachtelte Select-Felder habe, die ich definitiv nicht über userInput type="select" darstellen kann sondern nur über das html-select?

Im Übrigen muss ich da Thomas absolut recht geben. Die Entwickler hätten wissen müssen oder können, dass das setElement massenweise im Einsatz ist, zumal dies auch in der Doku explizit beschrieben ist. Das ohne Kommentar einfach wegfallen zu lassen ist meiner Ansicht nach nicht in Ordnung. Und ich hätte schon erwartet, dass man dann auch eine Alternative aufzeigt.

Weiterhin werde ich das Gefühl nicht los, dass das webEdition CMS mehr und mehr nur noch für die absoluten Profis ist. Eigentlich sollte das CMS für alle sein. Wenn aber die Dokumentation - insbesondere für die Änderungen - derartige Lücken aufweist und vorausgesetzt wird, dass man den webEdition Quelllcode gut kennt, dann kann ich damit niemanden mehr begeistern.

Und statt alles so jetzt als gegeben zu formulieren, hätte ich mir ein wenig mehr gewünscht, dass auf die sicherlich berechtigte Kritik etwas eingegangen und eine Lösung der Problematik zumindest als Diskussion angeboten wird mit dem Ziel, eine für alle tragbare Lösung zu finden. Leider scheint mir das bis jetzt nicht der Fall zu sein.

ThomasGoebe

Re: WE 9 - Initalisierung schlägt fehl

Beitragvon ThomasGoebe » Mo 31. Aug 2020, 17:03

mokraemer hat geschrieben: Mo 31. Aug 2020, 15:30 wir haben eine echte API: we-Tags!
Mir welchem Tag kann ich multiobjekt Felder via PHP schreiben? Oder einen neuen Objektordner (z.B. 2020/08) anlegen, sobald via Frontend ein Objekt gespeichert werden soll? Wie kann ich Felder des Typs Objekt (also Verknüpfungen zwischen Objekten) via we:tag erstellen? Wie kann ich per we:tag hunderte Objekte importieren und solche aktualisieren, die schon da sind (aber da dann nicht alle Felder) und die, die nicht da sind, neu gemäß Namensschema hinzufügen, benennen und untereinnander mit mehreren Sprachen verknüpfen? Habe ich da etwas übersehen?
mokraemer hat geschrieben: Mo 31. Aug 2020, 15:30 Es wurde schon immer überall beschrieben, das die Funktionen eben internen Änderungen unterliegen - das haben wir von Anfang an so kommuniziert. Selbst auf der alten we:devedge stand das so.
Das ist richtig und es ist aus meiner Sicht auch kein Problem, dass sich an internen Funktionen etwas ändert. Ich denke allerdings weiterhin, dass es keine echte API gibt, wie ich sie bei einem Web Application Framework erwarten würde.
mokraemer hat geschrieben: Mo 31. Aug 2020, 15:30 Wir haben fast auf jeder Konf dazu appelliert Tags zu nutzen und auch solche im Zweifel zu schreiben!
Naja, ein eigener Tag würde doch auch nur wieder setElement nutzen. Natürlich kapsel ich solche Aufrufe in eigene Klassen oder Funktionen so dass ich sie nicht an hundert Stellen anpassen muss. Aber in der Summe sorgen die grundlegenden Anpassungen in we 9 schon für eine Menge Aufwand beim Update und insbesondere beim Test.
mokraemer hat geschrieben: Mo 31. Aug 2020, 15:30 Und um das nun mal richtig zu stellen, wir machen das nicht um Leute zu ärgern, sondern um Fehler und Probleme durch Typisierung in den Griff zu bekommen.
Habe ich auch nicht anders verstanden. Ich begrüße weiterhin die Systemumstellungen und denke, dass es absolut in die richtige Richtung geht. Mir fehlt jedoch ein möglichst updatesicherer Weg, um Daten via PHP anzulegen, zu manipulieren und zu löschen.
mokraemer hat geschrieben: Mo 31. Aug 2020, 15:30 Das hätten wir gerne schon viel früher gemacht, aber erst PHP 7 und auch die neuen MySQL Versionen geben uns die Möglichkeit so viel wie möglich abwärtskompatibel anzubieten.
Das klingt doch für mich so, als wenn zukünfitg die jetzt neuen Funktionen stabil sein sollten und ggf. durch neue getter und setter ergänzt werden können. Da wäre dann ja die in kleiner Form API, solange nicht in we 10 wieder aller auf links gedreht werden muss.

ThomasGoebe

Re: WE 9 - Initalisierung schlägt fehl

Beitragvon ThomasGoebe » Mo 31. Aug 2020, 17:09

mokraemer hat geschrieben: Mo 31. Aug 2020, 15:30 Unter https://www.webedition.org/de/dokumenta ... collapse-0
Kleiner Schönheitsfehler: die Links klappen das Akkordion nicht auf (bei mir im FX). Bei dem ersten jetzt nicht schlimm, aber wenn auf einen anderen Eintrag im Akkordion verlinkt wird, klappt das dann nicht mehr so richtig.

NilSole
Senior Member
Beiträge: 303
Registriert: Mi 27. Mär 2019, 15:28

Re: WE 9 - Initalisierung schlägt fehl

Beitragvon NilSole » Mo 31. Aug 2020, 17:57

mediavantis hat geschrieben: Mo 31. Aug 2020, 16:18
In WE 8 und davor hält dich keiner davon ab z.B. mittels
CODE: ALLES AUSWÄHLEN

$obj->setElement('objFeld',"mein böser ?><?php Kode");
einigen Unsinn in die Felder zu schreiben. In dem Fall würde das früher einfach implizit zu "0" in der DB; sinnvoller Weise soll aber bereits die DB und auch WE hier einen Fehler melden und das Speichern gar nicht erst zulassen, wenn die Daten nicht zu dem Feld passen.
Das ist doch so nicht zutreffend.
Wo ist in dem Feld
$obj->setElement('ProfilStadt01',$stadt01);
ein böser PHP Code. Das Feld "ProfilStadt01" ist ein exakt so definiertes Feld in der Klasse und die Daten würden sehr wohl zum Feld(typ) passen. Wie soll ich das auch anders bewerkstelligen, wenn ich z. B. verschachtelte Select-Felder habe, die ich definitiv nicht über userInput type="select" darstellen kann sondern nur über das html-select?
Was hält denn einen böswilligen Nutzer davon ab, dein Html-Select im Browser zu editieren und da value=‘mein böser?><?php Kode’ einzufügen?

Die Doku ist veraltet, zur neuen Doku würde ich gern beitragen, gibt aber noch nichts konkretes so weit.

mokraemer
Senior Member
Beiträge: 3619
Registriert: So 8. Aug 2010, 01:23
Wohnort: Mainz

Re: WE 9 - Initalisierung schlägt fehl

Beitragvon mokraemer » Mo 31. Aug 2020, 18:04

Im Übrigen muss ich da Thomas absolut recht geben. Die Entwickler hätten wissen müssen oder können, dass das setElement massenweise im Einsatz ist, zumal dies auch in der Doku explizit beschrieben ist. Das ohne Kommentar einfach wegfallen zu lassen ist meiner Ansicht nach nicht in Ordnung. Und ich hätte schon erwartet, dass man dann auch eine Alternative aufzeigt.
Wissen wir, haben wir aber immer kritisiert und nie selbst dokumentiert.
Mir welchem Tag kann ich multiobjekt Felder via PHP schreiben? Oder einen neuen Objektordner (z.B. 2020/08) anlegen, sobald via Frontend ein Objekt gespeichert werden soll? Wie kann ich Felder des Typs Objekt (also Verknüpfungen zwischen Objekten) via we:tag erstellen? Wie kann ich per we:tag hunderte Objekte importieren und solche aktualisieren, die schon da sind (aber da dann nicht alle Felder) und die, die nicht da sind, neu gemäß Namensschema hinzufügen, benennen und untereinnander mit mehreren Sprachen verknüpfen? Habe ich da etwas übersehen?
Wo ist der FR dazu?
Das ist richtig und es ist aus meiner Sicht auch kein Problem, dass sich an internen Funktionen etwas ändert. Ich denke allerdings weiterhin, dass es keine echte API gibt, wie ich sie bei einem Web Application Framework erwarten würde.
Wir sind kein WebAppFW - und selbstverständlich sind Tags ne API! Du programmierst damit ja WE.
Mir fehlt jedoch ein möglichst updatesicherer Weg, um Daten via PHP anzulegen, zu manipulieren und zu löschen.
Wenn man klar wäre was gebraucht wird, kann man das implementieren. Es ist ja nicht richtig, das Tags langsam sind - das sind ja auch am Ende PHP-Funktionen. Was langsam ist, wenn Funktionen fehlen und dann drum herum gebaut wird, also wenn bspw. ein Tag eben nur eine ID verarbeitet, obwohl eine Liste benötigt wird. Da man eben teilweise mit php drum herum bauen kann, macht sich eben auch keiner die Mühe das mal in Tags updatesicher zu gießen - aber wenn du mal in die Tag-Doku schaust, sind viele ID-Felder auf CSV erweitert worden.
neuen Funktionen stabil sein sollten und ggf. durch neue getter und setter
das kommt drauf an, was du als "Funktionen" bezeichnest. Aber sicherlich sind die Funktionen mal aktuell drin und ermöglichen es Typsicher Daten zu schreiben. Evtl. nehmen wir aber bspw. noch den Default-Wert des 3. Arguments raus, denn wir wollen eigentlich wissen, welcher Typ sich hier konkret versteckt - dieses Raten nach Typen (wie es früher üblich war, soll eben auch komplett verschwinden).
webEdition-Kern-Entwickler


Zurück zu „webEdition Templates erstellen (we:Tags)“

Wer ist online?

Mitglieder in diesem Forum: Ahrefs [Bot] und 16 Gäste