Beiträge von Iarsin

Ist das aus urheberrechtlichen Gründen überhaupt gestattet die webfonts selbst zu hosten, aka zu kopieren?

Ich hatte die alte Zeile drin gelassen und falsch auskommentiert (für php, statt html, da ja mehrfach <php ?> in der Datei vorkommt). Nach dem entfernen der alten Zeile (die ich auskommentieren wollte) ging's dann. ka, ob das hier auch der Fall war, oder das Problem anders gelagert ist. Hatte den patch also manuell in den code eingearbeitet.

Ich hatte das Problem, dass ich die alte Zeile auskommentierte, und das immer noch störte. Nach der Entfernung der auskommentierten Zeile funktionierte der patch aus dem github, den ich manuell einfügte.

Ja, aber das wäre auch eine Möglichkeit. Eine Antwort beschließt die Möglichkeit und alle Änderungen bleiben als Versionen nachvollziehbar. Allerdings ist mir auch aufgefallen, dass der Versionsvergleich nicht ganz funktioniert. Einmal hatte ich nur zwei Kommata gesetzt und der ganze Vergleichstext war rot hinterlegt, man musste den Unterschied also selbst herausfinden.

Also ich brauche mindestens 10 Minuten oder gar eine Viertelstunde, so langsam wie ich offenbar bin, und bei der Fehleranfälligkeit im Tippen.

Ich kenne aus einigen Foren, dass eine Antwort einen Deckel drauf setzt. Das macht ja auch Sinn, so kann man eine Diskussion nicht verfälschen. Man muss es dann in der Diskussion zurücknehmen. Solange keine Antwort erfolgt kann ich dem zuvorkommen und meinen Unsinn zurücknehmen sobald er mir auffällt.

Danke für die Zusammenfassung einiger Posts zu einem.

Ich muss manchmal in die Quellansicht, weil ein Textblock den ich markiere, und dann als Quote oder Code auszeichnen will, nicht sauber als Block erfasst wird. Eigentlich sollte das auch schon anderen aufgefallen sein, mir jedenfalls passiert das häufig. Ich korrigiere das dann in der Quellcode-Ansicht.

Naja, da sieht man mal wie die Zeit vergeht. Ich denke das sind dann bei mir gefühlte 30 Sekunden bis eine Minute. Tut mir leid, dass der Thread so zu einem Dickicht verkommen ist. Besser fände ich, wenn die Zeit höher angelegt wäre, aber dass man, sobald jemand anderes antwortet nicht mehr bearbeiten kann, um den Beitrag nicht nachträglich zu verfälschen, falls es Streitpunkte gibt.

Außerdem habe ich des öfteren Probleme mit Quotes oder Codeblöcken.

Hallo, mir ist die verbleibende Bearbeitungszeit für Ergänzungen und Rechtschreibkorrekturen zu kurz. Vielleicht habe ich mir auch eine unschöne Art Beiträge zu verfassen angewöhnt, indem ich diese immer wieder bearbeite, korrigiere, verbessere und erweitere. Nur ist durch die kurze Zeit (30 Sekunden, 1Minute?) dieser Thread z.B. etwas ausgeufert: Update-Probleme und JCS funktioniert nicht nach Übertragung auf den Server

Die .htaccess hatte nichts damit zu tun, aber ich habe sie inzwischen um ein paar Zeilen aus der 3.8.6 htaccess erweitert, die die Verzeichnisauflistung („Directory Listing“) unterbinden.

So, das wars. Herzlichen Dank noch mal an j!-n für den entscheidenden Hinweis, dass es sich um joomfish handelte!

Das hatte ich zwar komplett entfernt, aber offenbar war dabei während der Upgrade-Prozedur vor etwa zwei Monaten einiges schief gelaufen. Der Datenbankeintrag dazu verhinderte jetzt jedenfalls den erneuten export/import, also die erfolgreiche Migration auf den remote/live(nennt man das unter Joomla! so?)- Server.

