توابع وردپرس برای ساخت لینک و URL | توابع URL وردپرس

اولین باری که یک سایت را از یک دامنه به دامنه دیگر منتقل کردم، فکر می‌کردم کار یک ساعت است: فایل‌ها را کپی می‌کنم، دیتابیس را ایمپورت می‌کنم، دامنه را تغییر می‌دهم، تمام. سه ساعت بعد، سرِ یک فهرست بلند از ۴۰۴ گیر کردم. برخی لینک‌های داخلی هنوز به دامنه قدیمی اشاره می‌کردند، برخی تصاویر لود نمی‌شدند، و یک ویجت فوتر که دو سال پیش توسط یک فریلنسر ساخته شده بود، آدرس‌ها را دستی hardcode کرده بود. آن شب، برای اولین بار به این فکر افتادم که تفاوت بین سایتی که به‌درستی از توابع URL وردپرس استفاده می‌کند و سایتی که آدرس‌ها را دستی می‌نویسد، در روز مهاجرت، فقط چند ساعت کار نیست — تفاوت بین یک مهاجرت آرام و یک بحران چندروزه است. از آن پروژه، در هر سایتی که می‌سازم، اولین چیزی که بازبینی می‌کنم، استفاده درست از توابع URL است. این مقاله، همان چیزی است که در پروژه‌های واقعی برای ساخت و مدیریت لینک‌ها و URL در وردپرس به کار می‌برم. اگر با مفاهیم پایه آشنا نیستید، پیش از ادامه وردپرس چیست و چطور شروع کنیم، نحوه استفاده از توابع وردپرس و ساختار هسته وردپرس را بخوانید.

آن مهاجرت، قانون اول را برایم نوشت

آن مهاجرت را به‌عنوان بدترین شبِ آن سال به یاد می‌آورم. اما سه درس از آن درآمد که تا امروز، در هر پروژه‌ای اجرا می‌کنم:

یک: URL، یک رشته ساده نیست؛ یک قرارداد بین لایه‌های سایت است. در آن سایت، فایل‌های CSS از یک قالب قدیمی، از مسیر دامنه قدیمی لود می‌شدند. هدر نوشته‌شده با https://oldsite.com/wp-content/... دستی، بعد از مهاجرت به دامنه جدید، همه شکسته بودند. اگر همان یک مسیر با get_template_directory_uri() ساخته شده بود، مهاجرت یک‌ساعته تمام می‌شد.

دو: hardcode کردن URL، یک بدهی فنی پنهان است. در روز توسعه، همه‌چیز کار می‌کند؛ در روز مهاجرت، SSL، تغییر زیرپوشه، یا انتقال به CDN، همه‌چیز می‌شکند. هزینه‌اش در ماه اول صفر است، در ماه دوازدهم، چند روز کار است.

سه: توابع URL، لایه‌ای است که بیشتر توسعه‌دهندگان وردپرس کم‌ترین توجه را به آن می‌کنند. چون ساده به نظر می‌رسند، چون فکر می‌کنیم «آدرس سایت که معلوم است»، اما همین سادگی، منبع حجم بزرگی از باگ‌های سکوت‌آمیز است.

URL، نه یک آدرس، بلکه یک قرارداد بین سایت شما و آینده‌اش است؛ اگر آن را دستی بنویسید، آینده‌اش را گروگان گرفته‌اید.

چرا URL به‌جای Hardcode؟

سه دلیل که در پروژه‌های خودم، hardcode کردن URL را ممنوع کرده‌ام:

مهاجرت دامنه بدون درد: وقتی سایت به دامنه جدید منتقل می‌شود، توابع URL وردپرس به‌طور خودکار به دامنه جدید اشاره می‌کنند. هیچ دیتابیس دست‌کاری لازم نیست، هیچ سرچ-ریپلیس در دیتابیس لازم نیست.
سازگاری با زیرپوشه و HTTP/HTTPS: اگر سایت شما در زیرپوشه نصب می‌شود، یا از HTTP به HTTPS منتقل می‌شود، توابع URL به‌طور خودکار هم‌خوانی می‌کنند. hardcode، این بار را به عهده شما می‌گذارد.
قابلیت گسترش و شخصی‌سازی: در چایلد تم و افزونه‌های اختصاصی، توابع URL به شما امکان می‌دهند تا آدرس‌ها را به‌صورت پویا تغییر دهید — مثلاً CDN یا مسیر asset سفارشی.

