Interaktion: Contao Mitglieder und CC

[Tim]

$entry->field('groups')->value() wird nicht erkannt.

Aber mit deiner groups Abfrage funktioniert es.

$entry->field('groups')->value() würde voraussetzen, dass wir in der member cc Konfiguration das groups Feld ergänzen.
Das führt aber dazu, dass es doppelt auftaucht und außerdem, dass keine Auswahlmöglichkeiten (checkbox) mehr vorhanden sind im ursprünglichen Feld.

Evtl. findet sich ja irgendwann mal eine Option, dass CC die bestehenden Attribute in erweiterten Tabellen standardmäßig erkennt und ausgeben / filtern kann.
Das wäre ein Quantensprung...

Mhh ja, das Attribut wird im System benötigt, damit die Zahnräder ineinander greifen können. Im Grunde würde es reichen die Backend-Ausgabe des Feldes zu unterbinden, wenn der gewählte Alias ein bestehendes Feld ist. Ich experimentiere mal in diese Richtung.

[eblick]

$entry->field('groups')->value() wird nicht erkannt.

Aber mit deiner groups Abfrage funktioniert es.

$entry->field('groups')->value() würde voraussetzen, dass wir in der member cc Konfiguration das groups Feld ergänzen.
Das führt aber dazu, dass es doppelt auftaucht und außerdem, dass keine Auswahlmöglichkeiten (checkbox) mehr vorhanden sind im ursprünglichen Feld.

Evtl. findet sich ja irgendwann mal eine Option, dass CC die bestehenden Attribute in erweiterten Tabellen standardmäßig erkennt und ausgeben / filtern kann.
Das wäre ein Quantensprung...

[eblick]

Auch kein Sonntag??

ist offenbar ein string...


array(5) { [0]=> string(2) "45" [1]=> string(1) "1" [2]=> string(2) "52" [3]=> string(2) "51" [4]=> string(2) "46" }

[Tim]

Dieser options_callback dient eher der lesbaren Ausgabe der Mitgliedergruppen-Auswahl im Registrierungs-Frontend-Modul. In jedem Fall überschreibt er den Feldwert nicht.

Prüf doch mal das richtige MemberModel. Die ID des Eintrags sollte hier ja die ID des Mitglieddatensatzes sein.

$objMember = \Contao\MemberModel::findByPk( $entry->id  );
$groups = \Contao\StringUtil::deserialize( $objMember->groups );

Da wir hier mit IDs arbeiten, würde ich auch keine Strings prüfen, sondern Integer (ggf. mit intval konvertieren vorab). Ich hab es nicht im Detail geprüft, aber z.B: PHP8.2 ist Typen-Stirkt (ob die in_array Funktion es auch ist, weiss ich nicht im Detail). Da würde die if-Abfrage schon scheitern, weil ID=46 nicht gleich '46' (String) ist, sondern 46 (Integer).

[eblick]

Zu diesem Thema gibt es aktuell ein Problem beim Filtern im FE.

Wir hatten bislang eine CC Liste im FE

 <?php $groups = deserialize($entry->field('groups')->value()); ?>

<?php if(in_array('46', $groups)): ?>
<td><?php echo $entry->field('firstname')->value(); ?> <?php echo $entry->field('lastname')->value(); ?></td>
<td><?php echo $entry->field('email')->value(); ?></td>
<?php endif; ?>

In den Template Vars taucht nun aber das Feld "groups" nicht mehr auf.

in der tl_member.php taucht dieser Eintrag auf:

// Filter disabled groups in the front end (see #6757)
if (\defined('TL_MODE') && \TL_MODE == 'FE') {
$GLOBALS['TL_DCA']['tl_member']['fields']['groups']['options_callback'] = array('tl_member', 'getActiveGroups');
} 

Hängt das damit zusammen?

Und wie können wir künftig auf die Mitgliedergruppe filtern?

[Tim]

Hi Tim,

aus irgendeinem Grund ist die letzte Nachricht hier wieder verschwunden, deshalb nochmal:

Bei Verwendung des geodata Moduls findet man in der generierten DCA nur einen Eintrag für 'geodata':

