نقش‌های وردپرس در سایت‌های ویراستاری به‌دلیل نیاز به مدیریت نسخه‌های متن، ردیابی تغییرات، چرخه بازخورد ویرایشی، و کنترل حق ویرایش، تنظیمات متنی اختصاصی می‌خواهند. یک ویراستار نباید به همه متن‌ها دسترسی داشته باشد؛ باید فقط به متن‌های تخصیص‌یافته خودش دسترسی داشته باشد. یک نویسنده نباید به ویرایش‌های سایر نویسندگان نفوذ کند. بدون تنظیمات متنی، یا نسخه اصلی متن از دست می‌رود، یا بازخورد ویرایشی نشت می‌کند، یا اعتبار حرفه‌ای پلتفرم زیر سؤال می‌رود.

سایت ویراستاری با چند لایه داده حساس سر و کار دارد: متن اصلی، نسخه‌های ویرایش‌شده، یادداشت ویرایشی، و داده هویتی نویسنده. هر لایه نیازمند سطح دسترسی متفاوتی است. مدل نقش پیش‌فرض وردپرس، این تفکیک را نمی‌شناسد. بدون تنظیمات متنی، خطر نشت متن ناتمام، تحریف بازخورد، و از دست رفتن اعتماد نویسنده وجود دارد. راه‌حل عملی، تعریف نقش‌های سفارشی، Track Changes سفارشی، و ثبت دقیق نسخه‌های ویرایشی است. این مقاله معماری کامل این حوزه را بررسی می‌کند.

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

چرا نقش‌های پیش‌فرض وردپرس کافی نیستند؟

وردپرس شش نقش پیش‌فرض دارد که حول مدیریت محتوا ساخته شده‌اند. در سایت ویراستاری، این نقش‌ها با شکاف‌های زیر روبه‌رو می‌شوند:

  • نبود تفکیک متن اصلی از متن ویرایش‌شده: متن اصلی باید تغییرناپذیر باشد و متن ویرایش‌شده مستقل.
  • نبود Track Changes بومی: Revision وردپرس برای بازیابی طراحی شده، نه برای ردیابی پیشنهادهای ویرایشی.
  • نبود چرخه بازخورد ویرایشی: هر ویرایش باید با دلیل، پیشنهاد، و تأیید نهایی ثبت شود.
  • ریسک نقض حق مؤلف: نویسنده حق دارد از تغییرات ناخواسته در متن خودش مطلع باشد.

در سایت ویراستاری، متن اصلی یک سند حقوقی است که اصالت آن باید حفظ شود.

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

نقش‌های ضروری در سایت ویراستاری

نویسنده (Author)

دسترسی به متن‌های شخصی، مشاهده پیشنهادهای ویرایشی، تأیید یا رد تغییرات، بدون دسترسی به متن سایر نویسندگان.

ویراستار (Editor)

مشاهده متن‌های تخصیصی، ثبت پیشنهاد ویرایشی نسخه‌محور، تأیید نهایی، بدون دسترسی به داده پرداخت.

ویراستار ارشد (Senior Editor)

مشاهده همه متن‌های دوره، تعیین استاندارد ویرایشی، تأیید نهایی، بدون دسترسی به داده هویتی نویسنده.

مدیر تحریریه (Editorial Manager)

تخصیص ویراستار، مدیریت مهلت‌ها، بدون دسترسی به محتوای متن.

ناظر حقوقی (Legal Reviewer)

دسترسی به نسخه‌های تأییدشده برای اهداف حقوقی، بدون دسترسی به متن‌های در حال ویرایش.

چالش‌های داده ویرایشی

پیش از ورود به پیاده‌سازی، باید چالش‌های خاص این حوزه را دقیق بشناسیم.

۱. اصالت متن اصلی

متن اصلی باید تغییرناپذیر باشد. هر تغییر باید به‌عنوان پیشنهاد ثبت شود، نه به‌عنوان جایگزین. این نیازمند یک لایه Immutable Storage برای متن اصلی است. برای مطالعه بیشتر، مطلب پیاده‌سازی درست Custom Post Type را ببینید.

۲. Track Changes

ردیابی تغییرات نیازمند ساختار متادیتای دقیق است که نشان دهد چه کسی، چه زمانی، و چرا تغییری اعمال کرده است. برای مطالعه بیشتر، مطلب کار با User Meta در وردپرس را ببینید.

۳. چرخه تأیید

هر پیشنهاد ویرایشی باید یک چرخه تأیید داشته باشد: پیشنهاد، بازبینی، تأیید یا رد، اعمال. این چرخه نیازمند یک State Machine است. برای مطالعه بیشتر، مطلب هوک‌های وردپرس: قلب تپنده توسعه را ببینید.

۴. سبک ویرایشی

هر مشتری ممکن است سبک ویرایشی اختصاصی داشته باشد که باید در یک Style Guide ذخیره شود. برای مطالعه بیشتر، مطلب فیلدهای سفارشی ACF و کاربردهای واقعی آن را ببینید.

۵. حق مؤلف