یک قاعده سرانگشتی که در تیم‌های خودم آموزش می‌دهم: اگر در کد قالب یا افزونه‌ای، URL کامل با دامنه دیدید — https://yoursite.com/... — آن خط را یک باگ فنی بدانید، حتی اگر امروز کار می‌کند.

دسته‌بندی توابع URL در وردپرس

توابع URL در وردپرس در پنج دسته اصلی تقسیم می‌شوند. شناخت این دسته‌بندی، انتخاب تابع درست را ساده می‌کند:

دسته	نمونه توابع	کاربرد
URL سایت	home_url، site_url، network_home_url	آدرس‌های پایه سایت
URL محتوا	get_permalink، get_term_link، get_author_posts_url	آدرس‌های پویا بر اساس محتوا
URL asset	get_template_directory_uri، plugins_url، includes_url	آدرس فایل‌های قالب و افزونه
URL پیشخوان	admin_url، get_edit_post_link	آدرس صفحات مدیریتی
Escape	esc_url، esc_url_raw	پاک‌سازی URL برای نمایش یا ذخیره

هر دسته را در بخش‌های بعدی مفصل مرور می‌کنم. یک نکته مهم: توابع URL معمولاً دو نسخه دارند — نسخه get_* که URL را برمی‌گرداند، و نسخه بدون get_* که URL را مستقیماً چاپ می‌کند. در این مقاله روی نسخه get_* تمرکز می‌کنم، چون انعطاف بیشتری می‌دهد.

site_url و home_url: تفاوت واقعی

دو تابع پرتکرار که بیشتر توسعه‌دهندگان، تفاوتشان را نمی‌دانند:

home_url( $path = '' ): آدرس صفحه اصلی سایت. اگر وردپرس در زیرپوشه نصب شده باشد و به دامنه اصلی ریدایرکت شده باشد، این تابع آدرس دامنه اصلی را برمی‌گرداند.
site_url( $path = '' ): آدرس نصب وردپرس. اگر وردپرس در زیرپوشه /blog نصب شده باشد، این تابع https://example.com/blog را برمی‌گرداند.

در ۹۰٪ پروژه‌ها، این دو یکی هستند. اما در نصب‌های خاص — مثل «WordPress در زیرپوشه با دامنه اصلی روی همان سایت» — تفاوت دارند. قاعده من: برای لینک به صفحات سایت خودتان از home_url استفاده کنید؛ برای لینک به فایل‌های اجرایی وردپرس از site_url. مثال:

// لینک به صفحه درباره ما
$url = home_url( '/about/' );

// لینک به wp-login.php
$login = site_url( 'wp-login.php' );

// اگر می‌خواهید مسیر را با پارامتر بفرستید
$search = home_url( '/search/?q=wordpress' );

یک نکته از تجربه: در پروژه‌هایی که زیرپوشه به دامنه اصلی منتقل می‌شوند، اگر همه لینک‌ها با site_url نوشته شده باشند، بعد از مهاجرت، همه لینک‌ها به مسیر اشتباه می‌روند. برای قالب و افزونه اختصاصی، همیشه از home_url برای لینک‌های کاربرپسند استفاده کنید. این نکته در پروژه‌هایی که با قالب آماده یا اختصاصی کار می‌کنم، بسیار کاربردی بوده است.

get_permalink و مشتقات آن

پرتکرارترین تابع URL در قالب‌ها و افزونه‌ها، get_permalink است. اما مشتقات آن، در موقعیت‌های خاص، کاربردی‌تر هستند:

get_permalink( $post_id ): لینک دائمی نوشته، برگه یا نوع‌نوشته سفارشی. اگر بدون پارامتر صدا زده شود، نوشته فعلی حلقه را برمی‌گرداند. راهنمای کامل در توابع وردپرس برای داده‌های نوشته.
get_the_permalink( $post_id ): معادل بالا، اما در نسخه‌های جدید وردپرس، معنی مشابه دارد. در عمل، هر دو یکسان عمل می‌کنند.
get_post_permalink( $post_id ): مخصوص نوع‌نوشته‌های غیر از post. برای لینک به نوع‌نوشته سفارشی، مناسب است. اگر با ساخت نوع نوشته سفارشی کار می‌کنید، این تابع بخش مهمی از کار شماست.
get_attachment_link( $attachment_id ): لینک به صفحه ضمیمه (attachment) در کتابخانه رسانه. در پروژه‌هایی که گالری اختصاصی می‌سازید، این تابع کاربرد مستقیم دارد.
get_page_link( $page_id ): معادل get_permalink برای برگه‌ها. در برخی نسخه‌ها هنوز توصیه می‌شود، ولی get_permalink عمومی‌تر است.

نکته مهم در استفاده صحیح: همیشه get_permalink را با متغیر بگیرید، نه با عدد hardcode شده. مثلاً به‌جای get_permalink( 42 )، از get_permalink( $post->ID ) یا get_permalink( get_the_ID() ) استفاده کنید. اگر روی لوکال سایت بسازید و بعد روی سرور منتقل کنید، hardcode شناسه، فاجعه‌ساز است.

یک تجربه شخصی: در یکی از پروژه‌های فروشگاهی، در سه صفحه از قالب، get_permalink( 1234 ) hardcode شده بود. یک بار بازنصب دیتابیس، شناسه‌ها را جابه‌جا کرد و آن سه صفحه به محصولات کاملاً اشتباه اشاره می‌کردند. پیدا کردن این باگ، سه ساعت وقت گرفت، چون همه دنبال مشکل در کوئری و هوک بودند. درس: hardcode شناسه، همان جنس خطای hardcode URL است.

توابع URL برای فایل‌ها و assetها

پس از permalink، دومین دسته پرتکرار، توابع URL مربوط به assetها هستند. پنج تابع اصلی:

get_template_directory_uri(): آدرس پوشه قالب والد. برای لینک به assetهای قالب والد.
get_stylesheet_directory_uri(): آدرس پوشه چایلد تم. برای لینک به assetهای چایلد تم. اگر با قالب چایلد کار می‌کنید، این تابع را جدی بگیرید.
plugins_url( $path, $file ): آدرس فایل‌ها داخل پوشه افزونه. برای enqueue در افزونه‌ها. راهنمای کامل در ساختار فایل‌های افزونه استاندارد.
includes_url( $path ): آدرس پوشه wp-includes/. برای لینک به assetهای هسته وردپرس. در پروژه‌های سفارشی، اکثراً لازم نمی‌شود، ولی در اسکریپت‌های مدیریتی کاربرد دارد.
content_url( $path ): آدرس پوشه wp-content/. برای لینک به فایل‌های اختصاصی در wp-content.

الگوی صحیح enqueue با این توابع:

function mytheme_enqueue_assets() {
    // استایل قالب والد
    wp_enqueue_style(
        'mytheme-parent',
        get_template_directory_uri() . '/style.css',
        array(),
        '1.0.0'
    );

    // استایل چایلد
    wp_enqueue_style(
        'mytheme-child',
        get_stylesheet_directory_uri() . '/style.css',
        array( 'mytheme-parent' ),
        '1.0.0'
    );

    // اسکریپت سفارشی
    wp_enqueue_script(
        'mytheme-script',
        get_stylesheet_directory_uri() . '/assets/js/main.js',
        array( 'jquery' ),
        '1.0.0',
        true
    );
}
add_action( 'wp_enqueue_scripts', 'mytheme_enqueue_assets' );

اگر با چایلد تم کار می‌کنید و می‌خواهید assetهای چایلد و والد را یکسان لود کنید، الگوی بالا را جدی بگیرید. تفصیل کامل این الگو را در توسعه با چایلد تم و ساختار فایل‌های قالب استاندارد آورده‌ام.

توابع URL برای پیشخوان و صفحات مدیریتی

در افزونه‌های اختصاصی و صفحات تنظیمات، توابع URL مربوط به پیشخوان نقش کلیدی دارند:

admin_url( $path ): آدرس پوشه wp-admin/. برای ساخت لینک به صفحات پیشخوان. مثال: admin_url( 'options-general.php' ).
get_edit_post_link( $post_id ): لینک ویرایش نوشته در پیشخوان. برای ساخت لینک «ویرایش» در قالب front-end.
get_delete_post_link( $post_id ): لینک حذف نوشته. توجه: این لینک باید همیشه با بررسی دسترسی کاربر استفاده شود.
wp_nonce_url( $actionurl, $action ): ساخت URL با نانس امنیتی. برای لینک‌های عملیاتی حساس مثل حذف یا تایید.
add_query_arg( $key, $value, $url ): افزودن پارامتر به URL. برای ساخت لینک‌های فیلتر یا صفحه‌بندی.
remove_query_arg( $key, $url ): حذف پارامتر از URL.

الگوی استاندارد در ساخت لینک پیشخوان با نانس:

$delete_url = wp_nonce_url(
    admin_url( 'admin.php?action=myplugin_delete&id=' . $id ),
    'myplugin_delete_' . $id
);

echo '<a href="' . esc_url( $delete_url ) . '">حذف</a>';

یک نکته از تجربه: در پروژه‌های فروشگاهی، لینک «ویرایش محصول» در پنل مدیریت مشتری، با get_edit_post_link ساخته می‌شود. اگر این لینک به‌جای admin_url با hardcode ساخته شود، در مهاجرت دامنه، این لینک‌ها می‌شکنند و پنل مدیریت مشتری از کار می‌افتد. مسیر کامل ساخت این لینک‌ها در ساخت صفحه تنظیمات اختصاصی و Customizer وردپرس آمده است.

توابع URL برای ترم‌ها، کاربران و نویسندگان

سومین دسته، توابع URL برای موجودیت‌های محتوایی مثل ترم، کاربر و نویسنده:

get_term_link( $term, $taxonomy ): لینک به صفحه آرشیو یک ترم (دسته، برچسب یا ترم تاکسونومی سفارشی). توجه: این تابع در صورت خطا، شیء WP_Error برمی‌گرداند، نه رشته. بررسی is_wp_error الزامی است. راهنمای کامل در توابع دسته‌بندی و ساخت تاکسونومی سفارشی.
get_category_link( $category_id ): معادل بالا فقط برای دسته‌ها.
get_tag_link( $tag_id ): معادل بالا فقط برای برچسب‌ها. راهنما در توابع برچسب.
get_author_posts_url( $author_id ): آرشیو نوشته‌های یک نویسنده.
get_author_feed_link( $author_id ): فید RSS نوشته‌های نویسنده.
get_edit_user_link( $user_id ): لینک ویرایش کاربر در پیشخوان. برای صفحات پروفایل.

الگوی صحیح استفاده از get_term_link:

$terms = get_the_terms( get_the_ID(), 'product_category' );
if ( ! empty( $terms ) && ! is_wp_error( $terms ) ) {
    foreach ( $terms as $term ) {
        $link = get_term_link( $term );
        if ( ! is_wp_error( $link ) ) {
            echo '<a href="' . esc_url( $link ) . '">' . esc_html( $term->name ) . '</a>';
        }
    }
}

اگر این الگو را در ابتدای پروژه یاد بگیرید، ۹۰٪ باگ‌های آرشیو تاکسونومی از بین می‌رود. مسیر کامل را در توابع متادیتای وردپرس و استانداردهای کدنویسی وردپرس آورده‌ام.

escape URL: esc_url در برابر esc_url_raw

یکی از تفاوت‌های ظریف اما مهم، بین esc_url و esc_url_raw است. هر دو URL را پاک‌سازی می‌کنند، اما برای context متفاوت:

esc_url( $url ): برای نمایش URL در HTML. کاراکترهای & را به & تبدیل می‌کند تا HTML معتبر باشد. برای href و src.
esc_url_raw( $url ): برای ذخیره URL در دیتابیس. کاراکترهای & را تغییر نمی‌دهد و URL را برای ذخیره آماده می‌کند.

الگوی صحیح در ذخیره و نمایش:

// ذخیره در دیتابیس
$url = esc_url_raw( wp_unslash( $_POST['custom_url'] ) );
update_post_meta( $post_id, '_custom_url', $url );