In der zu importierenden SQL-Datei der lokalen Installation kommentierte ich Zeile 36293 mit -- aus, und schon klappte der Import probemlos.

-- Zeile 36285
--
-- Struktur des Views `rtci1_jf_languages`
--
DROP TABLE IF EXISTS `rtci1_jf_languages`;
-- joomfish-Reste
-- CREATE ALGORITHM=UNDEFINED DEFINER=`dbo673384265`@`db673384265.db.1and1.com` SQL SECURITY DEFINER VIEW `rtci1_jf_languages`  AS  select `l`.`lang_id` AS `lang_id`,`l`.`lang_code` AS `lang_code`,`l`.`title` AS `title`,`l`.`title_native` AS `title_native`,`l`.`sef` AS `sef`,`l`.`description` AS `description`,`l`.`published` AS `published`,`l`.`image` AS `image`,`lext`.`image_ext` AS `image_ext`,`lext`.`fallback_code` AS `fallback_code`,`lext`.`params` AS `params`,`lext`.`ordering` AS `ordering` from (`rtci1_languages` `l` left join `rtci1_jf_languages_ext` `lext` on((`l`.`lang_id` = `lext`.`lang_id`))) order by `lext`.`ordering` ;
-- Zeile 36293

Joomla! Checksum-Scanner funktioniert wieder, die Datenbank war direkt aktuell, aber ich habe sie dennoch nochmals repariert. Alles scheint nun normal, auch die neuen redirects (Umleitungen) bekommen die nächst höhere ID 21700 statt wie zuvor die falsche ID 0, die auf die korrupte Datenbank verwies.

Kerndateien habe ich erneut inststalliert, dabei wurde das Akeeba Backup getriggert , das aber meckerte.

Zitat

Start a new backup

The automatic backup can not be started because your output directory is not writable. Please follow the instructions below to fix this issue.

In order to fix this issue, please go to the Configuration Page and set the Output Directory to [DEFAULT_OUTPUT] (all caps, including the brackets). If this still doesn't work, please take a look at our troubleshooting instructions

Das lagt daran, dass als output-directory der lokalen Installation "C:\xampp\htdocs\htdocs/administrator/components/com_akeeba/backup" angegeben ist.
Kann man hier auch einen anderen externen Host angeben? Das wäre ja sinnvoll? Ich habe nun das Server-Verzeichnis /administrator/components/com_akeeba/backup angegeben. Das erscheint mir suboptional, aus Sicherheitsgründen wegen Datenverlust und auch fremder Begehrlichkeiten durch Angriffe.

Nun habe ich noch Probleme mit dieser PHP-Warnung (Erweiterungen > Verwalten > Warnungen), oder ist das gar kein Problem?

Zitat

Das Verzeichnis für temporäre Dateien in PHP ist nicht gesetzt

Dieses Verzeichnis wird zum temporären Speichern von hochgeladenen Dateien benutzt, bevor Joomla! auf die Datei zugreifen kann. Obwohl das temporäre Verzeichnis nicht gesetzt wurde, sollte es in der Regel keine Probleme geben. Wenn es Probleme gibt, dass XML-Dateien (Manifest-Dateien) nicht erkannt oder hochgeladene Dateien nicht gefunden werden, sollte der Wert von „upload_tmp_dir“ in der „php.ini“-Datei angepasst werden.

Außerdem wüsste ich gern noch wie ich inkompatible Erweiterungen erkenne, und was es mit den oft niedrigen Versionen und den alten Datumsangaben der Erweiterungen auf sich hat.

Wie kann ich erkennen, welche Erweiterung nicht kompatibel ist, und sich querlegt. Übrigens kann ich joomfish nicht finden, daher werde ich mal versuchen die ganze Zeile aus der sql-Datei zu löschen und nochmals zu importieren. Merkwürdig auch, dass das lokal mit xampp 5.6.33 und 10.1.30-MariaDB funktioniert.

Lokal

Zitat

Datenbank-Server

