-
Notifications
You must be signed in to change notification settings - Fork 15
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
YRewrite Integration #205
Comments
Zu deiner anvisierten technischen Umsetzung kann ich nix sagen, aber grundsätzlich spricht nicht gegen einen solchen PR. |
Vom Ansatz her würde ich damit gerne möglichst neue Optionen in der Konfiguration vermeiden, so dass die Domains aus YRewrite einfach "da" sind und zur Auswahl stehen wenn vorhanden. |
@MC-PMOE |
@MC-PMOE ist das immer noch ein Problem aktuell? |
@alxndr-w Problem nicht, wäre eher ein "nice to have". Im Alltag aber vllt. auch eher zu vernachlässigen, da man ja selten Domains anpasst und man dann halt einmalig so anlegt. |
@MC-PMOE Ich hab' das Ganze in meiner Consent-Lösung in ein YForm-Value gepackt - das geht hier zwar nicht, aber die Domains sind ja schnell "hergezaubert", falls du's dir abschauen möchtest: (Prüft, ob YRewrite installiert ist und gibt immer die Default-Domain mit an - einen EP gibt's meines Wissens nicht) |
Das war hier schon mal Thema: #53
Wenn generell Interesse daran besteht bzw. es keine Einwände gibt, könnte ich wenn ich die Zeit finde einen PR dazu beisteuern.
Würde das dann vermutlich technisch so lösen wollen, dass bei vorhandensein von YRewrite die DB Query zur Abfrage der Tabelle rex_consent_manager_domain um die entsprechende Abfrage der YRewrite Tabelle erweitert wird, und eventuell doppelt vorhandene (Beim consent_manager und YRewrite eingetragene) zusammengefügt werden.
Gibt es da vielleicht Gründe die dagegen sprechen würden?
The text was updated successfully, but these errors were encountered: