Beiträge von bembelimen

    Es gibt nun hier mehrere Möglichkeiten:
    - eine ziemlich billige

    - die richtige


    Die Billige

    Formular A sieht so aus:

    Code
    1. <form action="link-zu-form-2" method="GET">
    2.     <select name="layout" id="xxx">
    3.         <option value="option1">Option 1</option>
    4.     </select>
    5. </form>

    Nun entweder für Formular 2 je Option ein layout anlegen (die dateien in dem tmpl Order) und per JS den Link zusammenbasteln und als IFrame im Modal öffnen: index.php?option=com_xxx&view=yyy&layout=zzz


    Oder das Formular schon auf der Seite haben und dann per JS Event den Wert setzen:

    Code
    1. jQuery('#myselect').on('change', function()
    2. {
    3.     jQuery('#target).val(jQuery(this).val());
    4. });


    Die Richtige

    Du solltest den Joomla!-Standard mit XML-generierten Formulare verwenden. Dort gibt es dann im Model eine getForm und loadFormData-Methode. Letztere kannst du dann verwenden um Werte für das Formular vorzubelegen.

    Der Nutzer wählt die Sprache nicht selbst aus, die kannst du per URL-Parameter selbst mitgeben (basierend auf die Backendsprache). Der Nutzer sollte nie direkt auf einen Artikel gehen, der bleibt immer in der Kategorieansicht, denn dort werden nur die Artikel der übergebenen Sprache angezeigt.

    Ich würde ja für jede Hilfsseite eine Kategorie (Typ: Blog, Sprache: all) anlegen und darin dann alle Übersetzungen der Hilfe reinwerfen. Dann hast du keine Hard-Coded IDs auf Artikel und kannst ohne Probleme weitere Artikel und Sprachen dazu packen. In der Hilfe verlinkst du einfach auf die Kategorie (und kannst eventuell noch den Language-Tag direkt mitgeben).


    Die Korrekte Sprache bekommst du so: https://github.com/joomla/joom…joomla/joomla.php#L82-L83

    Hallo Petris,


    ich würde dir an dieser Stelle zu einem kleinen Plugin empfehlen. Es gibt unmengen an SMS-Anbieter, über die du kostengünstig per Schnittstelle eine SMS versenden kannst. Den Code kannst du dann per (z.B.) Custom Field verwalten.


    In einem ähnlichen Szenario (aber anderen Seitenkontext) haben wir es zumindest so gelöst. Kunde bekommt SMS mit Link (und Code), kann auf den Link klicken und ist dann freigegeben.

    Ich kenne das Addon nicht und weiß nicht welche Schnittstellen es bietet (ich habe mir für AD eine eigene Erweiterung gebaut), aber einen Nutzer in eine Benutzergruppe zu schieben ist relativ einfach:

    PHP
    1. Joomla\CMS\User\UserHelper::addUserToGroup($userId, $groupId)

    Ganz dynamische Berechtigungen wirst du aber schwer umsetzen können, die Gruppen müssen vorher schon vorhanden sein*. Dann ist es ein Klacks hier hin und her zu schieben.


    Der Gegenweg ist folgender:

    PHP
    1. Joomla\CMS\User\UserHelper::removeUserFromGroup($userId, $groupId)


    Um die Berechtigungen immer frisch zu setzen, nimmst du:

    PHP
    1. Joomla\CMS\User\UserHelper::setUserGroups($userId, $groups)


    zu * : Das stimmt so natürlich nicht...theoretisch kannst du auch dynamisch eigene Gruppen "berechnen" und anlegen. Ich bin aber eher ein Fan davon Benutzergruppen hierachisch nach Funktion anzulegen und dann einfach entsprechend zuzuweisen:


    Und dann einfach die Kombination zuweisen.

    Ich gehe mal davon aus, dass du auch an komplexere Lösungen interessiert bist und diese umsetzen kannst, deshalb einfach mal ein paar Gedanken. Vielleicht kannst du damit was anfangen.

    1. Ein Artikel muss mehreren Kategorien zugeordnet werden können. Ich dachte, ich löse das über tags, momentan bekomme ich aber noch keine Ansicht gestatltet, die quasi Kategorien abbildet, die sich auf Basis mehrerer tags zusammensetzen.

    Ja das tagging ist die generelle Lösung dafür. Hier kommt es nun drauf an, wie umfangreich der Shop ist und insbesonders was für SEO-URLs du haben willst. Also ob die z.b. /shop/article-alias ausreicht oder ob du ganze Pfade haben willst: /shop/tag/subtag/article-alias.


    Bei Szenario 1 ist es relativ einfach:

    1. du erstellst eine Artikelkategorie "Shop"

    2. Alle Artikel wirfst du in diese Kategorie

    3. Artikel selbst taggst du nun wie es dir beliebt

    4. im Menu erstellst du verschiedene Menüpunkte, die alle ein Kategorieblog auf die "Shop"-Kategorie zeigen aber im Tag Filter dann entsprechend je nachdem, welche Artikel du angezeigt haben willst, die entsprechenden Tags aus.

    5. Du erstellst ein kleines Plugin, was den Router um eine Regel erweitert, sodass immer dein Hauptmenüpunkt als der aktive Menüpunkt in der Artikelansicht erscheint.


    Szenario 2 wird schon komplexer:

    Schritt 1-4. ist identisch, außer dass du bei 4. nun dein Menü so gestalten musst, dass du eine entsprechende URL-Struktur zusammen bekommst.

    Als letzten Schritt brauchst du wieder ein Plugin, was den Router erweitert, aber diesesmal musst du dem einiges an Pseudointelligenz mitgeben. Hier kann ich dir wenig helfen, aber du musst einfach entsprechend den verschiedenen URL-Parameter, je nachdem auf welchem Menüpunkt du bist die URL-Parameter des generierten Links basteln. (falls der Satz zu kompliziert war, musst du tief in das Routing eintauchen...)


    Hier bisschen Pseudocode für dein Plugin:



    2. Ein Artikel muss eine eindeutige Artikelnummer automatisch zugewiesen bekommen. Ich weiß nicht, wie ich die ins System/Datenbank bekomme.

    Ich könnte einfach die ID des Artikels verwenden, das wird nur problematisch, wenn der Shop langfristig zweisprachig ausgerichtet werden soll, da dann jeder Artikel eine eigene ID erhalten würde. Außerdem klingt es nach einer sehr unprofessionellen Lösung. Besser wäre natürlich, dafür ein eigenes Feld anzulegen

    Ja, einfaches custom Field, mit automatischer Generierung der Artikelnummer. (Kann dann beim Übersetzen übernommen werden).


    3. Die ID = Artikelnummer soll über die Suche gefunden werden. Dafür weiß ich noch gar keine Lösung. Selbst wenn ich die ID explizit in der URL mit anzeigen lassen, wird sie ja nicht indexiert/gesucht.

    Weiß gerade nicht, ob Joomla! die Custom Fields schon durchsucht, ansonsten kleines Suchplugin bauen, dürfte kein Rocket Science sein.


    4. Zudem wäre es schön, die Artikelnr. nach dem Erzeugen, in der Beitrags-Editor-Ansicht, z.B. in einem nicht editierbaren Feld mit auszugeben

    Das kannst du in den Permissions entsprechend einstellen.

    Außer den Raum zu organisieren (was du getan hast) und anwesend zu sein (was du scheinbar auch machen wirst), gibt es ja nicht viel was man als minimum machen muss.


    Worin siehst du das Problem, sodass du die Aufgabe nicht übernehmen kannst?

    Und als kleine Anmerkung zu Tobias fantastischer Erläuterung:

    Wenn die Overrides richtig gelöst sind, kann man Felder vorausfüllen lassen, indem man z.B. URL-Parameter mitgibt. Da dies aber relativ unschön aussieht wäre nun der Clou, die Weiterleitungskomponente zu verwenden, indem man z.B. als URL "/kundenanmeldung" anlegt und dann intern auf die parametrisierte URL weiterleitet. (siehe auch hier)

    Dann bekommt die ganze Lösung auch ein super Gesicht.


    Mittels Overrides sind viele Sachen nur mit der Core-Registrierung möglich, z.B.:

      

    Yep, leider kann ich trotzdem nicht abstimmen, da mein Grund für mein Nichterscheinen nicht dabei ist.

    Das wären Kosten: Mit Bahnfahrt, Hotel, und Eintritt kommt da schon ganz schön was zusammen und das für ein Hobby (bei mir)-


    Christian

    Diese Aussage verstehe ich nicht, angenommen du hättest am Tag deines Beitrages gebucht:

    Bahnfahrt: 60€

    Hotel: Do - So: 3x70€ => 210€

    Eintritt: ~150€ (dürfte wegen Earlybird noch günstiger gewesen sein und weit unter dem Preis von vergleichbaren Events anderer CMSe liegen)

    Macht insgesamt: 420€


    Das bedeutet, dass du jeden Monat 35€ für dein Hobby ausgeben/ansparen müsstest um dabei zu sein. Also ich wüsste keins meiner Hobbies was so günstig ist.

    Warum werden Updates derartig ungeprüft "auf den Markt geworfen"?

    Ich verstehe die Aussage nicht? Du hast doch all die Release Candidates freigegeben? Ich finde weder bei den Issues einen Einspruch von dir noch beim PR selbst. Somit kann man doch davon ausgehen, dass du damit einverstanden warst, dass Joomla! genau so released wird, wie es auch passiert ist?

    Um Joomla! 3 mit Bootstrap 4 zu betreiben ist das Overriden des Menu-Moduls (das der exakt richtige Weg ist) nur der erste Schritt. Du solltest mehrere Stellen zusätzlich in Erwägung ziehen:

    1. Bootstrap 4 Plugin schreiben: der erste Schritt sollte das Entfernen von Bootstrap 2 und das Laden von Bootstrap 4 lauten. Hierbei empfiehlt sich ein Plugin, was mittels HTMLHelper::register einfach die Joomla! Core-Aufrufe überschreibt. Damit kannst du dann relativ geschmeidig JS-Abhängigkeiten ändern oder überschreiben.

    2. Bootstrap 4 Plugin erweitern: wie oben erwähnt gibt es in Joomla! 3 das Bootstrap-Dropdown im Modulmanager, was wie du sicherlich schon festgestellt hast, bei weitem nicht ausreicht, denn Bootstrap 4 bietet xs, sm, md, lg, xl. Hier bietet es sich direkt an die nächste Funktion in das Plugin zu implementieren => Erweitern des Modul-manager-Formulars

    3. Module Chrome: Nun müssen die neuen Funktionen natürlich auch bei den Modulen ankommen, hierbei kann man ein Module Chrome implementieren, was all die Breakpoints unterstützt.

    4. das Template selbst: das Template würde ich auf SCSS-Basis entwickeln, dann kannst du locker flockig mit Bootstrap 4 arbeiten, schon direkt die Grundausgabe Bootstrap 4-tauglich gestalten und musst nicht mit irgendwelchen CSS-Dateien rumhantieren => Du baust dir selbst was du brauchst.

    5. die Overrides: Last but not least kommt es nun zu den Overrides. Neben dem Menu lohnt es sich auch mod_custom auseinanderzunehmen und weitere Module Chromes zu basteln (card, container, ...). Es ist auch ohne Probleme möglich direkt Bootstrap 4 Dropdowns mit Menuoverrides zu basteln oder z.B. das Bannermodul für Slider zu verwenden (auch das Newsflashmodul bietet sich hier an). Du zusätzlich auch wahrscheinlich alle Komponenten überschreiben müssen, aber bestimmt com_content (row-fluid/spanX => row/col-x).


    Mit diesen Schritten ist der größte Batzen geschafft. Zumindest wars bei mir so :)


    ein bisschen veraltet, aber teilweise noch gültig: https://www.youtube.com/watch?v=uXPidVdLCyw

    Was ich cool finden würde, wäre die Möglichkeit, den Pfad zu jQuery, Bootstrap (js und css) oder jedem anderen JS Framework speichern bzw angeben zu können, z.B. in der config Datei.

    Wenn das System (egal ob Extension oder Template) dann jQuery, Bootstrap oder was immer benötigt, holt er sich die entsprechende Datei aus dem Pfad. Wenn dort nichts ist, läd er die Standard JS Bibliothek.

    Das ist natürlich sehr einfach und pragmatisch gedacht, aber so könnte man diesen ganzen Problemen bei Einbindung von Scripten vllt etwas entgegen kommen...

    Das ist ohne Probleme möglich, per Override und/oder (imho der bessere aber bisschen aufwändigere Weg) indem man genau diese Pfade per HTMLHelper Überschrieb (Plugin) setzt z.B:

    Ohne dir jetzt ganz genau den Code sagen zu können, kannst du für Facebook eine App anlegen und damit die Gruppen des Nutzers abfragen (eventuell muss er dir dafür die Berechtigungen erteilen)


    Es gibt dafür in Joomla! die Klasse JFacebook(User) und die Methode ->getGroups(...). Damit kann man sich sicher was basteln, wenn man denn basteln kann. Eigenes Authentication-Plugin etc.