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 ID
con 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_post
che 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_post
o 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 ID
e 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_Post
per 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_page
but 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 false
la 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_list
la funzione di Polylang.
Funzione filtro finale: use_block_editor_for_post
Ecco la mia functions.php
funzione 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_style
in admin_init
un’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.