wp-config.php: הגדרות שמשפרות את המהירות והבטיחות של וורדפרס

מה זה wp-config.php, ולמה לא להגזים איתו

wp-config.php הוא קובץ ההגדרות של וורדפרס. הוא נטען בכל בקשה, עוד לפני התוספים והתבנית, ומחזיק את פרטי החיבור למסד הנתונים, את מפתחות האבטחה, וכל הגדרה שרוצים לקבוע לאתר כולו. ההגדרות נכתבות כקבועים (Constants) בפקודה define.

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

לפני שנוגעים בקובץ: גיבוי ומיקום נכון

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

1. מורידים עותק של הקובץ למחשב, דרך SFTP או מנהל הקבצים של האחסון.
2. עורכים בעורך טקסט, כמו VS Code או Notepad++, ולא ב‑Word. מעבד תמלילים, וגם הדבקה מחלק מהאתרים, הופכים גרשים רגילים לגרשים מעוגלים, ו‑PHP לא מבין אותם.
3. מוסיפים את השורות במקום הנכון: מעל השורה /* That's all, stop editing! Happy publishing. */ (בגרסאות ישנות כתוב שם Happy blogging). השורות שאחריה טוענות את וורדפרס, וקבוע שמוגדר אחריהן מגיע מאוחר מדי.
4. מגדירים כל קבוע פעם אחת בלבד. לפני שמוסיפים, מחפשים בקובץ אם הוא כבר קיים, ואם כן, מעדכנים אותו. הגדרה כפולה גורמת לאזהרה, והראשונה היא שקובעת.
5. בודקים: אם יש גישת SSH, הפקודה php -l wp-config.php מוצאת שגיאות תחביר. אחר כך פותחים את האתר ואת לוח הבקרה ומוודאים שהכול עובד.

זיכרון PHP: יציבות, לא מהירות

define( 'WP_MEMORY_LIMIT', '256M' );
define( 'WP_MAX_MEMORY_LIMIT', '512M' );

WP_MEMORY_LIMIT קובע כמה זיכרון וורדפרס רשאית לצרוך בבקשה רגילה באתר (ברירת המחדל היא 40MB, ו‑64MB ברשת אתרים). WP_MAX_MEMORY_LIMIT חל על פעולות כבדות בלוח הבקרה, כמו עיבוד תמונות ועדכונים, וברירת המחדל שלו היא 256MB.

שני דברים חשוב להבין. ראשית, זו תקרה ולא הקצאה: וורדפרס לא תופסת את הזיכרון מראש, ולא רצה מהר יותר כשהתקרה גבוהה. ההגדרה רק מונעת את השגיאה Allowed memory size exhausted באתרים עם תוספים כבדים. שנית, וורדפרס יכולה רק להעלות את הגבול, ורק אם השרת מרשה לה. אם חברת האחסון קבעה ב‑PHP גבול נמוך יותר ונעלה אותו, השורה לא תעזור. את הערך בפועל רואים במסך Site Health שבתפריט "כלים", בלשונית המידע.

סוג: יציבות. ואם האתר צריך יותר מ‑256MB לבקשה רגילה, זה סימן לבדוק איזה תוסף אחראי, לא להמשיך להעלות.

מסד נתונים מסודר: גרסאות, שמירה אוטומטית ופח

define( 'WP_POST_REVISIONS', 10 );
define( 'AUTOSAVE_INTERVAL', 120 );
define( 'EMPTY_TRASH_DAYS', 14 );

WP_POST_REVISIONS

כברירת מחדל וורדפרס שומרת מספר בלתי מוגבל של גרסאות (Revisions) לכל פוסט ועמוד, כל אחת כשורה נוספת בטבלה wp_posts. באתר עם הרבה עריכות זה מצטבר לאלפי שורות מיותרות. מספר כמו 5 או 10 משאיר מספיק היסטוריה לשחזור טעות. הערך false מבטל גרסאות לגמרי, ולא מומלץ.

ההגבלה לא מוחקת גרסאות קיימות מיד: וורדפרס מנקה את העודפות של פוסט רק כשנשמרת לו גרסה חדשה. לניקוי חד פעמי של כל הגרסאות, אחרי גיבוי של מסד הנתונים, אפשר להשתמש ב‑WP-CLI, כלי שורת הפקודה של וורדפרס:

wp post delete $(wp post list --post_type=revision --format=ids) --force

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

AUTOSAVE_INTERVAL

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

EMPTY_TRASH_DAYS

פוסטים, עמודים ותגובות שנמחקו נשארים בפח 30 יום, ואז נמחקים לצמיתות. אפשר לקצר, למשל ל‑14 יום. אל תגדירו 0: זה מבטל את הפח, וכל מחיקה הופכת לסופית מיד. סוג: סדר.

