Beiträge von Putzlowitsch

Ein Fehler ist mir im Formular aufgefallen. Du darfst dort keine Feldnamen verwenden, die Wordpress selbst benutzt. Eine Übersicht findest Du hier:
http://codex.wordpress.org/WordPress_Query_Vars

In Deinem Fall ist das Feld 'name' das Problem.

Und zum Absenden eines Formulars wird eine Button vom Typ 'submit' benötigt, nicht 'button'.

Gruß
Ingo

Guck mal hier:
http://forum.wpde.org/installation/1…html#post537403

Könnte dasselbe Problem sein.

Gruß
Ingo

Ihr also auch nicht, gut. Ich dachte schon, nur ich habe Tomaten auf den Augen. :-)

Gruß
Ingo

Auf der Beispielseite ist das mit Flash realisiert. Ob man das so gut auch nur mit CSS hinbekommt, wage ich zu bezweifeln, aber versuchen kann man es ja.

Gruß
Ingo

Also für eine Website mit etwa 10 Unterseiten braucht man nun wirklich keine Sitemap, würde ich sagen.
Die Sitemap ist mit 9 Untersitemaps fast größer als die Website selbst. :-)

Die Fehler kommen einfach daher, daß die Untersitmaps zwar in der Hauptsitemap aufgeführt werden, selbst aber keinen Inhalt haben. Das ist auch logisch, denn Kategorien und Tags gibt es nur für Blogartikel, die es aber nicht gibt. Wenn ich es richtig gesehen habe, gibt es nur statische Seiten.

Gruß
Ingo

Hmmm, seltsam. Nun könnte es auch noch sein, daß 1&1 im Moment Probleme mit den DB-Servern hat. Allerdings laufen meine Seiten bei 1&1 z.Z. problemlos. Da bin ich erstmal ratlos.

Gruß
Ingo

Naja, dann stimmt etwas mit den Daten nicht. Bei 1&1 sollten diese in etwa so aussehen:

define('DB_NAME', 'db418331374');
define('DB_USER', 'dbo418331374');
define('DB_PASSWORD', 'rz4q6btf7th');
define('DB_HOST', 'db418331374.db.1and1.com');

Man beachte z.B. das kleine o beim DB_USER.

Gruß
Ingo

Eine php.ini-Datei wirkt nur in dem Verzeichnis, wo sie liegt. Wenn es Probleme im Admin-Bereich gibt, ist dafür eine php.ini im Verzeichnis /wp-admin/ verantwortlich. Du kannst sie ggf. auch einfach löschen.

Gruß
Ingo

So wie das im Beispiel-Quelltext steht (mit dem Doppelpunkt), ist das kein normaler WP-Shortcode, sondern scheinbar eine Eigenentwicklung des Plugin-Erstellers. Deshalb funktioniert auch do_shortcode() nicht und es gibt folglich kein Daten.

Ein Ähnliches Problem hatte kürzlich jemand mit einem Amazon-Plugin:
http://forum.wpde.org/konfiguration/…html#post562610

Also Lösung mußte dort dann eine spezielle Shortcode-Funktion verwendet werden, die das Plugin bereitstellt. Ob es sowas bei dem Plugin hier gibt, kann ich nicht sagen.

Gruß
Ingo

gericoach
Ich denke, das ist nur Spam/Linkbuilding.
Allein der Link auf die Seite mit den Keywords deutet darauf hin. Sowas erkennt mittlerweile sogar Google selbst als Spam. :-)

midoo25
Warum ist alles auf Englisch? Wenn Du Dich an englischsprachige Kunden wenden möchtest, post Deine Links doch einfach in englischsprachige Foren.
Ich konnte auch nirgendwo finden, wer der Anbieter ist.

Gruß
Ingo

Warum fragst Du das in einem Wordpress-Forum und guckst nicht einfach auf der Hersteller-Seite nach?

AVM hält fast zu jeder Fragestellung gute Antworten und ausführliche Beschreibungen bereit. Zu Deiner Frage sollte das hier weiterhelfen.

Gruß
Ingo

