Ich bin für Beibehalten.
Wer meint, dass seine Domain nicht genannt werden soll, der hat auf Nachfrage auch angegeben, das es nicht zugänglich ist.
Unerfahrene bekommen aber etwas an die Hand, was die Problemlösung für die Helfer erleichtern kann.
Ich bin für Beibehalten.
Wer meint, dass seine Domain nicht genannt werden soll, der hat auf Nachfrage auch angegeben, das es nicht zugänglich ist.
Unerfahrene bekommen aber etwas an die Hand, was die Problemlösung für die Helfer erleichtern kann.
Wenn es unflexibel sein darf und der Pfad fest steht hart in in Index pho schreiben.
Da es dein spezilles Template ist, dürfte es auch mit Updates keine Probleme geben, da du ja für das Template-Update verantwortlich bist.
Das ist das vorgesehene Verhalten von Hauptbeiträgen.
Die werden zumeist in einer Blog-Ansicht dargestellt. Dann ist der Link sinnvoll.
Sollte mit Override änderbar sein.
Es gibt wohl auch ein Projekt ProtoStar für J4 umzustellen.
Ich selber bin aber auf Cassiopeia umgestiegen.
Das ließ sich gut anpassen und man kann die Optik damit gut nachbauen, wenn man will.
Bei den Optionen im Menü geht es ggf .
Schau mal in den Einstellungen, die du beim Menü machen kannst.
Schau mal in die Einstellungen des Templates.
Manchmal ist Ein Problem halt ein Problem!
Der Datenschutzbeauftragte sollte die Rechtslage vielleicht nochmal prüfen. Ich denke er ist mit seiner Ansicht absolut in der Minderheit.
Natürlich werden auch Informationen zu alten Joomlas hier gegeben.
Aber keiner hat empfohlen beim alten Joomla zu bleiben und ich gehe davon aus, dass dies auch keiner tuen wird.
Da keiner mehr aktiv nachschaut außer die Hacker, wird dass nicht so ohne weiteres zu finden sein.
Da aber alles vor Joomla 3 nicht aktiv gewartet wird, aber ggf. der Code derselbe ist, werden vorhandene Sicherheitslücken in späteren Versiionen gefixt in den älteren nicht.
Die Hinweise, die du erhalten hast, haben nichts mit Nerdverhalten zu tun.
Da du schreibst, dass einer deiner Studenten, die Seite erstellt hat, gehe ich davon aus, das du Lehrender bist. Dein Interesse ist wahrscheinlich mit der Seite deine Studis zu unterstützen. Wenn du dies mit einer Webseite machst gehört dann auch dazu , dass du dich mit Rechten und Pflichten eines Webseitenbetreibers vertraut gemacht hast. Wer eine Webseite betreibt hat aber nicht nur rechtlich sondern auch moralisch die Pflicht eine Webseite sicher zu betreiben. Veraltete Software ist aber nicht sicher. Die Wahrscheinlichkeit, dass enthaltene Sicherheitslücken ausgenutzt werden ist leider relativ hoch. Wenn jemand die Sicherheitslücken deiner alten Software ausnutzt, wird dies u.a. deine Besucher somit deine Studis gefährden. Dies ist sicher nicht von dir gewollt, aber entspricht der Realität. Deshalb haben die Kollegen sich so geäußert.
Vielleicht solltest du mal den Blickwinkel verändern, dann sieht dein Problem nämlich anders aus.
Und bildlich dargestellt verlangst du von deinem Helferlein, dein Fahrzeug, bei dem die Bremsen nicht zuverlässig funktionieren, über eine lange Strecke durch den Verkehr zu bewegen, um es danach wie fabrineu an dich zurück zu geben.
Das diesem Ansinnen kaum einer nachkommt ist wohl verständlich.
Und ja es gibt natürlich auch die Möglichkeit ein Joomla 1.5.26 auf Joomla 4.28 upzugraden. Dass ist aber sehr aufwendig und nicht mal eben erklärt.
Es können und werden viele Probleme auftreten. Daher wird man häufig eher die Seite neu unter dem aktuellen Joomla aufbauen, als den Upgradeweg zu nehmen, fa dies schneller und einfacher geht.
Neues Joomla erstellen.
Textinhalte per Copy and Paste möglichst mit Zwischencopy in einen reinen Texteditor übertragen. Bilder hochladen und einfügen. Aktuellen Slider und was sonst benötigt wird installieren und einrichten.
D anach die Software aktuell halten !
Warum hast du die nicht J4 kompatibelen Plugins, Erweiterungen nicht deinstalliert sondern nur deaktiviert. Hoffst du noch darauf, dass diese J4 kompatibel werden.
Wenn nicht mehr benötigt, ist deinstallieren aus meiner Sicht besser.
Wahrscheinlich sind im Ordner MySQL Datenbank-Dumps und die bz2 Dateien sind komprimierte Archive des Webspace.
Damit müsste ein Backup gehen.
Würde aber auch erst schauen, ob es dafür nicht Tools des Hosters gibt.
Ich würde Umstellung in Testumgebung durchführen und notwendige Schritte protokollieren.
Wenn Ergebnis gefällt würde ich Backup der Seite in Subdomain einspielen. Die anderen dürften dann nichts mehr ändern.
Schritte wie protoklliert durchführen, wenn Ergebnis gefällt und getestet ist Domain umstellen. Den anderen Freigabe mitteilen.
Das könnte die Zeit, in der nicht gearbeitet werden kann minimiert werden.
Dann etwas anders formuliert.
Warum wird in der Grundeinstellung soviel aktiviert, was wahrscheinlich ein Großteil der Anwender noch nicht braucht.
Der Nutzer der App würde dann in den System Bedingungen erklärt bekommen, dass er folgende ..... Einstellungen, Bedingungen bei Joomla benötigt. Die stellt er dann selber oder von einem Berechtigten ein.
Flapsig ausgedrückt: Ich fahre nicht schon jetzt mit einem Wasserstofftank durch die Gegend weil vielleicht in Zukunft das der Treibstoff ist. Achtung bewusste Übertreibung.
Ich finde weniger ist eben manchmal mehr. Und wer dann noch mehr braucht, der beschäftigt sich damit, wie er es erreicht.
Ist halt ein anderer Blick auf die Sache.
Das war nicht meine Aussage.
Es ist gut, dass joomla für viele Einsatzzwecke tauglich ist. Gut wäre aber, wenn es für den Standardeinsatzzweck möglichst sicher eingestellt ist, damit auch Einsteiger eine sichere Umgebung haben.
Da deine oben genannten Einsatzzwecke tiefere Kenntnis benötigen, kannst du dann die notwendigen Einstellungen machen.
Mir geht's darum, die nicht so versierten Anwender möglichst sicher arbeiten zu lassen.
Ohne dieden Thread würden bei mir weiter plugins laufen, die ich nicht brauche. Und da ich glaube, dass dies bei vielen Anwendern so ist, war mein Apell, in der Standardinstallation nur die Funktionalitäten zu aktivieren, die der Standardnutzer auch benötigt.
Ich kann auch nicht nachvollziehen, dass automatisch etwas aktiviert ist, das kaum ein Projekt nutzt. Da wäre andersrum der Sichere Weg.
Vielleicht sollten da die Security Verantwortlichen nochmals drüber nachdenken. Projekte mit API-Nutzung werden sicher von Personen betreut, die wissen, welche Plugins angestellt werden müssen. Die können diese dann anstellen. Die anderen, die diese Plugins nicht brauchen, müssten aber nichts extra deaktivieren.
Vielleicht hilft dir das weiter https://www.df.eu/de/support/d…nfactory/#accordion-24564.
Der Hoster kann ein caching nutzen.
Wer ist dein Hoster.