Home Polylang Filtra le prime pagine dei post WP nel loop con Polylang

Filtra le prime pagine dei post WP nel loop con Polylang

416
0

Requisiti: più editor, più lingue

Requisito : desidero fornire l’editor a blocchi di WordPress per la modifica delle pagine, a meno che non sia la prima pagina. (La prima pagina ha un design e un contenuto personalizzati utilizzando campi e tipi di post personalizzati.)

Requisito aggiuntivo : esiste più di una lingua, quindi più di una prima pagina, quindi non possiamo semplicemente confrontare i post correnti IDcon quelli get_option( 'page_on_front' ))nel backend.

Utilizzo dell’editor di blocchi Gutenberg in base ai tipi di post

In base ai tipi di post o di pagina, possiamo aggiungere un filtrofunctions.php

/* use block editor only for page type "page" */
add_filter('use_block_editor_for_post_type', function (
  $useBlockEditorForPost,
  $post
){
  if ($post->post_type === 'post') return false;
  if ($post->post_type === 'story') return false;
  return $useBlockEditorForPost;
},
  /** @var int $priority */ 10,
  /** @var int $accepted_args */2
);

Escludere la home page o la prima pagina?

Home page e prima pagina

Una home page predefinita di WordPress è una pagina che visualizza gli ultimi post del blog. Possiamo configurare il nostro sito per mostrare invece una pagina WordPress statica che può anche essere una home page. Possiamo anche fornire un modello HTML personalizzato chiamato front-page.php(secondo la gerarchia dei modelli nel manuale “Codex” di WordPress).

Ma dovremmo usare is_home()o is_front_page()per verificare se una pagina è una home page, o qual è la migliore pratica corretta nel mio caso, per estendere la mia funzione di filtro e disattivare l’editor a blocchi durante la modifica della home page.

Esiste un filtro più generale chiamato use_block_editor_for_postche non è limitato al tipo di post. Anche facile da scoprire: is_home()e is_front_page()non funziona per il post corrente all’interno di un ciclo, almeno non senza fornire un ID post. Senza alzare lo sguardo, proverei uno $post->is_front_page()o l’altro is_front_page($post->ID)?

