friendsofredaxo / geolocation Goto Github PK

Das muss geprüft werden. @alxndr-w hatte Probleme mit der Installation von Addons, die YForm benötigen, wenn die Instanz im Safe-Mode ist. Der Fall könnte hier auch gegeben sein wegen der YForm-Abhängigkeit.

Also mal Installationen in unterschiedlichen Varianten durchlaufen lassen und schauen, was passiert.

Basierent auf #110:

Grundsätzlich die automatische Auswahl der passenden Tile-URL für Retina- und Non-Retina-Dislays ermöglichen.

Leaflet liefert dazu in der URL im Falle eines Retina-Clients ein r=@2x mit. Damit der Parameter ankommt, muss die Abruf-Url um &r={r} erweitert werden.

Alle Tile-URLs, die den Parameter @2x untetstützen, könnn dann client-seitig je nach Anforderung normale oder hochauflösende Kacheln liefern. Beispiel CartoDB/OSM:

https://cartodb-basemaps-{s}.global.ssl.fastly.net/rastertiles/voyager_labels_under/{z}/{x}/{y}{r}.png

Es gibt auch URL-Provider, die statt dessen die Aufösung über anders geartete Parameter anfordern. Z.B. hat HERE fix 256 oder 512 in der URL stehen. Um den Fall abzudecken könnte man mit zwei URLs arbeiten. Die Standard-URL wird bei normalen Anfragen (r=) genommen, die Retina-URL bei Anfragen mit r=@2x.

https://{s}.base.maps.ls.hereapi.com/maptile/2.1/maptile/newest/normal.day/{z}/{x}/{y}/256/png8?apiKey=....
https://{s}.base.maps.ls.hereapi.com/maptile/2.1/maptile/newest/normal.day/{z}/{x}/{y}/512/png8?apiKey=....

Description / Beschreibung
Obwohl in den Benutzer- und Rollen-Einstellungen das Recht dafür nicht gegeben ist, bekommt der User trotzdem den Menüpunkt von Geolocation angezeigt, was dann bei Klick zu einer Fehlerseite führt, weil ja das Recht dafür nicht vergeben ist...

Workaround für mich wäre ähnlich wie beim bekannten yForm-Bug, das Ganze einfach via boot.php und EP manuell abzuschalten:

  if ((rex::isBackend()) && rex::getUser() && (!rex::getUser()->isAdmin())) {
    rex_extension::register('PAGES_PREPARED', function (rex_extension_point $ep) {
      $page = rex_be_controller::getPageObject('yform');
      $page->setHidden(true);
    });
  }

Affected versions / Verwendete Versionen

REDAXO: 5.14.2
PHP: 8.1.13
Database: MariaDB 10.5.18
Browser: egal
AddOns: egal

Did it whoops? / Whoops erhalten?
Nein

In YForm 4.2 gibt es ggü der Beta Änderungen, die Speichern der Layter-Datensätze behindert. Details zum Problem hier:
yakamara/yform#1480

Nichts das es eilig wäre, könnte man aber auch mal angehen. Evt. vereinfachen sich einige darauf aufsetzende Berechnungen im eigenen Geolocation-Code.

Weder die Tables sind in irgend einer Form freigegeben, noch die spezifischen geolocation-Einzelberechtigungen. Dennoch sieht der User das:

Klickt der Nutzer dort drauf, kommt:

#129

Es geht um die \FriendsOfRedaxo\Geolocation\tools::echoAssetTags() Funktion

Description / Beschreibung

rex_path::addonAssets(ADDON, 'geolocation.min.css') ergibt bei mir:
"D:\weblocal\xxxxx\public\assets\addons\geolocation\geolocation.min.css"

und dein assetpacker macht daraus:
http://xxxxx.local/public/assets/addons/geolocation/geolocation.min.css?buster=1681812590

Nur dass das "public" da nichts zu suchen hat, weil es das webroot ist.

Beide bringen Leaflet mit, das kracht aus JS-Ebene. Würde sich mit #28 und einer neuen Version von yform_geo_osm lösen. Könnte man b.a.w. in der package.yml lösen:

conflicts:
    packages:
        yform_geo_osm: '>0.0.0'

Und Hinweise in der README.md, docs/install.md sowie im Installer.

Nur mal so als Idee. Karten und Mapsets in den URLs nicht über die Datensatz-ID referenzieren, sondern über eine UUID.

Technisch ist das kein großes Ding. Beim Update das neue UUID-Feld hinzufügen und fehlende UUID-Einträge erzeugen. Die Nutzung sollte eh über generierten Code erfolgen. Nur wer die Proxy-Urls von Hand fest in sein JS gebaut hat, muss etwas umbasteln.