// نمایش در HTML
$url = get_post_meta( $post_id, '_custom_url', true );
echo '<a href="' . esc_url( $url ) . '">لینک</a>';

اشتباه رایج: استفاده از esc_url برای ذخیره در دیتابیس. این کار باعث می‌شود URL ذخیره شده، & داشته باشد و در استفاده‌های بعدی (مثل درخواست HTTP)، مشکل ایجاد کند. مسیر کامل این تفکیک را در پاک‌سازی داده‌ها در وردپرس و اعتبارسنجی داده‌ها آورده‌ام.

esc_url برای چشمی که به HTML نگاه می‌کند، esc_url_raw برای ذهن دیتابیس که به پردازش‌های بعدی فکر می‌کند.

توابع URL در REST API، AJAX و ریدایرکت

در پروژه‌های حرفه‌ای، URL تنها برای لینک‌های HTML نیست. سه سناریوی خاص که در پروژه‌های خودم زیاد دیده‌ام:

URL در REST API: در ساخت endpointهای REST، معمولاً از rest_url( 'myplugin/v1/item' ) استفاده می‌شود تا آدرس API با تنظیمات سایت هم‌خوانی داشته باشد. راهنمای کامل در ساخت API اختصاصی.
URL در AJAX: برای ارسال درخواست AJAX از front-end، از admin_url( 'admin-ajax.php' ) استفاده کنید و آن را با wp_localize_script به جاوااسکریپت پاس دهید. الگوی کامل در استفاده از add_action و تفاوت اکشن و فیلتر.
URL در ریدایرکت: برای ریدایرکت‌های امن، از wp_safe_redirect( $url ) استفاده کنید که فقط به دامنه‌های امن ریدایرکت می‌کند. برای ریدایرکت‌های عمومی، wp_redirect استفاده کنید. تفاوت این دو در افزونه‌های ریدایرکت و رفع خطای لینک‌ها در وردپرس آمده است.

الگوی صحیح برای AJAX:

function myplugin_enqueue_ajax_script() {
    wp_enqueue_script(
        'myplugin-ajax',
        plugins_url( 'assets/js/ajax.js', __FILE__ ),
        array( 'jquery' ),
        '1.0.0',
        true
    );

    wp_localize_script( 'myplugin-ajax', 'myplugin_ajax', array(
        'url'   => admin_url( 'admin-ajax.php' ),
        'nonce' => wp_create_nonce( 'myplugin_ajax_nonce' ),
    ) );
}
add_action( 'wp_enqueue_scripts', 'myplugin_enqueue_ajax_script' );

اگر با REST API کار می‌کنید، توصیه من این است: همیشه از rest_url() استفاده کنید، نه home_url( '/wp-json/' ). دلیل: در بعضی نصب‌های خاص، مسیر wp-json ممکن است تغییر کند. مسیر کامل را در راهنمای REST API وردپرس آورده‌ام.

مهاجرت دامنه و نقش توابع URL

مهاجرت دامنه، بزرگ‌ترین آزمون برای توابع URL است. اگر پروژه‌تان توابع URL را درست استفاده کرده باشد، مهاجرت یک کار معمول است؛ اگر نه، به یک بحران تبدیل می‌شود. سه تجربه از پروژه‌های خودم:

سرچ-ریپلیس دیتابیس، کافی نیست: بعضی داده‌ها در فیلدهای serialized ذخیره می‌شوند و سرچ-ریپلیس ساده، آن‌ها را خراب می‌کند. اگر کد شما از توابع URL استفاده کند، این مشکل به‌کلی وجود ندارد.
URL در فایل‌های asset قالب: اگر در CSS یا JS شما، آدرس با دامنه hardcode شده، سرچ-ریپلیس روی فایل‌ها لازم است. توابع URL، این نیاز را حذف می‌کنند.
URL در محتوای نوشته‌ها: اگر در محتوای نوشته‌ها، لینک‌های داخلی با دامنه hardcode شده باشند، مهاجرت دردناک است. راه‌حل، استفاده از لینک‌های نسبی یا سرچ-ریپلیس در محتواست.

