Interaktion: Contao Mitglieder und CC

[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.

[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]

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]

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" }

[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...

[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.