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 erstellenWarum schreibst Du den Titel denn nochmal in den Content?
Die Klasse [FONT=courier new].entry-title[/FONT] wird in Themes oft auch für die Auszeichnung strukturierter Daten verwendet, schau Dir mal ein paar WordPress-Seiten hiermit an: search.google.com/structured-data/testing-tool
Die Seite verwendet ein sog. Grid. Der Container der Beiträge und die Beiträge selbst sind durch enspr. Klassen auf das aktuell angezeigte Layout (mit eigentlich einem Sidebar) abgestimmt. Man müsste daher die Klassennamen im generierten HTML-Code anpassen.
Beispiel: col-md-12 entspricht der vollen Breite, der Container hat aber nur col-md-8. Die Beiträge haben mehrere Klassen bzgl. der Breite, die sich allerdings widersprechen, da wurde vermutlich schon daran gebastelt.
Wahlweise benutze die lokale Datenbank in XAMPP.
Um die 1&1 Installation komplett zu XAMPP zu übertragen, benutze in der 1&1 Installation ein Plugin wie Duplicator und installiere das Paket dann in XAMPP, siehe auch Video auf der Plugin-Seite. Das Plugin sorgt autom. für alle nötigen Anpassungen in der Datenbank.
Frage 1 löst sich von selbst, wenn man darauf achtet, dass der PHP-Quelltext im Editor "UTF-8 encoded" ist/bleibt.
Füge eine body_class (im Frontend, da der auf dem Bild sichtbare Adminbar im Frontend gezeigt wird) hinzu, wenn eine Deiner gewünschten Rollen angemeldet ist und blende dann den "linken" Teil des Adminbars via CSS aus, in etwa so:
body.meine-besondere-usergroup #wp-admin-bar-root-default {
display: none;
}Du könntest ein Plugin wie z.B. Antispam Bee verwenden.
gibt es irgendwelche fallen, die ich beachten sollte?
WordPress nutzt keine index.html, daher auf ..meinedomain.de/projekt/ verlinken.
Und ich bin mir eigentlich ziemlich sicher, dass das auch möglich ist.
Bin mir auch sicher, dass man das in der bestehenden Installation beheben könnte. Bei der Nutzung von "W3 Total Cache" kommt es oft zu solchen Neben/-Nachwirkungen, wenn das Plugin nicht (wie von danielgoehr im anderen Thread beschrieben) sauber entfernt wird.
Man könnte das z.B. über ein Custom Field lösen. ..
Oder über ein eigenes Post-Format, dieses WordPress-Feature ist eigentlich für sowas gedacht.
Normalerweise würde man das in "Einstellungen -> Lesen -> Blogseiten zeigen maximal X Beiträge" einstellen, geht das nicht?
Bei einem Filter wie diesem sollte man wissen, dass die $route nicht case-sensitive ist, d.h. der in #29 gepostete Filter lässt sich durch z.B. ein grosses U in users o.ä. umgehen.
[FONT=courier new]/wp-json/wp/v2/users[/FONT] -> forbidden
[FONT=courier new]/wp-json/wp/v2/Users[/FONT] -> Benutzerliste
Als Plugin sollte man das [FONT=courier new]add_shortcode()[/FONT] noch in eine [FONT=courier new]init[/FONT] action verpacken, mehr dazu hier unter "In a Plugin".
Ein [FONT=courier new]?>[/FONT] am Ende sollte man weglassen, mehr dazu hier bei Google.
Was gibt wo keinen Unterschied?
Der $deps Parameter für [FONT=courier new]wp_enqueue_script()[/FONT] lautet wie in der Dokumentation beschrieben [FONT=courier new]array( 'jquery' )[/FONT]
Wo auf dem Server befindet sich die Datei [FONT=courier new]cookie_setzen.php[/FONT] ? Wird die gefunden?
Die Variable kommt in PHP als [FONT=courier new]$_POST[/FONT] an und nicht als [FONT=courier new]$POST[/FONT]
Eine sehr einfache Lösung ohne manuelle Eingriffe in die Datenbank ist die Nutzung des Plugins Duplicator auf der Testdomain und das Einspielen des Installationspaketes auf der neuen Domain, siehe Video auf der Plugin-Seite.
Wenn man einen redirect wie in der Dokumentation macht, kann das nicht sein.
Poste doch mal Deinen Code.
Probiere es mal mit template_redirect.
Falls es nicht am Browser-Cache liegt, setze den neuen Pfad zur Installation manuell in der wp-config.php, ähnlich wie bei diesem Problem.
WordPress lädt jQuery automatisch selbst, wenn man beim Einbinden eigener Scripts über den Parameter $deps mitteilt, dass ein Script das benötigt.
Was postest Du denn mit jQuery.post() wo genau hin?
Die Frage ist warum will man die REST-API still legen?
Vielen gefällt die Ausgabe der Benutzernamen über die REST-API via /wp-json/wp/v2/users nicht so sehr. Das wird dann oft (wie auch auf Deinem Website?) durch ein generelles Abschalten der REST-API "behoben",
Das führt dann wiederum (u.a.) zu den aktuellen Effekten mit CF7 oder anderen Plugins mit REST-API Endpoints, wobei natürlich auch das magelhafte Error-Handling bei CF7 zu Unsicherheiten bzgl. der Ursache beiträgt, da sich zig. Probleme einfach nur durch "Sende-Icon dreht sich endlos" zeigen, anstelle im Client-JavaScript die HTTP-Header Codes der Antwort sauber auszuwerten und entsp. zu reagieren.
Falls es Mitlesern nicht bekannt sein sollte: Seit einiger Zeit können auch diverse "Sicherheits"-Plugins wie WordFence, iThemes o.ä. nur diese Ausgabe der Benutzer deaktivieren und den Rest aktiv lassen, mehr dazu z.B. hier.
Oder gibts nen anderen Lösungsweg?
Schau Dir die .htaccess Datei beim Auftreten des Fehlers an und nach dem Speichern der Permalinks. Wenn sich der Inhalt unterscheidet, könnte man daraus ableiten, woher die eigentliche Ursache kommt.
