Beiträge von Volker S

Nochmal Dankeschön Euch allen. Hat prima funktioniert.

Für alle Newcomer - bitte die Aktualisierung des Servers (meist so 5 Min) abwarten um den Effekt zu sehen.

Hi,

mit der Suche hier im Forum komme ich nicht klar. Suche ich nach lokale php.ini kommen über 50 Seiten, die nichts damit zu tun haben, weil der Interpreter den Punkt in php.ini als Leerzeichen interpretiert. Er findet jedenfalls massig Wörter mit "ini". Eine Suche nach "lokale php.ini" brachte das selbe unbefriedigende Ergebnis. Deshalb nun endlich meine Frage:

Da das Backend der Applikation "DokuWiki" keine einstellbare Uploadgröße kennt, müsste ich das über die php.ini einstellen.

Da das DokuWiki aber nur ein Teil eines Forum ist (bei dem man die Uploadgrenzen natürlich einstellen kann), bräuchte ich eine php.ini nur für das DokuWiki (ist ein Subdirektory vom Forum)

...geht das?

Jepp,

Danke Euch Beiden, nur der "-" war wohl das störende Element. Kann man das so stehen lassen, oder ist die Umleitung nach /dev/null für den Server besser?

Nein, der crontab wird nicht auf der Shell in die Datei eingetragen. Ich habe nur normales Webhosting, kann vielleicht per ssh mir die Datei anzeigen lassen und editieren. Aber was soll das bringen?

Ich benutze das WCP um den cronjob da einzutragen.

Hi,

ich betreibe ein sehr kleines Forum, welches Mailbenachrichtigung (neues Thema, Userantwort) so lange in einen Queue veschiebt, bis der nächste User das Forum ansteuert. Für ein sehr kleines Forum kommen dann auch sehr unterschiedliche Wartezeiten heraus, bis die User informiert werden.

Ursprünglich habe ich also gedacht, dieses Ansteuern des Forum alle halbe Stunde durch einen Cronjob erledigen zu lassen:

0,30 * * * * /usr/bin/wget -q -t1 -http://www.jollauser.de >/dev/null 2>&1 (so habe ich das eingestellt, und es wurde fehlerfrei abgearbeitet (laut erscheinendem Infofenster)

Doch es funktionierte nicht. Dann habe ich mal alles Unnötige weg gelassen und nur

/usr/bin/wget -http://www.jollauser.de oder auch

/usr/bin/wget http://www.jollauser.de

eingetragen. Dann schmeißt er mir ein: "Scheme missing" raus.

Den obigen langen Befehl, ohne >/dev/null 2>&1, da listet er mir nur alle Optionen von wget auf (als wenn man wget --help eingegeben hätte). Und da ich das ja ins Nirwana leite (wenn man ">/dev/null 2>&1" hinten dran setzt), funktioniert der Befehl zwar fehlerfrei, aber macht nicht das was ich will.

Also, kann doch eigentlich nicht so schwer sein, per cron eine Seite aufzurufen. Kann mir bitte diesbezüglich jemand unter die Arme greifen? Danke.

HI,

mich interessiert die alte php 5.6 - Version, die bei Euch in Zukunft noch Unterstützung findet. Ist das eine angepasste Version, die man noch nicht im CCP auswählen kann, oder ist die schon jetzt bei der Auswahl mit dabei? Augenblicklich gibt es ja 2 alte 5.6 - Versionen.

PS: Eine interaktive Google-Map-Karte habe ich mir vor langer Zeit aus verschiedenen Scripts selbst zusammengewurschtelt. Da müsste ich echt Zeit investieren. Wenn ich andere Seiten auf php 7.x hebe, die Google-Map aber noch auf 5.6 belassen möchte, greift dann eine .htaccess - Aufforderung?

-volker-

...und genau darauf bezieht sich ja meine Eingangsfrage. Also wann ist denn früher oder später?

Ich kann schon - ist halt zeitintensiv. Ich will also nicht, wenn ich nicht muss.

Hi,

da ich mir nicht sicher bin, ob zwangsumgestellt wird (und wenn, dann wann?) frage ich hier mal nach. Ich habe ein Webhostingpaket und benutze php 5.6.

Grüße
-volker-

H6G,

