جلوگیری از خطاهای مرگبار در وردپرس

درباره بهترین شیوه های توسعه وردپرس بیاموزید و نمونه های کد را مشاهده کنید.

خطاهای مهلک می توانند کل سایت را از بین ببرند، بنابراین مهم است که هنگام توسعه یک سایت وردپرس در هر پلتفرمی، دقیق باشید. بیایید چند نمونه که می تواند منجر به قطعی های ناخواسته شود، و چگونگی جلوگیری از آنها بحث کنیم.

خطاهای مهلک: برخورد توابع

یک تابع ممکن است در PHP، هسته وردپرس، یک افزونه یا یک تم وجود داشته باشد. اما اگر تابعی را که از قبل وجود دارد را اعلام کنید، PHP یک خطای مرگبار ایجاد می کند.

به عنوان مثال، تابع زیر در حال حاضر در وردپرس وجود دارد و هنگام اعلان خطایی ایجاد می شود:

// this will cause a fatal
function get_permalink( $url ) {
    // do something
}

بهترین راه برای محافظت در برابر برخورد این است که اعلان آنها را با «function_exists» بپیچید.

به طور متناوب، می توانید استفاده کنید:

• یک روش کلاسی
• فضای نام (این باعث ایجاد پیچیدگی می شود)

خطاهای مهلک: توابعی که وجود ندارند

PHP همچنین اگر سعی کنید به تابعی که اعلان نشده است دسترسی پیدا کنید، به عنوان مثال، زمانی که عملکرد در یک افزونه اعلام شده است اما افزونه نصب یا فعال نیست، یک خطای مرگبار ایجاد می کند.

// this will cause a fatal if Safe Redirect Manager is not active
$redirect = srm_create_redirect( '/old/', '/new/', 301);

بررسی این موضوع هنگام ایجاد افزونه ای که به افزونه دیگری متکی است، مهم است. از آنجایی که وردپرس فایل‌های wp-admin خاصی را برای قسمت جلویی بارگیری نمی‌کند، ارزش آن را دارد که آن عملکرد را بررسی کرده و در صورت لزوم فایل(ها) را به صورت دستی بارگیری کنید.

این همچنین می تواند زمانی اتفاق بیفتد که اعلان دارای اشتباه تایپی باشد یا در صورت لزوم از پیشوند فضای نام استفاده نکنید. اجتناب از این مسائل دشوار است، بنابراین “تست دود” همیشه مفید است.

هشدارها: بررسی نکردن مقادیر بازگشتی

استفاده از «WP_DEBUG» در توسعه و نمایش اخطارها و اعلان‌ها یک روش خوب توسعه است. این شرایط هشدار باید فوراً آشکار شود و به سرعت قابل رسیدگی و اصلاح باشد.

هشدارها و اخطارهای PHP لزوماً به یک سایت آسیب نمی رساند، اما وجود آنها نشان می دهد چیزی وجود دارد که نیاز به توجه دارد. حذف همه اخطارها و اخطارها بهترین روش است و تشخیص مسائل جدید را در “log_error_log” PHP آسان می کند.

توجه: گذاشتن اخطارهای غیرضروری یا بدون آدرس بیش از حد، گزارش های شما را مسدود می کند، از فضای دیسک استفاده می کند و یافتن و رفع مشکلات جدید را دشوار می کند.

در اینجا هشدارها یا اخطارهای متداول و کد مثالی که باعث ایجاد آنها می شود، آمده است.

دسترسی به یک آرایه بدون اطمینان از آرایه بودن آن

// expecting an array
$stuff = getStuff( $args );
// unless getStuff is guaranteed to always return an array, this is not good...
foreach ( $stuff as $thing ) { // Invalid argument supplied for foreach()
    // actions
}
// this is common and also not good without checking $stuff:
$thing1 = $stuff[0];
// even worse
$thing_name = $stuff[0]->getName();

استفاده از هر چیزی که اسکالر نیست به عنوان شاخص

$redirect_to = [ 'foo' => 'foo.com', 'bar' => 'bar.com' ];
$c = get_categories(); // returns an array

// (other code that fails to convert $c to a single string)

// this will fail because $c is an array
$redirect_url = $redirect_to[ $c ];

دسترسی به اشیایی که ممکن است آن چیزی که انتظار می رفت نباشد

// expecting an object
$something = getSomething( $id );
// if $something is null, this is not going to work
$something->doIt();
Certain functions return WP_Error when they fail. It's important to check that condition.
$categories = get_the_terms( $post->ID, 'category' );
// if the result is WP_Error, this next line will throw warnings
foreach ( $categories as $category ) {
    $cats[] = $category->name;
}

اجتناب از ارسال__not_in

آرگومان «WP_Query» «post__not_in» ممکن است گزینه مفیدی به نظر برسد، اما می‌تواند با تأثیر بر نرخ بازدید حافظه پنهان منجر به عملکرد ضعیف در یک سایت شلوغ و/یا بزرگ شود.

آرگومان «post__not_in» معمولاً برای حذف شناسه‌های پست خاص از نتایج جستجو استفاده می‌شود. به عنوان مثال، اگر یک ویجت پنج پست اخیر را در هر صفحه نشان دهد، طراح سایت شما ممکن است بخواهد از نمایش پست فعلی در آن ویجت اجتناب کند. گفتنی است، این استدلال کمی اضافی است، زیرا خواننده در حال خواندن آن پست اخیر است.