• Server: 127.0.0.1 via TCP/IP
• Server-Typ: MariaDB
• Server-Version: 10.1.30-MariaDB - mariadb.org binary distribution
• Protokoll-Version: 10
• Benutzer: root@localhost
• Server-Zeichensatz: UTF-8 Unicode (utf8)

Webserver

• Apache/2.4.29 (Win32) OpenSSL/1.0.2n PHP/5.6.33
• Datenbank-Client Version: libmysql - mysqlnd 5.0.11-dev - 20120503 - $Id: 76b08b24596e12d4553bd41fc93cccd5bac2fe7a $
• PHP-Erweiterung: mysqli, curl, mbstring
• PHP-Version: 5.5.33

phpMyAdmin

• Versionsinformationen: 4.7.4, aktuelle stabile Version: 4.7.9

Server (remote, live)

Systeminformationen

Module, ID >10000
FireShot Capture 006 - Erweiterungen_ V_ - http___www.my-joomla-site.local_administrator_index.php.pdf

Danke, ich schaue mir das Morgen weiter an. Das Frontend funktioniert nach wie vor. Anfang Februar hatte ich jedenfalls nach jedem Upgrade-Schritt alle Komponenten jeweils aktualisiert, die Datenbank repariert und Akeeba-Backups erstellt. Gute Nacht!

Der Link in #9 ist falsch, den hatte ich verwechselt mit dem zur php tmp Warnung. (leider lässt sich der Beitrag nun nicht mehr bearbeiten). https://stackoverflow.com/ques…-super-privileges-for-thi

Hallo j!-n, vielen Dank für Deine Unterstützung! Danke für den Hinweis, dann sind das Reste von Joomfish, das ich vor dem upgrade von 2.5.18 über 3.5.1 auf 3.8.4 .. 3.8.6 nicht vollständig entfernt habe. Keine Ahnung, weshalb das lokal so läuft. Ich versuche es mal das lokal zu säubern und dann nochmal zu ex-/importieren. Wenn das nicht geht versuche ich mal Akeeba für die Migration auf den remote Server. Das hatte vorher auch schon geklappt.

Mich wunderten schon die 4 Datenbankfehler. rtci1_jf_languages_ext hatte ich nicht mit joomfish assoziiert.

Der Index „'idx_old_url'“ ist nicht in Tabelle „'rtci1_redirect_links'“ enthalten. (Von Datei: „3.5.0-2016-03-01.sql“.)
Der Index „'idx_alias'“ ist nicht in Tabelle „'rtci1_content'“ enthalten. (Von Datei: „3.8.2-2017-10-14.sql“.)
Der Index „'idx_client_id_parent_id_alias_language'“ ist nicht in Tabelle „'rtci1_menu'“ enthalten. (Von Datei: „2.5.0-2011-12-24.sql“.)
Der Index „'idx_access'“ ist nicht in Tabelle „'rtci1_languages'“ enthalten. (Von Datei: „2.5.4-2012-03-19.sql“.)

Die beiden letzten Zeilen (menu, languages) haben aber trotzdem nichts mit joomfish zu tun, sind aber von 2.5.x, oder bedeuten die Versionshinweise nur, mit welcher Version das in Joomla! eingeführt wurde?

(Sorry, leider konnte ich das nicht mehr in den letzten Post eintragen).

SHOW GRANTS FOR 'dbo673384265'@'%'

Grants for dbo673384265@%
GRANT USAGE ON *.* TO 'dbo673384265'@'%' IDENTIFIED BY PASSWORD <secret>
GRANT ALL PRIVILEGES ON `db673384265`.* TO 'dbo673384265'@'%'

Die zweite Zeile bedeutet doch, dass alle Rechte vorhanden sind, oder?

Laut https://stackoverflow.com/ques…temp-files-go-experiments hätte DEFINER=`dbo673384265`@`localhost` eigentlich gegen den Fehler #1227 helfen müssen.

Im 1&1 Controlcenter wird dbo673384265 auch als Datenbankbenutzer angegeben. In der configuration.php auch.

