Beiträge von Putzlowitsch

Ich würde sagen, es liegt an der Post-Variable 'name'. Wordpress verwendet auch eine solche Variable und kommt damit durcheinander. Du muß also an allen Stellen, wo 'name' bei den Bewertungsfunktionen auftaucht, dieses durch z.B. 'bewertung_name' ersetzen.
Einmal im Formular selbst, z.B.:

<td>
    <input maxlength="24" type="text" [B]name="bewertung_name"[/B] value="<?php if(isset([B]$_POST['bewertung_name'][/B])) echo [B]$_POST['bewertung_name'][/B]; ?>" />
    <span id="warnung_name" style="display:none; color:#c53f3f">Bitte geben Sie hier Ihren Namen ein</span>
    <?php if(isset([B]$_POST['bewertung_name'][/B])){if([B]$_POST['bewertung_name'][/B]==""){ echo "<br /><span style=\"color:#c53f3f\">Bitte geben Sie hier Ihren Namen ein</span>"; }}?>
    <input type="hidden" name="id_objekt" value="<?php echo $row['id_objekt'];?>" />
</td>

Und natürlich an allen Stellen, wo es mit $_POST[] zu finden ist.

Gruß
Ingo

Die Frage ist nun wieder, wo werden wie die Bewertungsfelder ausgewerte. Da muß irgendwas mit $_POST stehen.

Gruß
Ingo

Wozu soll denn das #bewerten da oben am Ende der Action-URL gut sein? Nimm das mal raus und gucke, ob es dann funktioniert.

Gruß
Ingo

Bitte schön. Freut mich, daß es nun funktioniert.
Ich war 10 Tage unterwegs und konnte deshalb nicht antworten, aber Du hast es ja selbst hinbekommen.

Gruß
Ingo

Für die Auflösung der URL in eine WP-Abfrage und damit eine gültige Seite ist die Funktion parse_request in der class-wp.php zuständig. Da sollte man aber nicht ohne Not und nur wenn man wirklich weiß, was man tut, dran rumfummeln.

Gruß
Ingo

Die eigentliche Unschärfe rührt aber auch daher, daß das Bild, welches von WP auf eine Breite von 800 Bildpunkten runtergerechnet wurde, vom Browser dann noch auf 798 Pixel skaliert wird. Wenn ich mir das Bild alleine ansehe (z.B. rechte Maustaste->Grafik anzeigen) sieht es eigentlich ganz gut aus.

Warum da nochmal vom Browser skaliert wird, ist schwer zu sagen. Da müßte man sich mal das CSS und solche Dinge ansehen. Manchmal reicht da schon ein 1 Pixel breiter Rahmen, der durch einen übergeordneten Container mit fester Größe zu einer Skalierung führt.
Nachtrag:
Hab mal rumprobiert, wenn ich hier

.cycle .entry-image img, .entry-image-container .entry-image img {
    width: auto;
    max-height: 532px;
}

das width:auto; rausehme, verschwindet die Browserskalierung.

Gruß
Ingo

Vielleicht noch kurz als Erläuterung zum Fehler 403.

Wenn ein Webserver beim Aufruf eines Verzeichnisses den Fehler 403 ausgibt, hat das in den meisten Fällen nichts mit den Datei/Verzeichnis-Zugriffsrechten zu tun. Ursache ist dann eine fehlende index-Datei, die der Webserver immer dann anzeigen will, wenn nur ein Verzeichnis ohne expliziter Angabe einer Datei aufgerufen wird.

Welche Dateien der Server als Index verwendet, kann in der Konfiguration festgelegt werden. Oft ist es index.html, index.php usw. Selbst einstellen kann man das bei vielen Webhostern mit einem Eintrag in der .htaccess-Datei, z.B.:

DirectoryIndex index.php index.html

Bei 1&1 ist bereits eine Vielzahl an Index-Dateien vorkonfiguriert.

