Schlagwort-Archive: PHP

To boldly go where no php-script has gone before…

Veröffentlicht am von
Antworten

Wer in den letzten zwei Stunden hier in dieses bescheidene Bastelblog schauen wollte, bekam statt einer mehr oder weniger vernünftigen Seite nur so was: eine Fehlermeldung, dass der Server leider zurzeit nichts liefern könne wegen eines fatalen Fehlers. Da seien leider keine 35 Bytes mehr für eine neue Aufgabe übrig, weil das Speicherlimit von 16MB erreicht sei.

Hatte wieder unvorsichtig ein paar Plugins upgedated – und prompt die (inzwischen offenbar knapp bemessene) Speichergrenze erreicht. Zu meiner gewaltigen Überraschung ließ sich das auf dem Strato-Server in nur 5 Minuten korrigieren:

  • Ins Wurzelverzeichnis des Blogs (nicht des Servers!) gegangen, mittels sftp,
  • die Datei „php.ini“ geöffnet, die’s da schon gab,
  • …und sie so geändert, dass sie dann wie folgt aussah:
<?php
 memory_limit = "32M"  ;da stand vorher 16M, das war wohl zu knapp
 ?>

…und alles funktionierte wieder bestens. Hängt wohl mit deutlich gewachsenem WordPress zusammen – noch vor zwei Jahren war der Tipp für Strato-Nutzer, doch von 8 auf 16MB PHP-Memory zu erhöhen…

Mehr zu PHP-Speichernöten bei Strato in einem anderen Zusammenhang in diesem Artikel. Und diesmal ganz ohne Ironie: Es gibt viele, die über Strato mäkeln – ich kann das bisher nicht bestätigen…

untergeek lernt Drupal

Veröffentlicht am von
Antworten

Denke über ein kleines neues Projekt nach; spiele dafür derzeit mit Möglichkeiten herum, Redaktionen (und ähnliche Kleinstorganismen) mithilfe von sozialer Software zu organisieren, und da mir die herkömmliche Kombination aus MediaWiki und WordPress mit gemeinsamer Nutzerbasis nicht sexy genug war, habe ich angefangen, mit dem CMS Drupal herumzuspielen – beziehungsweise dessen auf Projektmanagement spezialisierten Ableger OpenAtrium.

Natürlich lief die Installation nicht rund, und das hat in diesem Fall mit einigen Eigenheiten von Strato zu tun, meinem sonst durchaus geschätzten und geliebten Provider.

  • Der erste Schritt war einfach: Das OpenAtrium-Installationspaket heruntergeladen und in ein Verzeichnis auf dem Server geschoben, die install.php aufgerufen – und die Installation läuft los. Leider läuft sie nicht durch, sondern bricht am immer gleichen Punkt ab mit der Fehlermeldung, der Speicher sei aufgebraucht. 32MB würden nicht reichen, sagt die PHP-Installation
  • Jetzt ist das mit dem Speicher für PHP so eine Sache. An die Datei php.ini, die globale Einstellungen festlegt, kommt man bei Strato nicht heran; dort kann man den Speicher also nicht hochsetzen. Ich wundere mich, dass das nötig ist – laut einem Hinweis von Strato bietet mein Hosting-Paket beim Einsatz von PHP5 maximal 64MB, was dicke reichen müsste. Und ich habe den OpenAtrium-Ordner im „Webkonfigurator“ zum Einsatz von PHP5 gezwungen. Ist das Paket mit sich selbst zu geizig?
  • Wie kann man sich mehr Speicher verschaffen? Neben der – wie gesagt: nicht zugänglichen – Konfigurationsdatei php.ini besteht die Möglichkeit, in der versteckten Datei .htaccess Anpassungen vorzunehmen. Zu der kursieren einige Tipps im Netz; man solle Verschiedenes auskommentieren oder sie ganz löschen. Dass das nötig ist, kann ich nicht bestätigen; Fakt ist aber: Trage ich in die .htaccess-Datei die Anweisung „memory_limit = ’64M‘;“ ein, produziert der PHP-Interpreter nur noch Fehler.
  • Der nächste Schritt war, dem Programm selbst mehr Speicher zu geben: Die OpenAtrium/Drupal-Installation hat in einem Unterordner eine „settings.php“; dort kann man das memory_limit auf 48MB setzen. Nicht schlecht, nützt aber nichts für die Installation. Moppelkotze.
  • Obwohl ich – spürst Du’s, Leser? – nur noch einen Schritt von der Lösung entfernt war, habe ich mich an diesem Punkt entschlossen, die Installation nochmal zu radieren und von vorn anzufangen. Nanu, ehemals schreibgeschützte Dateien lassen sich immer noch nicht löschen? Auch auf der ssh-Kommandozeile nicht? Kein Wunder, wenn der Ordner noch schreibgeschützt ist, du hohle Nuss. Und nein, bei Unix gibt’s kein chown und kein chgrp, sondern nur den Befehl chmod; Linux ist nicht Unix.
  • Vor der Neuinstallation habe ich das memory_limit in install.php UND in settings.php auf 48M gesetzt. Und siehe da: jetzt lief die Installation durch.

Gut, nun läuft OpenAtrium also, sieht gut aus, erst einmal aber auch nicht viel mehr. Komme mir ein wenig vor wie der Mann, der sich einen teuren Flügel kauft und ins Wohnzimmer stellt und dann allmählich darüber nachzudenken beginnt, ob es nicht doch mal hilfreich sein könnte, Klavierunterricht zu nehmen. Ob ich nicht doch lieber beim Wiki bleibe?

Grmbl… WordPress 2.6.1 verschluckt TinyMCE

Veröffentlicht am von
Antworten

Wunderbar: wieder mal ein WordPress-Update. Von 2.6 auf 2.6.1, nur wenige Wochen nach Freigabe der 2.6er-Version. Haben wir da mal wieder nicht gründlich genug getestet? Naja, egal. Das Update ist ja keine große Sache. Dumm nur: nach dem Update ist TinyMCE verschwunden, die lieb gewonnene Editor-Komponente für WordPress, die ein halbwegs vernünftiges Arbeiten für Nicht-Coder erst ermöglicht. (Ich weiß, ich weiß: Du, lieber Leser, kannst HTML nötigenfalls auch furzen, mir ist das für den Alltag zu anstrengend, und Drittautoren schließt man so komplett aus – die Erfahrung hat sich bei unserem von mir eingeführten Redaktionswiki leider nur zu deutlich bestätigt.)

Wordpress ohne WYSIWYG-Editor - nach dem Update auf 2.6.1
Kurz gesagt: das hier ist doch keine Art, oder?

Nach kurzer Suche habe ich diesen Tipp gefunden – die wp-config.php nicht als UTF-8-Textdatei abspeichern, sondern als (Windows-) ANSI-Code. Was mit KWrite unter Linux der Codierung cp 1252 oder ISO 8859-1 zu entsprechen scheint. Möglich, dass dieses Phänomen schon nach dem Update auf 2.6 vorhanden war und ich habe es bloß nicht bemerkt – Tatsache ist aber leider, dass der Tipp bei mir nicht funktioniert. Dasdarfdochnicht…

Update, 25.8.08: Nach Neuanmeldung funktioniert’s wieder – der Tipp, die wp-config neu zu speichern, stimmt also und greift bei einer neuen WP-Session.