Oder spielt dieser Kommentar, Zeile 21-22, in der sql Datei die importiert werden soll auch eine Rolle?

--
-- Datenbank: `db517208114`
--

Ich habe nun die Datenbank nochmal importiert. Das schlug aber trotz Ersetzung des Datenbanknamens wieder fehl.

#1227 - Access denied; you need (at least one of) the SUPER privilege(s) for this operation

Komplett:

SQL-Befehl: Dokumentation

CREATE ALGORITHM=UNDEFINED DEFINER=`dbo673384265`@`localhost` SQL SECURITY DEFINER VIEW `rtci1_jf_languages`  AS  select `l`.`lang_id` AS `lang_id`,`l`.`lang_code` AS `lang_code`,`l`.`title` AS `title`,`l`.`title_native` AS `title_native`,`l`.`sef` AS `sef`,`l`.`description` AS `description`,`l`.`published` AS `published`,`l`.`image` AS `image`,`lext`.`image_ext` AS `image_ext`,`lext`.`fallback_code` AS `fallback_code`,`lext`.`params` AS `params`,`lext`.`ordering` AS `ordering` from (`rtci1_languages` `l` left join `rtci1_jf_languages_ext` `lext` on((`l`.`lang_id` = `lext`.`lang_id`))) order by `lext`.`ordering` ;

MySQL meldet: Dokumentation
#1227 - Access denied; you need (at least one of) the SUPER privilege(s) for this operation

Zitat

Warnung

Achtung: Die Datenbank ist nicht auf dem neuesten Stand!

Andere Informationen

4 Datenbankprobleme gefunden!

Nach der Datenbankreparatur wieder:

Zitat

