Beiträge von Vanbrugg

    Ziel: Digitale Inhalte in Form von Erklär- oder Übungs-Videos sollen gegen eine Gebühr angeboten werden.

    ... nutzt dazu einen Dienstleister?

    Kann man machen. Dafür gibt es Plattformen wie bspw. Udemy.

    Grundsätzlich die Frage: Macht man das als Download oder als Stream?

    Das ist wohl Geschmackssache. Je nachdem, ob du die Videos herunterladbar machen willst oder die persönliche Speicherung mit Hürden versehen möchtest.

    Oder sonstwie schützen, um eine illegale Weitergabe zu vermeiden?

    Nein.

    Welche rechtlichen Hürden gilt es zu beachten, wenn man so eine Art "Shop" betreibt?

    Alle, die das Betreiben eines Gewerbebetriebes bzw. freischaffender Beschäftigung betrifft, bist ja dann aller Voraussicht nach unternehmerisch tätig - quasi als Videodienstleister. Wird akut, sobald du steuerlich relevante Einnahmen erzielst. (Dies ist keine Unternehmens- o. Steuerberatung).

    Tumbler Also ich hab Akeeba Backup Pro gekauft. Ist ja nicht sooo teuer - gerade auch wegen automatisierter Backups. Stef hat ja bereits die entsprechenden Links gegeben. Vor allem auf den zweiten möchte ich hinweisen. Dort wirst du feststellen, dass Akeeba ziemlich viele verschiedene Methoden anbietet. Die paar "Mark" waren es mir definitiv wert, denn ein - fehlendes - Backup wird aller Voraussicht nach wesentlich teurer.

    Hi Leute,

    hier ein Plugin, das ich GAAANZ alleine gebastelt habe. :saint:

    Das ist natürlich auf meinen Bedarf zugeschnitten, kann aber leicht angepasst werden.

    Was hab ich gemacht?
    1. Template-Override von com_users/registration/default.php
    2. In der default.php habe ich die Schleife auskommentiert, die die Formularfelder der Reihe nach rendert. Das ist in der Regel in Zeile 32/33 ungefähr.
    3. Folgenden Code platziert:

    Damit legt man manuell fest, dass die ersten drei Felder "Name", "E-Mail" und "Benutzername" sind.
    Praktisch verwende ich das Feld "Benutzername" als zweites E-Mail-Feld. Das heißt ich benenne die jeweiligen Sprachschlüssel (Sprach-Override) des Feldes "Benutzername" in "E-Mail bestätigen" um.

    Anschließend installiere man das Plugin (siehe Anhang). Das sorgt dafür, dass bei der Registrierung geprüft wird, ob die Felder "E-Mail" und "Benutzername" (was ja umbenannt wurde) identisch sind. Falls nicht, gibt es eine Fehlermeldung.

    Hab's getestet. Klappt mit Joomla 5.

    Viel Spaß damit! chinese

    Im Prinzip ist es mit Joomla! 4 relativ einfach, wenn du als Aufgabe hast, den Benutzername komplett nicht mehr zu verwenden sondern rein auf die Email zu gehen:

    - Override von Language Strings (Username => Email)

    - Override von Registrierung (Username rausnehmen)

    Hab gerade noch deinen Beitrag näher durchdacht. Eigentlich eine witzige Idee - einfach alle Strings umbenennen. Technisch bleibt es damit beim Benutzernamen - visuell hingegen registriert man sich mit der E-Mail-Adresse. Das passt insofern sogar, weil es auch nicht unüblich ist, die E-Mail-Adresse zweimal - quasi als Bestätigung - einzugeben. Demnach gibt der User seine E-Mail-Adresse erstmalig (als Benutzername) ein und beim zweiten - dem eigentlichen - E-Mail-Feld - gibt er seine Adresse quasi als Bestätigung ein. Damit hätten wir die E-Mail-Adresse - technisch betrachtet - zweimal pro User im System. Wen das nicht stört, hat damit einen einfach zu realisierenden Workaround.

    bembelimen Was ich allerdings nicht ganz verstehe - was genau macht dein Plugin? (Bin kein Coder)

    Darf ich das Thema noch einmal aufwärmen? Wie sieht es hier mit Joomla 5/6 aus? Für meine Begriffe wäre das ja eigentlich ein Core-Feature. Wisst ihr zufällig, ob da bei Joomla was in Arbeit ist oder bleibt nach wie vor nur der Umweg über ein Plugin?

    Btw. es geht im Grunde nicht nur um den Login per E-Mail-Adresse, sondern auch um die Registrierung. Also der Benutzer soll praktisch niemals mit einem Benutzernamen konfrontiert werden.

    LukasHH Ist dein Plugin Joomla5/6-ready?

    Hallo!

    In letzter Zeit versuche ich vermehrt von JCE zu TinyMCE zurückzugehen, was manchmal etwas gewöhnungsbedürftig ist. Aber das wird schon noch. :)

    Mein aktuelles Problem ist vermutlich ganz einfach zu lösen, aber ich weiß noch nicht wie. Ich möchte gern Icons (von Fontawesome) einfügen. Das Problem ist, dass Tiny die Attribute einfach rauswirft. Ich füge bspw. folgende Code ein:

    Code
    <i class="fas fa-enelope"></i>

    Sobald ich speichere, wird die CSS-Klasse einfach gelöscht. Wie bekomme ich Tiny dazu nix zu löschen? ;)

    Genau das mach ich seit nn Jahren ^^. Sonst wärs ja einfach.

    Wenn ich fragen darf: Wie sicherst du dich am Ende ab, dass du wirklich sagen kannst, dass die Website, die du übergibst tatsächlich barrierefrei ist, bspw. nach WCAG 2.2 AA. Momentan würde mir da vorschweben, Tools, wie WAVE, den IBM Accessibility Checker und Lighthouse durchlaufen zu lassen und die Ergebnisse per PDF zu dokumentieren und vom Kunden gegenzeichnen zu lassen. Denn ich gehe mal stark davon aus, dass die wenigsten Lust haben werden, mehrere 1000 Euronen für einen offiziellen BITV-Test zu investieren.

    Wie macht ihr das?

    Na ja ... es sieht erst einmal viel aus, ja. Bin auch gerade damit beschäftigt, mich tiefer in die Materie einzuarbeiten. Allerdings habe ich festgestellt, dass viele Aspekte streng genommen nicht unbedingt etwas mit Barrierefreiheit zu tun haben, sondern einfach mit sauberem Arbeiten.

    Gerade so Dinge wie eine vernünftige HTML-Struktur, korrekte Nutzung von HTML-Elementen und -Attributen. Vermeidung von 100 Wackelbildern und Animationseffekten an jeder Ecke. Ausreichende Schriftgröße und -lesbarbarkeit. Gute Kontraste. Das sind alles Dinge, die eigentlicher jeder Webdesigner beherzigen sollte - also auch früher schon vor 20 Jahren. Ich glaube die ersten Anstrengungen hinsichtlich Zugänglichkeit im Web begannen, zumindest öffentlich größer angelegt, um 1999 herum. Damals gab's noch Framesets, vermurkste Tabellenlayouts usw. All das hat heute längst keine Bedeutung mehr.

    Auf der anderen Seite glaube ich fast, dass technische Perfektionisten derweil auf ihre Kosten kommen. Denn je "perfekter" der HTML-Code aufgebaut ist, desto besser kommen Tools aus dem "Barrierefreiheitsuniversum" damit zurecht. Nebenbei natürlich auch Suchmaschinen usw.

    Zu guter Letzt darf man natürlich die inhaltliche Seite nicht vergessen. Fehlende oder falsche ALT-Texte bei Bildern/Grafiken jeder Art sind ein riesiges Problem. Falsch formulierte Seitentitel bzw. Headings (also Überschriften, wie H1, H2 usw.) ebenso.

    Hat man diese beiden Punkte umgesetzt (also sauberes HTML-Coding und gute inhaltliche Beschreibung aller Objekte), dürfte man schon fast 80% der nötigen Maßnahmen erreicht haben. Korrigiert mich bitte, falls ich mit dieser Schätzung danebenliege. Aber ich vermute mal der Rest sind technische Ergänzungen, wie ein sinnvoller Tabindex, landmarks, aria-Attribute usw.

    Was mich allerdings auch ein wenig zaudern lässt, ist die abschließende Frage: Wann ist meine Website tatsächlich barrierefrei? Denn selbst wenn ich alle möglichen technischen Aspekte bei der Entwicklung beachte, bleiben noch viele subjektive Dinge offen. Kann es sein, dass man hier nicht um einen (ziemlich teuren!) BITV-Test herumkommt? Wie sonst soll man juristisch haltbar feststellen oder beweisen können, dass man die Auflagen des BFSG erfüllt hat? Das meine ich gerade auch als Webdesigner, der zum Zeitpunkt X die fertige Website abliefert und sagt: "Bitteschön, eine barrierefreie Website!" Wenn der Kunde anschließend die Barrierefreiheit im Inhalt vermurkst muss ja irgendwie sichergestellt werden können, dass der Webdesigner dafür nicht haftbar ist bzw. verantwortlich gemacht werden kann.

    ... ist zwar schon etwas her, aber ich bin gerade "zufällig" drüber gestolpert. Also die Idee mit dem technisch-hilfreichen Adventskalender find ich richtig klasse! Hab mal ein wenig quergelesen. Sind super Beiträge dabei, die sich an verschiedenen technische Niveaus richten. Gut gemacht, Leute! Gerne dieses Jahr wieder einen. :D

    Na ja ... bin vielleicht nicht der größte Experte. Aber die Codequalität, die Astroid im Frontend erzeugt ist schon mal nicht von schlechten Eltern. Klar, gibt noch Luft nach oben. Aber ich hab schon wesentlich schlimmeren Murks gesehen. Man denke nur an diverse WP-PageBuilder. Mit Joomshapers Framework kenne ich mich allerdings nicht (mehr) aus. Früher war der Code schlimm. Weiß nicht, wieviel besser sie heute sind. Fehlt mir aktuell die Zeit, das zu checken.

    Zwar habe ich selbst noch keine barrierefreie Website mit Astroid entwickelt, allerdings beobachte ich eine stete Entwicklung. Gerade auch WM-Loose ist eifrig dabei allerlei Fixes beizusteuern. Bspw. wurden schon eine Menge semantische Probleme behoben. Bin mir gerade unsicher, ob die Tastatursteuerung inzwischen überarbeitet wurde, sodass man auch bequem Tabindex, Fokus-Highlights usw. definieren kann. Aria-Labels werden zumindest teilweise schon genutzt. Hab es aber, wie gesagt, noch nicht durchbuchstabiert.

    Aber ich sag mal so ... man kann es mal testen. Koscht ja nüx! search