Am zuverlässigsten gibt ein Blick in die Domain-Konfiguration im Kundenbereich Deines Webhosters Aufschluß. Dort wird die Domain einem Verzeichnis im Webspace zugeordnet. Wie man das findet und was man dort konkret sehen und einstellen kann, hängt vom Webhoster ab. Dazu kann man keine pauschalen Aussagen treffen.

Gruß
Ingo

Klar kann man Videos mit Altersbeschränkung einbinden. Die wird dann aber nur jemand sehen können, der bei YouTube/Google angemeldet ist und das entsprechende Alter hat. Alle anderen sehen nichts.

Gruß
Ingo

Zitat von Hille

Ist richtig. Ob eine Lastverteilung oder ein extra Datenbank-Server oder, oder ... im Einsatz sind, kann man nicht erkennen. Es könnte aber auch gut möglich sein, das gar keine Lastverteilung stattfindet ;-).

Doch, da wir wissen, daß es Strato-Hosting ist, weiß ich, daß es sehr wohl eine Lastverteilung und z.B. dediziert DB-Server gibt. Diese Strato-Pressemeldung ist zwar schon etwas älter, ich gehe aber nicht davon aus, daß dort wieder auf einzelne Kundenserver umgestellt wurde.

Die extra DB-Server kann man auch daran erkennen, daß als DB_HOST nicht 'localhost', sondern 'rdbms.strato.de' eintragen muß

Gruß
Ingo

Zitat von Hille

... Aktuell befinden sich auf dem Server über 1000 Domains, das nenne ich mal ne Hausnummer. Da ist es eigentlich normal, das der Server "ein wenig länger" braucht...

Du meinst sicher 1000 Domains auf einer IP-Adresse. Wie das dahinter auf Server verteilt wird, kann man meines Wissens von außen gar nicht sehen.

Außerdem waren die Werte auf der lokalen Xampp-Installation nicht besser. Da dürften es keine 1000 Domains gewesen sein. :-)

Gruß
Ingo

Auch aktuelle Plugins können Probleme verursachen. Da wirst Du mal alle Plugins deaktivieren und schrittweise aktivieren müssen, um den möglichen Übeltäter zu finden.

Gruß
Ingo

Die längste Zeit vergeht ja vom Request bis zum Eintreffen der Antwort der Hauptseite. Also ist WP mit irgendetwas so lange beschäftigt. Was dann alles noch an css oder js nachgeladen wird, spielt da eigentlich keine Rolle. Obwohl da auch ein paar dicke Sachen dabei sind. Das Hauptproblem liegt aber weiter vorne.

Wie gericoach schon vorgeschlagen hat, sollte man mal mit einem Standard-Theme testen, die Plugins abschalten und gucken, ob es immer noch 12 bis 14 Sekunden bis zur ersten Antwort dauert.

Gruß
Ingo

"liegt an Strato" kann man so pauschal auch nicht sagen. Ich habe dort auch eine Seite, die hat eine Antwortzeit von ca. 2 Sekunden. Das ist zwar auch nicht überragend, aber es sind keine 12 Sekunden.

Besonders die alten Webhostingpakete waren nicht wirklich schnell. Welches Paket hast Du denn? Wenn es sehr alt ist, so von 2009 oder davor, dann könnte ein Paket-Upgrade helfen.

Gruß
Ingo

Die robots.txt-Datei muß da liegen, wo sich die Wurzel der Domain befindet. Sei muß mit http://example.com/robots.txt abrufbar sein und nicht mit http://example.com/wordpress/robots.txt oder sonst einem anderen Unterverzeichnis.

Wenn Dein WP in einem Ordner /wordpress/ liegt und auch so aufgerufen wird, müßt der Eintrag in der robots.txt natürlich auch entsprechend das Verzeichnis /wordpress/ enthalten, also:

Disallow: /wordpress/tag/

Gruß
Ingo

Das ist halt die Frage, will man den Google-Bot vom Crawlen abhalten oder verhindern, daß die Seiten in den Index gelangen. Ich hatte oben eher Ersteres herausgelesen.

Es gibt noch so eine Art Mittelweg. Man liefert dem Google-Bot per .htaccess eine 410-Seite aus. Damit bekommt der Bot nie die richtige Seite zu sehen und wird sie auch nicht in den Index aufnehmen bzw. früher oder später entfernen.

Gruß
Ingo