Ostalada (Créer un compte)

Bonjour à tous,

Après réflexion, le mieux était à coup sûr d’utiliser le drag and drop natif de Gutemberg. Et donc de concevoir deux custom blocks. Un block parent et un block enfant. Le bloc parent possède un innerBlock qui ne peut recevoir que des blocks enfants. Voici le code simplifié.

block.json du parent

{
	"$schema": "https://schemas.wp.org/trunk/block.json",
	"apiVersion": 2,
	"name": "domain/vegetables",
	"version": "0.1.0",
	"title": "Vegetables",
	"category": "text",
	"icon": "carrot",
	"description": "A sortable list of vegetables",
	"supports": {
		"html": false
	},
	"editorScript": "file:./index.js",
	"editorStyle": "file:./index.css",
	"style": "file:./style-index.css"
}

index.js du parent

import { registerBlockType } from "@wordpress/blocks";
import metadata from "./block.json";
import { useBlockProps, InnerBlocks } from "@wordpress/block-editor";

registerBlockType(metadata, {
	edit: () => {
		const blockProps = useBlockProps();

		return (
			<div {...blockProps}>
				<InnerBlocks
					allowedBlocks={["domain/vegetable"]}
					template={[["domain/vegetable"]]}
				/>
			</div>
		);
	},

	save: (props) => {
		const blockProps = useBlockProps.save();

		return (
			<div {...blockProps}>
				<InnerBlocks.Content />
			</div>
		);
	},
});

block.json de l’enfant

{
	"$schema": "https://schemas.wp.org/trunk/block.json",
	"apiVersion": 2,
	"name": "domain/vegetable",
	"version": "0.1.0",
	"title": "Vegetable",
	"category": "text",
	"icon": "carrot",
	"parent": ["domain/vegetables"],
	"description": "A vegetable",
	"supports": {
		"html": false
	},
	"attributes": {
		"name": {
			"type": "string"
		}
	},
	"editorScript": "file:./index.js",
	"editorStyle": "file:./index.css",
	"style": "file:./style-index.css"
}

index.js de l’enfant

import { registerBlockType } from "@wordpress/blocks";
import metadata from "./block.json";
import { useBlockProps, RichText } from "@wordpress/block-editor";

registerBlockType(metadata, {
	edit: (props) => {
		const blockProps = useBlockProps();
		const {
			attributes: { name },
			setAttributes,
		} = props;

		return (
			<div {...blockProps}>
				<RichText
					{...blockProps}
					tagName="p"
					value={name}
					allowedFormats={[]}
					onChange={(name) => setAttributes({ name })}
					placeholder={"A vegetable..."}
				/>
			</div>
		);
	},

	save: (props) => {
		const blockProps = useBlockProps.save();
		const {
			attributes: { name },
		} = props;

		return (
			<div {...blockProps}>
				<p>{name}</p>
			</div>
		);
	},
});

Bonjour Li-An,

Et merci pour ce message. Oui, je me doutais bien que j’allais en territoire obscur. Je défriche.

Je viens à l’instant de trouver la source du problème. Alors si vous rencontrez le même (et si un dev WP core passe par là pour capter la doléance), voici ce qui se passe pour moi. En réalité l’export fonctionne mais est extrêmement long. Comme il n’y a aucun message qui indique qu’il est en cours, je quittais la page avant la fin. Il est extrêmement long car j’ai un dossier node_modules issu de nodeJS qui pèse son poids dans mon thème en développement. Notamment car j’ai développe des block Gutemberg personnalisé au sein de mon thème, via la librairie officielle create-block qui a besoin de NodeJS.

Mais même si j’attends suffisamment pour que l’export se finissent, le dossier zippé qui en résulte n’est pas dézipable. J’obtiens le message suivant « Impossible de décompresser ‘nom-du-theme’. Le format n’est pas pris en charge ». Je vais donc supprimer ce dossier node_modules dès que je vais avoir besoin d’exporter mon thème et je le régénérerai juste après.

Compère développeur WP core, il serait bien d’ajouter un hook ou un filtre pour pouvoir exclure des fichiers ou dossiers de l’export, au meme titre qu’un gitignore. Et pour les développeur qui souhaite aussi créé un thème FSE avec des blocks Gutemberg, je peux vous conseiller pour le moment de passer les blocks dans un plugin. Vous séparerez ainsi thème et blocks et l’export devrait fonctionner.

Bonne journée,
Ostalada

Bonjour à tous,

Et merci pour vos réponses @ferman et @Lumière de Lune. Je viens le tête basse car j’ai résolu mon problème en faisant ce que j’aurais dû faire avant de poster ce topic, à savoir commenter un par un mes hook et filtres et ainsi détecter un potentiel souci par discrimination. Le souci venait d’une mauvais priorité de filtre.

@ferman : Les common fixes ne m’ont donc été d’aucune utilité mais ils pourraient servir à une autre personne qui lit ces lignes.

@Lumière de Lune : Mes limites de php.ini était largement au-dessus. Mais, de même, si vous lisez ces lignes car vos uploads échouent, n’hésitez pas à tester avec des fichiers moins lourds et vérifier la limite d’upload de votre serveur. Cela se trouve dans un fichier php.ini. Vous trouverez de nombreux tuto.

Merci encore !

Ok, merci pour vos réponses.

@Lumiere de Lune, pour te répondre : un client a installé un plugin retina qui fait automatiquement une copie retina en ajoutant le fameux suffixe @2x avant l’extension. Pour x raisons, il souhaite ne plus utiliser ce plugin et internaliser le processus au thème. Mais il souhaite quand même avoir des images retinas via un système de srcset et avec le même principe de naming.

Je tentais donc de reproduire le système. Si je reprends l’exemple du topic.

1. Pour un format définis comme ceci add_image_size('custom-size', 120, 120)
2. Je créé un autre format add_image_size('custom-size-2x', 240, 240)
3. Avec le filtre, si j’uploadais une image hello-world.jpg, on aurait obtenu hello-world-120-120.jpg et hello-world-120-120@2x.jpg
4. Puis j’aurais affiché comme ceci

   <img src="hello-world-120-120.jpg" srcset="hello-world-120-120@2x.jpg 2x">

Mais je vais devoir certainement faire autrement.
Merci encore.

• Cette réponse a été modifiée le il y a 3 années et 2 mois par Ostalada.
• Cette réponse a été modifiée le il y a 3 années et 2 mois par Ostalada.
• Cette réponse a été modifiée le il y a 3 années et 2 mois par Ostalada.