Cron אמיתי במקום WP-Cron

וורדפרס מריצה משימות מתוזמנות: פרסום פוסטים מתוזמנים, בדיקת עדכונים, גיבויים של תוספים ומשימות של WooCommerce. כברירת מחדל זה נעשה דרך WP-Cron, שאינו cron אמיתי: בכל טעינת עמוד וורדפרס בודקת אם הגיע הזמן למשימה, ואם כן, שולחת לשרת בקשה נוספת שמריצה אותה.

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

הפתרון: מבטלים את ההפעלה דרך ביקורים, ומגדירים cron של השרת שמריץ את המשימות כל כמה דקות.

define( 'DISABLE_WP_CRON', true );

ואז מוסיפים שורה ל‑crontab, דרך Cron Jobs בלוח הבקרה או עם crontab -e בשרת. הדרך המומלצת היא עם WP-CLI:

*/5 * * * * wp --path=/home/USER/public_html cron event run --due-now >/dev/null 2>&1

אם השרת לא מוצא את הפקודה wp, כותבים את הנתיב המלא שלה, למשל /usr/local/bin/wp. ואם אין WP-CLI בכלל, אפשר לקרוא לקובץ דרך HTTP:

*/5 * * * * curl -s "https://example.co.il/wp-cron.php?doing_wp_cron" >/dev/null 2>&1

*/5 פירושו כל חמש דקות, וזה מספיק לרוב האתרים. את USER ואת example.co.il מחליפים בפרטים שלכם. בודקים שזה עובד עם wp cron event list: לא אמורות להצטבר שם משימות שמועד הריצה שלהן עבר מזמן.

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

WP_CACHE: מתג, לא קאש

define( 'WP_CACHE', true );

זו אולי ההגדרה הכי פחות מובנת. WP_CACHE לא שומר שום דבר בעצמו. הוא רק אומר לוורדפרס לטעון בתחילת כל בקשה את הקובץ wp-content/advanced-cache.php, שתוסף קאש עמודים יוצר. התוסף הוא שמגיש את העמוד השמור, עוד לפני שרוב וורדפרס נטען.

בפועל, תוספי קאש מוסיפים את השורה בעצמם כשמפעילים אותם. בלי תוסף כזה השורה לא עושה כלום. ולהפך: אם הסרתם תוסף קאש, ודאו שהשורה והקובץ advanced-cache.php הוסרו, אחרת הם עלולים לגרום לשגיאות או לקאש שלא מתעדכן. סוג: מהירות, בתנאי שיש תוסף.

בטיחות: דיבאג ועריכת קבצים

WP_DEBUG כבוי באתר חי

define( 'WP_DEBUG', false );

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

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', '/home/USER/logs/wp-debug.log' );
define( 'WP_DEBUG_DISPLAY', false );

עם הערך true, ההגדרה WP_DEBUG_LOG כותבת לקובץ wp-content/debug.log, שנמצא בתיקייה ציבורית ולפעמים אפשר להוריד אותו מהדפדפן. נתיב מחוץ לתיקייה הציבורית, כמו בדוגמה, בטוח יותר. התיקייה צריכה להיות קיימת וניתנת לכתיבה. כשהתקלה נפתרה, מחזירים את WP_DEBUG ל‑false ומוחקים את הקובץ. סוג: אבטחה, ובמידה קטנה גם מהירות.

DISALLOW_FILE_EDIT

define( 'DISALLOW_FILE_EDIT', true );

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

הכול בטבלה אחת, וטעויות נפוצות

ועכשיו הטעויות שכדאי להכיר, חלקן מופיעות ברשימות "שיפור ביצועים" ברשת:

• WP_ALLOW_REPAIR שנשאר מופעל: ההגדרה פותחת דף תיקון למסד הנתונים שכל אחד יכול לגשת אליו, בלי להתחבר. היא לא קשורה למהירות. משתמשים בה לתיקון חד פעמי, ומוחקים אותה מיד.
• WP_HTTP_BLOCK_EXTERNAL בלי רשימת חריגים: חוסם את כל הבקשות היוצאות מהאתר, כולל עדכונים, רישיונות של תוספים וחיבור לחברות סליקה.
• שורות מתחת ל‑"stop editing": נטענות מאוחר מדי, ולא משפיעות.
• הגדרות במקום אבחון: אם האתר עדיין איטי, הבעיה כנראה בתוסף, בתבנית או בשרת. כדאי לאבחן מה מאט אותו לפני שמוסיפים עוד שורות לקובץ.