Beiträge von Re:Later

    Lies bitte die Forenregeln, welche Infos Helfer benötigen, um dir helfen zu können. Vornehmlich mal einen Link zum Problem, zur Seite. Es hilft nichts das Joomlaplate-Template-Demo zu verlinken, noch dazu, wenn da das Problem gar nicht zu sehen ist.


    Und hast du nicht support beim Hersteller, wenn du es gekauft hast? Schätze aber, der wird dann auch einen Link haben wollen.

    Vergiss diese Dokumentation, schon allein, weil sie uralt ist. Ich lese da auch nicht, dass du irgendwas in der html.php verändern sollst. Das wäre Sünde und die Änderung ist auch nicht updatesicher.


    Und auch im ISIS macht man keine Änderungen. Wenn, dann in einer Kopie des Templates (nicht des Stils), was ich aber ehrlich gesagt nicht empfehlen kann.


    Damit Joomla nicht automatisch das favicon.ico aus dem ISIS-Templateordner zieht, musst du es nur entfernen. Dann schaut Joomla im Backend noch, ob eines im administrator/-Ordner liegt. Nur, wenn ja, nimmt er stattdessen das.


    Es ist Browserangelegenheit, welches Favicon er bevorzugt verwendet, wenn du mehrere Arten/Zeilen zur Verfügung stellst. Manche brauchen noch nicht mal mehr irgendeinen Hinweis im HTML, sondern suchen selber.


    Hier ein "spaßiges" Tool, das dir auch das HTML rauslässt.

    https://realfavicongenerator.net/


    Und beim Testen von favicons nicht vergessen, dass Browser die manchmal hartnäckig cachen und manchmal schlecht davon zu überzeugen sind, das eines ausgewechselt wurde.

    Gruppe ist:

    Registered -> Registered supporter

    Wo kommt denn diese Gruppe eigentlich her? Hat die Zugriff aufs Backend? Was ist die übergeordnete Gruppe?


    In einem normalen Joomla mach ich das so, wobei mir mal gesagt wurde, dass das nicht ganz richtig wäre. Mir wurst, solange ich einer der Meister über das betreffende Joomla bin. "Problem" ist halt, dass man bei Neuinstallationen, z.B. von Komponenten noch mal schauen sollte, ob "Untermanager" neues Verbot hinzubekommen muss.


    -Lege in einem Browser asl Super User eine Gruppe "Untermanager" an mit übergeordneter Gruppe "Manager". Erbt erst mal Rechte von Manager.

    - Lege User in Gruppe Untermanager an, logge mich mit dem in einem anderen Browser an.


    - Klicke als Super User alle Menüpunkte durch, die der Untermanager dann noch sieht und die er nicht sehen soll. Deaktiviere jeweils unter Optionen->Berechtigungen den Administrationszugang.

    - Untermanager lädt Seite neu.


    - Nächster Menüpunkt als Super User, was Untermanager noch sieht.


    Wenn ich das also für Menüpunkte Beiträge und Medien gemacht habe, verschwindet auch das jetzt leere Hauptmenü Inhalt, weil nix mehr drin ist.


    Und mit SP-Pagebuilder kenne ich mich nicht aus, ob er diese Möglichkeit Optionen->Berechtigungen überhaupt bietet.

    zusätzlichen eigenen "Administrations-Menü" und einem Menüeintrag "Modul" der eine Liste der Module anzeigen sollte

    Hat den "Nachteil", dass ein fieser Knabe über die Links trotzdem noch in die nicht explizit per ACL verbotenen Bereiche kommen könnte. Soweit ich mich erinnere...

    Options Symfollow.... eine # gesetzt (wegen 500Fehler

    Wenn du damit Zeile

    Code
    1. Options +FollowSymlinks

    meinst und die eben einen 500 erzeugt, dann ist das schon OK die einzelne Zeile zu deaktivieren. Zumindest im Core-Joomla.


    Es ist sowieso so, dass durch einen Sicherheitsfix im Media-Manager derzeit SymLinks im MediaManager NICHT funktionieren. Zu meinem Glück aber nach wie vor im JCE-FileBrowser, Backup-Erweiterungen etc..

    .ich lege dort Ordner an, gehe in den Ordner und lade dann hoch (in diesen Ordner rein)


    Wenn ich htaccess "aus" lasse, klappt dies,

    mache ich htaccess "an" läd es das Medium nicht in den Unterordner, sondern ins Grundverzeichnis images

    Da gab es die Tage ähnlich klingende Meldungen auf GitHub/IssueTracker. Da schien es aber darauf hinaus zu laufen, dass der angelegte Unterordner ebenfalls "images" hieß. Hab aber das Interesse verloren, weil auch bei mehrfachem Lesen mir nicht klar wird, um welche "Ecke" es bei wem eigentlich geht:

    https://github.com/joomla/joomla-cms/issues/25015


    EDIT: Folgend wohl Blödsinn, weils da um den Editror TinyMCE geht.

    Wennst dich traust, kannst ja probieren:

    Rotes raus, Grünes rein.

    https://github.com/joomla/joomla-cms/pull/25037/files

    Von "anderen Plugins" deaktivieren war nie die Rede. Wer Suchindex nicht benötigt, soll es deaktivieren. Und da reicht grundlegend das Master-Plugin des Suchindex. Sauberer ist alles deaktivieren. Anstatt an der DB rumzuschrauben, wenn man überhaupt darf.


    Post #12 klärt ja jetzt den Rest. Das habe ich eben zuvor vermisst. "Wer Suchindex braucht, kann versuchen....".


    Zurück zu Joomla. Bei einem Standard-Hoster und da laufen nun mal die meisten Seiten von Leuten, die hier Fragen stellen, wird zwar per phpMyAdmin mit SQL-Befehl

    Code
    1. select @@max_heap_table_size;

    zwar vermutlich die richtige Zahl ausgegeben (meist 16777216), aber ein

    Code
    1. set @@max_heap_table_size=25165824;

    wird ohne Fehlermeldung in's Leere laufen. Weitere Möglichkeiten haben die meisten Joomla-User eben nicht außer Hoster bitten und/oder größere (= teurere) Pakete.

    Für mich einer der wichtigsten Sätze bzgl. der unsäglichen Cookie-Warner, die sich die Leute auf Joomla installieren:

    Zitat

    Nicht selten ist zu beobachten, dass zwar ein, den Kriterien einer wirksamen Einwilligung entsprechender Cookie-Banner vorhanden ist, beim Besuch der Website jedoch im Hintergrund bereits Cookies in den Browser geladen werden, obwohl der Nutzer dem noch nicht zugestimmt hat. Dabei wird außer Acht gelassen, dass eine vorherige Einwilligung eingeholt werden muss und nicht eine nachträgliche Genehmigung. Ein rechtlich einwandfreier Einwilligungstext nützt wenig, wenn eine entsprechende technische Umsetzung nicht erfolgt.

    Zusätzlich ist es der Joomlaseite auch nachträglich gar nicht möglich z.B. Google-Tracking-Cookies wieder zu entfernen, wenn jemand "Ablehnen" klickt, falls es das im Warner gibt. Doppelte Irreführung, die ich im Fall der Fälle für noch gravierender halte.


    Und:

    Zitat

    Wer denkt, mit der DSGVO hätte man nun eine beständige Rechtslage in Bezug auf Cookies, liegt daneben.

    Muss man leider immer wieder betonen, auch hier im Forum.


    Und natürlich:

    Zitat

    Etliche Hinweise verdecken jedoch in Form eines großen Layers fast die gesamten Inhalte einer Website und bieten lediglich die Möglichkeit, mittels eines einzelnen OK-Buttons Cookies zu akzeptieren. Ohne Einwilligung kann man die Website somit nicht nutzen. In solchen Fällen gilt die Einwilligung nicht als freiwillig erteilt und ist daher unwirksam

    Ich bin jedoch der Meinung, dass es nur verschiedene Methoden sind wie man die Inhaberschaft bestätigen kann, es jedoch kein muss ist sich mit allen Methoden zu bestätigen.

    Code
    1. http://example.com
    2. https://example.com
    3. http://www.example.com
    4. https://www.example.com

    sind für Google alles einzeln zu bestätigende Domains, wenn man sie in der Search Console für irgendwas verwenden will.


    Das mit der "Methode": Klar nimmst nur 1 Bestätigungsmethode. Z.B. Hochladen einer html-Datei in den Webspace.

    Diese html-Datei kann dann aber für alle anderen example.com-Domeins wiederverwendet werden. Es reicht dann also ein Klick und man muss nicht blöd erneut Dateien hochladen.


    Wenn also schon vorher mit einer

    Code
    1. http://example.com

    gearbeitet wurde, wo man seine Daten verwaltet hat. und will jetzt "www" als bevorzugt und "https" musst also

    Code
    1. https://www.example.com

    anlegen und ebenfalls bestätigen.


    Rest wie in Post #2. Wobei ich mir immer etwas Zeit lasse mit dem Löschen der nicht mehr genutzen, weil's früher zumindest immer Überschneidungen bei den beiden "Statistiken" gab. Geschmackssache.

    Jetzt gibt es halt immer noch

    Code
    1. https://www.sf-tortechnik.de/component/contact

    Für meine Kontaktseite nutze ich Visforms, ich weiß nicht inwieweit das mit den Kontakten und Kategorien zusammenhängt

    Gar nicht. Also lösche den ganzen Schmarrn, auch aus dem Papierkorb und deaktiviere die Kontakt-Komponente unter Erweiterungen > Verwalten (nicht deinstallieren).


    Genauso, final auch aus dem Papierkorb löschen, solltest du es mit allen Demodaten in allen Bereichen machen.


    Vorher Backup. Kaffee- oder Tee-Kanne daneben und paar Stünderl durchgehen.


    Erst dann lohnt sich bei Google Neucrawl zu beantragen.

    Zu eigenes Layout:

    default_hip.php ist natürlich falsch.


    So sollte deine Datei-Liste im Override-Ordner aussehen:

    Code
    1. hip.php
    2. hip_component.php
    3. hip_heading.php
    4. hip_separator.php
    5. hip_url.php

    Dann unbedingt noch in der hip.php austauschen

    Code
    1. require JModuleHelper::getLayoutPath('mod_menu', 'default_' . $item->type);

    gegen

    Code
    1. require JModuleHelper::getLayoutPath('mod_menu', 'hip_' . $item->type);

    Sowie:

    Code
    1. require JModuleHelper::getLayoutPath('mod_menu', 'default_url');

    gegen

    Code
    1. require JModuleHelper::getLayoutPath('mod_menu', 'hip_url');

    Dann ins Menü-Modul gehen und im Feld Layout das "hip" auswählen. Jetzt werden deine Overrides als eigenes Layout verwendet.


    So, dann den Code ändern wie oben angedeutet.

    Zeilen 11-13 deines Codes in Post#9 bleiben, wo sie sind.


    Zeile 14

    Code
    1. $item->flink . '?UID=' . $UID;

    verschiebst aber nach Zeile 24, also ins foreach, wie von Waldbaer ja schon richtig gefunden.

    und derzeit noch ohne SEO wie folgt aus

    Da wird es zum Problem kommen, wenn du umschalten willst.

    Also gehts so weiter: Die Zeile im foreach

    Code
    1. $item->flink . '?UID=' . $UID;

    tauscht du aus gegen

    Ob's elegant ist, ist mir wurst ;-)