Beiträge von mensmaximus

Alles was Du brauchst steht im Handbuch: https://make.wordpress.org/core/handbook/…-standards/php/

Zitat von b3317133

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.

Korrekt! Deswegen muss natürlich ein Sanitizing statt finden, ebenso wie die Erweiterung um zusätzliche Endpoints.

REST APIs gehören heute zu jeder vernünftigen Applikation. WordPress macht da keine Ausnahme. Niemand behauptet die REST API wäre ausgereift und gerade das Thema Authentifizierung wird immer wieder heiß diskutiert. Jeder ist im Übrigen herzlich eingeladen im Slack in den jeweiligen Kanälen mit zu diskutieren. Auch ich bin ein Vertreter der Position, dass anonyme Anfragen an die API explizit frei gegeben werden sollten, mit Ausnahme der Anfragen die zum gleichen Ergebnis führen wie ein Webseitenaufruf. D.h. Posts und Pages soll man anonym erreichen können.

In der Zwischenzeit gibt es zahlreiche Filter die man verwenden kann. Das Entfernen von Endpunkten, wie oben dargestellt, ist eine Möglichkeit. Allerdings steht der Endpunkt dann auch nicht mehr für Anwendungen zur Verfügung. Besser ist das gezielte Filtern der Anfragen mit eigenen Bedingungen, wie z.B.

add_filter( 'rest_request_before_callbacks', 'rest_users_endpoint_permission', 10, 3 );
function rest_users_endpoint_permission( $response, $handler, $request ){
    $route = $request->get_route();
    if( '/wp/v2/users' == $route && empty( $request['roles'] ) ) {
        $response = new WP_Error( 'rest_forbidden', __( 'Sorry, you are not allowed to do that.' ), array( 'status' => 403 ) );
    }


    return $response;
}

Das Bedingungswerk kann man dann beliebig erweitern. Man kann auch nur Anfragen zulassen die bestimmte Parameter enthalten oder von bestimmten Hosts kommen.

Zitat von Babelfisch

Du kannst nicht einfach sagen, dass post_type von WordPress kommt und deshalb nicht von CRUD erfasst werden muss.

Das sage nicht ich sondern die Entwickler von WooCommerce. Wenn Du Dich mit der Entwicklung auskennst frage ich mich was Dein Thread hier soll? Zu faul zum Suchen? Du fragst nach Dingen die für einen Entwickler nach 15 Minuten Studium des zurück gegebenen Objekts, der zuständigen Klasse(n) und der CRUD Dokumentation klar sind. Gleichzeitig meckerst Du über die Umsetzung. Das darfst Du gerne machen aber dann mach es an der richtigen Stelle -> https://github.com/woocommerce/woocommerce.

Ach ja, ich habe gern geholfen. Nichts zu danken!

Imho ist Euer Denkansatz falsch. Die REST API ist nun wesentlicher Bestandteil (Core) von WordPress und Matt Mullenweg selbst war es, der die Entwickler (Plugins/Themes) dazu angeregt (um nicht zu sagen aufgefordert) hat, die REST API zu nutzen. Ob es klug ist ein Plugin ausschließlich auf die REST API zu stützen sei dahin gestellt und ist dem Entwickler überlassen. Das ändert in keinem Fall etwas daran, dass eine Deaktivierung der API ebenso wie (früher) der XML-RPC Schnittstelle zu Verlusten in der Funktionalität von WordPress führt.

Die Frage ist warum will man die REST-API still legen? Dann kann man überlegen ob es Alternativen zum Erreichen des Ziels gibt. Ich war noch nie ein Freund von CF7, würde aber per se nicht so weit gehen CF7 ob der REST-API Thematik an den Pranger zu stellen. Mit Ninja Forms oder Formidable stehen hervorragende Plugins zur Verfügung, suchen muss man also nicht wirklich.

Du wirfst die Dinge durcheinander. Die PHP Klasse definiert in WooCommerce die Eigenschaften des Objekts. Die Objekte können z.B. die Posttypes sein, die WooCommerce erstellt. Die Tatsache, dass es Posttypes gibt ist und bleibt Sache von WordPress. Am besten Du liest Dich in das Thema mal gründlich ein.

Der Post Type ist eine "Sache" von WordPress und nicht von WooCommerce. WooCommerce erstellt die Post Types aber WordPress implementiert das Objekt. Daher ist der Post Type nicht Bestandteil der WooCommerce CRUD Klassen.

$cartItem['data']->get_id()

Zitat von Babelfisch

Da hat man also CRUD noch nicht implementiert.

Es geht NICHT um den Inhalt des Warenkorbs per se, sondern um die Eigenschaften der darin enthaltenen Produkte. Diese - die Eigenschaften der Produkte - müssen über die CRUD Klassen abgefragt werden.

Da es sich nicht um eine WordPress Problem handelt, schlage ich vor Google zu bemühen: http://bfy.tw/DO3m

z.B. https://mihajlovicnenad.com/product-filter/

Weil Apple immer sein Ding macht und der Safari immer noch viele CSS Regeln nicht versteht.

evtl. https://de.wordpress.org/plugins/breadcrumb-navxt/

Installiere Chrome und lass den Safari in Frieden ruhen.

Das Core Bundle ist kostenpflichtig, entsprechend bitte an den Hersteller wenden: https://wpjobmanager.com/support/

Du kannst z.B. mit Enfold beliebig viele horizontale und eigenständige Menüs anlegen. Vertikale Menüs kannst Du mit dem WordPress Menu-Widget umsetzen

Bevor die Seite nicht repariert ist (Layout fehlerhaft, da die SSL Einrichtung fehlerhaft ist: https://www.schindel24.de/produkt-katego…small-1-rechts/) macht es wenig Sinn sich um eine Nebensache zu kümmern.

Zitat von Isabel

Also habe ich auch bei einer Multisite nicht nur einen Bestellvorgang, sondern jeder Woocommerce funktioniert für sich allein?

Ja, das ist die Standard Funktionsweise. Das Plugin https://wooglobalcart.com/ ermöglicht angeblich einen 'unified checkout' für WooCommerce in einer Multisite. Ich habe es weder getestet noch liegen mir Erfahrungsberichte aus erster Hand vor. Welche Plugins unterstützt werden und wie zuverlässige es funktioniert wird man selbst testen müssen. Aber möglicherweise ist es das, was Du suchst.

Das ändert nichts. Jeder Shop bleibt eigenständig.

Das geht so nicht.