Sortierung der Enträge im Frontend

[lennier83]

Contao 4.13.43 POI: 2.3.+

Ich komme nicht dahinter warum im Frontend die Einträge kreuz und quer ausgegeben werden von der Sortierung (also anders als im Backend). Das ist natürlich erstmal egal für nur POIs in der Map, aber wenn man die POIs auch als Liste ausgeben will wie im Backend (gleiche Reihenfolge), sieht man das die machen was die wollen 😅 In der Datenbank sind die sortiert (1-15). Im Frontend passiert sowas wie 9,1,2,3,6,9,7 (egal wie die in contao/Datenbank angeordnet sind). Könnt Ihr da auf die schnelle sehe ob es eine random Sortierung gibt im Template?

Btw. hätte ich bissl Budget und würde gerne noch generell eine Templateauswahl haben für die Zukunft. Also Contao-Standard um vers. POIs-Hauptpunkte mit angepassten Templates (points_of_interest.html5 ) zu versehen. ... Falls machbar :-)

[bytehead]

Die fehlende Berücksichtigung der Sortierung im Backend ist wohl ein Fehler, die zusätzliche Templateauswahl ein machbares Feature :)

[lennier83]

Juhuu. Konntet Ihr schon wegen der Sortierung schauen? Kann auch bezahlt werden :-)

[bytehead]

Sorry, das ist liegengeblieben. Versuche das asap anzugehen.

[bytehead]

@lennier83 kannst du den Branch dev-feature/respect-sorting-order mal in deinem Projekt testen?

[lennier83]

Mh. Geht leider noch immer nicht. Die Änderung kann ich im vendor sehen. Neue Version ist also drin. Aber es hat sich nicht geändert. Habe ein neues POI gemacht. Aus 1238 (Backend) wird 1283 (Frontend) und Sortierung hat keine Auswirkung.

[bytehead]

Was sagt die Symfony-Debug-Toolbar im Query-Window?

so sieht das z.B. bei mir aus:

SELECT
  tl_point_of_interest.*,
  j1.`id` AS pid__id,
  j1.`tstamp` AS pid__tstamp,
  j1.`title` AS pid__title,
  j1.`addIcon` AS pid__addIcon,
  j1.`icon` AS pid__icon,
  j1.`singleSRC` AS pid__singleSRC,
  j1.`size` AS pid__size
FROM
  tl_point_of_interest
  LEFT JOIN tl_points_of_interest j1 ON tl_point_of_interest.`pid` = j1.id
WHERE
  tl_point_of_interest.pid = '1'
  AND tl_point_of_interest.published = '1'
  AND (
    tl_point_of_interest.start = ''
    OR tl_point_of_interest.start <= '1720541340'
  )
  AND (
    tl_point_of_interest.stop = ''
    OR tl_point_of_interest.stop > '1720541340'
  )
ORDER BY
  tl_point_of_interest.sorting

[lennier83]

Im Frontend (ich teste das mal gleich och woanders):

SELECT
  tl_point_of_interest.*,
  j1.`id` AS pid__id,
  j1.`tstamp` AS pid__tstamp,
  j1.`title` AS pid__title,
  j1.`addIcon` AS pid__addIcon,
  j1.`icon` AS pid__icon,
  j1.`singleSRC` AS pid__singleSRC,
  j1.`size` AS pid__size,
  j1.`includeCss` AS pid__includeCss,
  j1.`includeJs` AS pid__includeJs
FROM
  tl_point_of_interest
  LEFT JOIN tl_points_of_interest j1 ON tl_point_of_interest.`pid` = j1.id
WHERE
  tl_point_of_interest.pid = ?
  AND tl_point_of_interest.published = '1'
  AND (
    tl_point_of_interest.start = ''
    OR tl_point_of_interest.start <= '1720542360'
  )
  AND (
    tl_point_of_interest.stop = ''
    OR tl_point_of_interest.stop > '1720542360'
  )
ORDER BY
  tl_point_of_interest.sorting

[lennier83]

Mh. Auch in einer frischen 4.13 Installation funktioniert das leider nicht (ohne weitere Erweiterungen).

[bytehead]

Weird. Bei meinen Projekten stimmt die Reihenfolge und die Query sieht mit ORDER BY tl_point_of_interest.sorting auch gut aus bei dir... 🤔

[bytehead]

Ich seh das Problem. Wir sortieren die Einträge nochmals Top->Down und Left->Right um Z-Index-Probleme zu vermeiden 🙃 Muss mal prüfen, ob das auch weg kann.

[bytehead]

Willst du nochmals updaten und testen? Bei der Einbindung als Content-Element oder Frontend-Modul gibt es jetzt eine Checkbox, ob die Einträge sortiert ausgegeben werden sollen oder nicht (mit Hinweis auf das Z-Index-Problem):

[lennier83]

Amaziiingggggg. Funktioniert ohne Probleme. 🥳 Einmal mit Profis arbeiten 😎

[bytehead]

2.4.0 ist veröffentlicht - have fun! 😎