dein Vorschlag für eine kostengünstige Variante eine Inklusivdomain loszuwerden wäre also: Irgendwo ein sehr günstigen Konkurrenten zu wählen (hier war ja vor Kurzem auch ein Angebot mit 1,44@/Jahr für eine .de Domain) - die Inklusivdomain dort hinzuziehen - und dann sofort kündigen.:)

Aber es müssen doch auch Inklusivdomains jedes Jahr verlängert werden. Ich verstehen nicht, warum netcup an diesem Termin keine Kündigung der Inklusivdomain transparent anbieten kann. Ein close und eine Löschung wären mit einem einfachen Klick im ccp machbar. Aber naja - ist halt so.

Zitat von [netcup] Felix

das funktioniert nicht. Inklusivdomains sind an den Tarif gebunden. Wir bezahlen für de-Domains z.B. Registrierungsgebühren und haben Laufzeiten die eingehalten werden müssen. Aus dem Grund können einmal genutzte Plätze nicht neu belegt werden.

Aber wenn man ganz normal eine Domain von den Inklusivdomains kündigt, dann verschwindet diese doch nach der Laufzeit aus dem Paket (weil sie einfach nicht erneut registriert wird). Nur wenn man das ausserhalb der Laufzeit verlangen würde, wäre das eine Extraleistung die - wenn überhaupt - auf Kulanz durchgeführt wird. Habe ich doch so richtig verstanden, oder?

-volker-

frostschutz,

Du bist da 100% auf der richtigen Spur. Genau diesen Einwand habe ich auch schon im Netz gefunden (bei einem anderen ähnlichem Problemfall)

Zitat:

"Nach meiner Erfahrung sieht das so aus wenn Strings in einem

Multibyte-Zeichensatz (z.B. UTF-8) vorliegen und in einer DB-Spalte

abgelegt werden, die einen Singlebyte-Zeichensatz hat. Zwei oder drei

Bytes ergeben zusammengenommen eigentlich ein Sonderzeichen – der

Singlebyte-Zeichensatz interpretiert aber jedes Byte einzeln und

speichert sie so."

Ich habe das für mich dann so interpretiert, dass ich das Multibyte-Format der neuen db vor der Migration meiner alten db in die Kollation 'utf8_general_ci' umstelle, um dann erneut ein Migrationsversuch zu starten. Da ich genau auf diese Kollation keinen Einfluss habe (Die allgemeine Einstellung 'utf8mb4_unicode_ci' lässt sich als User nicht verändern - siehe auch hier mein Eröffnungsthread) habe ich mal ein Ticket aufgemacht (nur die 'Operationen' und die Kollationen der Tabellen selber kann man umstellen).