نحوه استفاده از آن

ممکن است ویجتی مانند این داشته باشید:

// Display the most recent news posts
function my_recent_news_widget( ) {
	$args = array(
		'category_name' => 'news',
		'posts_per_page' => 5,
		'post_status' => 'publish',
		'ignore_sticky_posts' => true,
		'no_found_rows' => true,
	);
	$recent_posts = new WP_Query( $args );

	echo '<div class="most-recent-news"><h1>News</h1>';
	while ( $recent_posts->have_posts() ) {
		$recent_posts->the_post();
		the_title( '<h2><a href="' . get_permalink() . '">', '</a></h2>');
	}
	echo '</div>';
	wp_reset_postdata();
}

روش معمول این است که آن تابع را به تنهایی تغییر دهید، با افزودن یک آرگومان تابع اختیاری و یک آرگومان پرس و جو «post__not_in» در خط 9، به شرح زیر:

// Display the most recent news posts (but not the current one)
function my_recent_news_widget( $exclude = array() ) {
	$args = array(
		'category_name' => 'news',
		'posts_per_page' => 5,
		'post_status' => 'publish',
		'ignore_sticky_posts' => true,
		'no_found_rows' => true,
		'post__not_in' => $exclude,
	);
	$recent_posts = new WP_Query( $args );

	echo '<div class="most-recent-news"><h1>News</h1>';
	while ( $recent_posts->have_posts() ) {
		$recent_posts->the_post();
		the_title( '<h2><a href="' . get_permalink() . '">', '</a></h2>');
	}
	echo '</div>';
	wp_reset_postdata();
}

احتمالاً این را در قالبی با «ویجت_اخیرا_اخبار من» ( [ get_the_ID() ] )”؛ و پنج پست اخیر خبری را نمایش می دهد، اما پست فعلی را نمایش نمی دهد.

در حالی که استفاده در بالا ساده است، ایده آل نیست.

مشکلات با این رویکرد

پرس و جو، که قبلاً از کش پرس و جو داخلی استفاده می کرد، اکنون برای هر پست یا صفحه منحصر به فرد است، زیرا «AND ID در ( ‘12345’) اضافه نشده است. دلیل آن این است که کلید کش (که هش آرگومان ها است) اکنون شامل لیستی از حداقل یک شناسه است که در همه پست ها متفاوت است. به جای اینکه صفحات بعدی لیستی از پنج پست را از کش شیء بدست آورند، کش را از دست می دهد و پایگاه داده همان کار را در چندین صفحه انجام می دهد.

در نتیجه، هر یک از آن پرس‌و‌جوها به‌طور جداگانه ذخیره می‌شوند و استفاده غیرضروری از Memcached افزایش می‌یابد. برای سایتی با صدها هزار پست، این به طور بالقوه بر اندازه حافظه پنهان اشیاء تأثیر می گذارد و منجر به حذف زودهنگام حافظه پنهان می شود.

به جای آن چه باید کرد

تقریباً در همه موارد، می توانید با درخواست پست های بیشتر و پرش از پست های حذف شده در PHP، سرعت را به میزان قابل توجهی بهبود بخشید.

با اطمینان از سازگاری درخواست پست در همه URL ها، بازیابی شش پست اخیر، عملکرد را بهبود بخشید، بنابراین پست ها از حافظه پنهان شی ظاهر می شوند. اگر پیش‌بینی می‌کنید که فهرست «$exclude» بزرگ‌تر از یک پست باشد، حد را بالاتر، شاید روی 10 قرار دهید. برای کاهش تعداد انواع حافظه پنهان، آن را به‌عنوان یک عدد ثابت، نه یک متغیر، در نظر بگیرید.

تابع به روز شده دیگر پست(ها) را در SQL مستثنی نمی کند، از شرطی ها در حلقه استفاده می کند:

// Display the most recent news posts (but not the current one)
function my_recent_news_widget( $exclude = array() ) {
	$args = array(
		'category_name' => 'news',
		'posts_per_page' => 10,
		'post_status' => 'publish',
		'ignore_sticky_posts' => true,
		'no_found_rows' => true,
	);
	$recent_posts = new WP_Query( $args );

	echo '<div class="most-recent-news"><h1>News</h1>';
	$posts = 0; // count the posts displayed, up to 5
	while ( $recent_posts->have_posts() && $posts < 5 ) {
		$recent_posts->the_post();
		$current = get_the_ID();
		if ( ! in_array( $current, $exclude ) ) {
			$posts++;
			the_title( '<h2><a href="' . get_permalink() . '">', '</a></h2>');
		}
	}
	echo '</div>';
	wp_reset_postdata();
}

در حالی که نیاز به کمی منطق در PHP دارد، این رویکرد از کش کوئری بهتر استفاده می کند و از ایجاد تغییرات کش که ممکن است بر مقیاس پذیری و پایداری سایت تأثیر بگذارد، جلوگیری می کند.

درباره بهترین روش های وردپرس بیشتر بدانید

برای مشاوره فنی بیشتر در مورد توسعه وردپرس و وردپرس VIP، اسناد ما را بررسی کنید.