Da muß man nichts anpassen. Wordpress versucht nur das memory-Limit zu erhöhen, wenn es kleiner als die definierten Werte ist. Wenn sowieso schon 128M eingestellt sind, passiert gar nichts. Worpdress setzt das Limit ja nicht herunter.
Gruß
Ingo
Um schreiben oder kommentieren zu können, benötigen Sie ein Benutzerkonto.
Sie haben schon ein Benutzerkonto? Melden Sie sich hier an.
Jetzt anmeldenHier können Sie ein neues Benutzerkonto erstellen.
Neues Benutzerkonto erstellenDa muß man nichts anpassen. Wordpress versucht nur das memory-Limit zu erhöhen, wenn es kleiner als die definierten Werte ist. Wenn sowieso schon 128M eingestellt sind, passiert gar nichts. Worpdress setzt das Limit ja nicht herunter.
Gruß
Ingo
Ob es die Möglichkeit gibt, einfach PHP-Ini-Werte zu ändern, hängt vom Webhoster ab. Oft ist es nicht möglich.
Je nach Konfiguration des Webservers werden die Werte nicht durch "php_value" sondern mit einer php.ini angepaßt.
Bei welchem Webhoster liegt denn Deine Seite?
Gruß
Ingo
Die Dokumentation ist falsch. %tag% hat noch nie funktioniert und tut es bis einschließlich WP-Version 3.0.1 auch nicht.
Bei der Funktion get_permalink (in link-template.php) wurde einfach die Behandlung des tag-Platzhalters vergessen.
Zudem gibt es auch ein inhaltliches Problem. Was passiert, wenn kein Tag für einen Artikel angegeben wird? Im Unterschied zu den Kategorien gibt es ja kein Standard-Tag.
Gruß
Ingo
... Der Dumper nutz keinerlei Einstellungen, Caches oder dergleichen von WP. Ist eine ganz andere Baustelle.
Das kann man so pauschal auch nicht sagen. Schließlich schreibt Wordpress selbst und gegebenfalls auch irgendwelche Plugins Dinge in die .htaccess-Datei. Wenn nun der mySQLDumper in einem Unterverzeichnis vom Wordpress-Root liegt, werden diese .htacess-Einstellungen vererbt und könnten sich schon irgendwie auswirken.
Gruß
Ingo
Bei mir geht es mit Firefox nicht, mit dem IE6 aber schon.
Es dürfte daran liegen, das die Seite mit http://www.dienic.de aufgerufen, der Cookie aber für dienic.de (ohne www) gesetzt wird.
Manche Browser akzeptieren das, andere nicht.
Ich habe aber keine Ahnung, warum die falsche Cookiedomain gesetzt wird.
Gruß
Ingo
...
Einfach mal reinschauen und am besten persönlich Kontakt aufnehmen,wenn es umfangreicher werden soll. Die sind kompetent und recht schnell.
Keine "Massenabfertigung" wie bei Strato.Die bieten auch Typo3 Hosting und Webspace an.
...
Ich lese da irgendwie was anderes: ... Wir sind kompetent und recht schnell. ... Wir bieten auch Typo3 Hosting und Webspace an... ![]()
Ist ja nett, wann es bei Euch auch Typo3 Hosting gibt, das hier ist aber ein Wordpress-Forum und der TE suchte etwas für sein Wordpress-Blog.
Gruß
Ingo
Hmmm, also das mit den 64M funktionsfähig will ich nicht recht glauben. Du scheinst bei 1&1 zu sein, und da liegt die Grenze bei 32M. Was mit dem 2.9.2 passiert ist, kann ich auch nicht sagen. Laut readme.html scheint es tatsächlich WP 2.8.4 zu sein.
Ein Upgrade auf 3.0.x funktioniert aber auch bei 1&1 prinzipiell. Wichtig ist die Umstellung auf PHP5 (falls nicht schon passiert) und das vorrübergehenden deaktiviern aller Plugins.
Gruß
Ingo
Wobei eine eigene Domain ja auch nicht das Problem wäre. Gibt es schon für 50 Cent im Monat und der Domainname kann ja tatsächlich a la Google was mit Static sein, für jonas-broeckl dann z.B. jbstatic.de oder so.
Es hängt zudem noch vom Webbrowser ab, ob der die Cookies zur Subdomain durchreicht oder nicht. In meinem Kurztest hat es der Firefox 3.6 nicht gemacht, der IE 6 aber schon.
Gruß
Ingo
Meines Wissens gelten Cookies von übergordneten Domains auch für Subdomains (aber nicht anders herum). In dem Google-Page-Speed-Dokument steht auch nichts von Subdomains, sondern Domains, wie z.B. gstatic.com.
Gruß
Ingo
Ich kann es zwar nur vermuten, aber das web.de Webhosting dürfte technische gesehen ein spezielles 1&1-Paket sein. Damit gelten dort sinngemäß alle Einschränkungen (z.B. nur 32M PHP-Speicher, auch wenn 40M angezeigt werden) und Hinweise wie für das 1&1-Webhosting.
Gruß
Ingo
Jetzt noch mal für mich zum mitschreiben. Das WP-Update funktioniert also nach Eingabe der FTP-Daten? Das wäre ja auch logisch, denn dann agiert WP als FTP-User und hat dann ntürlich die Schreibrechte.
Mein "Trick" zielt übrigens darauf ab, das ganze ohne Eingabe der FTP-Daten auszuführen. Also einfach auf "Automatisch aktualisieren" klicken und los gehts.
Gruß
Ingo
Ich kann für all-inkl auch noch den "php-cgi-Trick" empfehlen:
http://schnurpsel.de/update-auf-wor…64/#comment-386
Gruß
Ingo
Ja, die Meldung hatte ich vorhin bei mir beim Testen auch. Kann ich mir nicht erklären, wie das kommt. Muß ich mal untersuchen...
Gruß
Ingo
Was ist mit den oben genannten Wordpress-HTTP-Transport-Methoden?
Hast Du mal nachgesehen, welche konfiguriert sind und welche möglicherweise nicht funktionieren. Bei mir war es damals, als ich das gleiche Problem hatte, die Streams-Methode. Diese wurde zwar als verfügbar erkannt, war aber PHP-seitig nicht richtig konfiguriert. Das deaktivieren der Streams-Methode hatte dann das Problem behoben.
Gruß
Ingo
Wenn man WP 3.0 aufruft (Link Nr. 2), und dann den Request gleich wieder abbricht, kann man danach die Seite für etwa 60 Sekunden ganz normal Aufrufen. Das ist dann praktisch genauso schnell wie WP 2.0 (Link 1).
Der Grund dürfte sein, daß Wordpress regelmäßig nach Hause "telefoniert", um z.B. nachzuschauen, ob es Updates gibt oder Ähnliches. Wenn der Request fehlschlägt, wird frühestens nach 60 Sekunden ein neuer Versuch gestartet.
Ursache sind möglicherweise nicht korrekt konfigurierte HTTP-Request-Methoden oder eine Firewall, die überhaupt keine HTTP-Requests vom Server nach draußen läßt.
Für die Request-Methoden könnte man mit dem Plugin "123 HTTP Transport" probieren, ob das Abschalten bestimmter Transport-Methoden das Problem beseitigt.
Ansonsten muß man rausfinden, warum WP sich nicht nach Hause verbinden kann.
Gruß
Ingo
Wildcard-Subdomain bedeutet, das der Webserver einfach alle Subdomains zu einer Domain akzeptiert, ohne das diese Subdomains explizit eingerichtet werden müssen.
Bei Host-Europe muß jede Subdomain angelegt werden. So ist dort z.B. mein Testblog unter:
erreichbar, nicht jedoch z.B. unter http://vor.gabedaten.de, weil ich diese Subdomain nicht angelegt habe.
Bei All-Inkl hingegen kann man Wildcard-Subdomains definieren. Dazu muß einfach z.B. eine "Subdomain" *.keintext.de konfiguriert werden. Damit kann ich dann alle denkbaren Subdomains für keintext.de aufrufen, z.B.:
Soetwas ist sehr praktisch, wenn man vorhat, mit WP 3.x (früher WPMU) sehr viele Unterblogs auf Subdomain-Basis zu betreiben. Das ist das gleiche wie bei wordpress.com, wo man ein Blog mit der Adresse irgendwas.wordpress.com einrichten kann.
Gruß
Ingo
Kleiner Nachteil bei Host-Europe, es werden in den Webpacks keine Wildcard-Subdomains unterstützt. Gerade für Multiblogs auf Subdomain-Basis nicht so optimal.
Gruß
Ingo
So direkt gar nicht. Du kannst aber eine normale Textdatei als robots.txt anlegen und da reinschreiben, was Du willst. Wenn eine echte Datei existiert, wird die virtuelle von Wordpress nicht verwendet.
Gruß
Ingo
Diese "erstellte" robots.txt ist genau so virtuell, wie jede Seite oder jeder Artikel in Wordpress. Sie existiert nicht im Dateisystem, wird aber auf Anforderung ausgeliefert.
Gruß
Ingo
Steht doch in der oben verlinkten Doku, da muß man nichts großartig umschreiben. Es reicht, folgende Zeile an der Stelle einzufügen, wo die Bilder ausgegeben werden sollen:
Ich weiß ja nicht, in welchen Situationen Du die Galerie ausgeben willst, sinnvoll ist das meiner Meinung nach nur bei der Artikel-Einzelansicht. Dann reicht es schon, in der Sidebar folgendes zu verwenden:
Da mußt Du Dir noch nicht mal die Artikel-ID extra merken oder so, weil die ID für die Seite normalerweise auch in der Sidebar noch gültig ist.
Gruß
Ingo