Beiträge von reni

    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?

    Code
    1050 - Es ist ein Fehler aufgetreten
    
    
    Table 'qmupy_postinstall_messages' already exists SQL=CREATE TABLE `qmupy_postinstall_messages` ( `postinstall_message_id` bigint(20) unsigned NOT NULL AUTO_INCREMENT, `extension_id` bigint(20) NOT NULL DEFAULT '700' COMMENT 'FK to #__extensions', `title_key` varchar(255) NOT NULL DEFAULT '' COMMENT 'Lang key for the title', `description_key` varchar(255) NOT NULL DEFAULT '' COMMENT 'Lang key for description', `action_key` varchar(255) NOT NULL DEFAULT '', `language_extension` varchar(255) NOT NULL DEFAULT 'com_postinstall' COMMENT 'Extension holding lang keys', `language_client_id` tinyint(3) NOT NULL DEFAULT '1', `type` varchar(10) NOT NULL DEFAULT 'link' COMMENT 'Message type - message, link, action', `action_file` varchar(255) DEFAULT '' COMMENT 'RAD URI to the PHP file containing action method', `action` varchar(255) DEFAULT '' COMMENT 'Action method name or URL', `condition_file` varchar(255) DEFAULT NULL COMMENT 'RAD URI to file holding display condition method', `condition_method` varchar(255) DEFAULT NULL COMMENT 'Display condition method, must return boolean', `version_introduced` varchar(50) NOT NULL DEFAULT '3.2.0' COMMENT 'Version when this message was introduced', `enabled` tinyint(3) NOT NULL DEFAULT '1', PRIMARY KEY (`postinstall_message_id`) ) DEFAULT CHARSET=utf8;


    Diesen Fehler bekomme ich bei o.g. Update.
    Kann mir jemand einen Tipp geben wo das Problem liegt bzw. ob noch etwas in diesem Zustand zu retten ist?
    Im Kontrollzentrum bin ich noch, aber abmelden geht nicht und auch sonst leider nicht viel :(
    Backup einspielen ist kein Problem, nur wenn ich nicht weiß wo mein Fehler ist ... weiß ich dann auch nicht weiter :(
    Vielen Dank vorab.

    Stand bei mir ist, dass der Hoster nun alle Rechte "verstellt" hat. Auffälligkeiten gibts momentan noch nicht deswegen.
    Aber nach Anpassung der Pfade steht nun auch mein /log auf "beschreibbar". Jetzt könnte ich einen nächsten Update-Versuch wagen.
    Mal schaun ... erst muss es ein wenig kühler werden ;)

    Ich mein ja schon, dass das Problem die Pfadangabe ist.
    Es wird auf dem Host-OS sicherlich ein /tmp und auch ein /log geben. Nur kann ich eben in genau diess log nicht schreiben und das sagt mir auch Joomla.
    Mit dem richtigen Pfad, sollte es dann vermutlich gehen.


    Woher der Hoster (HaBo Webservice) sein Wissen über die Joomla-Rechte hat, kann ich leider nicht sagen. Im Netz findet man ja nur die auch hier genannten.
    Die Systemionformationen reiche ich nach.


    EDIT:
    Systeminformationen

    PHP erstellt für Linux andrina.ispgateway.de 2.6.32.53-grsec-pvops-xen-x64 #5 SMP Fri Jun 13 13:46:07 CEST 2014 x86_64
    Datenbankversion 5.6.19-67.0-log
    Datenbankzeichensatz utf8_general_ci
    PHP-Version 5.3.28
    Webserver Apache/2.4.10 PHP-Interface für den Webserver cgi-fcgi
    Joomla!-Version Joomla! 2.5.28 Stable [ Ember ] 10-December-2014 15:00 GMT
    Joomla!-Plattform-Version Joomla Platform 11.4.0 Stable [ Brian Kernighan ] 03-Jan-2012 00:00 GMT
    Browsererkennung Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Firefox/38.0


    Genauso kenne ich es auch ... aber er stellt, wie ich eben gerade sah, nun alle Rechte um :(
    Bin ja mal gespannt, was dabei rauskommt... :-/

    Die Pfade habe ich mit der pfad.php inzwischen ausgelesen. Das hat super geklappt.
    Nur hab ich grad noch ein anderes Problem.


    Weiß denn jemand wie die Rechte bei einer Ur-Joomla-Installation sind?
    Mein Hoster will mir gerade einreden ich hätte alle Rechte geändert.
    Joomla Standard wäre alle Verzeichnisse 710 und Dateien 740. ;(
    Ich bin mir aber völlig sicher, daran nichts gedreht zu haben
    (und auch bei mir lokal stehen die Rechte auf 755 bzw. 644).


    'cannot open file for writing log'


    Könnte das aber auch an falschen Rechten des log-Verzeichnisses liegen?
    Ich habe zur Zeit das gleiche Problem beim Update von 2.5.28 auf inzwischen 3.4.3
    Das Update bricht mit o.g. Fehler ab.
    Ich habe gesehen, dass bei mir in Site - Systeminformationen - Verzeichnisrechte das log-Verzeichnis auf Schreibgeschützt steht (Rechte 755!) und vermute nun da mein Problem.
    Aber auch der Pfad in der configuration.php ist nicht richtig laut pfad.php. Es steht nur /log bzw. /tmp drin.
    Weißt du zufällig, wie deine Rechte des log-Verzeichnisses waren bzw. ob bei dir "schreibgeschützt" steht?

    Hallo Leute,


    meine erste Seite, die ich auf Joomla3.x umgestellt habe funktioniert soweit völlig problemlos.
    Nur eine Kleinigkeit, die mich stört.
    Die Breadcrumbs werden, wie der Betreff schon sagt, nicht in einer Zeile dargestellt.
    Benutzt wird weiter das Template Beez20 (dies würde ich auch gern so belassen).
    Hier der Link zur Seite: http://www.schriftsatzschmiede.de/


    Im Modul ist als Modul-Tag "nav" eingestellt, nur wenn ich mir das mit Firebug ansehe, dann sehe ich "div" ?(