האצת וורדפרס על ידי חיתוך אימוג'ים ו-wp-embed

אם אתה רואה wp-emoji-release.min.js et wp-embed.min.js במבט לאחור על דוחות Lighthouse או PageSpeed ​​שלכם, אתם לרוב משלמים עבור כמה בקשות ו-JavaScript... עבור תכונות שאתרי בלוגים רבים לעולם לא משתמשים בהן.

---

בעיית הביצועים

על וורדפרס 6.9.4 (אפריל 2026), שני תסריטים "היסטוריים" מופיעים לעתים קרובות שוב בביקורות:

• אימוג'ים של וורדפרס : קבוצה של ווים (hooks) שמוסיפים סקריפטים/סגנונות ומסננים (המרת תווים, זיהוי וכו'). בבלוג טיפוסי, זה לעיתים רחוקות חיוני.
• wp-embed : הסקריפט הקדמי שמאפשר פונקציונליות מסוימת שלoEmbed (אינטגרציות ו-"embeds" עם וורדפרס). אם אינכם משלבים תוכן חיצוני (יוטיוב/טוויטר/אינסטגרם...) באמצעות כתובת URL פשוטה, או אם בונה העיצוב/עמודים שלכם אינו מסתמך על זה, זה לרוב חסר תועלת.

הרווח אינו "קסום": אנחנו מדברים יותר על צמצום מספר הבקשותשל ג'אווהסקריפט לניתוח ולפעמים בכמה מילישניות על ה INP (אינטראקציה עם הציור הבא) ו- LCP תלוי במכשיר. אבל בנייד, ראיתי לעתים קרובות את הרווחים הקטנים האלה מצטברים כאשר ה- אתר כבר טעון בסקריפטים (Divi Elementor, Avada, ניתוח נתונים, פיקסלים...).

נקודה זו חשובה למתחילים: PageSpeed/Lighthouse לעיתים רחוקות מענישים "wp-embed" בפני עצמםזה מעניש אותך על "תקציב JS" גבוה מדי. הסרת 10-30 KB פה ושם יכולה להספיק כדי לרדת מתחת לספים מסוימים, במיוחד בטלפונים ברמת כניסה (מעבד איטי + רשת לא יציבה).

מציאות נוספת בשטח: תסריטים אלה נוכחים לעתים קרובות בכל העמודים (דף הבית, ארכיון, דפים, מאמרים), בעוד שאתה משתמש בתכונה רק ב 2% מהאתרזהו בדיוק סוג האופטימיזציה "הפשוטה" שהגיונית.

השפעה קונקרטית:

• קידום אתרים : מדדי ליבה יציבים יותר של Web Vitals (פחות JS מיותר).
• שיעור יציאה מדף הכניסה אתר שמגיב מהר יותר בנייד שומר על יותר קוראים.
• ניסיון פחות סקריפטים = פחות סיכון להתנגשויות ב-JS.

בסופו של דבר, תדעו:

• מדוד את נוכחותם של סקריפטים אלה באמצעות קוד (Sans צילום מסך),
• להשבית אותם כראוי באמצעות תוסף mu (תוסף "חובה לשימוש", נטען אוטומטית),
• בדוק שלא שברת שום דבר (הטמעות, עורך, בוני דפים).
• לכמת את הרווח (שאילתות, גודל, תזמונים פשוטים).

סיכום קצר

• כבה את האימוג'ים על ידי הסרת פעולות/מסננים ליבה + הימנעות מאחזור ה-DNS המשויך.
• השבת את wp-embed רק אם אינך משתמש ב-oEmbed בחזית.
• תעשה את זה בתוסף mu (אמין יותר מ-functions.php, במיוחד עם Divi/Elementor/Avada).
• למדוד לפני/אחרי מספר סקריפטים, גודל HTML ותזמונים (תזמון שרת + יומני רישום).
• היזהרו ממאגרים נקה את מטמון הדף/CDN ואת מטמון הדפדפן לפני סיום.

אלטרנטיבה שימושית (לעתים קרובות הפשרה הטובה ביותר): השבתת wp-embed בכל מקום מלבד במאמרים או למעט ברשימת דפים. אחזור לזה מאוחר יותר עם קצת קוד.

מקרה קצה משותף: אם אתם נמצאים באתר רב-לשוני (WPML/Polylang) או עם אחסון מטמון אגרסיבי, בדיקות ה"לפני/אחרי" שלכם צריכות להתבצע על אותה כתובת URL, אותה שפהובאופן אידיאלי על ידי עקיפת המטמון (או על ידי ניקויו). אחרת, אתם משווים תפוחים לתפוזים.

קוד אבחון

תנאים מוקדמים :

• וורדפרס 6.9.4 +, PHP 8.1 +.
• גישה ל fichiers (FTP/SSH) או למנהל הקבצים של המארח.
• צרו גיבוי (קבצים + מסד נתונים) לפני ביצוע שינויים כלשהם. לעולם אל תשנו את ליבת וורדפרס.

היכן להדביק את הקוד (מומלץ)

אני ממליץ על א תוסף mu קובץ PHP שהונח ב wp-content/mu-plugins/יתרון: הוא נטען לפני תוספים רגילים ולא ניתן להשבית אותו בטעות מפאנל הניהול.

צור את התיקייה אם היא לא קיימת, לאחר מכן צור קובץ, לדוגמה:

wp-content/mu-plugins/perf-disable-emoji-embed.php

מקרה קצה: חלק משירותי האירוח ה"מנוהלים" נסגרים חלקית wp-contentאם אינך יכול ליצור mu-pluginsהשתמש בתוסף ספציפי לאתר (תוסף מותאם אישית) ב wp-content/plugins/זה קצת פחות חזק מתוסף mu, אבל אמין משמעותית יותר מ... functions.php.

הפעלת מצב ניפוי שגיאות נקי (מבלי לשבש את הייצור)

Un וו היא נקודת הארכה: a פעולה מבצע קוד, א מסנן משנה ערך. לצורך אבחון, אנו רוצים יומני רישום, לא שגיאות מוצגות.

Dans wp-config.php (באתר פעיל, הימנעו מהצגת שגיאות), תוכלו להשתמש ב:

<?php
// wp-config.php — Sauvegardez avant de modifier.
// Active le debug sans afficher d'erreurs aux visiteurs.
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_DISPLAY', false );
define( 'WP_DEBUG_LOG', true );

// Optionnel : log des requêtes SQL (peut ralentir, à activer temporairement).
// define( 'SAVEQUERIES', true );