$GLOBALS['TL_DCA']['tl_member']['fields']['geodata']['sql'] = "varchar(255) NOT NULL default ''"; 

Es fehlen aber Einträge für geodata_country, geodata_zipcode, geodata_city, geodata_street.

Ah ok. Das sind die optionalen Felder. Muss ich prüfen.

Kannst du aber nach gleichem Muster ergänzen bzw. in der dcaconfig.php (oder vergleichbar) hinterlegen.

[PROSIS_Marketing]

Hi Tim,

aus irgendeinem Grund ist die letzte Nachricht hier wieder verschwunden, deshalb nochmal:

Bei Verwendung des geodata Moduls findet man in der generierten DCA nur einen Eintrag für 'geodata':

$GLOBALS['TL_DCA']['tl_member']['fields']['geodata']['sql'] = "varchar(255) NOT NULL default ''"; 

Es fehlen aber Einträge für geodata_country, geodata_zipcode, geodata_city, geodata_street.

[eblick]

Alles klar, hat funktioniert mit contao/dca/tl_member.php und den entsprechenden Einträgen!

[Tim]

Der Manager muss in gleichem Maße Contaos Hooks respektieren, wie das Install-Tool. Das wird sonst für viele Erweiterungen ein Problem geben.

[eblick]

Hallo Tim,

vielen Dank für den künftigen Workaround.
Ich denke auch, dass wir uns hier nicht auf den Manager verlassen dürfen.
Dafür ist es zu riskant im Live Betrieb.

Ich teste es mal über die dcaconfig und gebe Bescheid.

[Tim]

Das Thema hatte ich lange mit Prosis am Wickel. Die durch den Manager erstellen dca Dateien umfassen nicht die Daten aus CC und der Manager triggert die Contao-eigenen Hooks nicht, die das Install-Tool z.B. triggert. Hier entsteht die Diskrepanz zwischen normalen Contao / Install-Tool und Manager. Der Manager muss hier nachlegen.

Ich habe einen Fix/Workaround (ich weiss gar nicht genau, wie man es nennen soll) dafür in einer kommenden CC Version vorgesehen, in dem für erweiterte Tabellen die DCA Konfiguration hardcodiert als Erweiterung erstellt wird.

Bis dahin kann der Manager via dcaconfig besänftigt werden. Hier ein Beispiel für die Felddefintionen einige Felder (Feldnamen natürlich tauschen):

// CC default

$GLOBALS['TL_DCA']['tl_member']['config']['sql']['keys']['id'] = "primary";
$GLOBALS['TL_DCA']['tl_member']['config']['sql']['keys']['pid'] = "index";
$GLOBALS['TL_DCA']['tl_member']['config']['sql']['keys']['tstamp'] = "index";
$GLOBALS['TL_DCA']['tl_member']['config']['sql']['keys']['sorting'] = "index";
$GLOBALS['TL_DCA']['tl_member']['fields']['id']['sql'] = "int(10) unsigned NOT NULL auto_increment";
$GLOBALS['TL_DCA']['tl_member']['fields']['pid']['sql'] = "int(10) unsigned NOT NULL default '0'";
$GLOBALS['TL_DCA']['tl_member']['fields']['tstamp']['sql'] = "int(10) unsigned NOT NULL default 0";
$GLOBALS['TL_DCA']['tl_member']['fields']['sorting']['sql'] = "int(10) unsigned NOT NULL default '0'";
$GLOBALS['TL_DCA']['tl_member']['fields']['ptable']['sql'] = "varchar(64) NOT NULL default ''";

// eigene CC Felder
$GLOBALS['TL_DCA']['tl_member']['fields']['textfeld1']['sql'] = "varchar(255) NOT NULL default ''";
$GLOBALS['TL_DCA']['tl_member']['fields']['textfeld2']['sql'] = "varchar(255) NOT NULL default ''";
$GLOBALS['TL_DCA']['tl_member']['fields']['select1']['sql'] = "varchar(64) NOT NULL default ''";
$GLOBALS['TL_DCA']['tl_member']['fields']['textfeld3']['sql'] = "varchar(255) NOT NULL default ''";

