[gelöst] Benutzerprofildaten und Contenttype zusammen in einer View darstellen

Kallo Hai,

wenn ich Dich richtig verstehe gibt es 2 verschiedene Gruppen:
a. User mit account,
b. User ohne account.

Versuche alle 6 Felder in einer View zu zeigen:

a-Name
a-Bild
a-Text
b-Name
b-Bild
b-Text

und bei den Fields-Einstellungen --> "No results behavior" --> "Hide if empty"

Ps: Um an die User-Felder "ranzukommen" solltest Du ein "Inhalt: Autor" - Relationship hinzufügen.

Viele Grüße
Piotr

hallo

ja du hast mich richtig verstanden.

Nur schaffe ich es nicht in einer View gleichseitig Inhalts- und Benutzerdaten anzuzeigen. Die Auswahl muss ich ja schon beim erstellen der View machen.

Über ein "Inhalt Autor" Relationship bekomme ich zur Zeit nur Nutzer, welche auch Inhalt vom Typ b erstellt haben. Aber leider nicht an alle.

Eigentlich will ich die Namen auch noch Alphabetisch sortieren (egal ob sie vom Typ a oder b sind). Deshalb will ich die Daten in einer View haben. Sonst könnte ich auch einfach 2 Views machen und diese über Blöcke auf einer Seite anzeigen.

Grüße
derHai

kann auch kein Profil haben.

Wo soll das herkommen, und wie soll das zugewiesen werden?

Gast ist Gast, und hat kein Profil.

Ansonsten ist es natürlich möglich eine Referenz auf den logged in User zu setzen.

Natürlich haben Leute ohne Account kein Profil.

Deshalb gibt es für diese, (wie im ersten Post beschrieben) einen Content type in dem die Daten erstellt wurden. Das ist der Grund, warum ich überhaupt sowohl BenutzerProfil-Daten als auch normale Inhaltsdaten zusammen in einer View darstellen will.

Ich weiß nicht in wie weit mich Referenzen überhaupt weiter bringen. Eigentlich will ich ja nicht referenzieren, sondern zwei verschiedene Dinge in einer View darstellen.

sind nicht Darstellungsobjekte, sondern Datenbankabfragen, die man dann natürlich darstellen kann.

Insofern gehen in eine View nur Dinge, die referenziell zusammenhängen.

Deshalb wäre es sinnvoll, auch für die registrierten User einen solchen content_type zu erstellen, und von diesem auf die entsprechenden Inhalte zu referenzieren.

View heißt hier Ansicht (der Datenbankrecords)

Vielleicht wird es ja in SQL verständlicher. Ich will im Prinzip folgende vereinfachte SQL anfrage in einer View basteln:

Die Abfrage ist sehr vereinfacht, da weitere Felder (Bilder Beschreibungstexte) aus anderen Tabellen dazu kommen. Außerdem gibt es noch mehr where Bedingungen für den User. Zur Vereinfachung habe ich auch gleich den Accountnamen, anstatt den Realname verwendet.

Wenn es mit Views nicht gehen sollte muss ich mir das in SQL halt selbst zusammenbasteln.

Viele Grüße
derHai

Wähle eine neue View vom Typ Inhalt samt den Feldern "user ohne account", und in dieser View dann über Beziehungen die "user mit account" dazu nehmen.
Die Zusatzfelder für user mit account stehen dir erst nach dem Bezug zur Verfügung, vorher siehst du die nicht.

Generelle Frage: was hast du denn später mit den "user ohne accounts" vor? Weil man oft bei solchen Kombinationen später auf Probleme stößt bzw. die User händisch eventuell in einen "echten" Account übertragen muß oder tritt der Fall nie ein?

Eventuell passt ja auch eine Rules, die dem "user ohne account" wenn du ihn anlegst (über Userprofile) eine Rolle Basic gibt, diese Rolle darf dann nichts tun, und du könntest später auch die Usernamen sortieren, denn 2 verschiedene Felder ineinander zu legen für eine Sortierung gibt sicher Probleme.

Grüße Jenna

Ich könnte natürlich für jeden User noch einen extra node mit Reference auf das Profil erstellen. Darüber hatte ich auch schon mal nachgedacht. Allerdings ist das bei der Accountverwaltung und Aktualisierung ein ziemlicher Mehraufwand, der für die Nutzer auch verwirrend ist. Dann könnte ich auch Dummy User für die Leute ohne Accounts erstellen. Das würde es zumindest übersichtlicher machen.

dass es sich um verschiedene entity typen handelt.
Das eine sind User, das Andere ist ein content_type.

Schon alleine deshalb würde ich auch die Profile der registrierten User in einen content_type packen.