Version des Datenbankschemas (in #__schemas): 3.8.6-2018-02-14

Aktualisierungsversion (in #__extensions): 3.8.6

Datenbanktreiber: mysqli

146 Datenbankänderungen wurden überprüft.

186 Datenbankänderungen hatten keinen Einfluss auf die Struktur der Datenbanktabellen und wurden deshalb übersprungen.

Nein, das lag am redirect auf https:// , die Seite wird hier vom xampp lokal wohl nicht über :443 ausgeliefert. Da müsste ich nochmal schauen, was da in der Apache-Konfíguration des xampp falsch eingestellt ist.
Übrigens meinte ich die Anweisungen deGobbis, in Kommentar #20, hatte ihn mit kitepascal verwechselt.

Ich habe nun mal die remote .htaccess lokal „installiert“. Nun bekomme ich dort ein 404. Vielleicht liegt es also wirklich an der .htaccess . Ich werde dem mal weiter nachgehen. Vielleicht probiere ich auch mal zu Testzwecken eine Joomla!-Standardinstallation Remote, dazu muss ich aber eine andere Datenbank löschen. Jetzt gehe ich erst mal raus.

Ich habe Akeeba für den Transfer ja gar nicht verwendet, nur zur Sicherheit Backups erstellt.

Ich habe nun lokal nochmal getestet: Dort gibt es keine redirect links mit ID 0 und die Sprachdateien ließen sich problemlos upgraden.

JCS funktioniert dort auch.

.htaccess ist unterschiedlich

Lokal

$ egrep -v '^[[:space:]]*#|^ *$' "C:\xampp\htdocs\htdocs\.htaccess"

<IfModule autoindex>
IndexIgnore *
</IfModule>
Options +FollowSymlinks
Options -Indexes
RewriteEngine On
RewriteCond %{QUERY_STRING} base64_encode[^(]*\([^)]*\) [OR]
RewriteCond %{QUERY_STRING} (<|%3C)([^s]*s)+cript.*(>|%3E) [NC,OR]
RewriteCond %{QUERY_STRING} GLOBALS(=|\[|\%[0-9A-Z]{0,2}) [OR]
RewriteCond %{QUERY_STRING} _REQUEST(=|\[|\%[0-9A-Z]{0,2})
RewriteRule .* index.php [F]
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteCond %{REQUEST_URI} !^/index\.php
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule .* index.php [L]

Remote

$ egrep -v '^[[:space:]]*#|^ *$' "C:\Users\Iarsin\AppData\Local\Temp\fz3temp-2\.htaccess"

Options +FollowSymLinks
RewriteEngine On
RewriteCond %{QUERY_STRING} base64_encode[^(]*\([^)]*\) [OR]
RewriteCond %{QUERY_STRING} (<|%3C)([^s]*s)+cript.*(>|%3E) [NC,OR]
RewriteCond %{QUERY_STRING} GLOBALS(=|\[|\%[0-9A-Z]{0,2}) [OR]
RewriteCond %{QUERY_STRING} _REQUEST(=|\[|\%[0-9A-Z]{0,2})
RewriteRule .* index.php [F]
RewriteCond %{HTTP_USER_AGENT} .*{.* [NC]
RewriteRule .* - [F,L]
RewriteCond %{HTTP_USER_AGENT} O:[0-9]+: [NC]
RewriteRule .* - [F]
RewriteCond %{THE_REQUEST} !^POST
RewriteCond %{THE_REQUEST} ^[A-Z]{3,9}\ /index\.php\ HTTP/
RewriteCond %{SERVER_PORT}>s ^(443>(s)|[0-9]+>s)$
RewriteRule ^index\.php$ http%2://www%.{HTTP_HOST}/$1 [R=301,L]
RewriteCond %{SERVER_PORT} !^443$
RewriteRule (.*) https://%{HTTP_HOST}/$1 [R=301,L]
RewriteCond %{HTTP_HOST} !^www\. [NC]
RewriteRule ^(.*)$ http://www.%{HTTP_HOST}/$1 [R=301,L]
RewriteCond %{HTTP:X-FORWARDED-FOR} ^66\.249\.(6[4-9]|[78][0-9]|9[0-5])\.
RewriteCond %{HTTP_USER_AGENT} Googlebot
RewriteCond %{REQUEST_URI} (/index\.php/de/|/)[a-z0-9+%\/]{6,21}[_/+]{0,1}[0-9a-z+%\=]{4,9}[-/+]{0,1}[0-9a-z+%.]{0,14}[/]{0,1}$
RewriteRule ^ - [R=410,G]
RewriteBase /
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteCond %{REQUEST_URI} !^/index\.php
RewriteCond %{REQUEST_URI} /component/|(/[^.]*|\.(php|html?|feed|pdf|vcf|raw))$ [NC]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule .* index.php [L]

Hallo Axel,

vielen Dank für Deine Antwort.

Ich habe alle Dateien per FTP hochgeladen und per phpmyadmin die Datenbank exportiert, remote eine neue angelegt und per phpmyadmin wieder importiert. In der configuration.php habe ich log und tmp entsprechend der Serverangaben und die mysqli Zugänge, wie db, dbo und Passwörter angepasst.

Die Datenbank unter Erweiterungen > Verwalten > Datenbank habe ich mehrmals repariert, auch kitepascals Prozedur auf Seite 1 unten im verlinkten 3seitigen Thread durchgeführt (core Dateien ersetzt, db-Reparatur etc.).

Mit akeeba hatte ich vorher und nachher noch Backups gemacht. configuration.php hat 444, Dateien 604 und Verzeichnisse 705. Das Frontend funktioniert. Das Backend ja auch so weit, bis auf die genannten Einschränkungen, die mir bisher auffielen.

Was ist mit meiner Vermutung, Vorkommnisse des alten Datenbanknamen in der zu importierenden sql-Datei per search-and-replace mit dem neuen Namen auszutauschen und dann nochmals den import (nach löschen der vermutlich korrupten db auf dem remote server) zu versuchen?

Ich sehe gerade, seit dem Import angelegte redirect links haben die ID 0. Das ist doch auch ein Hinweis auf eine beschädigte Datenbank, oder?