היומנים ייכנסו לתוך wp-content/debug.log.

מניסיוני, הסיבה מספר אחת ל"אני לא רואה כלום ביומן" היא קובץ debug.log לא ניתן לכתיבה. בדוק במהירות את ההרשאות (או בדוק על ידי כתיבת error_log('test'); זְמַנִי).

מקור רשמי: ניפוי באגים בוורדפרס.

מדוד את נוכחות הסקריפטים (ממשק קצה) באמצעות "מונה" מיני

לפני שאני ממליץ על אופטימיזציה, אני רוצה הוכחה. הקוד למטה רושם:

• si wp-emoji-release נמצא בתור
• si wp-embed נמצא בתור
• רשימת הסקריפטים שהוכנסו בפועל לתור.

הדבק את הבלוק הזה לתוסף ה-mu שלך באופן זמני (תוכל להגיב עליו מאוחר יותר).

<?php
/**
 * Plugin Name: Perf — Désactiver Emojis & wp-embed
 * Description: Optimisations front (WP 6.9.4+) : emojis et wp-embed.
 * Author: Votre Nom
 */

if ( ! defined( 'ABSPATH' ) ) {
	exit;
}

/**
 * Log simple des scripts enqueued sur le front.
 * À activer temporairement : utile avant/après.
 */
add_action( 'wp_print_scripts', function () {
	if ( is_admin() ) {
		return;
	}

	// Évitez de spammer les logs : ne logguez que pour les admins connectés.
	if ( ! is_user_logged_in() || ! current_user_can( 'manage_options' ) ) {
		return;
	}

	global $wp_scripts;

	if ( ! $wp_scripts instanceof WP_Scripts ) {
		return;
	}

	$handles = $wp_scripts->queue;

	error_log( '--- PERF SCRIPTS (front) ---' );
	error_log( 'Total scripts enqueued: ' . count( $handles ) );
	error_log( 'wp-emoji-release present? ' . ( in_array( 'wp-emoji-release', $handles, true ) ? 'YES' : 'NO' ) );
	error_log( 'wp-embed present? ' . ( in_array( 'wp-embed', $handles, true ) ? 'YES' : 'NO' ) );
	error_log( 'Handles: ' . implode( ', ', $handles ) );
}, 999 );

הערה: אנו משתמשים wp_print_scripts לעדיפות גבוהה כדי לצפות בתור הסופי. אם תשימו זאת מוקדם מדי, אתם מסתכנים ב"מדידה" לפני שבונה העיצוב/הדפים הוסיף את הסקריפטים שלו.

מקרי קצה מרכזיים שכדאי להכיר:

• דפי AMP / מצב "אופטימיזציה" חלק מהתוספים של AMP משנים לחלוטין את אופן הטיפול בסקריפטים. במקרה זה, יומן זה עשוי להציג תור שונה (או ריק) עבור כתובות URL של AMP.
• מטמון הדף אם הדף שלך מוצג כ-HTML סטטי ללא וורדפרס פועל (מטמון של הדף המלא בשרת), קובץ יומן זה לא ייכתב מכיוון שוורדפרס אינו פועל. נסה לעקוף את המטמון (באמצעות הפרמטר "nocache", קובצי Cookie של מנהל מערכת ומטמון נקי).
• דחיפה של HTTP/2 / CDN זה נדיר בשנת 2026, אבל ישנן ערימות של ערימות (stacks) שמזריקות רמזים או סקריפטים. כאן אנחנו מודדים מה וורדפרס מזריקת, לא מה ה-CDN מוסיף.

צג שאילתות ו-WP-CLI (אבחון מהיר)

למתחילים, מעקב אחר שאילתה זוהי נותרה השיטה המעשית ביותר לצפייה בסקריפטים, ווים (Hooks), שאילתות ותזמונים. יש להתקין אותה ולאחר מכן להשבית אותה לאחר שתסיים (זה מוסיף תקורה של ניפוי שגיאות).

• צג שאילתות (wordpress.org)

אם יש לך WP-CLI:

# Vérifier versions (utile en dépannage)
wp core version
wp php version

# Lister les must-use plugins (pour vérifier que votre mu-plugin est bien chargé)
wp plugin list --status=must-use

# Vérifier que les permaliens et la config sont OK
wp option get permalink_structure

גרסה שימושית של WP-CLI לביצועים (כאשר אתם חושדים בתוסף):

# Voir les plugins actifs (et repérer les "gros" habituels)
wp plugin list --status=active

# Vérifier rapidement la taille de l'autoload (souvent cause de TTFB élevé)
wp db query "SELECT ROUND(SUM(LENGTH(option_value))/1024/1024,2) AS autoload_mb FROM wp_options WHERE autoload='yes';"

תשומת הלב השאילתה מניחה שקידומת הטבלה שלך היא wp_אם יש לך קידומת שונה, התאם אותה (wp-config.php → $table_prefix).

מקור רשמי של WP-CLI: פקודות WP-CLI.

יומן שאילתות איטי (כאשר האתר איטי בצד השרת)

השבתת אימוג'ים/wp-embed משפיעה בעיקר על ממשק המשתמש (בקשות + JS). אם שלך TTFB אם יומן הרישום גבוה, הפעל רישום שאילתות איטי עבור MySQL/MariaDB או PHP-FPM בצד השרת. אדון בצד השרת של הדברים בהמשך.

---

שלב 1: השבתת אימוג'ים של וורדפרס (ליבה)

הנה מה שקורה מאחורי הקלעים: וורדפרס מוסיפה פעולות ומסננים לניהול אימוג'ים, כולל:

• סקריפט חזיתי wp-emoji-release.min.js,
• מסננים על תוכן ודוא"ל,
• אחזור מקדים של DNS לקראת s.w.org (בהתאם לתצורה).

תרגום למתחילים: וורדפרס מנסה להפוך את האימוג'ים לעקביים בכל מקום, כולל בדפדפנים ישנים יותר. בשנת 2026, עבור רוב הקהלים, זה כמעט ולא הכרחי. לכן התועלת מינימלית, והעלות (גם אם קטנה) קבועה בכל העמודים.

לפני (איטי/מיותר): תן לליבה להפעיל הכל

"לפני" פירושו: אין קוד, ולכן וורדפרס טוענת את מה שהיא רואה לנכון. בבלוגים רבים, זהו שטח אחסון פנוי.

