Beiträge von bembelimen

    Du kannst mit der Direktive <FileMatch Dateien blockieren, aber da Joomla! für eine URL viele Wege kennt um diese aufzurufen, ist das eine Arbeit die sehr schnell ausufern kann.


    Was ich aber nicht verstehe ist, warum du überhaupt mit einer htaccess arbeitest.... Ich meine du hast Joomla! mit einem ausgeklügelten Rechtesystem. Installiere dir eine Dateiverwaltung und lege 1-x Joomla!-Nutzer an. Diese kannst du dann einer speziellen Mitglieder Zugriffsebene zuweisen der dann auch entsprechend die Artikel und Dateien etc zugeordnet werden. Macht doch das ganze viel einfacher wartbar und gleichzeitig so viel flexibler.

    Wenn du ein bisschen programmieren kannst, mache ein override des mod_custom und baue sowas ein:

    Den Link pflegst du dann ganz normal als Content im Modul (natürlich ist der Link für Leute die ihn kennen weiterhin erreichbar). Dann brauchst du auch keine Erweiterung um die du dich kümmern musst...

    REST ist weniger Magic als es sich anhört. Wenn du dir im klaren bist, wie der Prozess aussieht dann ist es nicht schwer, sowas zu implementieren.


    Dein Flow ist:

    Nutzer kommt auf DEINE Seite auf der DEINE Komponente läuft und füllt irgendein Formular aus. Danach drückt der Nutzer auf speichern und das Formular wird an DEINE Komponente gesendet. Und nun müssen die Daten die in DEINER Komponente gespeichert sind an die FREMDE Software gesendet werden?


    oder:


    Nutzer kommt auf die FREMDE Seite mit der FREMDEN Software und füllt irgendein Formular aus. Danach drückt der Nutzer auf speichern und das Formular wird an die FREMDEN Software gesendet. Nun müssen die Daten irgendwie in DEINER Komponente ankommen?

    Sorry, aber eine Empfehlung für Extensions und eine Aussage über das stable Release sagt jetzt nicht aus, dass Joomla! 4 Beta per se unsicher ist.


    Die größte Gefahr von Joomla! 4 Beta ist, dass sich fundamentale Sachen (z.B. Bootstrapversionen) ändern und nach einem Update die Seite nicht mehr richtig geht.

    Man muss eher die Version 3 im Blick haben und dafür sorgen, dass dessen Lücken bei 4 mit gefixt werden.

    Diesen Vorgang möchte ich automatisieren. Ich möchte also die Registrierdaten in Joomla mit meinen Mitgliederdaten zeit zyklisch vergleichen und daraus eine Aktivierung oder eine Ablehnung ableiten. Zusätzlich soll das Ergebnis als Mail an den Anforderer/In gesendet werden.

    Meine Frage ist, ob ich das alles selber programmieren muss oder ob jemand von euch geeignete Komponenten kennt, die so etwas ermöglichen/unterstützen?

    Wie liegen denn die Daten vor und woran wird denn erkannt, ob ein Benutzer ein Mitglied ist?

    Hallo Re:Later,

    es gibt hier mehrere Möglichkeiten, da kommt es auch darauf an, was dein Hoster erlaubt.


    Das einfachte ist natürlich eine htaccess (oder Serverside), die von example.de auf example.eu weiterleitet. Aber "ohne sichtbare Umleitung" bedeutet URL-Änderung, oder? Dann fällt das natürlich flach.


    Das gute (oder auch das schlechte) an Joomla! ist, dass man beliebige URLs drauf werfen kann und es funktioniert. Wir haben z.B. ein Project, dass je nach URL verschiedene Sachen tut. Das haben wir (weil es unser Hoster so vorgibt) folgermaßen gelöst:


    Server 1 mit Domain 1

    Server 2 mit Domain 2 und dem Joomla!


    Auf Server 2 hast du ganz normal die Domain 2 eingerichtet und lässt sie auf den Joomla! Ordner zeigen.


    Auf Server 1 musst du die DNS-Einträge bearbeiten können und dort den A-Record von Domain 1 auf Server 2 zeigen lassen (sprich die IP des Server 2 eintragen). Das kannst du per Wildcard für alle Domains machen oder explizit für einzelne Subdomains.


    Das wars eigentlich schon auf Server 1, nun gehts wieder weiter mit Server 2. Dort haben wir dann Domain 1 als Domain eingerichtet und auch auf den Joomla!-Ordner zeigen lassen.


    Ich hoffe, das hilft.

    1. Suchfunktion (Tabellen "präfix_finder_terms", "_finder_links", "_finder_links_termsX" wobei X als Platzhalter für Ziffern steht):
      offenbar bläht das Indizieren der Seite oder das Sammeln der Suchergebnisse diverse Tabellen auf. Derer gibt es mehrere und fast alle liegen im MB-Bereich. Die größte hat aktuell 26 MB. Ich habe in der Komponente "Suche" bereits die Suchergebnisse zurückgesetzt, was aber keine Verbesserung brachte.


    Wenn du keine Auswertungen fährst:

    1. Deaktiviere die Suchstatistiken in den Optionen
    2. Leere die entsprechenden Tabellen
    3. Optional: nutze dieses Plugin: https://www.joomlager.de/de/extensions/finder (ist fast die 4.0 Version, hilft zwar nicht beim Datenvolumnen, dafür sind aber die Ergebnisse besser)
    4. Generiere den Index neu
    1. Redirect (Tabelle "präfix_redirect_links"):
      Das Plugin dazu habe ich aktiviert, aber nicht wirklich etwas eingetragen. Nach meinem Verständnis werden dort aber "tote Verweise" gesammelt und auf aktuelle Adressen umgeleitet. Als ich hier in die Tabelle geschaut habe, fand ich auch diverse Einträge wie "http://meinedomain.de//images/3xp.php" oder "http://meinedomain.de/blog/wp-login.php" in verschiedensten Ausprägungen. Sind das Relikte eines Hackversuches? "http://meinedomain.de/wp-login.php" hat 414 hits.

    Deaktiviere das Redirect Plugin und lösche alle nicht veröffentlichten Einträge. Da du es scheinbar nicht nutzt, braucht es das Sammeln nicht.


    1. Banner (Tabelle "präfix_banner_tracks"):
      aktuell 545.279 Datensätze bei 52 MB. So wie ich das verstanden habe, werden hier die Banneraufrufe gezählt/summiert. Die Tabelle könnte auch problemlos geleert werden. Allerdings sind auf der Webseite Banner enthalten. Ob die Anzahl der Klicks aktuell für eine Abrechnung verwendet wird, kann ich (noch) nicht sagen.

    Deaktiviere "Track Impressions" (keine Ahnung was das in deutsch heißt) in den Banner Optionen und leere die Tabelle wenn nicht benötigt. Wenn du sauberes Caching etc. aktiviert hast, ist der Zähler eh nicht sehr zuverlässig und es sollte anders getrackt werden.


    Auf kleinen Seiten reicht com_search vollkommen. EDIT: Oder gleich eine seitenspezifische CSE (Custom Search Engine) von Google, wenn man mit der üblichen Werbung in den Suchergebnissen leben mag.

    Das sind halt Welten zwischen einer (sauber konfigurierten) Smart Search (Finder) und einer normalen Suche. Das hat weniger was mit kleiner oder großer Seite zu tun sondern mehr was für eine Qualität an Suchergebnisse man haben will.

    was aber in Joomla 4 im Core in dieser Art wieder "abgeschafft wurde", ohne, dass ich verstanden hätte warum, was nun "best practice" ist. Funktioniert aber vom Prinzip her trotzdem noch.

    Code
    Factory::getApplication()->enqueueMessage(...)
    
    oder
    
    throw new \Exception(...);

    Je nachdem wie schlimm es ist...