Zur fehlenden Konfigurationsdatei:
Du mußte die Datei wp-config-sample.php, die im Wordpress-Basisverzeichnis liegt, in wp-config.php umbennen und dort die Werte für die Datenbank eintragen, z.B.:

define('DB_NAME', 'db123456789');
define('DB_USER', 'dbo123456789')
define('DB_PASSWORD', 'rh473256');
define('DB_HOST', 'db1234.1und1.de');

Die Daten findest Du im 1&1-Controlcenter im Bereich Webspace->MySQL. Falls Du noch keine Datenbank angelegt hast, findest Du hier die entsprechende Anleitung.

Im übrigen gibt es in den Dual-Hosting-Paketen nur noch PHP 5, da muß man also nichts mehr in der .htaccess konfigurieren. Man kann aber z.B. im Controlcenter die globale PHP-Version zwischen 5.2 und 5.4 wechseln.

Gruß
Ingo

Hallo Clari,

in Ergänzung zu den Hinweisen von Herrn FrageSelten möchte ich darauf hinweisen, daß auch die Datei wp-app.php den kompletten Pfad zu Deiner Wordpress-Installation preisgibt. Du solltest auch diese Datei in den Schutz mit aufnehmen. Möglicherweise geben auch weitere Wordpress-Dateien beim direkten Aufruf eine Fehlermeldung oder Warnung mit dem kompletten Pfad aus. Das sollte mal überprüft werden.

Gruß
Ingo

Ja richtig, das Ding da im WP ist kein echter cron, aber es heißt in WP nun mal so. Ich wollte damit nur auf das Modul hinweisen, das dafür verantwortlich ist.

Mit der Musik im Hintergund ist doch ganz nett. :-)

Gruß
Ingo

Ahhh, jetzt kommen wir der Sache näher. Es wird also über ein Seitentemplate verzweigt, ob die Übersichtsseite oder die Detailseite angezeigt werden soll. Da aber das Seitentemplate nicht der Startseite zugwiesen ist, sonder den jeweiligen Übersichtsseiten gibt es zwei Möglichkeiten.

Entweder Du nimmst die Seiten-ID der Übersichtsseite mit, also das der Link z.B. so aussieht:
http://www.planet-gericke.de/neuZimmervermi…d=14&details=16
oder Du erstellst eine neue Seite nur für die Details (bekommt z.B. die ID 1234), und der Link zeigt dann eben auf die feste ID dieser Seite und den Parameter details, also so /?page_id=1234&details=16.

Gruß
Ingo

Nach meinem Verständnis bedeutet "Papierkorb deaktivieren" aber eigentlich den Papierkorb abzuschalten, also das Verhalten wie ohne Papierkorb herzustellen. Das heißt, Artikle werden sofort gelöscht.

Das die Artikle, die ehemals im Papierkorb waren, nach der Umstellung in der wp-config nicht sofort gelöscht werden dürfte daran liegen, daß die WP-Müllabfuhr per WP-Cron nur alle 24 Stunden vorbeikommt. Deshalb bleiben die Artikel erstmal noch liegen, dürften aber spätestens nach 24 Stunden auch verschwunden sein.

Gruß
Ingo

Achso, schade. Das wäre jetzt auch zu einfach gewesen. :-)

Nun weiß ich wirklich nicht mehr weiter. Was mich nur wundert, irgendwie muß der Parameter details in Wordpress ja ausgewertet werden. Woher soll den Wordpress sonst wissen, das es nun die Details zu einem Hotel anzeigen soll.

Das der Aufruf mit index.php?details=123 von Wordpress auf die Startseite umgeleitet wird, ist erstmal ein nomales Verhalten. Das passiert auch beim Aufruf der index.php ohne Parameter. Nur wie erfährt Wordpress, was es mit dem Parameter details anfangen soll. Das kann nur im Theme, in einem Plugin oder in der my-hacks.php stecken. Aber wenn Du sagst, da ist nichts derartiges zu finden.