نویسنده حق دارد از هر تغییر در متن خودش مطلع باشد و آن را تأیید کند. این نیازمند یک سیستم Notification و رضایت است. برای مطالعه بیشتر، مطلب توابع وردپرس برای دریافت اطلاعات نوشته را ببینید.

تنظیمات متنی برای هر نقش

نقش دسترسی متن پیشنهاد ویرایشی تأیید
نویسنده متن شخصی تأیید یا رد تأیید نهایی
ویراستار تخصیصی ثبت پیشنهاد اعمال پس از تأیید
ویراستار ارشد همه دوره ثبت و تأیید تأیید نهایی
مدیر تحریریه خیر مدیریت تخصیص خیر
ناظر حقوقی نسخه تأییدشده خیر مشاهده

پیاده‌سازی با PHP

ابتدا CPT متن ویراستاری را می‌سازیم. برای مطالعه بیشتر، مطلب پیاده‌سازی درست Custom Post Type را ببینید.

function wk_register_editing_text_cpt() {
    register_post_type('wk_editing_text', array(
        'label' => 'متون ویراستاری',
        'public' => false,
        'show_ui' => true,
        'capability_type' => 'wk_editing_text',
        'capabilities' => array(
            'read_post' => 'read_wk_editing_text',
            'edit_post' => 'edit_wk_editing_text',
            'edit_posts' => 'edit_wk_editing_texts',
            'edit_others_posts' => 'edit_others_wk_editing_texts',
        ),
        'map_meta_cap' => true,
        'supports' => array('title', 'editor', 'author', 'custom-fields'),
    ));
}
add_action('init', 'wk_register_editing_text_cpt');

سپس نقش‌های سفارشی را می‌سازیم. برای درک بهتر هوک‌ها، مطلب هوک‌های وردپرس را ببینید.

function wk_register_editing_roles() {
    add_role('wk_text_author', 'نویسنده متن', array(
        'read' => true,
        'edit_wk_editing_texts' => true,
        'publish_wk_editing_texts' => true,
        'approve_wk_suggestions' => true,
        'upload_files' => true,
    ));

    add_role('wk_text_editor', 'ویراستار', array(
        'read' => true,
        'edit_wk_editing_texts' => true,
        'edit_others_wk_editing_texts' => true,
        'write_wk_editing_suggestions' => true,
        'apply_wk_editing_suggestions' => true,
    ));

    add_role('wk_senior_editor', 'ویراستار ارشد', array(
        'read' => true,
        'edit_wk_editing_texts' => true,
        'edit_others_wk_editing_texts' => true,
        'final_approve_wk_editing_texts' => true,
    ));

    add_role('wk_legal_reviewer', 'ناظر حقوقی', array(
        'read' => true,
        'read_approved_texts' => true,
    ));
}
add_action('init', 'wk_register_editing_roles');

برای اعتبارسنجی و پاک‌سازی داده‌های ورودی، مطلب اعتبارسنجی داده‌ها در کدنویسی وردپرس و پاک‌سازی داده‌ها در کدنویسی وردپرس را ببینید.

ردیابی تغییرات سفارشی

Track Changes باید پیشنهادها را به‌صورت مستقل ثبت کند تا متن اصلی دست‌نخورده بماند:

function wk_save_editing_suggestion($text_id, $editor_id, $position, $original, $suggested, $reason) {
    if (!current_user_can('write_wk_editing_suggestions')) {
        return new WP_Error('forbidden', 'دسترسی غیرمجاز');
    }
    $suggestions = get_post_meta($text_id, 'wk_editing_suggestions', true);
    if (!is_array($suggestions)) {
        $suggestions = array();
    }
    $suggestions[] = array(
        'editor_id' => $editor_id,
        'position' => (int) $position,
        'original' => sanitize_text_field($original),
        'suggested' => sanitize_text_field($suggested),
        'reason' => sanitize_textarea_field($reason),
        'status' => 'pending',
        'created_at' => current_time('mysql'),
    );
    update_post_meta($text_id, 'wk_editing_suggestions', $suggestions);
    return true;
}

نکته کلیدی: هر پیشنهاد باید مستقل و با وضعیت روشن باشد تا در صورت اختلاف، قابل استناد باشد. برای مطالعه بیشتر، مطلب کار با Options API در وردپرس را ببینید.

نسخه‌بندی متن

هر نسخه از متن باید مستقل و با Hash محتوا ثبت شود:

function wk_save_text_version($text_id, $author_id, $content, $stage) {
    if (!current_user_can('edit_wk_editing_texts')) {
        return new WP_Error('forbidden', 'دسترسی غیرمجاز');
    }
    $version_id = wp_insert_post(array(
        'post_type' => 'wk_text_version',
        'post_status' => 'publish',
        'post_author' => $author_id,
        'post_title' => sprintf('نسخه %s', $stage),
        'post_content' => wp_kses_post($content),
    ));
    update_post_meta($version_id, 'wk_text_id', $text_id);
    update_post_meta($version_id, 'wk_version_stage', sanitize_key($stage));
    update_post_meta($version_id, 'wk_content_hash', hash('sha256', $content));
    update_post_meta($version_id, 'wk_created_at', current_time('mysql'));
    return $version_id;
}

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

