Beiträge von Kallle

    Aber offenbar halten sich mehr als 90% der Entwickler an <name>com_component</name>. Ein <name>com_component_menu</name> findet man wohl eher selten direkt oben in der ersten Codezeile.

    Eine davon abweichende Bezeichnung in einem Extra-Menüblock findet man wohl nicht so oft.


    Egal: Als relativer Dummy freue mich, jetzt den Weg gezeigt bekommen zu haben, wie ich dem Ganzen auf den Grund gehen und die Namen dann nach meiner Vorstellung ändern kann - auch wenn sie sich nicht so verhalten wie der Durchschnitt. pardon

    Vielen Dank, Sieger66!


    Wieder was dazugelernt! Und dabei auch den Grund für das ungebührliche Verhalten von "com_seminarman" herausgefunden: Während die anderen Schlüssel tatsächlich nur "com_namederkomponente" lauten, heißt der Sprachschlüssel des Seminarmanagers "com_seminarman_menu". Manche Entwickler mögen's wohl ein bisschen anders ...hmm

    Du könntest das auch händisch in der Datenbank machen. In der Tabelle #__menus findet man auch die Einträge des Komponentenmenüs im Backend. Aber es ist abzusehen, dass das bei einem Update einer Erweiterung überschrieben werden wird / werden kann.

    Bloß nicht! In den letzten Jahren habe ich mich oft genug mit solchen direkten Änderungen in Coredateien und Datenbanken herumgeschlagen. Bei einer Vielzahl von zu betreuenden Seiten verliere ich es aus den Augen, wo ich was gemacht habe und dass ich es nach jedem Update wiederholen muss. Das ist mir zu stressig. Was nicht über Overrides zu bewerkstelligen ist, muss eben so bleiben wie es ist - habe ich gelernt. Nicht alle Wünsche können erfüllt werden ...

    Hast du des denn probiert mit com_XXX als Sprachstring? Genau dann sollte es funktionieren ein Problem hätten wir nur wenn da direkt der Name der Erweiterung drinsteht ;)

    Okay, ich hatte Dich falsch verstanden. Jetzt habe ich's probiert und erhalte ärgerlicherweise unterschiedliche Resultate:

    Bei "com_sobipro" funktioniert es genau so, wie Du es beschrieben hast. SOBIPRO könnte ich also umbenennen.

    Bei "com_seminarman" aber tut sich einfach gar nichts, obwohl ich das Override exakt gleich angelegt habe und obwohl es auch in der com_seminarman.xml ebenso codiert ist, wie com_sobipro.


    NACHTRAG: Das Sprachoverride bei com_seminarman führt dazu, dass nicht der Text im Komponentenmenü geändert wird, sondern nur der Text ganz oben im Tab des Browsers! Weiß der Teufel, was der Entwickler da codiert hat!


    Ich belasse es dabei und verzichte darauf, umzubennenen. Es ist mir zu nervig und zeitraubend, zu recherchieren, warum Joomla (bzw. die Erweiterung) einmal so (richtig) und einmal so (nämlich gar nicht) auf die gleiche Vorgehensweise reagiert.

    Zitat

    Hast du vielleicht auch das neue und das alte Menü gesehen? Das neue musst du so einstellen das dir als Super Admin nicht angezeigt wird (also ein access level wo der SU keinen Zugriff hat) Oder du baust ein neues für alle und deaktivierst das Modul mit dem original Menü.

    Offenbar bin ich im Englischen nicht gut genug zu Fuß, um alles richtig zu begreifen. Deshalb belasse ich es beim Alten.


    Vielen Dank für Deine Tipps.

    Danke für Deine Tipps, zero24!


    Leider steht in den XMLs überall nur direkt <name>com_XXX</name>. Sprachoverrides gehen also schon mal nicht.


    Eigenes Backend Menü muss ich mir mal in Ruhe zu Gemüte führen.

    Auf die Schnelle fand ich jetzt in der Beschreibung nicht genau meinen gewünschten Anwendungsfall.

    Ich erinnere mich, vor einiger Zeit mal mit einer ähnlichen (oder mit dieser?) Erweiterung versuchsweise an den Backendmenüs herumgeschraubt zu haben. Wahrscheinlich hab' ich da was nicht richtig verstanden: Was ich beabsichtigte, passierte nicht; dafür hatte ich plötzlich mehrere Menüs doppelt nebeneinander stehen.

    Das fand ich dann nicht so lustig, hab' schnell das Backup wieder hergestellt und mir vorgenommen, die Finger von solchen Experimenten im Backend zu lassen.

    Ich dachte, irgendwo eine Ankündigung gelesen zu haben (bei Joomla 4?), dass ein solches Umbenennen der Komponenten etc. möglich werden sollte.


    Schau'n mer mal. Es ist ja nicht wirklich kriegsentscheidend ...thinking

    Wenn eine sehr komplexe Webseite an die 20 verschiedene Komponenten im Backend auflistet, sind die Originalnamen der Komponenten meist verwirrend. Die meisten sind nicht "sprechend".

    Ich möchte es den Joomla-Redakteur*innen gern einfacher machen und zum Beispiel "SobiPro" in "Adressverzeichnis" umbenennen oder "Matukio Events" in "Seminarbuchungen" usw. Gibt es mittlerweile die Möglichkeit des dauerhaften Umbenennens der Menüpunkte im Backend (zumindest Komponentenmenü), so dass die Namen auch beim Updaten erhalten bleiben? Oder ist das vielleicht für Joomla 4 geplant?

    Hallo zusammen!

    Zum ersten Mal habe ich heute eine E-Mail über/von diesem Forum erhalten. Als höchstmisstrauischer Mensch erscheint sie mir äußerst suspekt. E-Mails, die ich nicht erwarte, bzw. die nicht absolut plausibel sind, lösche ich i.d.R. gleich, ohne darauf zu reagieren. Für den Fall, dass auch andere Mitglieder hier solche Mails erhalten haben, poste ich sie hier. Sie stammt angeblich von einem "sgthelenmarkm", der hier aber (laut Suchmaschine) noch keinen Beitrag gepostet hat.

    Oder täusche ich mich - und es handelt sich dabei um einen Eurer Admins?

    LG, Kallle

    Ich verwende die Extension "Ultimate Users" und möchte, dass man nach einem Login direkt zu einem bestimmten Menüpunkt (Phocadownload) geführt wird.

    Leider gibt es in den Redirection-Einstellungen nur wenige Optionen: Homepage, Previous Page, Login, Register und Custom. Zu allem Übel kann man aber bei "Custom" nur zu einem Joomla-Artikel weiterleiten, nicht zu einem bestimmten Menüpunkt (der eben kein Artikel ist).


    In meinem jugendlichen Leichtsinn (oder auch Altersstarrsinn) stelle ich mir vor, dass es möglich sein müsste, zwar zu einem bestimmten Artikel zu redirecten, dass aber dieser Artikel seinerseits sofort wieder zum Menüpunkt "Phocadownload" weiterleitet. Wenn ich das richtig verstanden habe, sollte es über eine Meta-Anweisung im head-Bereich des betreffenden Artikels möglich sein:

    Code
    1. <meta content="URL=domainname/phocadownload" http-equiv="refresh" />

    Der JCE bietet ja allerhand. Aber einen Zugang zum Artikel-Headbereich habe ich noch nicht finden können. Für sachdienliche Hinweise wäre ich dankbar.

    Herzlichen Dank für Deine Tipps, Re:later!


    Damit werde ich mich in den nächsten Tagen beschäftigen (Ostern). Heute bin ich erst mal genervt, weil ich dachte, ich "schmeiß" die Brocken und die Beschreibungen (die ich noch aus einer alten Joomlaseite extrahieren und umformatieren muss) mal eben schnell in die Seite. Stattdessen tauchen immer wieder neue Hürden auf. Jetzt muss ich mir erst mal was Gutes tun: Ein bisschen Radfahren.

    Ich melde mich wieder, wenn ich weitergekommen bin.


    So, 3 Uhr morgens - und die grundsätlichen Probleme sind beseitigt!

    Nachdem das Zugriffsproblem endlich geklärt war (es fehlte ein "File view = yes" - allerdings mit ursprünglich bewusster Absicht), konnte ich das PD-Search Plugin auf die Dateiansicht umschalten. Dann habe ich begonnen, die Dateiansichten, die jetzt jede für sich erreichbar sind, umzugestalten. Die ganzen schönen Slider können jetzt wieder raus. Sie sind nicht mehr nötig.

    Und ich hoffe, dass heute bei der Datenpflege der noch fehlenden Beschreibungen nicht doch noch irgendetwas anderes Unerwartetes querschießt.


    Geht es eigentlich Profis wie Dir auch manchmal so, dass Du Dich beim Zeitaufwand total verschätzt und dann doppelt oder dreimal so lange brauchst wie gedacht? Oder passiert das nur Dummies wie mir?


    Schöne Ostergrüße - auch an Indigo66, der mich ja mit seiner Frage erst auf den richtigen Weg gebracht hat. Und auch dsa Phoca-Forum hat mir weitergeholfen.

    Manchmal erhält man die richtigen Antworten, obwohl man die falsche Frage gestellt hatte ...vain

    Zeig halt mal einen Link wie es jetzt ist. Damit Doofies wie ich eine Vorstellung haben. Was hilft ein Anker im Ergebnis-Link, wenn er auf der Kategorieseite gar nicht vorhanden ist? Oder stehen die da schon?

    Der Link zur Archivseite lautet https://jung-journal.de/archiv. Der Anker ist vorhanden und wird offenbar von den durch mich in die Beschreibungen intergrierten Regularlabs-Slider erzeugt. Die dienen dazu, alle Beschreibungen zunächst eingeklappt zu halten, weil die Seite sonst irre lang würde.


    Wenn ich einen Anker anspringe z. B.: https://jung-journal.de/archiv#heft38 , dann funktioniert das zwar prinzipiell bereits. Aber leider landet der Sprung etwas zu tief. Ich müsste einen Offset setzen können. Und eigentlich sollte sich dabei der Slider auch gleich ausklappen - aber das ist eine andere Thematik. Die müsste ich wohl mit Regularlabs klären.

    Zitat

    Handelt es sich um die normale Joomla-Suche (com_search) oder Indexsuche (com_finder)?

    Bei ersterer werden die Ergebnisse on-the-fly im zugehörigen Plugin abgefragt und die Links dort zusammengesetzt. Wäre also die Frage, ob man da irgendwelche Infos zur Sprungmarke bekommt, zusätzlich abfragen kann.

    Nicht unbedingt, wenn bspw. eine Erweiterung eine eigene Rechteverwaltung hat, die reingrätscht.

    Oder auch, wenn Super User nicht zur Zugriffsebene "Gast" gehören. Dann sehen die z.B. auch Module nicht, deren Zugriffsebene auf "Gast" steht.

    Ich denke, es handelt sich um com_search. Zumindest habe ich keinen com_finder konfiguriert. Aber könnte es sein, dass, wenn ich den nutze, er einen festen Index anlegt, wo ich dann in der DB manuelle URL-Änderungen vornehmen könnte?


    Übrigens: Die Seite ist zwar produktiv online. Dennoch teste ich zur Zeit die geeignete Integration der Suchfunktion - also bitte nicht wundern, wenn sich heute von Zeit zu Zeit die Position und das erscheinungsbild der Suchfunktion ändert. Außerdem muss ich auch noch die meisten Beschreibungen erst noch einpflegen (heute und morgen).

    Ja.

    Leider kann ich es nicht auf "File-View" einstellen, sondern muss es auf "Category_View" stehen lassen.

    Grund: Die Kategorien-Übersicht ist öffentlich. Jeder kann das ganze Downloadangebot sehen, die Beschreibungen lesen und danach suchen.

    Aber der Download ist nur registrierten Mitgliedern erlaubt. D. h. bei "File-View" würde jeder Öffentliche die Meldung erhalten:

    Heft ## Datei: Keine Rechte zum Zugang zu dieser Kategorie vorhanden


    Und zu allem Übel stelle ich gerade fest, dass bei Suche mit "File-View" sogar der Superuser die Meldung erhält:

    Heft ## Datei: Keine Rechte zum Zugang zu dieser Kategorie vorhanden


    Das verstehe ich nicht. SUs sollten doch alle nur denkbaren Rechte haben. Es kann soch auch nicht sein, dass die Suchfunktion selbst nur mit öffentlichen Rechten zu Werke geht, wenn man als SU angemeldet ist ... ?


    Ich versuche es mit einer neuen Frage:

    Wo in der Datenbank werden eigentlich die URLs der Ergebnislinks gespeichert?

    Hallo, liebe Joomlarianer,


    wie/wo kann ich die URLs der Ergebnisse der Joomla-Suche ändern/anpassen?


    Mein Problem: Ich habe ein Archiv mit Hilfe von Phocadownload (PD) aufgebaut. Es enthält PDF-Dateien (Hefte). Im zum jeweiligen Heft gehörenden Beschreibungsfeld von PD steht das Inhaltsverzeichnis und eine Leseprobe. Die Joomla-Suche habe ich so eingestellt, dass sie ausschließlich diese PD-Beschreibungen durchsucht. D.h. sie sucht nicht in aktuellen Beiträgen, sondern nur im Archiv. Das funktioniert bestens!


    Leider ist die URL aller Ergebnisse standardmäßig identisch und führt immer nur zur PD-Archivseite: domainname/archiv . Das hilft dem Suchenden natürlich nicht, denn dort gibt es z. Z. 40 verschiedene Hefte, die jeweils einen eigenen Download darstellen. Der Suchende sollte daher direkt zur Beschreibung des gefundenen Heftes geführt werden. Der Ergebnislink müsste deshalb z. B. lauten: domainname/archiv#heft38 (bzw. jeweils individuelle Heft-Nummer).

    Dieser Ankerpunkt würde dann direkt zur Heftbeschreibung führen und diese auch gleich ausklappen.


    Jetzt suche ich nach einer Möglichkeit, die URLs der Ergebnislinks individuell anzupassen. Das würde ich gern auch manuell machen, denn auf dieser Webseite (und in diesem Archiv) gibt es nur zweimal pro Jahr eine Änderung, weil die betreffenden Hefte - seit ca. 20 Jahren - eben nur zweimal im Jahr erscheinen.


    Kann mir jemand von Euch da weiterhelfen?

    Eine kommunikationstechnisch nicht ganz so einfache Materie (für mich). Ich denke, dass wenn XML das Format sein soll, in dem auch z. B. Hans Wurst, Fleischerei-Fachverkäufer bei Edeka (kann zwar auf seinem Smartfon herumtippen und wischen, versteht aber weiter nichts Informationstechnisches), seine Auskunft erhalten und lesen können soll, dann sollte es auch einen Standard geben, der vorschreibt, dass jedes der gängigen großen mobilen und PC-Betriebssysteme von vornherein einen XML-Viewer mitbringt der es schafft, die enthaltenen Informationen von der beschreibenden XML-Struktur zu trennen, so dass letztere einfach entfernt und wo nötig durch eine einfache Überschrift ersetzt wird. Aber das ist ja auch gar nicht mehr Joomlas oder WPs Bier, sondern das von Windows, Linux, Android und Apple etc. Das wäre etwas Grundsätzliches, sozusagen das XML-Pendant zu einem Texteditor (der diese Trennung von Inhalt und Struktur nicht leisten kann).


    Aber um Missverständnisse zu vermeiden: Ich fordere diesbezüglich gar nichts. Ich hoffe vielmehr auf die Vernunft* der von mir betreuten Nutzer und tue alles, um die Sicherheit ihrer Daten - natürlich in Relation zu den gegebenen finanziellen und personellen Mitteln - auf höchstmöglichem Level zu gewährleisten. D. h. ich hoffe, nicht zum Opfer der DSGVO zu werden und leiste meinerseits im Vorfeld möglichst viel Prävention. Als Einmannunternehmen stehe ich ganz und gar nicht auf plötzlich und unerwartet hereinbrechende Katastrophen, die meine Arbeits- und Lebenszeit für Wochen oder Monate an sich reißen oder mich im worst case gar zum aktiv praktizierten Ableben zwingen könnten.

    *) Damit meine ich, dass sie sich vernünftig und auch mir gegenüber anständig verhalten, statt mir unnötig Arbeit zu bescheren, die letztlich auch für sie keinen Mehrwert bringt. Bisher war und ist das so, weil der Durchschnitt meiner Nutzer bereits fortgeschrittenen Alters ist, aus dem medizinisch-/therapeutischen Bereich kommt und überwiegend nicht sehr digitalaffin ist: Hauptsache funktioniert weitgehend automatisch! Warum - ist doch egal!

    ... Zugegebenermaßen habe ich da bei SobiPro auch meine Zweifel, das ja von Joomla möglichst wenig wissen will. Wahrscheinlich brauchst dann ein Diamanten-Abo und SobiPro speichert das in einer eigenen Tabelle oder in den 2 Mio Cache-Dateien ;-) Bin ein Lästermaul... Müssen die Entwickler selber wissen.

    Bei diesem Sobi-Dingens konfiguriert am Ende ja jeder Webseitenersteller selbst, was genau da unter welchen Bedingungen und Abhängigkeiten erfasst wird und wie die Fragen und Eingabemöglichkeiten gestaltet sind. Bei mir sind es außer den eigentlichen Adressdaten z. B. noch ca. 30 weitere sehr unterschiedliche beschreibende/beschränkende Parameter (Praxiseigenschaften und Eigenschaften des Praxisinhabers). Dennoch dürfte es bei Sobi wahrscheinlich doch gehen, weil die ja schon seit Jahren intern diese XML-Struktur nutzen.


    Aber bei Matukio habe ich z. B. das Buchungsformular für bestimmte Seminare sehr individuell gestaltet, weil unsere Interessenten überwiegend mit SEPA-Lastschrift bezahlen, Matukio aber gerade auf diesem Auge sehr schwach ist: Die angebotene Lösung (Ausfüllen eines extra PDF-Formulars, unterschreiben, scannen und wieder einsenden) bedeutet einen drastischen Medienbruch. Als Interessent würde ich an dieser Stelle abspringen und denken "Ach leckt mich doch!" Zur Vermeidung des Medienbruchs ist da individuelle "Bastelarbeit" gefragt. Da bin ich mal gespannt, wie dieser individuelle Teil per XML weitergegeben wird.

    Und wär doch ein tolles Feature für deine Seite, die XML-Dateien menschen-lesbar zu machen ;-) Musst nur darauf achten, dass es sich um vertrauliche Daten handelt, die User dann bei dir hochladen.

    Ich befürchte, jetzt verstehe ich Deine Ironie nicht ganz. hmm Die DSGVO fordert ja nicht, dass die abgefragten Daten NUR maschinen-lesbar sein dürfen, sondern lediglich AUCH. Im Gegenteil: Jeder Nutzer (i. d. R. ein Mensch, der nicht vom IT-Fach ist) soll auf möglichst einfache Art und Weise vollständige Auskunft über seine gespeicherten Daten abfragen können.

    Das könnten die entsprechenden Entwickler aber in ihre Erweiterung einbauen so, wie ich das verstanden habe :)

    Dann hoffen wir mal, dass sie das auch bald umsetzen ... pardon

    Ich befürchte nur, dass bei so flexibel auf den jeweiligen Bedarf konfigurierbaren Extensions wie Matukio, SobiPro und anderen, eine automatische Auskunftei nicht ganz so einfach zu stricken ist, wie bei der Joomla-Benutzerverwaltung.

    Aber genau die wird von der DSGVO gefordert. Hintergrund ist die Plattform-unabhängige Kompatibilität, um die Daten in anderen Systemen wieder einlesen zu können.

    Ja, das ist ein Teil der Forderung. Aber ich vermute, dass die meisten Anfragenden die Daten gar nicht an ein anderes System weitergeben, sondern nur selbst in Augenschein nehmen wollen, was da über sie gespeichert ist. Und dem Auge eines unbedarften Nutzers erscheint die explizite XML-Struktur doch wie ein Programmcode. Und noch gibt es ja wohl keinen allgemein verfügbaren XML-Viewer, der beliebigen XML-Code in einfachen Klartext umsetzt.

    Noch ein Nachtrag:

    Die wirklich kritischen Personendaten werden bei mir ja auch gar nicht in der Joomla-Benutzerverwaltung verwaltet, sondern in diversen Extensions, wie z. B. Matukio (Seminarbuchungssystem) und SobiPro (Adress- und Informationsverwaltung) . Diese Daten werden ja eh nicht automatisch mit ausgegeben.

    Und wäre ich ein anfragender Nutzer, würde ich erwarten, dass sämtliche von mir gespeicherten Daten (Joomla plus Extensions) im Klartext mitgeteilt werden, also ohne die maschinenlesbare XML-Struktur.