Vieleicht könnte man auf die Art auch mal einen Pool an Karten- und Service-URLs aufbauen, die bei jedem Update automatisch ausgeliefert und mit eingespielt werden.

oder gehört das zu yform?

1.0.0-beta2

Feature description / Feature Beschreibung
Darkmode-Karten simulieren per CSS-Style auf dem Kartenkontainer (<rex-map>).

• Grundsätzlich als Stil für den Container vorsehen? Also wenn DM aktiviert schlägt es auch auf die Karten durch?
• Oder bewusst anfordern durch Hinzufügen einer .rex-map-dark-Klasse?
• Auf dem äußeren Container (<rex-map>) und damit für Karte und alles was darauf positioniert ist?
• Oder nur auf dem Kartenlayer-Container?
• Oder auswählbar nur für eine Karte?

man muss ja bedenken, dass es Anbieterseits auch Nacht-Karten als Alternative zur normalen Karte gibt. Das würde dann bedeuten, je Karte auszuwählen zwischen (1) kein DM, (2) DM per CSS und (3) DM per alternativer Karte.

Referenz / Credits:
Oliver Kreischer: ich hab farbige mit einem css Filter in Graustufen verwandelt. Das geht doch bestimmt auch im Dunkeln

Andreas Lenhardt: du gibst der karte den css stil: filter: invert(1) hue-rotate(180deg); (damit kann man alles mit einem darkmode versehen :leichtes_lächeln: )

von @tyrant88 bemerkt: auf einem Windows-System sieht man an den Backslashes, dass hier aus einem Dateipfad eine URL erzeugt wurde...

Richtig schön ist das nicht.

Stimmt. Bei Gelegenheit ändern.

Die Karten-Provider haben auch Service-URLs, mit denen z.B. Adressauflösung (Koordinaten zur Adresse) oder Umkreissuchen (was ist im Umkreis von ...) möglich sind. Die Rückgabe ist meist ein JSON-Record, der aber inhaltlich nicht bei jedem Anbieter gleich aufgebaut ist.

Dass ließe sich ähnlich wie die Karten einbauen:

• Tabelle "rex_geolocation_service" mit der Anbieter-URL und weiteren Hilfsinformationen
  • URL selbst mit frei vergebenen Platzhaltern {....} an den Stellen, die mit Input-Werten befüllt werden müssen
  • Callback A: (optional) Anfragewerte vom Client werden in URL-Platzhalter umgebaut (z.B. Client meldet "Ort" mit PLZ/Stadt in einem Feld, Callback wandelt in {plz} und {ort} für die URL um)
  • Callback B: (optional) Baut die JSON-Rückgabe des Providers in einen optimierten, standardisierten JSON für den Client um.
• kein Caching

Description / Beschreibung

Affected versions / Verwendete Versionen

Nur mal so in den Raum gestellt und weil ich grade das Addon mit RexStan durchflöhe und dabei nur PHP 8.0 / 8.1 / 8.2 teste:

Was haltet ihr davon, das nächste (Major-)Release an PHP 8.0 zu koppeln. Oder gleich 8.1. Man muss ja mal anfangen ....

In der Doku den JS-Kopf mit den Default-Werten prüfen; da fehlt wohl noch was.

• Geänderte dataset-Klassen
• rex_yform_list statt rex_list
• query-klasse statt SQL-String
• ...

Weil man ja zuerst noch nen API-Key für HERE besorgen muss, würde das Anfänger-Frust vermeiden.

Description / Beschreibung

AddOn geolocation konnte aus folgendem Grund nicht installiert werden:
Fehler beim Import der YForm-Formulare: «Error while executing statement "ALTER TABLE rex_yform_field ADD validate_type TEXT NOT NULL" using params []! SQLSTATE[42S21]: Column already exists: 1060 Duplicate column name 'validate_type'»

Affected versions / Verwendete Versionen

REDAXO: 5.15.0
PHP: 8.2.7
AddOns: Form 4.1.0

ErrorException: Undefined variable: mapset
File: redaxo/src/addons/geolocation/lib/yform/dataset/mapset.php
Line: 265

Hintergrund: es gibt im JS eine Funktion, die farbige Marker als Inline-SVG erzeugt. Der erzeugte Code ist escaped, also z.B. " ist durch %22 ersetzt. Die an die Funktion übergebenen Farbnamen (z.B. green) werden auch klaglos richtig in den Code eingesetzt. Mit Farbcodes (z.B. `#008800') geht das schief.

Aktueller Workaround: Farbcodes als %23.... (z.B. %23008800) selbst escapen.

Für die nächste Version das JS selbst escapen lassen.

Püfen und ggf. anheben anlässlich der wegen REDAXO 5.13 und YForm 4.0 erforderlichen neuen Version