پروتکل کامل مهاجرت امن قالب و سایت در تغییر امن قالب وردپرس و افزونه‌های ریدایرکت آمده است. یک قاعده در پروژه‌های خودم: قبل از مهاجرت، همه URLهای hardcode را در فایل‌های قالب و افزونه با توابع URL جایگزین می‌کنم. این کار، مهاجرت را از چند روز به چند ساعت کاهش می‌دهد.

جدول چک‌لیست استفاده از توابع URL

جمع‌بندی چک‌لیست استفاده از توابع URL در پروژه‌های وردپرس:

موقعیت	تابع صحیح	نکته
لینک به صفحه سایت	home_url	نه site_url، نه hardcode
لینک به نوشته	get_permalink( $id )	متغیر، نه شناسه hardcode
لینک به دسته	get_term_link( $term )	بررسی is_wp_error
لینک به نویسنده	get_author_posts_url( $id )	نه ساخت دستی
asset قالب والد	get_template_directory_uri	در چایلد تم هم کار می‌کند
asset چایلد	get_stylesheet_directory_uri	فقط چایلد
asset افزونه	plugins_url( $path, __FILE__ )	با __FILE__ دقیق
لینک پیشخوان	admin_url	نه ساخت دستی
ذخیره URL در دیتابیس	esc_url_raw	نه esc_url
نمایش URL در HTML	esc_url	نه esc_html
لینک AJAX	admin_url( 'admin-ajax.php' )	با wp_localize_script
لینک REST API	rest_url( 'namespace/v1' )	نه ساخت دستی wp-json

اشتباهات رایج در ساخت URL

در اشتباهات رایج کدنویسی وردپرس و اشتباهات رایج توسعه وردپرس فهرست کامل را نوشته‌ام؛ اما هفت مورد که در ساخت URL بیشتر می‌بینم:

Hardcode کردن URL کامل: https://yoursite.com/contact در کد. راه‌حل: home_url( '/contact/' ).
استفاده از esc_url برای ذخیره در دیتابیس: باعث می‌شود کاراکترهای & به & تبدیل شوند و در استفاده‌های بعدی مشکل ایجاد کنند.
نبود بررسی is_wp_error در get_term_link: در صورت خطا، شیء WP_Error برگردانده می‌شود و به‌جای لینک، خطای PHP نمایش داده می‌شود.
hardcode کردن شناسه در get_permalink( 42 ): در مهاجرت دیتابیس، شناسه‌ها جابه‌جا می‌شوند و لینک به نوشته اشتباه اشاره می‌کند.
استفاده از get_template_directory_uri در چایلد تم: assetهای چایلد باید از get_stylesheet_directory_uri لود شوند.
نبود esc_url در نمایش: echo $url; به‌جای echo esc_url( $url );. این اشتباه، در پروژه‌های فروشگاهی می‌تواند به XSS منجر شود.
فراموش کردن wp_unslash قبل از esc_url_raw: کاراکترهای بک‌اسلش در داده‌های ورودی نابود می‌شوند.

یک اشتباه کم‌تکرار اما گران‌قیمت: استفاده از home_url برای لینک به فایل‌های اجرایی وردپرس. مثال: home_url( 'wp-login.php' ) به‌جای site_url( 'wp-login.php' ). اگر سایت شما در زیرپوشه نصب است و بعداً به دامنه اصلی منتقل می‌شود، این لینک اشتباه می‌شود. راه‌حل: برای فایل‌های اجرایی، همیشه از site_url استفاده کنید.

دید مهندسی

