Ok, dann ist es vielleicht ein BUG ?
Ich musste den Installationsordner auch manuell löschen. Es wird aber angegeben, dass man diesen Ordner manuell löschen soll. Für mich ist das kein Problem.
Habe ich auch immer bei lokalen Installationen (nutze nicht XAMPP, sondern Laragon).
Ich finde die Argumentation -gelinde gesagt- überraschend. Was Du sagst, heißt übersetzt: Ich installiere mir ein riesiges Framework (verbunden mit der Abhängigkeit vom Hersteller), damit ich keine kleine Komponente installieren muss.
Wenn ich zu Joomla Core noch, sagen wir, EngageBox installiert habe und Tassos schmeißt irgendwann mal hin, nehme ich halt etwas anderes. Wenn irgendwann der SPPagebuilder eingestellt wird, siehst Du ziemlich alt aus.
Ist aber nur meine Meinung.
Hast Du die neueste Weblinks-Version von hier?
Es ergibt in größeren Softwarepaketen meistens keinen großen Sinn, Dinge zu löschen, von denen man nicht ganz genau weiß, wofür sie gut sind.
Aber ein Korn Wahrheit steckt aus meiner Sicht in der Aussage: Was mir zu Joomla fehlt, ist so etwas wie ein Wiki mit "Best Practices". Da würden größere Dinge hineingehören wie die Migrationsleitfäden, aber auch so kleine Tipps wie meiner von #11 mit den zusätzlichen Zugriffsebenen. Oder ein paar Tipps, wie man mit Bildern umgeht oder wie man sein /images-Verzeichnis organisieren sollte.
Es ist nie eine gute Idee, die Standard-Zugriffsebenen von Joomla zu ändern oder gar zu löschen. Wenn ich eine Zugriffsebene brauche, die so ungefähr die Rechte wie z.B. Manager hat, dann eine neue Zugriffsebene erstellen, die von Manager abgeleitet wird ("erbt") und dann nach Bedarf angepasst wird.
Eigentlich sind wir nicht hier, um an Ratespielen teilzunehmen.
Dann kannst Du die fehlende Angabe ja in Dein user.css setzen.
Ich nutze in solchen Fällen immer die Entwicklerwerkzeuge meines Firefox zum Testen und kopiere mir dann die fertige Regel.
Sorry, aber ich habe nicht verstanden, was Du haben möchtest.
Um diese Files habe ich mich noch nie gekümmert. Nachdem ich sie mir jetzt mal angeschaut habe, verstehe ich aber den Grund: Dieses Verzeichnis liegt innerhalb Deiner Website und kann dann natürlich mit seinem bekannten Namen auch aufgerufen werden:
https://<DeineWebsite>/administrator/components/com_akeebabackup/backup
Ohne Schutzmaßnahmen würde dieser Aufruf die Backup-Dateien auflisten und damit zugänglich machen. Mit den Dateien bekommst Du einen 403.
Legst Du Deinen Backup-Ordner "neben" Deine Website, hat er keinen (von außen) aufrufbaren Pfad (außer Du legst eine Subdomain auf das Verzeichnis). Deshalb brauchst Du die Schutzmaßnahmen nicht. Es schadet aber sicher nicht, wenn Du die paar Dateien dorthin kopierst.
Nein, dafür habe ich keine Idee.
Bei Deiner Lösung oben wundert mich, dass Du mit inline styles arbeitest. Kannst Du nicht die Farb-Klasse direkt zuordnen? (Ich bin kein PHP-Programmierer.)
Das weiß ich auch nicht. Muss man auch nicht wissen, denn man kann die Einstellungen ja per user.css (oder custom.css) überschreiben.
Ich habe immer einen eigenen Ordner für die Backups direkt unter /www. Und nach jedem Backup per FTP auf meine lokale Infrastruktur mit dem entsprechenden Backup-Konzept. Bei einer größeren Anzahl von Websites sollte man dann einen externen Speicherplatz mit entsprechend automatisiertem Backup-Konzept einsetzen, wie in #3 beschrieben.
Müsste auch ohne Override gehen, da die Weblinks ohnehin einen eigenen Satz von Klassen (z.B. .com-weblinks-category__items) mitbringen. Mit deren Hilfe und eigenem CSS habe ich meine Weblinks komplett neu gestaltet.
Nette Zusammenfassung. Entspricht aber im Ergebnis (ohne die Beschreibung Deiner Fehlversuche) ziemlich genau dem, was ich schon in #7 geschrieben hatte.
Gemeint sind natürlich die Beitragsdetails: Erstellt am, Autor, Seitanaufrufe, Änderungsdatum, Kategorie...
Steht halt alles untereinander und zieht die Seite in die länge.
Ich zeige normalerweise nur einen kleinen Teil der Beitragsdetails an. Manchmal ist weniger mehr ...
Eine index.php einfach so zu löschen, ist sicher keine gute Idee. Die Fehlermeldung kommt wahrscheinlich daher, dass in der ursprüngliche Installation https eingeschaltet war und das geht lokal natürlich nicht
drmenzelit Diese Aussage stimmt meistens, aber nicht absolut. Ich nutze als lokale Test-Umgebung seit einiger Zeit Laragon. Dort kann man auch lokal https nutzen; funktioniert manchmal etwas eigenwillig, geht aber prinzipiell.
Hast Du bei Kickstart die HTTPS-Verbindung abgeschaltet?
Wenn Deine Angaben im Kopf stimmen, bist Du ziemlich weit zurück mit Updates. Aktuell sind 4.4.8 und 5.1.4.
Es wäre nett, wenn Android und Mac-Nutzer diesen Link öffnen und bestätigen. Sie sollten folgendes Schriftbild sehen
Mit Android getestet und funktioniert.
Nichts überprüfen oder ändern, das ist Sache des Templateherstellers
Hoffentlich weiß das der Template-Ersteller auch ....