מקרה קצה: אם יש לכם קהל ארגוני המשתמש בדפדפנים ישנים יותר (אינטראנט, מסופים וכו'), תוכלו לבחור לשמור על תמיכה זו. במקרה זה, אל תשביתו אימוג'ים, או תשביתו את השליפה המוקדמת רק אם זו המטרה שלכם.

AFTER (ממוטב): הסרת פעולות/מסננים + אחזור מקדים

הדבק את הקוד הזה לתוך התוסף mu שלך. הוא תואם לוורדפרס 6.9.4+.

<?php
if ( ! defined( 'ABSPATH' ) ) {
	exit;
}

/**
 * Désactive les emojis WordPress (front + admin) en retirant les actions/filtres core.
 * Gain : moins de JS et moins de traitements de contenu.
 *
 * Attention : si vous utilisez des emojis via l'éditeur, ils resteront des caractères Unicode.
 * Ce que vous perdez, c'est surtout la "compatibilité" avec d'anciens navigateurs.
 */
function bpcab_disable_emojis() : void {
	// Front-end.
	remove_action( 'wp_head', 'print_emoji_detection_script', 7 );
	remove_action( 'wp_print_styles', 'print_emoji_styles' );

	// Admin.
	remove_action( 'admin_print_scripts', 'print_emoji_detection_script' );
	remove_action( 'admin_print_styles', 'print_emoji_styles' );

	// Emails / flux / contenu.
	remove_filter( 'the_content_feed', 'wp_staticize_emoji' );
	remove_filter( 'comment_text_rss', 'wp_staticize_emoji' );
	remove_filter( 'wp_mail', 'wp_staticize_emoji_for_email' );

	// Éditeur (TinyMCE historique). Toujours présent pour compat.
	add_filter( 'tiny_mce_plugins', function ( array $plugins ) : array {
		return array_diff( $plugins, array( 'wpemoji' ) );
	} );
}
add_action( 'init', 'bpcab_disable_emojis' );

/**
 * Retire le DNS prefetch vers s.w.org souvent lié aux emojis.
 * Mesurable sur des audits réseau et parfois utile en environnement strict (RGPD/proxy).
 */
add_filter( 'wp_resource_hints', function ( array $urls, string $relation_type ) : array {
	if ( 'dns-prefetch' !== $relation_type ) {
		return $urls;
	}

	// Retire s.w.org si présent.
	return array_values(
		array_filter(
			$urls,
			static function ( $url ) {
				return ! is_string( $url ) || false === strpos( $url, 's.w.org' );
			}
		)
	);
}, 10, 2 );

פרט שימושי לגבי הקוד (שהרבה קטעי קוד לא מסבירים):

• remove_action() מסיר פונקציה שהייתה קשורה לפעולה. כאן, וורדפרס מצרף print_emoji_detection_script à wp_headאז אתה מסיר את זה מה-HTML <head>.
• העדיפות 7 ב remove_action( 'wp_head', ..., 7 ) עליו להתאים לזו ששימש בעת הוספתו. אם תגדיר עדיפות שונה, הדבר לא יסיר דבר. זוהי טעות נפוצה בעת "כתיבה מחדש" של קטע מהזיכרון.
• המסנן wp_resource_hints מנהל רמזים כמו dns-prefetch, preconnectוכו'. כאן אנו מגבילים את עצמנו ל dns-prefetch ואנחנו רק מסירים s.w.org אם קיים.

גרסה (מקרה קצה): אם תרצה השבתת אימוג'ים רק על המצח (ולהשאיר את פאנל הניהול ללא שינוי), ניתן להקיף את מדור "ניהול" בבדיקה. אני לפעמים עושה זאת באתרים שבהם העורך הוויזואלי צריך להישאר "זהה" עבור כל הצוותים:

<?php
function bpcab_disable_emojis_front_only() : void {
	// Front-end uniquement.
	if ( is_admin() ) {
		return;
	}

	remove_action( 'wp_head', 'print_emoji_detection_script', 7 );
	remove_action( 'wp_print_styles', 'print_emoji_styles' );

	remove_filter( 'the_content_feed', 'wp_staticize_emoji' );
	remove_filter( 'comment_text_rss', 'wp_staticize_emoji' );
	remove_filter( 'wp_mail', 'wp_staticize_emoji_for_email' );
}
add_action( 'init', 'bpcab_disable_emojis_front_only' );

אם אתם משתמשים בגרסה זו, שמרו רק מימוש אחד (אל תשאירו את שתי הפונקציות פעילות בו זמנית).

למה זה יותר מהיר?

• פחות JS אתה מסיר קובץ שהועלה לממשק המשתמש (ולפעמים גם לפאנל הניהול).
• פחות מסננים כל מסנן על התוכן הוא שלב נוסף במהלך הרינדור.
• פחות "רעש" רשת אחזור מוקדם של DNS יכול להיות מיותר (ולפעמים לא רצוי).

מדידת ההשפעה (פשוטה ומציאותית)

בבלוגים שאני מתחזק, הרווח האופייני הוא:

• בקשה אחת פחות (wp-emoji-release) בחזית,
• כמה KB פחות JS,
• לפעמים 10–30 אלפיות השנייה פחות עבודה של JS על מובייל ברמת כניסה (זה תלוי מאוד בשאר).

המדידה ה"אובייקטיבית" שלך: הפעל מחדש את היומן שלך PERF SCRIPTS ולבדוק את זה wp-emoji-release אינו רשום עוד.

מקרה קצה: אם ערכת הנושא או התוסף שלכם כוללים סקריפט "אמוג'י" משלהם, ייתכן שתראו handle שונה. במקרה זה, אכן הסרתם את הליבה, אך רכיב אחר מחליף אותה. יומן ה-handle הוא בדיוק מה שעוזר לזהות זאת.

מקורות שימושיים:

• remove_action() (developer.wordpress.org)
• מסנן wp_resource_hints (developer.wordpress.org)

---

שלב 2: השבתת wp-embed (oEmbed) כשאינך זקוק לו

wp-embed הוא סקריפט קצה-קדמי המשמש לאינטגרציות והתנהגויות הטמעה מסוימות. אתרים רבים אינם זקוקים לו אם:

• אינך משלב תוכן באמצעות כתובת URL פשוטה המודבקת בעורך.
• אתם משתמשים רק ב-iframes מפורשים (לדוגמה, יוטיוב דרך iframe),
• בונה הדפים שלך כבר מנהל את ההטמעות שלו.

תשומת הלב אם אתם מפרסמים מאמרים עם הטמעות של וורדפרס (או אם אתם משתמשים לעתים קרובות בכתובות URL "קסומות" בגוטנברג), בצעו בדיקה על 2-3 פריטי תוכן קיימים לפני פריסה בכל מקום.

המכשול הנפוצ הוא שאולי כבר לא "משתמשים" בהטמעות כיום, אבל יש לכם מאמרים ישנים היכן שהדבקת כתובת URL של YouTube/Spotify. בלי wp-embedחלק מההתנהגויות הנלוות עשויות להשתנות. זה לא בהכרח "שבור", אבל זה כבר לא אותו הדבר.

לפני (איטי / ברירת מחדל): wp-embed נטען

בלי אופטימיזציה, wp-embed ניתן להכניס לתור מקדימה.

מקרה קצה: חלק מהתמות אינן נחקרות wp-embed בכל העמודים. מכאן החשיבות של מדידה דרך הלוג: אל תמחק משהו שלא קיים (זה לא מזיק, אבל אתה מבזבז זמן).

AFTER (ממוטב): ביטול רישום הסקריפט wp-embed

הוסף קוד זה לאותו mu-plugin.

<?php
/**
 * Désactive le script wp-embed sur le front.
 * Gain : 1 requête JS en moins (souvent), moins de JS à parser.
 *
 * Risque : certains embeds ou fonctionnalités liées peuvent ne plus fonctionner.
 * Testez sur quelques articles contenant des intégrations avant de généraliser.
 */
add_action( 'wp_enqueue_scripts', function () {
	if ( is_admin() ) {
		return;
	}

	// Désenregistre wp-embed (handle core).
	wp_deregister_script( 'wp-embed' );
}, 100 );

פרט : wp_deregister_script() פעולה זו מסירה את רישום הסקריפט ("הידית" שלו) מרגיסטרי וורדפרס. אם רכיב אחר ינסה לאחר מכן להכניס אותו לתור, הוא עלול להיכשל... או לרשום אותו מחדש. לכן עדיפות ותזמון חשובים.

מקרה קצה חשוב: אם תוסף נכנס מחדש לתור wp-embed לאחר הקוד שלך (עם עדיפות גבוהה יותר), תראה שוב wp-embed בתור. במקרה זה, יש להגדיל את העדיפות (לדוגמה, 999) או לזהות את התוסף הפגום באמצעות Query Monitor.

למה עדיפות (100) חשובה

נתקלתי לעתים קרובות במקרים בהם ערכת נושא (או Elementor/Divi/Avada דרך מודולים) מבצעת שאילתות חוזרות על סקריפטים באיחור. אם מבטלים את הרישום מוקדם מדי, הסקריפט יכול להופיע שוב. עדיפות גבוהה הופכת את ה-Intent לאמינה יותר.

אלטרנטיבה: אפשר אפילו ללכת רחוק יותר ו להתיר זנב (הסר מהתור) בנוסף לביטול הרישום, אם אתה נתקל במקרה שבו הסקריפט כבר נוסף:

<?php
add_action( 'wp_enqueue_scripts', function () {
	if ( is_admin() ) {
		return;
	}

	// Retire de la queue si déjà enqueued, puis désenregistre.
	wp_dequeue_script( 'wp-embed' );
	wp_deregister_script( 'wp-embed' );
}, 999 );

גרסה זו שימושית כאשר תבנית אחת נכנסת לתור מוקדם ותוסף אחר נכנס לתור מחדש מאוחר. אתם "מנקים" בסוף.

תאימות Divi 5 / Elementor / Avada

• Divi 5 רוב המודולים אינם זקוקים wp-embed, אבל אם תדביק כתובות URL במודולים של "טקסט" בתקווה להטמעה אוטומטית, אתה עלול לאבד את ההמרה הזו.
• Elementor ווידג'טים ייעודיים (YouTube, Vimeo וכו') משתמשים בדרך כלל ב-iframes משלהם ואינם תלויים ב- wp-embedהטמעות באמצעות תוכן WYSIWYG עשויות להיות מושפעות.
• אבדתי ל-Fusion Builder יש אלמנטים משלו של אינטגרציה. אותה הערה: דפי בדיקה המשתמשים בתוכן שהודבק "בכתובת URL גולמית".

