[gelöst] Hilfe: View hat nur noch Zugriff auf manche Felder.

am 31.07.2013 - 09:32 Uhr in
Hallo zusammen, ich benötige dringend eure Hilfe!
Eine View, die ich schon eine Zeit lang verwende, funktioniert plötzlich nicht mehr (richtig).
Aufgefallen ist mir es, weil Bilder nicht mehr angezeigt wurden. Also habe ich mir über ein PHP-Feld
über den Befehl
<?php
print_r($data);
?>
Normalerweilse (so war es auch die ganze Zeit) wurden alle Felder ausgegeben, die auch zu dem
dahinterstehenden Inhaltstypen gehören.
Jetzt aber werden nur noch die nid, der Title, ein ein paar wenige weitere von mir erstellte Felder ausgegeben,
aber etliche Felder fehlen, obwohl per Devel alle Felder einer einzelnen Inhaltsseite angegeben / zu sehen sind.
Als Test habe ich mal eine neue View erzeugt, die auch Felder des bestimmten Inhaltstypen ausgeben soll,
und dabei wurden sogar noch weniger Felder ausgegeben.
Kann mir bitte jemand weiterhelfen? Woran kann das liegen? In den Einstellungen des Inhaltstypen, dass irgendwo
die Freigabe für Views eingeschränkt wurde?
Mir ist nicht bewusst, dass ich irgendwas dieser Art verstellt hätte. Wie gesagt, ich benötige dringend eure Hilfe!!!
- Anmelden oder Registrieren um Kommentare zu schreiben
Berechtigungen verstellt? Das
am 31.07.2013 - 10:33 Uhr
Berechtigungen verstellt? Das kannst du unterdrücken indem du "disable SQL rewriting" ausschaltest.
Also...Mittlerweile habe ich
am 31.07.2013 - 14:47 Uhr
Also...
Mittlerweile habe ich die Ursache und eine Zwischenlösung gefunden. Allerdings verstehe ich es trotzdem nicht und ich hätte gerne eine saubere Lösung.
Und zwar trat der Fehler auf, weil ich ein ungenutzes Bildfeld, das zu meinem Inhaltstypen gehörte, löschte.
Dieses Bildfeld, in etwa hieß es so $data->_field_data['nid']['entity']->field_background_image['und'][0]['filename'], wird aber mittlerweile
weder von einem meiner PHP-Skripte mehr verwendet, noch direkt in einem Views-Feld.
Gelöst bekommen habe ich es erst mal so, dass ich das nicht mehr benötogte Bildfeld dem Inhaltstypen wieder hinzugefügt habe (was ja aber Schwachsinn ist).
Die "disable SQL rewriting" Checkbox löste das Problem leider auch nicht.
Hat jemand vielleicht noch eine Idee dazu? Würde mich freuen...
Poste mal dein PHP-Skript.
am 31.07.2013 - 15:28 Uhr
Poste mal dein PHP-Skript. Das hört sich schonmal verdächtig an. In Drupal kapselt man PHP gewöhnlich in Hooks und legt diese in ein Modul oder legt diese in die template.php.
Also zur Generierung des
am 31.07.2013 - 15:45 Uhr
Also zur Generierung des Views benutze ich mehrere Felder (u. a. PHP-Felder) und in einem
letzten Feld bereite ich ein HTML-Gerüst vor und setze die generierten Felder per replacement tokens
unter den REWRITE RESULTS ein.
Die dahinterstehenden Inhaltstypen überschreibe ich über das node-template (node--application-profile.tpl.php in meinem Fall).
Soll ich den Code dieser Datei posten??? Da wäre allerdings viel unnötiges enthalten, was nicht unbedingt hilfreich wäre.
Also was genau soll ich posten???
Sind die Felder zu sehen,
am 31.07.2013 - 16:18 Uhr
Sind die Felder zu sehen, wenn du eine View ohne deinen PHP-Feldern und HTML-Gerüst anlegst? Was verstehst du unter PHP-Feldern?
Sorry, dass ich nicht gleich
am 01.08.2013 - 15:51 Uhr
Sorry, dass ich nicht gleich zurückschreiben konnte.
Also zunächst erst einmal, was ich mit PHP-Feldern meine:
Damit ich in Views auf die Ausgabe der einzelnen Feldern reagieren kann, habe ich das Modul Views PHP
installiert.
Für die Ausgabe in einem letzten Feld (auch PHP-Feld) bereite ich mir über verschiedene einzelne Felder ("normale und PHP-Felder) Werte vor (z.B. einen Bildpfad) in dieser Form:
<?php
$parts = explode(".", $data->_field_data['nid']['entity']->field_app_profile_image['und'][0]['filename']);
$ext = end($parts);
array_pop($parts);
$filename_small = implode("", $parts)."_small.".$ext;
print "/sites/default/files/path/to/".$filename_small;
?>
Zum Testen habe ich eben mal eine neue View erstellt, die Inhalte desselben Typen ausgeben soll.
Es ist so, dass ich auf alle Werte zugreifen kann, wenn ich "ganz normale" (keine PHP-) Felder verwende.
Versuche ich allerdings über ein PHP-Feld auf das gesamte Objekt zuzugreifen über
<?php
print_r($data);
?>
erhalte ich lediglich ein Objekt bestehend aus [node_title], [nid], [node_language].
Neue Erkenntnis:
Wenn ich vor das PHP-Feld ein "normales" Feld setze bzw. speichere, ist das ausgegebene Objekt wieder komplett (auf den ersten Blick).
Ich blick da leider nicht mehr durch, welche Veränderung/Einstellung welche Konsequenzen nach sich zieht...
A. Winter
am 03.08.2013 - 11:50 Uhr
<?php
print_r($data);
?>
Um besser zu wissen, was in den Drupal-Arrays oder Objekt-Stacks enthalten ist (die oft ziemlich umfangreich sind), hat es sich als Königsweg erwiesen, das Drupal Devel Modul zu installieren. Dann kannst du deine Objekte/Arrays anstatt mit dem armen print_r(); Befehl mit
<?php
dpm();
?>
dumpen. Dein Objekt wird dann mittels Krumo so dargestellt, dass du das Objekt "durchklicken" kannst. Du klickst dich also durch die verschiedenen Dimensionen und kannst die Objekte/Arrays so inspizieren.
Weiterhin:
Es ist auch mit Devel, dpm(); und Krumo noch manchmal schwierig, die exakte Dimension des gesuchten Arrays zu bekommen. Deshalb solltest du dir zusätzlich zu Devel noch das Modul Search Krumo installieren. Dann hast du noch ein Suchformular mit dem du einen Wert suchen kannst. Auch kannst du dir die Dimenion einfach kopieren und musst nicht suchen/probieren.
Damit ich in Views auf die Ausgabe der einzelnen Feldern reagieren kann, habe ich das Modul Views PHP
installiert.
Du schreibst damit PHP über die Views UI? Wenn ja, rate ich stark davon ab. Das ist sowas von umständlich, da ohne Syntax-Highlighting und mit dem Herumklicken in der UI zu programmieren. Kennst du die Views Template Dateien und hast du dich einmal mit dem Hooks von Views beschäftigt?
Lasse uns "einen Schritt nach hinten" tun: was beabsichtigst du zu tun? Ich glaube nicht, dass du da einfach einen Bildpfad ausgeben willst. Möchtest du das Bild mittels Imagecache Preset ausgeben? Möchtest du eine Bildunterschrift neben das Bild packen? Möchtest du Div-Elemente um das Bild packen? Ansonsten versuche ich den explode(); Befehl zu meiden, da er Code oft später nicht mehr gut nachvollziehbar ist.
Vielen Dank jepster für deine
am 05.08.2013 - 08:17 Uhr
Vielen Dank jepster für deine ausführliche Antwort,
besonders die dpm() Funktion sowie das Search Krumo-Modul erscheinen
mir wirklich als sehr hilfreich.
Mittlerweile habe ich das nicht mehr benötigte Bildfeld im Drupal-Backend entfernen können, ohne dass die View dadurch kaputt geht.
Wieso das jetzt geht, kann ich leider nicht sagen
Um besser zu verstehen, was die Anforderungen waren/sind bzw. was ich realisiert habe, poste ich hier einfach mal die URL:
http://i-sft.com/solutions/spider-charts
Der Grund, wieso ich das bisher über PHP-Felder gemacht habe, ist, dass ich dabei am meisten Kontrolle über die HTML-Ausgabe hatte und mir
anders nicht zu helfen wusste, obwohl dieser Weg (fehlendes Syntax-Highlighting) alles andere als elegant ist.
Würdest du/würdet ihr denn stattdessen komplett auf "PHP-Felder" verzichten? Und wenn ja, wie erreiche ich dasselbe mit einer anderen Lösung?
Wirklich nur über die Views-Templates?
Natürlich würde ich mich freuen, eine bessere/professionellere Methode zu erfahren/lernen. Ich bin gespannt...
Wenn du nur ein paar kleinere
am 05.08.2013 - 09:11 Uhr
Wenn du nur ein paar kleinere Änderungen am Layout bzw. der HTML-Struktur der View vornehmen willst, solltest du die Views-Templatedateien benutzen.
Möchtest du die Ausgabe der Felder selbst bestimmen, solltest du dir einmal die Field Formatter ansehen. Folgendes Tutorial hat mir einmal geholfen: http://www.metaltoad.com/blog/drupal-7-tutorial-creating-custom-formatters. Anschließend kannst du dann bei der Ausgabe deiner Felder - überall bei deren Ausgabe, egal ob View oder Node Display - deinen Field Formatter wählen und so die Ausgabe bestimmen.
Ansonsten in Drupal:
- PHP solltest du in den Template-Dateien möglichst meiden.
- Kleinigkeiten und theme-hooks: template.php
- Größere Sachen: immer in Modul verlagern
In Drupal 8 wird es mit der twig Theme Engine auch richtigerweise erschwert, all zu viel PHP ins Theme zu legen, weil das bei den Designern/Themern/Webentwicklern in der Drupal-Welt ein häufiger Fehler in der Erstellung einer Drupal Website war.