[eblick]

Ich hänge mich hier nochmal ran. Wir nutzen auch in der ein oder anderen Installation die CC Tabelle erweitern Möglichkeit, z.B. mit Mitgliedern.
Nach wie vor ein Dorn im Auge ist das Datenbank Update in diesem Fall.

Hier wird immer vorgeschlagen, die z.B. in der Mitgliedertabelle ergänzten CC-Felder zu löschen. Zumindest wenn über den Contao Manager regulär der Cache geleert wird und die Datenbankprüfung angestoßen wird.
Anbei mal ein Screenshot:

Ein Falscher Klick und alle Felder werden gelöscht, inkl. Inhalte. Das ist für den Produktiveinsatz mehr als gefährlich.

Könntet ihr hier nicht eingreifen und Contao beibringen, dass die Tabelle erweitert wurde?

[Tim]

Filter können nur für existierende Attribute angewendet werden. Contao-eigene Felder sind für CC unbekannt bzw. für die Filter gibt es keine Grundlage welcher Art das Feld ist.
Du kannst das austricksen und Attribute erstellen mit den Alias der Contao-eigenen Felder z.B. "company" = "Firma" usw. Es entstehen dann zwar Dopplungen in der Eingabemaske, aber technisch hast du dann den Grundaufbau.
Die Dopplungen kann man im Nachgang über eine DCA config sicher auch kaschieren. Das ganze ist aber schon sehr speziell und übersteigt den möglichen Support hier über das Forum.

[PROSIS_Marketing]

Ich habe jetzt einmal Versucht, die Tabellen wie du beschrieben hast zu verknüpfen, allerdings gibt die CC-Liste keine Contao-internen Felder als Option, sondern nur die über CC angelegten:


Auch im Filter können Felder wie z.B. Firma oder Vorname nicht verwendet werden. Das reguläre Contao Auflistungsmodul stellt jedoch alles zur Verfügung.
Muss man da noch separat etwas anlegen?

Bzgl. der "Freigabe" Funktion (also Partner ändert etwas, Änderung soll aber erst nach Freigabe durch uns live gehen) - ist das mit Contao und CC Bordmitteln machbar oder muss man da tiefer reingehen?

Danke und Grüße

[Tim]

Hallo Zusammen,

ich bin auf der Suche nach einer Lösung für eine Art Partnerportal - CustomCatalog scheint sich da ganz gut zu eignen. Jetzt wollte ich einmal Fragen, in wieweit man den Katalog mit den Contao internen Mitgliedern verknüpfen kann. Ziele wäre, dass die Partner einen Login haben, über den sie evtl. sogar ihr Profil verwalten können, jedoch nicht direkt "live" veröffentlichen, sondern eine Art Änderungsantrag abschicken und erst wenn der freigegeben wurde, werden die Änderungen veröffentlicht.

Kann mit CC die Mitgliederfunktion von Contao um eigene Felder/Funktionen erweitert und die Daten dann auch über CC Module gesammelt ausgegeben bzw. gefiltert werden oder liefert CC selbst eine Art Login/User Verwaltung mit?

Ist eine derartige Umsetzung mit CustomCatalog möglich?

Danke schonmal und Grüße
Manuel

CC erlaubt mit seinen eigenen Feldern bestehende Contao Tabellen zu verwalten und zu erweitern. Sprich, neue Felder etc. anzulegen.

Daraufhin kann CC auch eine Liste mit diesen Daten ausgeben (ganz normale CC-Liste) und kann sein Bandbreite an Filtern etc. anwenden.
-> Ja, du kannst quasi mit CC eine Mitgliederliste ausgeben, die die Mitgliederdaten aus (tl_member) fährt.

Hier ist ein Beispiel, wo ich mitgearbeitet habe und dort diese Verknüpfung erstellt habe: https://www.branchenloesung-forst.ch...enznehmer.html
Sämtliche Daten sind Mitgliederdaten mit allen Rechten, die Contaos Mitglieder erlauben. Die Ausgabe erfolgt via CC.