Beiträge von reni

    Guten Abend,


    seit einiger Zeit, ich glaube ab dem Akeeba Backup-Update auf 5.2.2, ist etwas seltsam.
    Joomla zeigt mir das Update an (Erweiterungen: Aktualisieren) und ich führe es aus.
    Danach bekomme ich die Meldung: Warnung: Copy file failed und Nachricht: Fehler beim Aktualisieren von Paket und das Update wird mir immer noch angezeigt.
    Gehe ich aber zur Komponente Akeeba Backup direkt ist alles ok und auf dem neuesten Stand: Akeeba Backup Core 5.2.3 (2016-09-16) :rolleyes:


    Warum zeigt mir Joomla dann noch immer das Update an bzw. sagt mir, dass Akeeba Backup auf Stand von 5.1.4 wäre?
    Es irritiert mich :/


    Gruß reni

    Was genau soll denn zu sehen sein im Beitrag mit dem Weiterlesen-Link?
    Dieser kommt doch nur zum Tragen bei einem Menüpunkt mit Menütyp "Blog".
    Wird der Beitrag selbst aufgerufen, siehst du den Weiterlesen-Link nicht.


    Evt. möchtest du aber eher etwas wie einen "Seitenwechsel" - das gibts auch.

    Danke für die Idee und ich werde es an den Autor weiterleiten, um zukünftig das Problem zu vermeiden.
    Dass das Ganze letztendlich an der Formatierung des Beitrages hängt, hab ich mir schon gedacht.


    Es muss doch aber einen Grund geben, dass FF bzw. IE die Seite richtig darstellt und alternative Browser nicht.
    Oder könnte es an Browser-Einstellungen liegen?

    Hallo,


    mich beschäftigt zur Zeit folgendes Problem.


    Es gibt auf unserer Seite Beiträge, die im Firefox od. Internet Explorer korrekt dargestellt werden,
    im Google Chrome od. in Browsern auf Android nicht.


    Es geht dabei um Beiträge im Menü „Portraits“ zum Beispiel diesen:
    http://www.deutsche-mugge.de/portraits/1215-city.html


    Geht man hier zu „Alben“ sieht im Firefox alles so aus, wie es soll.
    Die selbe Stelle in Google Chrome od. auch alternativen Browser im Linux (reqonk od. Konqueror) sieht ganz anders aus.
    Je mehr Text neben dem CD-Cover steht, um so kleiner wird das dazugehörige Bild.


    Ich kann es nicht bestätigen, aber mein Autor meinte, dass das vor dem Upgrade auf Joomla 3.4.x nicht so gewesen wäre.
    Die Beitrage sahen in allen Browsern gleich und richtig aus.


    Meine Frage, was kann ich tun, damit auch die anderen Browser diese Beiträge korrekt darstellen
    (möglichst ohne jeden Beitrag neu zu schreiben und/oder zu formatieren)?

    :S Sorry Sorry Sorry, das Problem saß vor dem Rechner.
    Man muss sich eben alle Zeilen in der entsprechenden Tabelle anschauen :S
    3 Zeilen in Tabelle #__extensions gelöscht und nun ist alles "sauber".


    Besten Dank! :thumbup:


    Vielen Dank für die Hilfe.
    Nun sieht es so aus:
    - Template-Ordner sind gelöscht
    - in der Tabelle #_extensions gibt es nur einen allgemeinen Eintrag "com_templates" => da nichts verändert
    - die Stiles konnte ich nicht im Backend löschen => in der DB gemacht und nun auch im Backend nicht mehr zu sehen
    - geblieben sind nun aber noch Einträge in "Erweiterungen - Templates" (siehe Anhang)
    - Und wie schon erwähnt in Erweiterungen - verwalten sind diese Templates nicht sichtbar, da hab ich sie deinstalliert.

    Erweiterungen- dann links auf Verwalten klicken.
    Unten links kannst du den Typ, in deinem Falle "Template" einstellen.
    Die zu löschenden markieren und oben dann auf Deinstallieren..


    Sorry, da hatte ich mich wohl nicht korrekt ausgedrückt, aber genau das habe ich getan (deinstalliert) und Ergebnis sieht man im Bild 1 ;)

    Hallo,


    nach dem erfolgreichen Joomla-Update auf 3.x wollte ich nun die "alten" Templates aus 2.5.x entfernen.
    Ich hab also in Erweiterungen - Verwalten die nicht benötigten Templates aus Bereich "Site" gelöscht und so schauts da jetzt aus (s. template1.jpg)


    Wunderbar eigentlich. Nur wenn ich in Erweiterungen - Templates - Stile schaue, ist das "wunderbar" verflogen ;(
    Da sieht man nämlich noch immer die eigentlich gelöschten Templates (template2.jpg)
    Auch im Verzeichnis "templates" sind alle Ordner noch vorhanden.


    Wie kann das sein und was kann ich tun?
    Danke vorab.

    2.) kannst du den Bilderordner unberührt auf dem Server lassen, kopierst den Rest und Datenbank auf lokal herunter. Machst Update und Akeeba-Backup, lebst damit, dass im Frontend die Bilder fehlen. Löscht auf dem Server die Ordner, außer nicht lokal kopierte Bilderordner. Machst Akeeba Kickstart, das bestehende Ordner und Dateien dabei nicht überschreibt, soweit sie im Archiv nicht enthalten sind.


    Das klingt für micht sehr gut.
    Bisher hatte ich immer Bedenken, dass mir der Kickstart die JoomGallery-Verzeichnisse, welche nicht im Akeeba-Archiv enthalten sind löscht.
    Vielen Dank!


    Hab mich da bisher hier im Thread zurückgehalten, aber jetzt halt doch die Empfehlung, den Hoster zu wechseln. Ich kenne auch so kleinere, die Kunden von mir "lieb gewonnen haben", die überall die Hand drauf halten, blockieren, unübliche Konfigurationen "aus Sicherheitsgründen" haben, bestimmte Dinge nicht installiert haben, die das Seitenbetreiberleben extrem erleichtern.
    Oder eben Kunden nicht selbst an die Datenbank lassen. Das ist mit Anleitung, z.B. von jemand hier im Forum, nicht so schwer eine Tabelle zu löschen.

    Oh oh, ehe ich einen phpMyAdmin-Zugang hatte ... aber den hab ich und ich kenn mich da auch bissel aus ;)



    Die Tabelle dient dem Speichern von Nachrichten, die nach Joomlaupdates, aber auch paar Erweiterungen, zur Anzeige kommen. Sie wurde in Joomla3 eingeführt und gehört zu Joomla, ohne weitere Probleme geht es nicht ohne. Aber, wenn sie eben ein zerschossenes Update blockiert, weil sie erneut angelegt werden soll und schon da ist, dann kann man sie problemlos löschen.

    da staune ich nun aber doch, dass es diese Tabelle nach dem Einspielen des Backups noch gibt :/ Diese sollte ich also unbedingt vor einem erneuten Versuch löschen.



    Wenn es lokal klappt und du nicht ganz so fit bist, dann verwende Akeeba-Backup zum sichern deines lokalen, geupdateten Joomlas. Mit dem Tool Akeeba Kickstart, kannst du das Joomla dann auf dem Server installieren. Bei deinem Hoster sehe ich allerdings irendwie schwarz. Du brauchst mindestens die Zugangsdaten für die Datenbank, die dann automatisch von Kickstart angelegt wird; und Akeeba Kickstart braucht volle Schreibrechte für den Webspace. Bei "normalen" Providern für die "normale" Webseite wird das durch CGI (fastcgi, fcgi) gewährleistet.

    Leider kann ich mir lokal nicht die ganze Joomla-Installation sichern. Wir haben so in etwa an die 20 - 30.000 Bilder drin und das bekomme ich schon kaum in akzeptabler Zeit zum Download, geschweige denn wieder zum Upload.
    Auch schon deshalb bin ich auf die Mithilfe des Hosters (leider) angewiesen.
    Liebend gern würde ich das alles selbstständig mit Akeeba machen, da ich das Tool echt super finde.

    Hm, irgendetwas ist seltsam.
    Jetzt nach dem das Backup wieder eingespielt ist, gibt es die Tabelle "qmupy_postinstall_messages" schon und ich geh davon aus, dass auch die DB zurückgespielt wurde (ich mach das nicht, kann das nicht selbst, macht nur der Hoster).
    Wie wichtig bzw. was hat es eigentlich mit dieser Tabelle auf sich?
    Bisher habe ich dazu gelesen, dass die angelegt wird bei einem Abbruch des Updates?


    Auf jeden Fall hab ich das Update vorerst verschoben und teste nun alles zum x.ten Mal lokal (da hatte ich bisher noch nicht einmal ein derartiges Problem).

    Wenn ich im andern Thread richtig verstanden habe, hast du bereits ein Backup angestoßen, dass wegen Dateirechten nicht abgeschlossen wurde.

    Die Backups liefen immer ohne Probleme wieder rein.
    Inzwischen wurde das Backup auch wieder eingespielt und ja, das Update lief diesmal schon ganz schön weit durch.
    Nun habe ich eine Vermutung zu diesem Fehler.
    Beim allerersten Update-Versuch war u.a. eine Fehlermeldung, dass die Tabelle qmupy_postinstall_messages nicht erstellt werden konnte.
    Ein Tipp aus dem Netz: Tabelle einfach selbst entsprechend anlegen.
    Das hatte ich getan und zumindest dieser Fehler war weg. Aber ansonsten schien damals aber nicht viel gelaufen zu sein und ich bin zurück.
    Jetzt hatte ich vor dem Update diese Tabelle manuell angelegt.
    Kann genau das diesmal mein Fehler gewesen sein?