Dann hast du einen content_type "Userprofile", in dem ein Feld besteht, das auf den realen User Bezug nehmen kann.

Ist diese Referenz leer, handelt es sich um einen nicht registrierten User.

kannst du mit einer Rule anlegen lassen.

Dem User ist egal, ob er eine contentseite, oder ein Profil pflegt.

Wird ein User gelöscht, musst du eh entscheiden was mit seinem content passieren soll.
Wenn der content des Users beibehalten, und dem Gastuser zugeschlagen werden soll, aber das Profil gelöscht werden soll, und dieser Fall oft vorkommt, könntest du auch das mit einer Rule abfangen und erledigen lassen.

Allerdings wäre es natürlich auch sehr einfach, alle User (auch die, die sich nicht anmelden sollen) anzulegen.

Hierbei ergibt sich allerdings das Problem mit den eMailadressen.
Da müsstest du fakeadressen anlegen, damit sich diese User keinen Einmalzugang holen können.

Aber auch, wenn sie sich einen Einmalzugang holen, wäre das kein Problem, wenn du alle User, die nur authenticated sind, also keine gesonderte Rolle haben, behandelst wie Gäste.

Das habe ich versucht, aber leider nicht hinbekommen. Welche Art von Beziehung muss ich hier wählen? Vorher hieß es ja Inhalt - Author Beziehung nur das macht keinen SInn.

Dieser Fall wird nicht eintreten.

Ja für alle Accounts anzulegen wäre theoretisch möglich. Ich könnte die nicht gebrauchten auch einfach sperren und anders filtern... Das wollte ich aber eigentlich möglichst vermeiden.

View Typ Inhalt anlegen, 1 oder 2 Felder aus deinem Content Type unter Felder anlegen (user ohne account), dann unter Beziehungen Author wählen, speichern. Dann wieder auf Felder und jetzt hast du in der Auswahl zusätzlich "Benutzer" oder bei EN "User" stehen mit der ganzen Field Auswahl die du unter dem Benutzerkonten angelegt hast und natürlich auch Username.

Du darfst hier nur nicht die Beziehung erzwingen, da es ja echte User gibt die eventuell keinen Content ausgefüllt haben aus deinem "user ohne account".

Ich würde dir aber eher zu der Lösung von Ronald raten über ein Referenzfeld zu arbeiten welches die echten User mit ausfüllen oder per Checkbox anklicken.
Dann kannst du über Views nach allen suchen die sich auf dieses eine Feld beziehen.

Grüße Jenna

Genau das habe ich versucht. Nur leider hat das nicht funktioniert :(. Mit der Lösung erhalte ich leider nur User, welche einen "user ohne Account" Content erstellt haben. Und die User, welche mehrere Nodes davon erstellt haben sind mehrfach vorhanden.

Die Beziehung habe ich bei den Einstellungen nicht erzwungen.

Außerdem habe ich dann einen gemeinsamen Rekord vom "user ohne account Content" und dessen Author und muss diese irgendwie wieder auseinander basteln.

Die Author- Relationship entbehrt wirklich jeder Logik, denn wie bereits gesagt wurde:

Und User Typ A und User Typ B haben nix miteinander zu schaffen. Hier stößt man halt an die Grenzen von Views!

@derHai

Mittels Views hast du folgende Alternative: Du erstellst zwei Views. Eine vom Typ User und eine vom Typ Inhalt. Dann verbindest du die Ausgabe beider Views mittels EVA, indem du die eine View der anderen "anhängst".

Der Nachteil: Man sieht zuerst alle registierten User und dann alle diejenigen, die ihre Daten in der Node gespeichert haben. Oder umgekehrt. Sprich, die DB Records kommen nicht im Wechsel sondern per View getrennt:

User A
User A
User A
User B
User B
.......

Wenn das ok ist, ist EVA wohl die einfachste Lösung. Brauchst du hingegen:

User A
User B
User A
User B
...

musst du wohl selbst in die Tasten greifen und Querys schreiben und die Ausgabe dann in einer Schleife steuern.

Nachtrag: Statt mit EVA kann man natürlich auch einfach mit Blöcken arbeiten....

Alles klar. Ich habe mittlerweile damit gerechnet, dass ich an die Grenzen von Views gestoßen bin.

Für die von dir beschriebene Lösung hatte ich schon das Modul Views Field in View gefunden.
Sortiert wäre natürlich schöner...

Mal schauen welche der Lösungen ich jetzt nutze.

Danke euch alle für die Tipps und kann geschlossen werden.

Sorry, da habe ich gepennt, man kann zwar auf die User Felder zugreifen aber es kann so keine Ausgabe erfolgen über Beziehungen, hatte das nicht vollständig gestestet.
Dank auch an glycid für die logische Erklärung dazu...

Grüße Jenna