add_filter('use_block_editor_for_post_type', function (
  $useBlockEditorForPost,
  $post
){
  if ($post->post_type === 'post') return false;
  if ($post->post_type === 'story') return false;
  if (is_front_page($post->ID)) return false;

Vabbè, ok, dopo aver provato e letto circa 10 o 20 oscure discussioni di domande e risposte su StackExchange, trovo un altro approccio:

get_option(‘pagina_sul_fronte’)

 if ($post->ID && 
      $post->post_ID > 0 && 
      $post->ID === (int) get_option( 'page_on_front' )
     ) return false;

Anche se funziona, come dovrebbe restituire più di un ID post se utilizzato su una pagina di amministrazione? Ricordando le mie esigenze: in uno scenario multilingue localizzato, ho tante prime pagine quante sono le lingue.

Il Loop rispetto alla Query corrente

Molte funzioni core integrate di WordPress come is_home()o is_front_page()presumono che vogliamo verificare le proprietà del post corrente (o della pagina), implicitamente disponibili in un contesto globale o all’interno di un loop (o meglio THE Loop ) dopo la chiamata the_posto come viene chiamato. Ci sono alcune coppie di funzioni getter “tipiche” come the_title()e get_the_title($post_ID)dove la prima stampa il titolo del post corrente su stdout, mentre solo la seconda accetta un opzionale IDe può essere assegnata a una variabile, ma molti built-in booleani non hanno controparti ufficiali che accettano un ID e può essere utilizzato all’interno di un ciclo personalizzato.

Conclusione: come verificare se la pagina corrente (all’interno di un ciclo multilingue) è la prima pagina in WordPress

O, più tecnicamente parlando, come filtrare WP_Postper proprietà is_front_page()nel ciclo con Polylang o, come vedremo, come farlo senza utilizzare is_front_page()affatto.

Sulla base di un’altra risposta StackOverflow , possiamo eseguire l’iterazione su tutte le lingue e confrontare ciascuna prima pagina localizzata con la pagina corrente.

Ingenuo, pragmatico e incurante delle prestazioni (almeno nel backend o se è memorizzato nella cache)

Ingenuo e pragmatico, so che sul mio sito web ci sono solo due lingue, quindi iniziamo con un array codificato e concentriamoci sulla nuova funzione e scopriamo se funziona.

Non mi interessa nemmeno le prestazioni, perché è nel backend di amministrazione e, se così non fosse, non mi importerebbe neanche perché mi assicuro comunque di memorizzare nella cache i risultati dell’elaborazione sovraingegnerizzata in modo che i visitatori della mia pagina ottengano una pagina Web HTML statica dalla cache rapidamente, a meno che non abbiamo effettivamente bisogno di qualcosa che non possa essere memorizzato nella cache, come i dati personalizzati per gli utenti che hanno effettuato l’accesso.
Quindi le home page sono:

English : https://www.example.com
French  : https://www.example.com/fr/accueil/
Spanish : https://www.example.com/es/inicio/

È possibile ottenere l’URL della home page di una lingua selezionata?

Quando copio il codice dalla risposta accettata, sento già di essere solo a metà strada, poiché non si chiama pll_home_pagebut pll_home_url. Facciamo semplicemente eco ai valori e vediamo dove andare da lì.

// (string) pll_home_url(  $lang = '' );
'home url en: .pll_home_url('en');
echo 'home url de: pll_home_url('de');

Se non utilizziamo return falsela nostra funzione di filtro, la SPA JavaScript di Gutenberg nasconderà il nostro messaggio di eco, ma potremo comunque trovarlo controllando l’origine della pagina:

Eccoli:

</pre>
<pre class="highlight plaintext"><code>home url en: http://bs-local.com:1234/homepage/
home url de: http://localhost:1234/</code></pre>
<pre>

Sembra un po’ inaspettato ma è corretto. Dato che il tedesco ( 'de') è stato impostato come lingua predefinita e le mie impostazioni del permalink omettono qualsiasi altra cosa tranne il titolo della pagina, l’URL della home page inglese non contiene ab /en/slug. Quindi possiamo confrontare l’URL della pagina corrente (o, tecnicamente parlando, il permalink del post corrente ) con le varianti linguistiche conosciute?

echo post permalink: get_permalink($post->ID());

e quando corrisponde, restituisce false per disabilitare l’editor di blocchi.

add_filter('use_block_editor_for_post', function (
  /** @var bool */ $useBlockEditorForPost,
  /** @var WP_Post */ $post
){
  if ($post->post_type === 'post') return false;
  if ($post->post_type === 'story') return false;
  $languages = pll_languages_list();
  foreach ($languages as &$language) {
    if (get_permalink($post->ID) == pll_home_url($language))
      return false;
  }
  return $useBlockEditorForPost;
},
  /** @var int $priority */ 10,
  /** @var int $accepted_args */2
);

Infine, utilizziamo le lingue attuali in modo che il nostro tema funzioni ancora quando il proprietario del sito desidera aggiungere una terza lingua. Possiamo usare pll_languages_listla funzione di Polylang.

Funzione filtro finale: use_block_editor_for_post

Ecco la mia functions.phpfunzione di filtro finale per mantenere abilitato l’editor di blocchi per le pagine ad eccezione delle prime pagine in qualsiasi lingua e ad eccezione dei post e dei miei tipi di post personalizzati:

add_filter('use_block_editor_for_post', function (
  /** @var bool */ $useBlockEditorForPost,
  /** @var WP_Post */ $post
){
  if ($post->post_type === 'post') return false;
  if ($post->post_type === 'story') return false;
  $languages = pll_languages_list();
  foreach ($languages as &$language) {
    if (get_permalink($post->ID) == pll_home_url($language))
      return false;
  }
  return $useBlockEditorForPost;
},
  /** @var int $priority */ 10,
  /** @var int $accepted_args */2
);

Questo bloccherà l’editor a blocchi per le prime pagine ma potremo comunque usarlo su qualsiasi altra pagina.

Personalizzazione degli stili e delle barre degli strumenti dell’editor classico

Possiamo anche personalizzare l’editor classico ( tinyMce ), aggiungere stili dell’editor ( add_editor_stylein admin_initun’azione) e nomi di classi (in JavaSript: acf.add_filter( 'wysiwyg_tinymce_settings') e personalizzare le barre degli strumenti dell’editor classico (in PHP: add_filter('acf/fields/wysiwyg/toolbars') per rendere facile e sicura la modifica da parte dei proprietari di siti web. il contenuto del loro sito quando si utilizza un tema WordPress ibrido (modifica classica + modifica a blocchi, come ho spiegato in un post precedente sui temi classici con schemi a blocchi in WordPress nel 2023.

Previous articleCambio del placeholder image woocommerce
Next articleSessioni PHP: cosa sono e come funzionano

LEAVE A REPLY

Please enter your comment!
Please enter your name here