از منظر مهندسی، توابع URL در وردپرس یک لایه انتزاعی است که سایت شما را از جزئیات محیط اجرایی جدا می‌کند. سه لایه را در پروژه‌های حرفه‌ای همیشه مرور می‌کنم. لایه اول، تفکیک URL به‌عنوان یک Domain Value: در پروژه‌های بزرگ، URL باید به‌عنوان یک شیء ارزشی در نظر گرفته شود، نه یک رشته ساده. مثلاً یک کلاس My_Plugin_Url که متدهای admin_url، rest_url، asset_url دارد و در هر جای پروژه، از همان کلاس استفاده می‌شود. این الگو، هم تغییرات محیطی را ساده می‌کند و هم در تست‌ها، mock کردن URL را راحت‌تر می‌کند. تفصیل این نوع معماری را در اصول کدنویسی تمیز آورده‌ام. لایه دوم، مدیریت URL در سطح زیرساخت: در پروژه‌هایی که با CDN، زیرپوشه یا چند دامنه کار می‌کنند، URL باید در سطح زیرساخت مدیریت شود. مثلاً یک تابع wrapper که asset URLها را به CDN مسیر می‌دهد، یا یک فیلتر که مسیر پیش‌فرض را در محیط staging تغییر می‌دهد. مسیر کامل در اتصال وردپرس به سرویس‌های خارجی و بهبود عملکرد سرور آمده است. لایه سوم، پایش یکدستی URL در پروژه: در پروژه‌های بلندمدت، باید به‌طور دوره‌ای بازبینی کنید که آیا همه URLها از توابع وردپرس استفاده می‌کنند یا نه. ابزارهای تست سرعت می‌توانند URLهای خارجی و داخلی را نشان دهند، و ابزارهای جستجو در کد (مثل grep) می‌توانند الگوهای hardcode را کشف کنند. یک قاعده در پروژه‌های خودم: در بازبینی کد هر Pull Request، به دنبال الگوهای http:// و https:// می‌گردم؛ هر مورد، یک نامزد بازبینی است.

یک نکته تکمیلی برای تیم‌های فنی: در پروژه‌های بزرگ، استفاده از توابع URL به‌عنوان بخشی از استاندارد کد تیمی، می‌تواند تفاوت بین پروژه‌ای با مهاجرت دردناک و پروژه‌ای با مهاجرت یک‌روزه باشد. مسیر پیاده‌سازی استاندارد در استانداردهای کدنویسی وردپرس و استفاده از استانداردها در پروژه‌ها آمده است. اگر می‌خواهید این استاندارد را به‌صورت خودکار اجرا کنید، می‌توانید یک اسنیپت در PHP_CodeSniffer بنویسید که الگوهای hardcode URL را کشف کند. تجربه مستقیم خودم از یک پروژه فروشگاهی: با یک بازبینی ساده در کد قالب، ۴۷ نقطه hardcode URL پیدا کردیم. جایگزینی همه با توابع وردپرس، یک روز کار بود. مهاجرتی که ماه بعد اتفاق افتاد، در چهار ساعت انجام شد — بدون یک لینک شکسته، بدون یک تصویر ناموجود.

جمع‌بندی

توابع URL در وردپرس، در پنج دسته خلاصه می‌شوند: URL سایت، URL محتوا، URL assetها، URL پیشخوان، و escape URL. سه اصل در پایان تاکید می‌کنم: اول، هیچ URLی را با دامنه hardcode نکنید؛ همیشه از توابع وردپرس استفاده کنید. دوم، esc_url و esc_url_raw را بر اساس context انتخاب کنید: اولی برای نمایش، دومی برای ذخیره. سوم، برای لینک‌های پویا (نوشته، دسته، کاربر)، همیشه متغیر بفرستید، نه شناسه hardcode.

اگر همین امروز در حال کار روی یک پروژه وردپرسی هستید، پیشنهاد عملی من سه گام است: ابتدا در کد قالب و افزونه‌های خود، به دنبال الگوی http:// و https:// بگردید و همه را با توابع URL جایگزین کنید؛ سپس در همه فرم‌ها و متاباکس‌ها، از esc_url_raw برای ذخیره و esc_url برای نمایش استفاده کنید؛ و در پایان، قبل از مهاجرت بعدی، یک تست ساده انجام دهید: سایت را در دامنه‌ای دیگر شبیه‌سازی کنید و ببینید آیا همه لینک‌ها کار می‌کنند. اگر در هر مرحله‌ای گیر کردید یا تجربه‌ای از مهاجرت با لینک‌های شکسته یا کشف یک hardcode خطرناک دارید، در دیدگاه‌ها بنویسید. تجربه شما از یک پروژه با توابع URL درست یا یک فاجعه ناشی از hardcode، برای توسعه‌دهنده بعدی که در همین نقطه ایستاده، ارزشمندترین راهنماست. 🔗