[Gelöst] Mehrere Translation Ids abrufen wie mit wp_prime_option_caches() & get_options()

Hallo WPML-Team.

Sagen Sie uns, was Sie versuchen zu erreichen?
Ich benötige an einigen stellen die originale object_id eines Elements.
z.B. möchte ich folgenden Filter nutzen:
- nav_menu_css_class

Ziel ist es, einen Menüpunkt mit einer speziellen CSS-Klasse besonders hervorzuheben.
Aktuell muss ich für jede Sprache eine eigene CSS-Regel bauen, weil sich die IDs von Seiten/Beiträgen, etc. von Sprache zu Sprache unterscheiden.

menu-item-123, /* DE */
menu-item-456, /* EN */
menu-item-789 /* FR */ {
/* ... */
}

Das Beispiel wird natürlich mit jeder weiteren Sprache immer schlimmer.

Auch an anderen Stellen ist es ineffizient. z.B. bestimmte CSS-Regeln anhand der body-class "page-id-*" anwenden.
Auch hier muss ich mehrere Regeln schreiben, um ein styling über mehrere Sprachen hinweg synchron zu halten.

Damit ich die CSS-Regeln nicht mehrfach schreiben muss, möchte ich nun die originalen ids, in unserem Fall deutsche Sprache, in die CSS-Klassenliste mit aufnehmen.
Damit kann ich ganz einfach alle Sprachen ansprechen.

myprefix-menu-item-object-id-DE--123 {
/* ... */
}

Aktuell nutze ich folgenden Code, um eine id in der Originalsprache von unserem Shop zu erhalten:

myprefix_get_id_DE($id, $post_type = 'page') {
	if (myprefix_is_wpml_active()) {
		$id = apply_filters('wpml_object_id', $id, $post_type, TRUE, 'de');
	}
	return $id;
}

Damit kann ich arbeiten.

Schön wäre nun, wenn ich alle DE-ids der Menü-Elemente mit einmal abrufen kann.
Anschließend kann ich meine Berechnungen machen.
Das sollte zahlreiche DB-Queries sparen.

Ich fände etwas Richtung "wp_prime_option_caches" gut, um meine bald benötigten IDs anzukündigen - https://developer.wordpress.org/reference/functions/wp_prime_option_caches/.

Um bei eurem hook/filter-Ansatz zu bleiben:

do_action('wpml_prime_object_id_caches', int $element_id, string $element_type, mixed $ulanguage_code );

Wenn ich die nächste ID abfrage, könnte unter der Haube eine db query laufen, die alles angekündigte abruft und mir lediglich die eine, in diesem Moment angefragte, ID zurückgibt.

// user code

$required_ids = [123,456,789];
foreach($required_ids as $required_id) {
  do_action('wpml_prime_object_id_caches', $required_id, 'page', 'de' );
}

// later...
$id = apply_filters('wpml_object_id', 123, 'page', TRUE, 'de'); // query all "registered" ids from db


// later #2...
$id = apply_filters('wpml_object_id', 123,456,789, 'page', TRUE, 'de'); // load from wpml cache - no db query required since db was queried before



// wpml internal code

add_action('wpml_prime_object_id_caches', function(int $element_id, string $element_type, mixed $ulanguage_code ) {
  // add to internal object_id fetch queue if requested element was not fetched before
});

add_filter('wpml_object_id', function(int $element_id, string $element_type, bool $return_original_if_missing,mixed $ulanguage_code) {
  // maybe add to queue

  // execute queue - fetch all items in one db query if possible

  // return requested object_id - do not change return behaviour of existing filter
});

Alle folgenden Nutzungen von apply_filters('wpml_object_id',..); könnten dann auf den Cache zurückgreifen und lösen keine separaten DB-queries mehr aus, sofern die id bereits abgefragt und intern gecached wurde.

Als nette utiliity-Funktion könnte etwas wie get_options() noch oben drauf wandern - https://developer.wordpress.org/reference/functions/get_options/.

$result = apply_filters('wpml_object_ids', [
  123 => [
    'element_id' => 123 ,
    'element_type' => 'page', //optional 
    'lang_code' => 'de', //optional
    'return_original_if_missing' => true //optional
  ]
]);

WPML könnte in diesem Szenario das array so zurückgeben, wie es bereitgestellt wurde.
Alles Keys legt der user fest und werden nicht verändert, damit user die größte Freiheit haben, ihre Daten zu arrangieren.
Lediglich die Eigenschaft "element_id" wird verändert zurückgegeben.
(Evtl. macht es sinn, das array und seine verschachtelten Kinder via spread-operator zu "kopieren" und ohne Referenz zum Original zurückzugeben, um unerwünschte Nebeneffekte bei php-usern, die ggf. input und ouput-array vergleichen wollen, zu reduzieren?)

Falls euch das Beispiel mit Inspiration von wp_prime_option_caches() nicht gefällt, dann wäre zumindest etwas wie get_options() wünschenswert für object_ids.
Dann kann ich als user an einer Stelle gebündelt object_ids abrufen und effizient mit dem Ergebnis arbeiten statt zahlreiche einzelne db queries anzustoßen, weil ich den wpml_object_id-Filter, so wie es jetzt ist, mehrfach nutzen müsste.

Grüße