Ich sehe nur Wanings und Deprecated-Meldungen, keine Fatal Errors. Das ist ganz "normal", wenn Du die Fehleranzeige entsprechend hoch einstellst (Maximum oder Entwickler). Das sind also in erster Linie nur Hinweise auf zukünftige Inkompatibilitäten.
Beiträge von flotte
-
-
Vermutlich ist die tmp-Partition auf dem Server voll oder die Rechte sind vermurkst. Sollte das der Fall sein, wäre dies ein Fall für den Hoster. Ein reboot würde helfen oder aber die manuelle Bereinigung des /tmp-Ordners.
-
"1709 Index column size too large" deuted auf Limitierungen des MySQL-Servers hin. Der Server muss large indexes unterstützen, wenn ein entsprechender Dump eingeladen werden soll. Das kannst Du nicht auf User-Ebene einstellebn, sondern das ist Providersache.
Bei MariaDB geht es beispielweise so in der Konfigdatei von MySQL:
[mysqld]
innodb_large_prefix=true
innodb_file_format=barracuda
innodb_file_per_table=true
Dann MySQL-Server restarten...
Diese Problematik ist bei einigen anderen Scripten wie z.B. Contao ein Dauerthema, aber bei Joomla ist mir das noch nicht über den Weg gelaufen.
-
Hier die passende Anleitung
https://www.fc-hosting.de/joomla/joomla-spamschutz.php -
Danke für die Hinweise!
Mein Provider (Strato) bietet leider keinen OPCache
ernsthaft?
-
Beachte die Informationen vom Hoster. Dort sollte erklärt sein, welche Bedeutung die vorhandene Ordnerstrukur hat und wie und wo man eine Homepage einrichten kann.
Welchen FTP-Client Du benutzt spielt keine Rolle. Sofern die FTP-Zugangsdaten korrekt eingegeben wurden, sollte jeder FTP-Client Zugriff bekommen.
-
Bei Facebook und Google wundert mich gar nichts mehr ehrlich gesagt. Krebsgeschwüre des Netzes und alle machen mit (mich eingeschlossen) - es geht ja gar nicht anders.
-
Extrem sind seit geraumer Zeit auch diese Masche von Erpresser-Emails:
-
Ich hatte vor einiger Zeit mit einem Google-Berater gesprochen, wobei kurz das Thema auf dieses Captcha kam. Er sagte das KI zum Einsatz kommt. Ein Bot verhält sich anders als ein Mensch. Wie umfangreich Surfprofile sind, die dann da ausgewertet werden, ob also nur die eigene Domain/Website betroffen ist oder auch andere Daten zusammengeführt werden, kann ich nicht sagen. Ich finde allerdings beide Varianten erschreckend und habe das unsichtbare Captcha für meine Seiten gar nicht erst in Betracht gezogen.
-
Ich habe mich mit dem Thema noch gar nicht groß beschäftigt. Ist es nicht so das Google das Surfverhalten auf der Seite analysiert, um dies als Entscheidungsgrundlage für eine Bot-Erkennung zu nutzen? Wenn ja kann ich mir gut vorstellen, das dies datenschutzrechlich nicht unbedenklich ist.
-
besser spät als nie
-
Redaktionelle Arbeiten, wie Content-Pflge und dergleichen kann man problemlos online machen. Das ist "ungefährlich" und vorab in der Vorschau des Editor ja auch sichtbar.
Programmierungen, Installationen oder andere komplizierte Dinge würde ich bei einer sehr gut besuchten Seite immer in einer parallelen Entwicklungsumgebung machen. Lokal oder in einer geschützten Subdomain auf dem Server - je nachdem was einfacher ist. Nach dem Test kann man dann die Dateien kopieren oder die Scripte installieren - jenachdem um was es ging.
Ist die Seite nicht so supertoll besucht, dann kannst Du sie auch mal für kurze Zeit in den Offline-Modus schalten. Dann siehst Du selbst alles, andere aber nix.
-
Öffne mit einen Editor deiner Wahl die configuration.php und suche nach...
Nicht ganz, benutze kein Notpad!!
-
leider finde ich den alten Thread nicht mehr wo das angesprochen wurde. Ich glaube das kam mit dem Update auf Joomla 3.9.1. und ich meine Erinnerung zu haben, das ein JavaScript Problem vorliegt.
-
Hier liegt also ein mit PHP 7.2 inkompatibles Script vor. Die Funktion mcrypt_get_iv_size() ist veraltet und wird nicht mehr unterstützt ab PHP 7.1
http://php.net/manual/de/function.mcrypt-get-iv-size.php
Mit PHP 7.0 wird es vermutlich funktionieren.
Bzw. aktualisiere Laravel
-
Fall ein Artikel ausgewählt wurde, sich aber dennoch nichts tut, wenn man auf den Link klickt, ist ein anderen Problem die Ursache. Ich kenne das aus mehreren anderen Installationen und hatte das mal im Forum gepostet, aber bislang keine Zeit gehabt das weiter zu vertiefen.
-
Zu wenig Infos um konkret helfen zu können.
Schalte zunächst das Error-Reporting auf "maximum". Mit etwas Glück bekommst Du dann die Ursache zu sehen, sofern es sich um einen Scriptabbruch durch PHP handelt. So ein "Fatal Error" wird dann im Browser angezeigt.
-
-
Wenn ich das mit meinem schlechten English richtig gelesen/verstanden habe, hat ein User ein Problem gemeldet, der lokal mit root-Rechten arbeitet und das Anlegen der Datenbank dem Install-Script überlässt. Draufhin wurde kurzerhand die Restriktion eingeführt das der Datenbankname nicht mit einer Zahl anfangen darf, ohne sich Gedanken darüber zu machen, was das in einer normalen Hostingumgebung plötzlich für Quereffkte haben kann. Dort arbeitet man nicht mit root Rechten und richtet die Datenbank vorab mit dem Mitteln das Hosters ein. Das Erstellen der Datenbank ist -und sollte auf gar keinen Fall- die Aufgabe des Installers sein.
Das die Supporter hier das nicht ändern können ist mir klar, aber gesagt werden muss es trotzdem. Habe ja Kontakt aufgenommen.
-
Ja den issue-Thread 23041 habe ich schon gesehen.
Ich bin ehrlich gesagt ziemlich genervt über diese Restriktion, wenn sie denn bleiben sollte. Wir sind ganz sicher nicht die einzigsten Hoster die ein solches Namenschema fahren....
ZitatIf we could identify the
automatic identifier quotation failing
bugs maybe we could take a look at those instead of just saying "Hey Liquid Web, and 1000s of other webhosts - although your table names meet the mysql standards for identifiers, change your ways, or else Joomla cannot be used on your webhost"Manche Entwickler sehen einfach nicht die Nachwirkungen ihres Handelns. Bei Contao4 sind es beispielsweise vollkommen unflexible Vorgaben an die Namensgebung des Webrootverzeichnisses, was für ganz viele Hoster ein KO-Kriterium darstellt und der Sicherheit dienen sollte (aber man auch kompatibler lösen könnte) ... und Joomla bringt plötzlich diese Vorgabe.
Wie würde es sich denn bei Updates bestehender Joomla verhalten? Laufen die dann alle nicht mehr oder betrifft es nur Neuinstallationen?
Wie es auch immer sein wird, wir werden das serverseitig alles nacharbeiten damit nicht plötzlich tausende Kunden Alarm schlagen, aber Joomla wird das nicht gut tun. Wir merken schon seit einiger Zeit, das es mit Joomla bergab geht und solche unnötigen Rerstriktionen werden das weiter unterstützen. Wir merken das daran das immer mehr Joomla-Webmaster mittlerweile auf WordPress umschwenken, weil es einfach leichter zu bedienen ist. Uns ist es letztlich egal, ob wir Joomla oder WordPress hosten, aber als treuer Joomla-Anhänger sehe ich das mit einer Träne im Auge...