Der Dump meiner alten db wurde tatsächlich mit MySQLDumper vollzogen, welcher schon länger nicht mehr weiter entwickelt wird. Wenn ich ein Dump bei meinem alten Hoster mit PHPMyAdmin mache (welches hoffentlich dann das Multibyte-Format unterstützt muss ich doch vor dem Dump meine gange db in das Multibyte-Format umwandeln (stimmt doch, oder?). Aber gleichzeitig habe ich von irgenwo auch gehört, dass ich hier mit PHPMyAdmin keine db > 2 MB (komprimiert) migrieren kann. Meine db ist aber > 5 MB. Ich werde mal den netcup-Support hierhin verlinken - vielleicht fällt dem noch was ein.

-volker-

Nachtrag: Ich selber kann meine db gar nicht löschen - auch nicht mittels Konsole und drop-Befehl. Da muss ich wohl ein Ticket für aufmachen.

Die neue db dann am Besten (vor dem Importieren) so einstellen, wie die alte Datenbank (siehe Eröffnungsthread). Oder soll ich alles auf utf8_unicode_ci stellen.

Allerdings (fällt mir gerade ein): Die anderen beiden Homepages (sind cms-Systeme) laufen ja anscheinend fehlerfrei mit den Einstellungen der neuen db. Ich werde das mal überprüfen, und auch mal bei einem cms ein Umlaut abspeichern. Jepp, das cms speichert die Umlaute richtig in die db ab und holt sie auch so wieder raus. Dann muss es also doch per Script zu lösen sein. Ich schau mir aber auch noch mal die Tabellen des cms an, unter welcher Kollation das abgespeichert ist.

Hi Peter,

für den Ex -und Import benutze ich MySQLDumper. An der Benutzung von phpmyAdmin lag es also nicht.

aNewUser,

kann schon sein - bisher (ich glaube seit 10 Jahren steht die Seite im Netz) ist das noch nicht passiert. Außerdem mache ich täglich Backups. Aber Du hast schon recht - ne Profiseite ist das natürlich nicht.

...macht mal Vorschläge, wie ich den Kollationsfehler weg bekomme. db komplett löschen und neu importieren?

-volker-

KB19,

keine Ahnung, ich habe jedenfalls mittels .htaccess php5.6 eingestellt (AddHandler x-httpd-php56 .php). Und dieses .htaccess ist auch im netcup-Verzeichnis enthalten. Dann müsste doch auch hier 5.6 laufen - oder nicht?

Ich habe mal gerade auf palmenstandorte ein phpinfo() abgesetzt - die Einstellung wurden also mit .htaccess übernommen. PHP-Version ist 5.6.36

H6G,

mein Fehler war wohl diesbezüglich bei netcup eine Datenbank anzulegen und sofort zu importieren. Besser wäre es wohl gewesen erst mal alles bei der neuen db auf utf8_unicode_ci umzustellen. Trotzdem, vorm Import und nach dem Import haben beide Tabellen die gleiche Kollation (utf8_general_ci).

Was ist Deine Empfehlung? Ganze db löschen und neu importieren? Alles auf utf8_unicode_ci einstellen - ich schätze die Tabelle wird dann trotzdem mit ihrem Zeichensatz utf8_general_ci importiert - nur ist dann wenigsten die Verständigung zwischen Client und Server einheitlich.

-volker-

Hi liebe Forenmitglieder,

bin gerade nach netcup migriert und habe meine 3 Homepages nebst Datenbanken auch schon auf dem Webspace abgelegt. Das Problem ist meine gebastelte interaktive Karte. Diese will auf einmal nicht so wie früher - und das ist definitiv ein Kollationsproblem. Bloß kenne ich mich mit den utf8-Derivaten nicht so ganz aus. Meine alte Datenbank habe ich einfach hier in die neu angelegte Datenbank migriert.

Hier mal die Einstellungen der alten SQL-db:

Startseite (allgemeine Einstellungen: Zeichensatz der MySQL-Verbindung): utf8_general_ci

Operationen: utf8_unicode_ci

besagte Tabelle: utf8_general_ci

Das wurde in die netcup-db migriert, welche diese Einstellungen hatte (und natürlich immer noch hat:

Startseite (allgemeine Einstellungen: Zeichensatz der MySQL-Verbindung): utf8mb4_unicode_ci

Operationen. utf8_general_ci

besagte Tabelle: utf8_general_ci

Wie man sieht hat die besagte Tabelle also bei netcup die gleiche Kollation wie bei meinem alten Hoster. Sollte also hinhauen - weit gefehlt. Die HTML-Seite wurde zwar angezeigt, aber die Datenbankabfrage (Marker werden auf eine Landkarte gesetzt) funktionierte nicht. Dabei werden die Datensätze in eine XML-Datei geparsed und ich habe schnell herausfinden können, wann der Parser abgebrochen hat. Das war an einem Umlaut (ü). Damit war klar was das Problem war, und da ich mit dem mistigen Kollationen immer auf Kriegsfuß stehe, habe ich mein Script angepasst (an den Kommentaren ersichtlich was umgestellt wurde).

Hier das Script: phpsqlinf_result.php

So, nun wurden alle Marker wieder angezeigt. Leider bleibt ein Kollationsproblem beim Editieren der Marker - besser gesagt beim wieder reinschreiben in die Datenbank. Auch hier ist das php-Script mit einem Kommentar versehen. Geschrieben wird mittels HTML-Post-Methode. Meta-Tag und auch Header stehen auf utf8.

Hier das Script: edit_reg.php

...da ich die Seite schon vor langer Zeit gemacht habe, bin ich nun etwas eingerostet. Wie gesagt, es ist ein Kollationsproblem, weil ja von Anfang an das Einlesen aus der Datenbank an Umlauten scheiterte - ich seh vor lauter utf8 Tags aber nicht den Fehler. Vielleicht könnt Ihr mir helfen.

Ihr könnt gerne mal selber ein paar Marker setzten und das Ergebnis überprüfen (rausholen funktioniert / reinschreiben da verhaut er die Umlaute).

Hier die Seite (die vorher funktionierte): www.palmenstandorte.de

-volker-