امنیت و حق ویرایش

سه لایه امنیتی ضروری است:

  1. حفظ اصالت متن اصلی با ذخیره تغییرناپذیر و Hash محتوا.
  2. ثبت لاگ هر دسترسی و هر پیشنهاد ویرایشی.
  3. الزام تأیید نویسنده برای اعمال هر تغییر در متن او.

برای مطالعه بیشتر درباره کدنویسی امن، مطلب نوشتن کد PHP امن برای وردپرس را ببینید. برای Nonce، مطلب نانس وردپرس و امنیت فرم را ببینید. برای امن‌سازی احراز هویت، مطلب تقویت احراز هویت در وردپرس را ببینید.

مرجع فنی این حوزه در ویکی‌پدیا، مقاله Copy editing مرور خوبی از اصول و تاریخ ویراستاری ارائه می‌دهد.

پرسش‌های پرتکرار درباره تنظیمات نقش ویراستاری

آیا می‌توانم از نقش Editor وردپرس استفاده کنم؟

خیر. Editor به همه پست‌ها دسترسی دارد و می‌تواند متن اصلی را تغییر دهد. باید نقش سفارشی با Capability اختصاصی بسازید.

چگونه متن اصلی را تغییرناپذیر نگه دارم؟

با ذخیره نسخه اصلی در یک CPT جداگانه که فقط read دارد و هرگز ویرایش نمی‌شود. تغییرات به‌عنوان پیشنهاد جداگانه ثبت می‌شوند.

آیا نویسنده باید هر تغییر را تأیید کند؟

بله. در ویراستاری حرفه‌ای، حق مؤلف ایجاب می‌کند که نویسنده از هر تغییر مطلع و آن را تأیید کند.

چگونه سبک ویرایشی مشتری را ذخیره کنم؟

در یک Style Guide اختصاصی با استفاده از ACF. مطلب فیلدهای سفارشی ACF و کاربردهای واقعی آن را ببینید.

آیا استفاده از AI برای ویراستاری مفید است؟

به‌عنوان کمک اولیه، بله. اما تصمیم نهایی باید توسط ویراستار انسانی باشد.

اشتباهات رایج

اشتباه پیامد راه‌حل
ویرایش مستقیم متن اصلی از دست رفتن اصالت ذخیره تغییرناپذیر + پیشنهاد جداگانه
نبود Track Changes عدم امکان ردیابی تغییرات CPT اختصاصی برای پیشنهادها
نقش یکسان برای همه ویراستاران دسترسی به متن‌های غیرمجاز Capability اختصاصی + تخصیص دینامیک
نبود تأیید نویسنده نقض حق مؤلف State Machine با تأیید نهایی
نبود لاگ دسترسی عدم امکان استناد حقوقی ثبت هر دسترسی در جدول اختصاصی

نگاه معماری در سطح سیستم‌های ویراستاری

در سطح معماری، سایت ویراستاری با یک چالش بنیادین روبه‌روست: متن یک دارایی است که در طول زمان تکامل می‌یابد، اما اصالت آن باید حفظ شود. این یعنی نیازمند یک معماری «Immutable + Diff» هستیم که متن اصلی را دست‌نخورده نگه دارد و تغییرات را به‌صورت Delta ذخیره کند.

رویکرد پیشنهادی، معماری «Content Provenance Chain» است. هر نسخه از متن به نسخه قبلی متصل می‌شود و Hash آن ثبت می‌شود. این ساختار، مشابه Git است و امکان ردیابی کامل تاریخچه را فراهم می‌کند.

نکته دوم، بحث «Semantic Diff» است. برای اینکه ویراستار بتواند تغییرات را به‌صورت معنادار ببیند، Diff باید در سطح کلمه و پاراگراف باشد، نه فقط در سطح کاراکتر. این نیازمند یک الگوریتم Diff پیشرفته است.

نکته سوم، بحث «Editorial Policy Engine» است. سبک ویرایشی هر مشتری باید به‌صورت خودکار قابل اعمال باشد. این نیازمند یک موتور قواعد است که پیشنهادهای ویرایشی را بر اساس Style Guide تولید کند.

پیشنهادهای عملی برای پیاده‌سازی

سه توصیه عملی که در پروژه‌های واقعی مؤثر بوده‌اند:

  1. متن اصلی را در یک CPT تغییرناپذیر ذخیره کنید و همه تغییرات را به‌عنوان پیشنهاد جداگانه ثبت کنید.
  2. هر نسخه را با Hash محتوا و امضای نویسنده ثبت کنید تا در صورت اختلاف، قابل استناد باشد.
  3. یک Endpoint عمومی برای تأیید اصالت متن طراحی کنید تا در صورت سرقت ادبی، قابل استناد باشد.

اگر این چالش‌ها را در یک پروژه واقعی تجربه کرده‌اید، برای ما جالب است بدانید کدام بخش بیشترین زمان را گرفت: پیاده‌سازی Track Changes، چرخه تأیید، یا طراحی Semantic Diff. تجربه خود را در دیدگاه‌ها بنویسید.