Feedback eines Beta-Testers:
Ich habe soeben die 2.0beta installiert (neuestes Redaxo auf PHP 8.0) und ohne das ich großartig etwas an der nackten Installation verändert habe erhalte ich im Register "Kartensatz" beim Speichern des Datensatzes eine Fehlermeldung => siehe Screenshot.

Gruß,
Stefan

Bisher wird die erste Karte in der Liste der Basiskarten automatisch aktiviert. Overlay-Karten sind per se ausgeblendet und müssen immer selbst aktiviert werden.

Das ist nicht so toll, wenn man z.B. Overlay-Informationen als wesentlichen Kartenteil direkt sichtbar haben möchte.

Lösungsansatz: das Anzeige-Widget erweitern um Checkboxen (Overlay-Karten) oder Radio-Boxen (Basiskarten)

Da gibt es demnächst was zu tun. Erstmal ist nur die erste Beta-Version raus.

https://github.com/Leaflet/Leaflet/releases/tag/v1.8.0-beta.0

Description / Beschreibung

https://github.com/FriendsOfREDAXO/geolocation/blob/master/lib/yform/dataset/Mapset.php#L498

sammelt die Karteninhalte ein (siehe Geolocation.js -> Tools).

Diese Datei scheint es nicht zu geben.

Eigentlich wollte ich nachsehen, was die 10 hier genau bedeutet:

echo Mapset::take($mapSetId)
    ->dataset('center', [[$latitude, $longitude], 10])

Affected versions / Verwendete Versionen

REDAXO: 5.14.2
PHP: 8.1
Geolocation 2.0.0-beta2

Addon kann nicht installiert und verursacht beim Versuch immer einen Speicherüberlauf.
Allowed memory size of 134217728 bytes exhausted (tried to allocate 67092480 bytes)

07.02.2022, 10:18:59
Warning
tempnam(): open_basedir restriction in effect. File(/tmp) is not within the allowed path(s): (/home/www/web3/)
redaxo/src/addons/geolocation/install.php
111

07.02.2022, 10:18:59
Warning
unlink(): open_basedir restriction in effect. File() is not within the allowed path(s): (/home/www/web3/)
redaxo/src/addons/geolocation/install.php
110

07.02.2022, 10:18:59
Warning
rename(): open_basedir restriction in effect. File() is not within the allowed path(s): (/home/www/web3/)
redaxo/src/addons/geolocation/install.php
109

#36

Das war mal in der Doku, ist wohl rausgefallen

In LICENCE.md und package.yml steht noch mein Name. Gegen FOR austauschen

Werde ich testen und berichten

Ich gehe jetzt mal Stück für Stück ran, die Analyse-Ergebnisse aus RextStan umzusetzen. Das gibt eine ganze Reihe von PRs, die ich dann mit dem Label RexStan markiere. Bitte daraus noch kein Release machen, da es sich am Ende auch um Breaking Changes handeln wird.

• Deprecated
• Können neue Features eigenen Code ersetzen
• ...

Im Formular für den Mapset sind zwei Felder (...geolocation_layerselect extends ... be_manager_relation), die das vom Erbonkel rex_yform_value_be_manager_relation erzeugte HTML (ein Widget) etwas umbauen. Grund: die darin befindlichten SELECT-OPTIONS dürfen um HTML-konform zu sein kein komplexes HTML enthalten. Das Select wird daher durch eine List-group ersetzt.

Seit YForm 4.2 klappt das nicht mehr, denn der Widget-Aufbau wurde geändert.

Lösung ist in Arbeit. Geplant: rex_yform_geolocation_layerselect baut das HTML komplett selbst auf und basiert nicht mehr auf be_manager_relation.

Im Tab für Kartensätze wird ja eine YForm-Tabelle angezeigt. Die Spalte "Funktion" mit den Action-Buttons wird per EP verändert, indem eine Custom-Function darauf gesetzt wird. Bis dahin kein Problem.

Es könnte ja sein, dass ein Entwickler zusätzliche Hilfsfunktionen über das Menü einbauen will. Beim herkömmlichen $list->setCustomFormat() gilt: der letzte gewinnt. Also würde das Callback von Geolocation ein zuvor gesetztes Callback überschreiben.

Dem kann man gegensteuern, indem vor dem $list->setCustomFormat() erst einmal ermittelt wird, ob es ein Callback gibt. Und im eigenen Callback wird zuerst dieses vorherige Callback aufgerufen ...

PR folgt und sollte den Weg in das finale Release 2.0 finden

TypeError: Cannot access offset of type string on string
File: redaxo/src/addons/yform/plugins/manager/fragments/yform/manager/page/list.php
Line: 152

in Verbindung mit yForm 4.0.4