Guten Tag,
Ich würde gerne wissen ob es möglich ist ein neues Datenbankfeld “aus dem Code heraus” anzulegen, so dass man das ganze dann in ein Modul integrieren kann.
Was ich damit meine wäre z.B. ein Modul das eine zusätzliche Checkbox im Backend erstellt (Das scheint ja per Template und mit den neuen oxBlocks (irgendwie) realisierbar zu sein) und zusätzlich dazu gleich das entsprechende neue Feld in der Datenbank anlegt, in dem dann der Zustand der Checkbox (Haken gesetzt oder nicht) gespeichert wird.
Es wäre halt schön wenn das möglichst alles direkt in dem Modul integriert wäre und nicht alles vom Benutzer manuell gemacht werden müsste.
sicher doch
Auch hier würde ich mich über eine etwas nähere Erklärung freuen 
sagt dir SQL etwas?
Du musst nur in deinem Modul eine SQL Quqery unterbringen, die genau dein gewünschtes Feld erstellen.
Wenn du PhpMyAdmin hast, dann geh mal da rein und füge darüber dein gewünschtes Feld in die Tabelle hinzu. Nach dem Bestätigen siehst du oben in einem meistens grün umrandeten Kasten die SQL Query, die ausgeführt wurde, um dieses Feld hinzuzufügen.
Wenn du kein PhpMyAdmin hast, dann schau dir mal SQL Tutorials an.
Wenn du deine Query hast machen wir weiter.
Sie mal einer an, dass mir die SQL Query dort angezeigt wird wusste ich noch garnicht
Das hier wäre sie:
ALTER TABLE oxarticles ADD ARTICLEHIDE TINYINT( 1 ) NOT NULL DEFAULT ‘0’ AFTER OXID
okay, ab hier ist dann kreatives Denken gefragt.
Ich arbeite selbst erst seit ein Paar Tagen an dieser Geschichte, weil sowas wie “automatisch ein Feld erstellen” gibts eigentlich nicht, daher bin ich übermorgen vielleicht einer anderen Meinung als heute 
also, wir müssen ja dafür Sorgen, dass das Modul die SQL Query ausführt. Das Problem ist, dass dein Modul eine Model Klasse erweitert. Und in einem Model so eine SQL Query unterzubringen wäre praktisch mit der Abschaffung der Führerscheinprüfung gleichzusetzen: wäre zunächst viel entspannter, aber macht man nicht weil dann das komplette Chaos ausbricht.
D.h. du musst deine Query in einer Klasse unterbringen, die möglichst selten ausgeführt wird, um den Server nicht unnötig zu beschäftigen, aber dennoch zwischen dem Zeitpunkt wenn man sich ins Backend einloggt und dem Punkt wenn man die Artikel verwalten möchte um die Checkbox zu setzen.
Mit ein bisschen Programmiererfahrung und ein Paar Tricks kann man bisschen Perfomance schonen. Und bedenke, dass du danach noch die Views aktualisieren musst, damit das neue Feld “gemerkt” wird und zugänglich ist.
Du merkst vielleicht, dass es nicht unbedingt einfach ist. Deswegen haben eigentlich alle Module eine “README.txt” im Ordner, in der die Anweisungen und SQL Queries stehen, die man ausführen muss um das Modul zum Laufen zu bekommen.
Also, wenn du weitermachen möchtest, dann überlege mal eine Klasse, die sich eignen würde
Also wenn das mit der Readme ganz üblich ist werde ich es wohl auch dabei belassen. Ich dachte es wäre nur “schöner” wenn der Benutzer quasi ein 1-click Modul hätte
Aber deine Herangehensweise und Erläuterung ist wieder mal klasse!
Leider habe ich es eben geschafft mein Modul zu zerschießen, Gott weiß wie.
Checkbox, Checkbox-Beschriftung, Übergabe des Checkbox-Inhalts and die Datenbank - das funktioniert alles nach wie vor.
Nur scheinbar klappt das Überladen der Klasse oxarticles nicht mehr.
Eigentl. hatte ich nur einige Dateien umbenennen wollen.
Habe die Umbenennungen sowie die entsprechenden Änderungen in den Dateien wieder rückgängig gemacht, aber ohne Erfolg.
Aber da das Modul ja schon einmal lief dürfte ich das wohl wieder hin bekommen (hoffentlich).
Eventuell kannst du ja kurz testen ob das Modul bei dir läuft:
bei mir läuft alles und auch die Beschriftung/Übersetzung.
und ich würde diesen Satz aus readme.txt rausnehmen:
(Standartmäßig C:\xampp\htdocs\oxid\modules)
die Mehrheit von uns habt den Shop nicht im c:/xampp/htdcos/ Ordner 
Also du musstest nichts mehr verändern? Artikel werden ordnungsgemäß für die eingestellte Benutzergruppe ausgeblendet?
Faszinierend. Hab den Shop grad extra ein zweites mal an einer andren Stelle mit einer neuen Datenbank installiert und es klappt bei mir immer noch nicht.
Eventuell sollte ich mal das Windowsallheilmittel, den PC-Neustart durchführen.
edit: Auch nach dem Neustart klappt es bei mir nicht. Ich glaube OXID mag mich nicht
Es liegt wohl definitiv daran, das die klasse oxarticle bzw deren Funktion getActiveCheckQuery nicht richtig durch mein Modul überschrieben wird. Selbst wenn ich $sQ = " $sTable.oxactive = 1 "; auf 0 setze ändert sich rein garnichts, das sollte ja eigentl. bewirken, dass nur die inaktiven Artikel angezeigt werden.
ah, ich hab nur einen Entwicklungsshop ohne Kunden, Gruppen und Artikel, hab diesen Teil deines Moduls nicht ausprobiert.
warte mal kurz ich baue was ein.
Oh man, hab’s dann jetzt rausgefunden… Ich bin vielleicht doof
in der metadatei muss es natürlich ‘oxarticle’ => ‘test_hide/test_oxarticle’, heißen, nicht
’oxarticles’ => ‘test_hide/test_oxarticle’,
Ich häng dann nochmal die abgeänderte Version an, die müsste wie gewollt funktionieren. Vielleicht kann später damit jemand ja etwas anfangen
na dann: ich gratuliere zum ersten Modul
Herzlichsten Dank!
Ohne dich hätte das nicht mal ansatzweise geklappt!
Irgendwie aber etwas deprimierend, dass das Ganze (inklusive Bild) gradmal 12kb groß ist hehe
Habe das Modul gerade installiert. Mir zeigt es auch den Status an wenn ich in der Datenbank entsprechend 1 bzw 0 eingebe.
Im Backend allerdings wird der Hacken (wenn man ihn ändert) nicht gespeichert.
OXID Version: 4.7.8.
Auch nicht nach tmp leeren und Views updaten