בפועל: אם אתם משתמשים בווידג'ט "וידאו" (Elementor) או במודול "וידאו" (Divi/Avada), אתם בדרך כלל בסדר. אם אתם משתמשים בבלוק "פסקה" ומדביקים כתובת URL בתקווה שוורדפרס תטפל בשאר, בדקו זאת.

מקור: wp_deregister_script() (developer.wordpress.org).

---

שלב 3: ניקוי העורך והממשק (מבלי לפגוע ב-Gutenberg)

כשמדברים על "ביצועים", מתחילים רבים משביתים הכל בכל מקום. רעיון גרוע: לפאנל הניהול ולעורך הבלוקים (גוטנברג) יש צרכים שונים מאשר לממשק הקצה.

המטרה: אופטימיזציה של הקצה הקדמי (דפים שנצפו על ידי מבקרים), מבלי להפוך את העריכה למייגעת.

כלל פשוט: כל מה שנוגע לחוויית המבקר מטופל בחזית. כל מה שקשור לנוחות העריכה זה מטופל בפאנל הניהול, ואנחנו נמנעים מלפרוץ אותו "כדי לחסוך 5 KB".

אפשרות: השבתת wp-embed רק בדפים מסוימים

אם יש לכם בלוג עם כמה מאמרים המשתמשים בהטמעות, תוכלו להשבית אותן באופן מותנה. לדוגמה: אנחנו שומרים wp-embed על המאמרים (is_single()), אבל אנחנו מוחקים אותו מהדף הבית, מהדפים והארכיון.

<?php
add_action( 'wp_enqueue_scripts', function () {
	if ( is_admin() ) {
		return;
	}

	// Exemple de stratégie : garder wp-embed sur les articles (single).
	if ( is_single() ) {
		return;
	}

	wp_deregister_script( 'wp-embed' );
}, 100 );

זה פחות "אגרסיבי", וזה מונע שבירת תוכן ישן שאולי שכחת.

וריאנטים שימושיים (מקרי קצה):

• שמור wp-embed על גבי CPT (סוג פוסט מותאם אישית): החלף is_single() נָקוּב is_singular( 'votre_cpt' ) ou is_singular() בהתאם לצרכים שלך.
• שמור את wp-embed רק אם התוכן מכיל הטמעה זה יותר מדויק, אבל זה דורש גילוי. אראה דוגמה "פרגמטית" מיד לאחר מכן.
• WooCommerce אם יש לכם דפי מוצר עם תוכן מוטמע, בדקו is_product() (פונקציית WooCommerce) לפני השבתתה באופן גלובלי.