Plugins sind übrigens nicht nur im Ordener /wp-content/plugins/ zu finden, sondern auch in /wp-content/mu-plugins/ zu finden. Hast Du da auch alles kopiert?

Gruß
Ingo

Ahhh, da haben wir möglicherweise das Problem. Bei Strato ist der Datenbank-Host nicht "localhost", sondern "rdbms.strato.de". Probier das mal aus.

Gruß
Ingo

Hmm, nun bin ich mit meinem Latein auch fast am Ende.

Ansatzpunkt wäre für mich nur noch diese per include eingebundene Datei, welche die Verbindung zu den Hoteldaten herstellt. Was steht da drin?
Und irgendwo im den Theme-Dateien muß ja auch der Parameter details verarbeitet werden. Das läßt sich jetzt so von außen natürlich schwer nachvollziehen.

Besonders seltsam ist ja, daß es lokal funktioniert.

Gruß
Ingo

Gut, das klingt erstmal gut. Welche Plugins sind das und welches Theme verwendest Du? Sind die Plugins tatsächlich alle auch auf dem Server aktiv? Gibt es in der lokalen Installation im Wurzelverzeichnis eine Datei my-hacks.php und hast Du die ggf. auch auf den Server kopiert?

Du schreibst, "und die DB mit den Hoteldaten", also liegen die Daten nicht in der Wordpress-Datenbank. Es muß also irgend etwas existieren, was die externe Datenbank in das System einbindet. Nur was?

Gruß
Ingo

Ich denke nicht, daß es ein Problem ist, wenn /page/ ohne Zahl einen Fehler 404 zurückgibt. Die Seite existiert nun mal nicht und sie ist ja auch nicht auf Deinen Seiten so verlink oder in der Sitemap vorhanden. Wenn Tools irgendwelche nicht vorhandenen Seiten "raten", dann ist das deren Problem.

Das /page/ ist schon wichtig, damit Wordpress erkennt, das es eine Folgeseite ist. Um Dein Beispiel mit dem Archiv aufzugreifen, /2012/2/ ist eben nicht die zweite Seite des Archives für 2012, sondern das Archiv für Februar 2012. Durch /2012/page/2/ ist für Wordpress aber eindeutig die Seite zwei erkennbar.

Gruß
Ingo

So, Mittagspause beendet. :-)

Die index.php des Themes ist nicht direkt aufrufbar, sondern wird von Wordpress nachgeladen. In der Richtung mußt Du nicht weiter probieren, das kann nicht funktionieren.

Meine nächste Frage, wie hast Du Wordpress bei Strato installiert? Per AppWizard?
Dann fehlen bestimmt noch Sachen von Deiner lokalen Wordpress-Installation, die für die Verarbeitung der Hotel-Daten zuständig sind. Nur der Datenbank-Import reicht da nicht aus.

Gruß
Ingo

Ja stimmt, ich sollte mich mal wieder meiner richtigen Arbeit zuwenden... :-)

Gruß
Ingo

Hast Du alle Wordpress-Daten der lokalen XAMPP-Installation auf den Webspace bei Strato kopiert?
Wenn es lokal schon funktioniert hat, sollte es auch auf dem Server gehen, wenn tatsächlich alle Dateien und die Datenbank 1:1 übertragen wurden. Allerdings müssen ggf. einige Anpassungen vorgenommen werden.

Gruß
Ingo

Sorry Frank, da mußte ich erst noch drauf antworten.

Jetzt zum Thema. Es gibt Themes, die fassen Artikel mit dem selben Datum zusammen und geben es nur einmal beim ersten Artikel eines bestimmten Datums aus. Also bei alle Artikel mit dem selben Datum wird das dann nicht mehr angezeigt. Quasi eine Anzeigegruppierung nach Datum.

Gruß
Ingo