אפשרות: רישום דפים שנמצאים בתור באמצעות wp-embed

שימושי כשרוצים לדעת ou התסריט בפועל נמצא בשימוש.

<?php
add_action( 'wp_print_scripts', function () {
	if ( is_admin() ) {
		return;
	}
	if ( ! is_user_logged_in() || ! current_user_can( 'manage_options' ) ) {
		return;
	}

	global $wp_scripts;
	if ( ! $wp_scripts instanceof WP_Scripts ) {
		return;
	}

	if ( in_array( 'wp-embed', $wp_scripts->queue, true ) ) {
		error_log( '[PERF] wp-embed enqueued on URL: ' . home_url( add_query_arg( null, null ) ) );
	}
}, 999 );

מניסיוני, לעתים קרובות מגלים שתוסף "חברתי" או חסימה ספציפית מוסיפים אותו למרות שכבר אינכם משתמשים בו.

מקרה קצה: home_url( add_query_arg( null, null ) ) זה נוח, אבל אם האתר שלך נמצא מאחורי פרוקסי/CDN עם ​​שכתובות URL, כתובת ה-URL הרשומה עשויה להיות שונה ממה שאתה רואה בדפדפן. זו לא בעיה: הדבר החשוב הוא לזהות את התבנית/נתיב (דף הבית, ארכיון, יחיד וכו').

דוגמה לקוד נוסף (קונקרטי): השבתת wp-embed רק אם הדף אינו זקוק לכך

כשאני רוצה פשרה נקייה, אני משתמש בכלל פשוט: אם אנחנו נמצאים בדף יחיד (מאמר/דף) והתוכן מכיל כתובות URL שניתן להטמיע אוטומטית, אני שומר על wp-embed.אחרת אסיר את זה.

זה לא מדע מדויק (oEmbed תלוי גם בספקים), אבל זה יעיל במניעת פגיעה בתוכן קיים תוך כדי הסרה. wp-embed על רוב העמודים.

הוסף את הקוד הזה לתוסף ה-mu שלך במקום זאת השבתה עולמית של wp-embed (אין לתחזק שתי אסטרטגיות במקביל).

<?php
/**
 * Désactive wp-embed de façon "intelligente".
 * - On ne garde wp-embed que si on est sur un contenu singular (page/article)
 *   ET que le contenu semble contenir une URL qui pourrait déclencher un oEmbed.
 *
 * Objectif : éviter de casser d'anciens articles où vous aviez collé une URL (YouTube, etc.)
 * tout en supprimant wp-embed sur home/archives/pages "listing".
 */
add_action( 'wp_enqueue_scripts', function () {
	if ( is_admin() ) {
		return;
	}

	// Par défaut : on retire.
	$keep = false;

	if ( is_singular() ) {
		$post = get_post();
		if ( $post instanceof WP_Post ) {
			$content = (string) $post->post_content;

			// Détection simple : présence d'une URL sur une ligne seule (cas courant de l'auto-embed).
			// On couvre http/https + www.
			$has_standalone_url = (bool) preg_match( '~(^|R)s*(https?://S+|www.S+)s*(R|$)~i', $content );

			// Détection d'un shortcode embed explicite (rare mais existe).
			$has_embed_shortcode = ( false !== stripos( $content, '.
אתם נמנעים מהמצב של "ביטלתי את wp-embed והתוכן הישן השתנה".

מגבלות (שחשוב להיות מודעים להן):

אם התוכן שלך מכיל כתובת URL באמצע פסקה (לא בשורה אחת), ייתכן שבדיקה זו לא תזהה אותה, למרות שהתבנית/תוסף שלך עדיין יוכלו לעשות איתה משהו.
חלק מבוני הדפים מאחסנים נתוני הטמעה במטא תגיות (postmeta) במקום ב... post_contentבמקרה זה, הזיהוי לא יראה אותם. זה נדיר עבור הטמעות "קלאסיות", אבל זה קורה.




תצורת שרת
השבתת אימוג'ים/wp-embed מפחיתה בעיקר בקשות ושימוש ב-JavaScript. השרת יכול להגביר את הרווח אם תגישו לדפים אלה כותרות מטמון ודחיסה טובות.
נקודה למתחילים: אם לאתר שלך יש מטמון הדף (תוסף מטמון, מטמון שרת, מטמון CDN), ה"תחושה" יכולה להיות מצוינת אפילו עם הרבה JS. אבל Core Web Vitals (LCP/INP) נשארים רגישים לעומס חזיתי. מכאן היתרון של ביצוע שניהם: מטמון + ניקוי.

.htaccess (Apache): דחיסת דפדפן ואחסון במטמון
אם אתה משתמש באפאצ'י עם .htaccess לאחר הפעלת הכללים, ניתן להוסיף (או לבדוק) אותם. שמור את הקובץ תחילה: שגיאת תחביר עלולה לגרום לאתר להחזיר שגיאת 500.
# .htaccess — exemple (Apache)
# Active la compression (si mod_deflate est disponible)
<IfModule mod_deflate.c>
  AddOutputFilterByType DEFLATE text/html text/plain text/css application/javascript application/json image/svg+xml
</IfModule>

# Cache navigateur pour fichiers statiques
<IfModule mod_expires.c>
  ExpiresActive On
  ExpiresByType text/css "access plus 30 days"
  ExpiresByType application/javascript "access plus 30 days"
  ExpiresByType image/svg+xml "access plus 30 days"
  ExpiresByType image/png "access plus 365 days"
  ExpiresByType image/jpeg "access plus 365 days"
  ExpiresByType image/webp "access plus 365 days"
</IfModule>

למה זה רלוונטי כאן: אם מסירים סקריפטים, מפחיתים בקשות. עם מטמון דפדפן תקין, העלויות הנותרות למבקרים חוזרים נמוכות עוד יותר.
מקרה קצה: אם אתם כבר משתמשים בתוסף אחסון במטמון (או ב-CDN כמו Cloudflare), ייתכן שכבר יש לכם כללים מקבילים. אל תשכפלו אותם בלי לבדוק, אחרת אתם עלולים לקבל כותרות סותרות.
wp-config.php: מגבלות זיכרון ומטמון של אובייקטים (אבחון)
אני לא ממליץ לך "לכוון באופן אקראי", אבל שני קבועים עולים לעתים קרובות בפתרון בעיות:
<?php
// wp-config.php — exemples.
// Augmenter la mémoire PHP côté WordPress si vous êtes trop bas (évite des lenteurs/erreurs).
define( 'WP_MEMORY_LIMIT', '256M' );
define( 'WP_MAX_MEMORY_LIMIT', '512M' );

אם ספק האירוח שלך מגביל את PHP ל-128M, קבועים אלה לא יעבדו פלאים, אך הם ימנעו תקרה נמוכה מדי בסביבות מסוימות.
מקרה קצה: אם אתם רואים שגיאות "גודל הזיכרון המותר מוצה" ביומני הרישום, תחילה הגדל את הזיכרון, ולאחר מכן בדוק את הסיבה (תוסף גדול, בקשה מסיבית, טעינה אוטומטית מוגזמת). הגדלת הזיכרון ללא אבחון הבעיה לא תפתור את הבעיה הבסיסית.
php.ini / PHP-FPM: OPcache (אם יש לך גישה)
OPcache מאיץ את PHP על ידי הימנעות מקומפילציה מחדש של סקריפטים עם כל בקשה. זה לא ספציפי לאמוג'יז/wp-embed, אבל אם קובץ ה-TTFB שלך אינו יציב, זה חשוד חזק.
; php.ini — exemples (les valeurs exactes dépendent du serveur)
opcache.enable=1
opcache.memory_consumption=256
opcache.interned_strings_buffer=16
opcache.max_accelerated_files=20000
opcache.validate_timestamps=1
opcache.revalidate_freq=2

מקור: PHP OPcache (php.net).
מקרה קצה: בחלק מתכניות האירוח, OPcache מופעל אך בגודל נמוך מדי (זיכרון מועט מדי, קבצים מועטים מדי). התוצאה: החמצות תכופות של מטמון ו-TTFB לא עקבי. אם יש לכם גישה למדדי OPcache (phpinfo או status), זה ניכר במהירות.

אימות התוצאות
אתם רוצים לאמת בלי "רגשות". שמרו על פשטות: מדדו מה באמת משתנה.
1) ודא שהסקריפטים נעלמו (יומני רישום)
לאחר הפריסה, רענן 2-3 עמודים כשאתה מחובר כמנהל, ולאחר מכן פתח wp-content/debug.logאתה אמור לראות:

האם wp-emoji-release קיים? לא
האם wp-embed קיים? לא (אם השבתת את זה)

אם עדיין מופיעה המילה "כן", בדרך כלל פירוש הדבר:

הדבקת את הקוד לתוך functions.php של ערכת הנושא של האב (והערכת הנושא עודכנה),
תוסף מבצע שאילתה מחדש על הסקריפט לאחר שתסיים.
אתה צופה בדף המוגש על ידי מטמון/CDN שלא נוקה.

מקרה קצה: אם אתם משתמשים בקובץ מטמון מסוג "HTML סטטי" שאינו מאפשר לעוגיית ההפעלה של המנהל לעבור דרכו, ייתכן שאתם מחוברים ל-WordPress אך רואים דף מוסתר. במקרה זה, בדקו עם כתובת URL שלא נכללה בקובץ המטמון (או השבתו את הקובץ המטמון למשך 2 דקות).
2) מדידת מספר הסקריפטים וזמן ה-PHP (מיני-אינסטרומנטציה)
בלוק זה מוסיף כותרת HTTP Server-Timing עם זמן היצירה בצד של וורדפרס ומספר הסקריפטים/סגנונות. זה מאוד פרקטי עם כלי פיתוח ברשת, וזה לא דורש תוסף.
הוסף אותו לתוסף ה-mu שלך (ושמור אותו אם אתה רוצה ניטור קל משקל).
<?php
add_action( 'send_headers', function () {
	if ( is_admin() ) {
		return;
	}

	// Uniquement pour les admins connectés (évite de divulguer des métriques à tout le monde).
	if ( ! is_user_logged_in() || ! current_user_can( 'manage_options' ) ) {
		return;
	}

	global $wp_scripts, $wp_styles;

	$script_count = ( $wp_scripts instanceof WP_Scripts ) ? count( $wp_scripts->queue ) : 0;
	$style_count  = ( $wp_styles instanceof WP_Styles ) ? count( $wp_styles->queue ) : 0;

	// timer_stop() renvoie le temps depuis le début du chargement WP (en secondes).
	$php_seconds = function_exists( 'timer_stop' ) ? (float) timer_stop( 0, 3 ) : 0.0;

	header(
		sprintf(
			'Server-Timing: wp;dur=%.3f, scripts;desc="scripts";dur=%d, styles;desc="styles";dur=%d',
			$php_seconds * 1000,
			$script_count,
			$style_count
		)
	);
}, 999 );

איך לקרוא את זה (למתחילים): בכרטיסייה רשת בדפדפן שלך, לחץ על בקשת ה-HTML הראשית, ולאחר מכן חפש Server-Timingתראה זמן "wp" (משך PHP משוער) ושני מונים "scripts/styles". אם תסיר wp-embedמונה הסקריפטים יורד לעתים קרובות ב-1.
מקור: timer_stop() (developer.wordpress.org).
3) הפעל בדיקת Core Web Vitals נוספת
כדי להישאר "קוד-קודם", ניתן להפוך מדידה של Lighthouse לאוטומטית באמצעות ממשק שורת הפקודה (CLI) (אם Node מותקן במחשב המקומי שלך). דוגמה:
# Exemple local (nécessite Node + Lighthouse)
lighthouse https://votre-site.tld/ --only-categories=performance --output=json --output-path=./lh.json

אתם מחפשים בעיקר: ירידה בשימוש הכולל ב-JS, פחות בקשות, ולפעמים שיפור קל ב-INP.
מקרה קצה: Lighthouse רגיש לשינויים ברשת/מעבד. הרץ 3 ריצות והשווה חציון. והשווה אותו עמוד (לדוגמה, דף הבית) לפני/אחרי.

אם הביצועים לא משתפרים
זה קורה לעתים קרובות: מסירים סקריפט אחד או שניים, אבל האתר נשאר איטי. במקרה הזה, צוואר הבקבוק לא שם.
שלב א': הבחנה בין TTFB (שרת) לרינדור (חזית)

TTFB גבוה בעיית PHP/MySQL, מטמון חסר בדף, ערכת נושא כבדה, שאילתות איטיות.
TTFB נכון אבל LCP/INP גרוע יותר מדי JS/CSS, תמונות, גופנים, סקריפטים של צד שלישי.

מניסיוני, מתחילים רבים מבלבלים בין השניים. הסר wp-embed זה כמעט ולא יעשה כלום עבור TTFB של 1,5 שניות. לעומת זאת, מטמון עמודים מצוין לא יתקן INP שנפגע עקב 700KB של JS של צד שלישי.
שלב ב': הפעל באופן זמני את SAVEQUERIES ורישום שאילתות איטיות
תשומת הלב : SAVEQUERIES מאט אותו. הפעל אותו למשך 5 דקות, בסביבת בימוי במידת האפשר.
<?php
// wp-config.php (temporaire)
define( 'SAVEQUERIES', true );

לאחר מכן, רשום את השאילתות הארוכות ביותר בסוף השאילתה:
<?php
add_action( 'shutdown', function () {
	if ( ! defined( 'SAVEQUERIES' ) || true !== SAVEQUERIES ) {
		return;
	}
	if ( is_admin() ) {
		return;
	}
	if ( ! is_user_logged_in() || ! current_user_can( 'manage_options' ) ) {
		return;
	}

	global $wpdb;
	if ( empty( $wpdb->queries ) || ! is_array( $wpdb->queries ) ) {
		return;
	}

	$slow = array();

	foreach ( $wpdb->queries as $q ) {
		// Format: [ query, time, caller ]
		$sql  = $q[0] ?? '';
		$time = (float) ( $q[1] ?? 0 );
		$from = $q[2] ?? '';

		if ( $time >= 0.05 ) { // 50ms
			$slow[] = array( 'time' => $time, 'sql' => $sql, 'caller' => $from );
		}
	}

	usort( $slow, static fn( $a, $b ) => $b['time'] <=> $a['time'] );

	error_log( '--- PERF SLOW QUERIES (top 10) ---' );
	foreach ( array_slice( $slow, 0, 10 ) as $row ) {
		error_log( sprintf( '%.4fs | %s | %s', $row['time'], $row['caller'], $row['sql'] ) );
	}
}, 999 );

אם אתם רואים בקשות איטיות, היתרון של הסרת אימוג'ים/wp-embed יבוטל. תצטרכו לטפל במסד הנתונים, ברעמת העיצוב או להוסיף מטמון אובייקטים.
מקרה קצה: אם אתם נמצאים מאחורי מטמון של דף, לא תראו יומני רישום אלה בדפים המאוחסנים במטמון (וורדפרס לא פועל). בצעו בדיקה על דף שלא נכלל במטמון או נקו את המטמון לפני כל בדיקה.
שלב ג': בדיקת סקריפטים של צד שלישי
בחיים האמיתיים, "גדול" נובע לעתים קרובות מ:

מנהל התגים של גוגל + מספר תגיות,
פיקסלים של פרסום,
ווידג'טים של צ'אט,
גופנים חיצוניים אינם ממוטבים.

יומן הסקריפט שלך (Handles:) היא נקודת התחלה טובה לזיהוי מי אחראי על מה.
גרסה שימושית של "קוד בלבד": אם אתם מזהים שם משתמש של צד שלישי (למשל, תוסף חברתי) ורוצים למדוד את העלות שלו, תוכלו להסיר אותו באופן זמני מהתור בדף בדיקה ולהשוות את הכותרות שלכם. Server-Timing + ממשק שורת הפקודה (CLI) של Lighthouse שלך ​​פועל.

מלכודות וטעויות נפוצות
השגיאות שלהלן הן אלו שאני רואה בתדירות הגבוהה ביותר כאשר מישהו "מדביק קטע קוד" שנמצא במדריך ישן.
טעויות נפוצות (ואיך להימנע מהן)

הדבק את הקוד לקובץ הלא נכון : functions.php של ערכת הנושא הראשית במקום ערכת נושא בת או תוסף mu. תוצאה: הכל נעלם עם העדכון הבא.
שכחת נקודה-פסיק מסך לבן / שגיאה 500. בדוק תחילה את תהליך ההפעלה, או הפעל רישום.
וו רע ביטול רישום wp-embed סור init זה יכול לעבוד... או לא, תלוי בסדר השאילתה. מעדיפים wp_enqueue_scripts עם עדיפות גבוהה.
התנגשות מטמון אתה מודד דף המוגש על ידי מטמון/CDN מלפני השינוי. נקה את מטמון הדף ואת ה-CDN.
בדיקות על ייצור ללא גיבוי קטע טקסט שהועתק בצורה גרועה יכול לנעול את מנהל המערכת. ודאו שגישה ל-FTP/SSH מוכנה.
קוד ממדריך ישן הערה: חלק מהקטעים מסירים ווים שהשתנו בהתאם לגרסה. ב-WP 6.9.4, השתמשו בהפניות רשמיות ובדקו.

מלכודות שאני רואה ספציפית עם Divi/Elementor/Avada:

אופטימיזציה "גלובלית" בתוסף ביצועים אתה מבטל wp-embed באמצעות כפתור דו-מצבי, בונה הדפים שלך מעדכן ומשנה את אופן הטיפול שלו בתוכן מסוים. כתוצאה מכך, אינך יודע עוד אם זה הבונה או ה-du-מצבי שגורם לבעיה. Casseהתוסף mu הופך את ההתנהגות למפורשת וניתנת לגירסה.
מזעור/דחייה אגרסיבית : חלק מהכלים חלים defer לכל הסקריפטים, כולל אלו שוורדפרס מצפה ש"יחסמו". זה יכול לפגוע ב-INP או לשבש אינטראקציות. כאן, ראשית נסיר את המיותר, מה שמונע את הצורך "לבטל" כל דבר.
בדוק רק את מסך הבית ייתכן שהבית שלך לא ייטען wp-embed, בזמן שמאמר טוען אותו. לפחות בדיקה: דף הבית + ארכיון + מאמר + בונה דפים "כבד".

תרשים אבחון



סימפטום
סיבה סבירה
אימות
פתרון




wp-emoji-release עדיין טעון
קטע לא בוצע / מיקום שגוי
מאמת wp plugin list --status=must-use et debug.log
הכניסו את הקוד לתוסף mu, בדקו את הנתיב wp-content/mu-plugins/


wp-embed מחזירה לאחר ניקוי
תוסף/תבנית הוכנס מחדש לתור באיחור
לוגר $wp_scripts->queue עדיפות 999
בטל רישום עם עדיפות 100+, או קבע הגדרה לפי דפים


הטמעות (כתובות URL מודבקות) אינן מוצגות עוד
נדרש wp-embed/oEmbed
בדיקת מאמר עם אינטגרציה דרך כתובת URL גולמית
הפעל מחדש את wp-embed ב is_single() או רק על תבניות מסוימות


אין שיפור נראה לעין במהירות הדף
צוואר הבקבוק נמצא במקום אחר (סקריפטים / תמונות / TTFB של צד שלישי)
השווה TTFB לעומת LCP/INP, בדוק סקריפטים של צד שלישי
אופטימיזציה של תמונות, גופנים, מטמון דפים, סקריפטים של צד שלישי, מסד נתונים


שגיאה 500 לאחר הוספת קוד
שגיאת PHP (תחביר, PHP ישן מדי)
צפה ביומני שרת + wp-content/debug.log
תקן את התחביר, ודא PHP 8.1+, שחזר גיבוי




טיפים לתחזוקה

שמרו את האופטימיזציות שלכם בתוסף mu פשוט יותר לביקורת וחזק יותר מתוסף של snippets.
תעד את התנאים שלך אם תשמור wp-embed סור is_single()אנא הסבר מדוע בתגובה.
ניטור רגרסיות לאחר הוספת תוסף חברתי או מודול Divi/Elementor/Avada חדש, יש לרשום מחדש את תור הסקריפטים למשך דקה אחת.
אוטומציה של בדיקה קטנה פעם בחודש, להריץ ממשק שורת פקודה (CLI) של Lighthouse או בדיקת שאילתה על 2-3 עמודים מרכזיים.
הימנעו מ"אופטימיזציות" אגרסיביות אשר משלבים/דוחים הכל ללא שליטה: ראיתי בוני דפים קורסים בגלל דחייה גלובלית שיושמה בצורה גרועה.

אלטרנטיבה שימושית: שמור את ה-mu-plugin שלך כ"מודולים" (פונקציות נפרדות, הערות ומתג בחלק העליון). בעת פתרון בעיות, תוכל להפעיל/להשבית אופטימיזציות בצורה נקייה מבלי למחוק קוד.

משאבים

ניפוי באגים בוורדפרס (developer.wordpress.org)
wp_deregister_script() (developer.wordpress.org)
remove_action() (developer.wordpress.org)
מסנן wp_resource_hints (developer.wordpress.org)
צג שאילתות (wordpress.org)
מראה של פיתוח וורדפרס ב-GitHub (wordpress-develop)
מעקב אחר תהליכים ב-WordPress Core (כרטיסים והיסטוריה)
OPcache (php.net)


שאלות נפוצות
האם השבתת אימוג'ים מסירה אימוג'ים מהתוכן שלי?
לא. האימוג'ים שלך נשארים תווי יוניקוד במסד הנתונים וב-HTML. אתה בעיקר מסיר את סקריפט הזיהוי ומסנני התאימות. בדפדפנים מודרניים, בדרך כלל אין לכך השפעה נראית לעין.
האם זה תואם לוורדפרס 6.9.4?
כן, הגישות דרך remove_action/remove_filter et wp_deregister_script להישאר תואמים. הימנעו מקטעי טקסט ישנים שמשנים קבצי ליבה.
למה להשתמש ב-mu-plugin במקום functions.php?
כי functions.php תלוי בערכת העיצוב הפעילה. שינוי הערכת העיצוב (או עדכון ערכת העיצוב של האב) עלול לגרום להיעלמות האופטימיזציות שלך. תוסף mu נטען אוטומטית ונשאר במקומו.
האם wp-embed הכרחי עבור יוטיוב?
לא אם אתם משתמשים ב-iframe (או בווידג'ט של בונה דפים שיוצר iframe). ייתכן שזה יהיה הכרחי אם אתם מסתמכים על הטמעה אוטומטית על ידי הדבקת כתובת URL בעורך, תלוי במצב.
ביטלתי את wp-embed וחלק מהאינטגרציות כבר לא עובדות: מה עליי לעשות?
הפעל אותו מחדש רק במידת הצורך (למשל is_single()), או בתבנית דף ספציפית. זוהי לרוב הפשרה הטובה ביותר.
למה אני עדיין יכול לראות את הסקריפטים אחרי השינוי?
שלוש סיבות נפוצות: מטמון של דף/CDN שלא נמחק, קוד שהודבק במקום הלא נכון, או תוסף שמחזיר את התור לתור אחריך. השתמש ברישום התורים עבור סקריפטים עם עדיפות 999 כדי לקבוע את הסיבה.
האם זה באמת משפר את מדדי הליבה של האינטרנט?
לפעמים קצת, במיוחד במובייל. הרווח בפני עצמו הוא לעיתים רחוקות מרהיב, אבל מדובר בניקוי "בסיכון נמוך" (במיוחד אימוג'ים) שמפחית את סך ה-JS ואת מספר הבקשות.
האם אני צריך גם למזער/לשרשר את הסקריפטים?
לא אוטומטית. בוורדפרס מודרני עם HTTP/2/3, שרשור לא תמיד מועיל. התחילו בהסרת קוד מיותר (כפי שמוצג כאן), לאחר מכן דחו/השהו סקריפטים כבדים של צד שלישי.
מה עליי לעשות אם האתר שלי עדיין איטי למרות הכל?
כתובת ראשונה: מטמון עמוד, תמונות (LCP), סקריפטים של צד שלישי, שאילתות איטיות (SAVEQUERIES זמניים), ויישום מטמון אובייקטים (Redis/Memcached) אם האתר שלך דינמי.
האם אופטימיזציות אלו משפיעות על מנהל מערכת וורדפרס?
קטע האימוג'י מסיר גם סגנונות/סקריפטים באזור הניהול. בפועל, זו לעיתים רחוקות בעיה. אם אתם רוצים להיות זהירים, תוכלו להגביל את השבתת האימוג'י לממשק הקצה בלבד.
האם אני יכול לעשות את זה דרך תוסף מטמון?
חלק מהתוספים מציעים אפשרויות "השבת אימוג'ים" ו"השבת הטמעות". זה נוח, אבל ראיתי אפשרויות משתנות במהלך עדכוני תוספים. ה-mu-plugin נשאר השיטה הכי צפויה וניתנת לביקורת.

פריטים קשורים

השתמשו ב"מה חדש למפתחים" בוורדפרס
הוסף קוד וורדפרס מבלי לפגוע באתר שלך
שילוב וורדפרס בתוך וורדפרס מבלי לפגוע באתר
תקן את שגיאת Polylang הקטלנית הקשורה ל-Lingotek