mehdi keyvani ۰۷ دی ۱۳۹۵ بدون نظر 643 بازدید
ایجاد یک Licensed Controlled Theme و پلاگین بروزرسانی سیستم، بخش دوم: API مدیریت لایسنس

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

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

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

در هنگام کار با پلاگین، موارد زیر را یاد خواهید گرفت:

– ساخت یک API در بالای پلاگین وردپرس.
– ایجاد صفحه تنظیمات.
– بارگذاری فایل‌ها در سرویس ذخیره‌سازی ساده آمازون.
– استفاده از AWS SDK برای URL‌های امضا‌شده که برای دانلود فایل‌های خصوصی از اس۳ استفاده می‌شوند.

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

حال بیایید شروع کنیم.

ایجاد API مدیریت لایسنس

یک API معانی مختلفی دارد. در این آموزش، API به معنی مجموعه از عملکردها است( متد هم می‌توان گفت) که می‌توان آنرا روی اتصال HTTP فراخوانی کرده، تا بتوان به خوبی عملکرد بخشی از یک برنامه کاربردی را محدودکرده و تعیین کرد.

در بخش سوم این آموزش، ما از این API در قالب و پلاگین وردپرس ویژه استفاده می‌کنیم، تا صحت لایسنس را بررسی کرده و بروزرسانی‌ها را دانلود کند، اما خود API به تنهایی هیچ محدودیتی ندارد. برنامه‌ای که از API استفاده می‌کند باید مانند یک بازی برای فعال‌سازی نیاز به کلید لایسنس داشته باشد.

API ما از طریق آدرس http:///api/license-manager/v1/ در دسترس است، که به جای yoursite آدرس سایت وردپرس‌تان که پلاگین مدیریت لایسنس وردپرس در آن است قرار می‌گیرد. این API دو تابع دارد:

– info: اگر کلید لایسنس صحیح باشد، اطلاعات محصول درخواست شده را برمی‌گرداند.
– get: اگر کلید لایسنس صحیح باشد، فایل‌های قابل دانلود را برمی‌گرداند.

حالا شروع کنید به ساختن!

قدم اول: ایجاد یک کلاس برای عملکر API
تاکنون، ما از کلاس‌های موجود در قالب استاندارد پلاگین وردپرس استفاده می‌کردیم، اما حالا، برای اینکه همه چیز مرتب باشد، یک کلاس برای ذخیره عملکردهای خاص API اضافه کنید.

یک API بخشی از نمای عمومی پلاگین است، پس باید کلاس ساخته شده را در پوشه public قالب استاندارد پلاگین قرار دهیم. کلاس API را Wp_License_Manager_API بنامید و آنرا در فایلی به نام class-wp-license-manager-api.php قرار دهید.

و حالا کلاس را خالی کنید:

/**
 * The API handler for handling API requests from themes and plugins using
 * the license manager.
 *
 * @package    Wp_License_Manager
 * @subpackage Wp_License_Manager/public
 * @author     Jarkko Laine <jarkko@jarkkolaine.com>
 */
class Wp_License_Manager_API {
 
}

کلاسی که جدیدا ایجاد کردید را به کلاس Wp_License_Manager_Public پیوند دهید تا قابل دسترس باشد. ابتدا یک فیلد برای کلاس API اضافه کنید:

/**
 * @var     License_Manager_API     The API handler
 */
private $api;

سپس آنرا در contructor مقداردهی اولیه کنید( خط ۱۱ جدید است، باقی کدها از بخش اول است).

/**
 * Initialize the class and set its properties.
 *
 * @var      string    $plugin_name       The name of the plugin.
 * @var      string    $version    The version of this plugin.
 */
public function __construct( $plugin_name, $version ) {
    $this->plugin_name = $plugin_name;
    $this->version = $version;
 
    $this->api = new Wp_License_Manager_API();   
}

حالا، همه چیز آماده ساخت عملکر API است.

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

به طور پیشفرض، URLهای وردپرس ترکیبی از فایل index.php و مجموعه‌ای از پارامترهای کوئری هستند، برای مثال: http:///?p=123 ( فایل index.php از این URL حذف شده، اما در جایی که درخواست داده می‌شود، وجود دارد). اغلب سایت‌ها از تنظیمات لینک دائمی زیباتری استفاده می‌کنند – و ما هم استفاده خواهیم کرد – تا URLهایشان خواندنی‌تر شود، ولی این فقط یک لایه تزیین‌شده در بالای هسته عملکرد است.

پس، برای ایجاد API خودمان، اول مورد افزودن یک متغییر کوئری سفارشی به نام wp_license_api__ است، تا به جای p از آن استفاده کنیم. سپس، یک بار که کار کرد، تنظیمات لینک دائمی سفارشی را اضافه خواهیم کرد تا API خواندنی‌تر شود.

در آخر تابع define_public_hooks در کلاس Wp_License_Manager، خط زیر را برای پیوند به یم فیلتر برای قلاب زدن query_vars اضافه کنید:

// The external API setup
$this->loader->add_filter( 'query_vars', $plugin_public, 'add_api_query_vars' );

سپس، تابع را به کلاس Wp_License_Manager_Public اضافه کنید:

/**
 * Defines the query variables used by the API.
 *
 * @param $vars     array   Existing query variables from WordPress.
 * @return array    The $vars array appended with our new variables
 */
public function add_api_query_vars( $vars ) {
    // The parameter used for checking the action used
    $vars []= '__wp_license_api';
 
    // Additional parameters defined by the API requests
    $api_vars = $this->api->get_api_vars();
 
    return array_merge( $vars, $api_vars );
}

این تابع با افزودن متغییرهای کوئری ما به آرایه vars$ و گذراندن آنها از فیلتر و سپس بازیابی آرایه دیگر، آنها را به لیست سفید وردپرس اضافه می‌کند:

خط ۹: متغییری برای عملکرد wp_license_api__ که مختص API است را، اضافه می‌کند( و تشخیص می‌دهد که آیا درخواست برای API است).

خط ۱۲: یک فرصت به API می‌دهد برای افزودن پارامترهای اضافی که در توابعش استفاده کرده است.

خط ۱۴: آرایه بروزشده vars$ را برمی‌گرداند.

برای اینکه کد کار کند، هنوز احتیاج به ساخت تابع get_api_vars داریم:

/**
 * Returns a list of variables used by the API
 *
 * @return  array    An array of query variable names.
 */
public function get_api_vars() {
    return array( 'l',  'e', 'p' );
}

در حال حاضر، همانطور که API خیلی ساده است، بنده تصمیم گرفتم که تابعی با تمامی پارامترها در یک آرایه ایجاد کنم و آنها ر ابرگرداند.

قدم سوم: گرفتن درخواست‌ها API
اکنون متغییرهای کوئری‌مان در لیست سفید است، اما هنوز کاری انجام نمی‌دهند. برای اینکه متغییرها تفاوت ایجاد کنند، نیاز به ساخت عملکردی برای گرفتن درخواست‌ها است.

این کار با استفاده از عملکرد parse_request انجام می‌شود:

در define_public_hooks که در Wp_License_Manager است، یک تابع را به عملکرد پیوند دهید:

$this->loader->add_action( 'parse_request', $plugin_public, 'sniff_api_requests' );

حال، همه درخواست‌های وردپرس از این تابع می‌گذرند قبل از اینکه به توابع کنترل‌کننده درخواست خود وردپرس برسند. این بدین معناست که ما نیاز به نگهداری تابع کنترل‌کننده سبکی داریم: وجود wp_license_api__ را بررسی کنید اگر نبود، سریعا آنرا بازگردانده، و اجازه دهید تا وردپرس به کار خود ادامه دهید. اما اگر وجود داشت، زمان آن است که بررسی‌های پیچیده‌تری انجام دهیم – این درخواست ماست و ما آنرا کنتل خواهیم کرد.

در زیر تابع sniff_api_requsts را در Wp_License_Manager_Public می‌بینید:

/**
 * A sniffer function that looks for API calls and passes them to our API handler.
 */
public function sniff_api_requests() {
    global $wp;
    if ( isset( $wp->query_vars['__wp_license_api'] ) ) {
        $action = $wp->query_vars['__wp_license_api'];
        $this->api->handle_request( $action, $wp->query_vars );
 
        exit;
    }
}

خط ۶: حضور متغییر کوئری عملکرد API را بررسی می‌کند. اگر وجود داشت، این خواسته‌ای برای رسیدگی به API است.

خط ۷ تا ۸: درخواست را برای رسیدگی، به تابع handle_request در کلاس API ارسال می‌کند. این تابع را در آینده خواهیم ساخت.

خط ۱۰: زمانی که فراخوانی API را انجام داده شد، اجرای وردپرس را متوقف می‌کند. این مسئله به این جهت اهمیت دارد، در غیر این صورت عملیات در وردپرس ادامه پیدا می‌کند و بعد از خروجی API، یک صفحه‌ی خطای ۴۰۴ نمایش می‌یابد.

بعد، تابع handle_request را اضافه کنید.

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

/**
 * The handler function that receives the API calls and passes them on to the
 * proper handlers.
 *
 * @param $action   string  The name of the action
 * @param $params   array   Request parameters
 */
public function handle_request( $action, $params ) {
    switch ( $action ) {
        case 'info':
            break;
 
        case 'get':
            break;
 
        default:
            $response = $this->error_response( 'No such API action' );
            break;
    }
 
    $this->send_response( $response );
}

خط ۱۷: response$ آرایه‌‌ای برای ارسال داده به برنامه‌ای که API را فراخوانی کرده، است.

خط ۲۱: جواب را به عنوان رشته رمزشده JSON چاپ می‌کند.

برای اجرای تابع هنوز به افزودن توبع کمکی send_response و error_response نیاز است:

ابتدا، send_response:

/**
 * Prints out the JSON response for an API call.
 *
 * @param $response array   The response as associative array.
 */
private function send_response( $response ) {
    echo json_encode( $response );
}

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

درحال حاضر، بنده تصمیم گرفتم از نسخه اصلی خالی، فقط با یک پیام خطا درون آرایه استفاده کنم:

/**
 * Generates and returns a simple error response. Used to make sure every error
 * message uses same formatting.
 *
 * @param $msg      string  The message to be included in the error response.
 * @return array    The error response as an array that can be passed to send_response.
 */
private function error_response( $msg ) {
    return array( 'error' => $msg );
}

اکنون، شما ساختار درونی را ساخته‌اید، و می‌توان ایجاد عملکردهای API را شروع کرد. برای آزمایش آن، تلاش کنید تا یک عملکرد ناموجود API را فراخوانی کنید، برای مثال http:///?__wp_license_api=dummy-action ، را در مرورگر خود جستجو کنید.

باید چیزی شبیه به تصویر زیر مشاهده کنید:

error_response

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

حالا، قبل از افزودن عملکرد به API، بیایید آدرس API را ساده‌تر کنیم.

قدم چهارم: ایجاد قالب URL سفارشی برای API
در حالیکه http:///?__wp_license_api= کار می‌کند، اما به عقیده من، گیرا نیست، و همچنین یک مقدار بیش از حد محتوای API درحال اجرا را نمایش می‌دهد. پس، به جای آن یک URL بهتر را درست کنید.

همانطور که از ابتدای این بخش به خاطر دارید، URLای که ما استفاده خواهیم کرد http:///api/license-manager/v1/ است.

بنده v1 را به این آدرس API اضافه کردم تا امکان پشتیبانی از چندین نسخه مختلف API فراهم شود. دانستن اطلاعات صحیح نسخه از اول باعث افزودن ساده‌تر نسخه‌های بعدی می‌شود.

ابتدا، برای زیبا ساختن URLها، گزینه Permalinks در تنظیمات وردپرس را مقداری به جز مقدار پیشفرض بدهید( دیگر گزینه‌ها به جز Default درست هستند).

سپس، یک فیلتربرای ایجاد دستور جدید بازنویسی‌شده، اضافه کنید. فیلتر ثبت‌شده را به تابع define_public_hooks که در Wp_License_Manager است اضافه کنید:

$this->loader->add_action( 'init', $plugin_public, 'add_api_endpoint_rules' );

بعد، تابع را در Wp_License_Manager_Public ایجاد کنید:

/**
 * The permalink structure definition for API calls.
 */
public function add_api_endpoint_rules() {
    add_rewrite_rule( 'api/license-manager/v1/(info|get)/?',
        'index.php?__wp_license_api=$matches[1]', 'top' );
 
    // If this was the first time, flush rules
    if ( get_option( 'wp-license-manager-rewrite-rules-version' ) != '1.1' ) {
        flush_rewrite_rules();
        update_option( 'wp-license-manager-rewrite-rules-version', '1.1' );
    }
}

خط ۵: با استفاده از یک عبارت ساده، URL جدید دستور بازنویسی را تعیین می‌کند تا درخواست‌های قالب‌بندی شده را طبق URLای که از قدم قبلی در ذهن داریم، ارسال کند. (info|get) روش‌هایی که یک API باید بپذیرد، تعیین می‌کند.

خط ۹ تا ۱۲: دستورات بازنویسی را برای فعال سازی، ذخیره می‌کند. flush_rewrite_rules منبع مصرف است پس برای اطمینان از اینکه ترازبندی هنگام تغییر دستورات، انجام می‌شود به آن تابع بررسی اضافه کردم.

حالا، با این قدم کامل‌شده، هر درخواستی به آدرس http:///api/license-manager/v1/ ارسال می‌شود و به درخواستی برای آدرس http:///?__wp_license_api= تبدیل می‌شود. این کار را با عملکرد ساختگی قدم قبلی، آزمایش کنید – اکنون باید نتیجه مشابهی با استفاده از هردو URL بگیرید.

فریم‌ورک‌های API در جای خود مستقر هستند و اکنون می‌توان شروع به افزودن عملکرد کرد.

قدم پنجم: ایجاد عملکرد برای لایسنس‌های تایید‌شده
هر دو عملکرد API که می‌خواهیم در این آموزش ایجاد کنیم با تایید لایسنس کاربر شروع می‌شود.

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

برای صرفه‌جویی در زمانتان، در بخش‌هایی که کدها تکراری هستند، مستقیم به نسخه آخر رفته و کدهای رایج را در تابع آن قرار دهید.

در Wp_License_Manager_API، تابعی به نام verify_license_and_execute ایجاد کنید. این تابع قدمی اضافه‌تر از تابعی که قبلا ایجاد کردیم است و دقیقا کار کنترل درخواست‌ها را انجام می‌دهد.

/**
 * Checks the parameters and verifies the license, then forwards the request to the
 * actual API request handlers.
 *
 * @param $action_function  callable    The function (or array with class and function) to call
 * @param $params           array       The WordPress request parameters.
 * @return array            API response.
 */
private function verify_license_and_execute( $action_function, $params ) {
    if ( ! isset( $params['p'] ) || ! isset( $params['e'] ) || ! isset( $params['l'] ) ) {
        return $this->error_response( 'Invalid request' );
    }
 
    $product_id = $params['p'];
    $email = $params['e'];
    $license_key = $params['l'];
 
    // Find product
    $posts = get_posts(
        array (
            'name' => $product_id,
            'post_type' => 'wplm_product',
            'post_status' => 'publish',
            'numberposts' => 1
        )
    );
 
    if ( ! isset( $posts[0] ) ) {
        return $this->error_response( 'Product not found.' );
    }
 
    // Verify license
    if ( ! $this->verify_license( $posts[0]->ID, $email, $license_key ) ) {
        return $this->error_response( 'Invalid license or license expired.' );
    }
 
    // Call the handler function
    return call_user_func_array( $action_function, array( $posts[0], $product_id, $email, $license_key ) );
}

خط ۱۰ تا ۱۲: تمامی لایسنس‌های را که مطابق پارامترهای موجود هستند را تایید می‌کند. p شماره محصول، e آدرس ایمیل کاربر، و l کلید لایسنس هستند.

خط ۱۴ تا ۱۶: پارامترها را مطابق اصول جمع‌آوری می‌کند.

خط ۱۹ تا ۲۶: هماهنگی آی‌دی محصول با پست را بررسی می‌کند. همانطور که در بالا گفته شد، آی‌دی محصول دقیقا همان شماره پست محصول است تا کاربر مقدار صحیح آنرا بداند.

خط ۲۸ تا ۳۰: اگر محصول موردنظر یافت نشد، پیام خطا برمی‌گرداند.

خط ۳۳ تا ۳۵: دقیقا کار تایید کلید لایسنس را انجام می‌دهد، این تابع را در ادامه خواهیم ساخت.

خط ۳۸: تابعی که مسئول کنترل عملکرد API هست را فراخوانی می‌کند. به عنوان یک ایده پیشرفته در آینده، مکانی عالی است، تا دیگر پلاگین‌ها از آن برای جایگزینی تابع کنترل‌کننده استفاده کنند.

سپس، تابع تایید لایسنس را اضافه کنید:

/**
 * Checks whether a license with the given parameters exists and is still valid.
 *
 * @param $product_id   int     The numeric ID of the product.
 * @param $email        string  The email address attached to the license.
 * @param $license_key  string  The license key.
 * @return bool                 true if license is valid. Otherwise false.
 */
private function verify_license( $product_id, $email, $license_key ) {
    $license = $this->find_license( $product_id, $email, $license_key );
    if ( ! $license ) {
        return false;
    }
 
    $valid_until = strtotime( $license['valid_until'] );
    if ( $license['valid_until'] != '0000-00-00 00:00:00' && time() > $valid_until ) {
        return false;
    }
 
    return true;
}

خط ۱۰ تا ۱۳: لایسنس را با استفاده از پارامتر ارسال، در پایگاه‌داده جستجو می‌کند( این تابع را بعدا اضافه خواهیم کرد). اگر لایسنس پیدا نشد، مورد تایید نیست، پس مقدار false را برمی‌گردانیم.

خط ۱۵ تا ۱۸: اگر لایسنس موجود است، انقضای آنرا برری می‌کند. در بخش اول آموزش، ما تعیین کردیم که مقدار ۰۰۰۰-۰۰-۰۰ ۰۰:۰۰:۰۰ یعنی لایسنس هیچوقت منقرض نمی‌شود.

خط ۲۰: همه بررسی‌ها انجام شده، و لایسنس مورد تایید است.

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

تابع finde_license را اضافه کنید:

/**
 * Looks up a license that matches the given parameters.
 *
 * @param $product_id   int     The numeric ID of the product.
 * @param $email        string  The email address attached to the license.
 * @param $license_key  string  The license key
 * @return mixed                The license data if found. Otherwise false.
 */
private function find_license( $product_id, $email, $license_key ) {
    global $wpdb;
    $table_name = $wpdb->prefix . 'product_licenses';
 
    $licenses = $wpdb->get_results(
        $wpdb->prepare( "SELECT * FROM $table_name WHERE product_id = %d AND email = '%s' AND license_key = '%s'",
            $product_id, $email, $license_key ), ARRAY_A );
 
    if ( count( $licenses ) > 0 ) {
        return $licenses[0];
    }
 
    return false;
}

در این تابع، یک کوئری SQL برای جستجوی لایسنسی که پارامترهای آی‌دی محصول، ایمیل و کلید لایسنس آن ارسال شده، ایجاد کردیم. در این روش، برای نتیجه یا عدم نتیجه نیازی به تجزیه جواب نیست.

اگر لایسنس پیدا شد، تابع آنرا برمی‌گرداند. در غیر این‌صورت، false برمی‌گرداند.

قدم ششم: افزودن عملکرد اطلاعات محصول API
در ادامه، عملکرد info را اضافه کنید. در تابع handle_request که قبلا آنرا ایجاد کردیم، بخش مورد نظر برای عملکرد را پر کنید:

case 'info':
    $response = $this->verify_license_and_execute( array( $this, 'product_info' ), $params );
    break;

خطی که اضافه کردیم، تابع verify_license_and_execute را با دو پارامتر فراخوانی می‌کند:

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

پیش از این فهمیدیم که چه اتفاقی درون verify_license_and_execute می‌افتد، پس حالا، تابع product_info را اضافه کنید. این تابع اطلاعات محصول را جمع‌آوری کرده و در قالب آرایه برمی‌گرداند.

احتمالا از بخش اول آموزش به یاد دارید، که محصولات در پلاگین مدیریت لایسنس به عنوان نوع پست سفارشی با یک متاباکس برای ورود اطلاعات اضافی محصول، ذخیره شده‌اند. در این تابع، ما به آن داده‌ها وصل شده و آرایه response$ را با اطلاعات محصول درخواست‌شده پر می‌کنیم.

/**
 * The handler for the "info" request. Checks the user's license information and
 * returns information about the product (latest version, name, update url).
 *
 * @param   $product        WP_Post   The product object
 * @param   $product_id     string    The product id (slug)
 * @param   $email          string    The email address associated with the license
 * @param   $license_key    string  The license key associated with the license
 *
 * @return  array           The API response as an array.
 */
private function product_info( $product, $product_id, $email, $license_key ) {
    // Collect all the metadata we have and return it to the caller
    $meta = get_post_meta( $product->ID, 'wp_license_manager_product_meta', true );
 
    $version = isset( $meta['version'] ) ? $meta['version'] : '';        
    $tested = isset( $meta['tested'] ) ? $meta['tested'] : '';
    $last_updated = isset( $meta['updated'] ) ? $meta['updated'] : '';
    $author = isset( $meta['author'] ) ? $meta['author'] : '';
    $banner_low = isset( $meta['banner_low'] ) ? $meta['banner_low'] : '';
    $banner_high = isset( $meta['banner_high'] ) ? $meta['banner_high'] : '';
 
    return array(
        'name' => $product->post_title,
        'description' => $product->post_content,
        'version' => $version,
        'tested' => $tested,
        'author' => $author,
        'last_updated' => $last_updated,
        'banner_low' => $banner_low,
        'banner_high' => $banner_high,
        "package_url" => home_url( '/api/license-manager/v1/get?p=' . $product_id . '&e=' . $email . '&l=' . urlencode( $license_key ) ),
        "description_url" => get_permalink( $product->ID ) . '#v=' . $version
    );
}

خط ۱۴: اطلاعات محصول را از پست فراداده بازیابی می‌کند.

خط ۱۶ تا ۲۱: داده‌ها را از فیلدهای فراداده جمع‌آوری می‌کند.

خط ۲۳ تا ۲۴: واکنشی ایجاد می‌کند. اساسا این واکنش برای قرار دادن داده‌های خطوط ۱۶ تا ۲۱ درون یک آرایه است. گر چه در خط ۳۲ توجهات بیشتری شده است.

این موارد برای سیستم بروزرسانی وردپس که در بخش بعدی آموزش است، استفاده می‌شود. برای اینکه همه چیزی در قدم بعدی راحت باشد، عملکرد info آدرس URL را عملکرد دیگر API به نام get، با همه پارامترهای مورد نیاز نشان می‌دهد.

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

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

خروجی بر اساس داده محصولاتتان مانند تصویر زیر خواهد شد:

Test the API Action

ذخیره فایل‌ها در Amazon S3

با توجه به اینکه نیمی از API کامل‌شده، زمان آن است تا نگاهی به تابع get بیندازیم. این تابع همانند تابع info کلید لایسنس را بررسی کرده و سپس فایل قابل پانلود را برمی‌گرداند.

برای اینکه عملکرد API حس ایجاد کنید، مهم است که دانلود بدون کلید لایسنس تاییدشده قابل دسترس نباشد و نتوان به سادگی آنرا دور زد و مستقیم به فایل دسترسی پیدا کرد. Amazon S3 قابلیتی را آسان و مقرون به صرفه( برای اغلب کاربران مجانی) برای دانلود مطمئن، به ما می‌دهد.

در قدم‌های بعدی، ابتدا طریقه آپلود فایل‌ها در Amazon S3 با استفاده از داشبورد آنلاین AWS( سرویس‌های وب آمازون) یاد خواهیم گرفت. سپس، یک‌بار که فایل آپلود شد، عملکرد دانلود را به API خود اضافه می‌کنیم.

اگر قلا از Amazon S3 استفاده کرده‌اید و دانش لازم برای آن را دارید، می‌توانید مستقیما به بخش بعد رفته و شروع به اجرای عملکرد get کنید. اگر با S3 آشنا نیستید، بخ خواندن ادامه دهید.

قدم اول: ایجاد حساب کاربری

ایجاد حساب کاربری AWS راحت است، اما مراحل زیادی دارد، پس سریعا شروع کنید.

ابتدا، به سایت aws.amazon.com رفته و روی Sign Up در بالا گوشه سمت راست کلیک کنید.

در تصویر زیر، هم می‌توانید در Amazon حساب کاربری جدیدی ایجاد کنید یا از حساب کاربری که برای استفاده از دیگر سرویس‌های Amazon که قبلا ایجاد کردید استفاده کنید( برای مثال فروشگاه آنلاین خود Amazon):

Create an Account

انتخاب با شماست: اگر تصمیم به ایجاد یک حساب کاربری جدید گرفتید، که در مرحله بعد انجام خواهد شد. اما اگر از حساب قبلی خود استفاده می‌کنید، پنج قدم از ایجاد حساب کاربری AWS را گذرانده‌اید. در طول ثبت‌نام، اطلاعات کارت بانکی شما پرسیده خواهد شد – نگران قیمت نباشید زیرا برای استفاده‌های معمول است.

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

verify your phone number

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

اکنون حساب شما ایجاد و فعال شده، و آماده افزودن فایل‌ها است.

قدم دوم: ایجاد باکت
به کنسول مدیریت AWS رفته و از بین گزینه‌های موجود S3 را انتخاب کنید:

Create Bucket

قابلیت‌های زیادی در بخش مدیر AWS وجود دارد، اما می‌توانید باقی گزینه‌ها را رد کنید( زیرا آنها موارد پیشرفته‌ای هستند که بیشتر توسعه دهندگان وردپرس به آنها احتیاجی ندارند – بنده فقط از S3 و EC2 استفاده می‌کنم).

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

هر چیزی که در Amazon S3 ذخیره می‌کنید در باکت قرار می‌گیرد. می‌توانید باکت‌ها را براساس موارد آنها گروه بندی کنید همانند روشی که در گروه‌بندی فایل‌ها در سیستم فایل استفاده می‌کنید. باکت‌ها گزینه‌هایی نظیر مجوزهای دسترسی و وضعیت نسخه دارند، و می‌توانید منطقه قرارگیری آنها را مشخص کنید.

S3 admin console

برای باکت خود نامی متشکل از حروف کوچک، اعداد، خط تیره‌ها و نقطه‌ها اختصاص دهید( برای اطلاعات بیشتر، مستندات را بررسی کنید) و روی Create کلیک کنید.

اگر دوست دارید، می‌توانید مکانی برای ذخیره فایلهایتان انتخاب کنید. به‌هر‌حال، برای تکمیل کار OK را زده و تنظیمات را در حالت پیشفرض خود بگذارید.

یک‌بار که باکت ایجاد شد، ظاهر مرورگر فایل باکت ایجاد شده را مشاهده خواهید کرد:

file browser

در این تصویر، باکت‌های جدیدی را می‌توان ایجاد کرد. اکنون هین یک مورد کافیست. روی نام باکت کلیک کرده تا بتوانید فایل‌ها را اضافه کنید.

قدم سوم: آپلود فایل‌ها

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

روی دکمه Upload که در بالا گوشه سمت چپ صفحه مدیر S3 هست، کلیک کنید.صفحه بارگذاری ظاهر می‌شود:

upload screen

برای انتخاب و بارگذاری فایل‌ها Add Files را انتخاب کنید. و سپس روی Start Upload کلیک کنید.

ما می‌توانستیم از Set Details برای تعیین مجوز‌های فایل استفاده کنیم، ولی اگر نمی‌خواهیم دانلود به طور عمومی در اختیار باشد، گزینه‌های پیشفرض چیزی است که ما می‌خواهیم.

یک‌بار که فایل آپلود شد، آن را در باکت خواهید دید:

Set Details

پنجره انتقال را با کلیک برروی ضربدر بالا گوشه سمت راست ببندید. سپس فایل را انتخاب کرده و Properties را از منوی بالا سمت راست انتخاب کنید:

Properties

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

اگر همه موارد هم کامل باشد، شما نباید قادر به دانلود باشید: حتی اگر بازدیدکننده دیگری هم URL دقیق برای دانلود فایلتان را بداند،‌ با گذر از بررسی لایسنس در فراخوانی API هم نباید قادر به دانلود فایل باشد.

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

download the file

به عنوان آخرین قدم و قبل از کدنویسی، یک محصول با استفاده از پلاگین مدیریت لایسنس ما( یا با بروزرسانی مورد اول) ایجاد کرده و اطلاعات دانلود فایل را اضافه کنید:

product in WordPress

خدمات دانلود از S3

حالا که با موفقیت فایل‌ها را در Amazon S3 آپلود کردید، کاری کنید که API مدیریت لایسنس فایلی که درخواست شده را برگرداند – اما فقط اگر لایسنس کاربر تایید شود.

بدین منظور، حفره عملکرد API را که به تابع کنترل‌کننده API به نام handle_request اضافه کردیم، پر می‌کنیم. این عملکرد ابتدا با استفاده از verify_license_and_execute لایسنس را بررسی کرده و سپس از کتابخانه رسمی AWS در Amazon برای ایجاد و برگرداندن یک لینک دانلود علامت‌دار به فایل قابل دانلود محصول استفاده می‌کند.

قدم اول: دانلود و استفاده از کتابخانه AWS
برای شروع، ابتدا، فایل AWS SDK برای PHP را از Amazon دانلود کنید.

راه‌های زیادی برای استفاده از فایل‌های SDK در پروژه وجود دارد، اما پیشنهاد می‌دهم که از فایل زیپ حتی اگر قدیمی است، استفاده کنید: SDK شامل عملکردهایی برای استفاده از تمامی مشخصه‌های AWS است – همانطور که قبلا بسیاری از آنها را مشاهده کردید – و فقط ما S3 را از بین آنها استفاده می‌کنیم. دانلود فایل زیپ و پخش و استفاده از آن به صورت دستی در پروژه‌تان، به شما فرصتی برای حذف فایل‌های اضافی که فضا اشغال کرده‌اند را می‌دهد.

یک‌بار که فایل SDK را از AWS دانلود کردید، پوشه‌ای به اسم lib در پوشه wp_license_manager ایجاد کنید. درون آن، پوشه به نام aws که حاوی محتویات درون فایل زیپ SDK هست، ایجاد کنید.

حالا، اگر دوست دارید، می‌توانید محتویات اضافی پوشه را حذف کرده، و فقط پوشه‌های Common و S3 را در aws نگه‌دارید. اگر از نظر اندازه پلاگین مشکلی ندارد، می‌توانید این مرحله را با همه محتویات SDK رد کنید.

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

SDK از فضاهای نام استفاده کرده، که یکی از مشخصه‌های اضافه شده به PHP 5.3 است. PHP رسمی موردنیاز وردپرس ۵.۲.۶ بوده، پس SDK با هر وردپرسی کار نمی‌کند.

روشی که می‌توان این محدودیت را گذراند این است که یا از کتابخانه شخص ثالث S3 استفاده کنید، یا یک نمونه خودتان بنویسید. با این حال، در اصل استفاده از فایل رسمی SDK بیشتر توصیه شده، این بار از آن راه استفاده کنید. در نسخه پلاگینی که برای انبار پلاگین وردپرس منتشرشده، بنده هم از نسخه AWS SDK و هم مجدد از نسخه مستقل کتابخانه S3 استفاده کرده‌ام. پلاگین بر اساس نسخه PHP سیستم، از پلاگین درست در حین اجرا استفاده می‌کند.

با این حال، در این آموزش، همه چیز را ساده می‌گیریم و فقط از یک نسخه از AWS SDK استفاده می‌کنیم.

کلاس جدیدی با نام Wp_License_Manager_S3 ایجاد کرده و آنرا در پوشه includes پلاگین قرار دهید:

<?php
/**
 * A wrapper for our Amazon S3 API actions.
 *
 * @package    Wp_License_Manager
 * @subpackage Wp_License_Manager/includes
 * @author     Jarkko Laine <jarkko@jarkkolaine.com>
 */
class Wp_License_Manager_S3 {
 
}

برای استفاده از کلاس در پروژه، خط زیر را به تابع load_dependencies در Wp_License_Manager اضافه کنید:

/**
 * A wrapper class for our Amazon S3 connectivity.
 */
require_once plugin_dir_path( dirname( __FILE__ ) ) . 'includes/class-wp-license-manager-s3.php';
require_once plugin_dir_path( dirname( __FILE__ ) ) . 'lib/aws/aws-autoloader.php';

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

قدم دوم: ایجاد تابعی برای تولید لینک دانلود
تابع زیر را برای تولید لینک دانلود علامت‌دار درون کلاس Wp_License_Manager_S3 اضافه کرده، تا بتوان برای دانلود فایل‌‌های حفاظت‌شده از Amazon S3 استفاده کرد:

/**
 * Returns a signed Amazon S3 download URL.
 *
 * @param $bucket       string  Bucket name
 * @param $file_name    string  File name (URI)
 * @return string       The signed download URL
 */
public static function get_s3_url( $bucket, $file_name ) {
    $options = get_option( 'wp-license-manager-settings' );
 
    $s3_client = Aws\S3\S3Client::factory(
        array(
            'key'    => $options['aws_key'],
            'secret' => $options['aws_secret']
        )
    );
 
    return $s3_client->getObjectUrl( $bucket, $file_name, '+10 minutes' );
}

بیایید تابع را بررسی کنیم:

خط ۱۱ تا ۱۶: کلاس مشتری Amazon S3 را ایجاد می‌کند، به عنوان مثال ایجاد لینک دانلود. SDK به گواهی‌نامه‌های امنیتی AWS نیاز دارد، که با استفاده از صفحه تنظیمات که در قدم بعدی ایجاد می‌کنیم، در گزینه‌های وردپرس ذخیره خواهیم کرد.

خط ۱۸: با استفاده از SDK برای باکت و نام فایل داده شده یک لینک دانلود تولید می‌کند. لینک دانلود به مدت ده دقیقه معتبر خواهد بود پس کاربر زمان کافی برای دانلود دارد.

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

بدین منظور، از Settings API استفاده کنید. با استفاده از Settings API در سه مرحله یک صفحه تنظیمات ایجاد کنید: فیلدهای تنظیمات مقداردهی اولیه کرده، صفحه تنظیمات را اضافه کرده، و توابع تفسیر کننده برای قسمت‌های مختلف صفحه تنظیمات را تعیین کنید.

با افزودن دو عملکرد، یکی به admin_init و دیگری به admin_menu شروع می‌شود:

// Plugin settings menu
$this->loader->add_action( ‘admin_init’, $plugin_admin, ‘add_plugin_settings_fields’);
$this->loader->add_action( ‘admin_menu’, $plugin_admin, ‘add_plugin_settings_pa

اکنون که عملکردها را اضافه کردید، تابعی برای کنترل آنها ایجاد کنید. هر دو آنها باید به کلاس Wp_License_Manager_Admin اضافه شوند.

ابتدا، تابع add_plugin_settings_fields را که یک بخش تنظیمات را مقداردهی اولیه خواهد کرد، اضافه کرده، و سپس دو فیلد از تنظیمات را درون آن قرار دهید:

/**
 * Creates the settings fields for the plugin options page.
 */
public function add_plugin_settings_fields() {
    $settings_group_id = 'wp-license-manager-settings-group';
    $aws_settings_section_id = 'wp-license-manager-settings-section-aws';
    $settings_field_id = 'wp-license-manager-settings';
 
    register_setting( $settings_group_id, $settings_field_id );
 
    add_settings_section(
        $aws_settings_section_id,
        __( 'Amazon Web Services', $this->plugin_name ),
        array( $this, 'render_aws_settings_section' ),
        $settings_group_id
    );
 
    add_settings_field(
        'aws-key',
        __( 'AWS public key', $this->plugin_name ),
        array( $this, 'render_aws_key_settings_field' ),
        $settings_group_id,
        $aws_settings_section_id
    );
 
    add_settings_field(
        'aws-secret',
        __( 'AWS secret', $this->plugin_name ),
        array( $this, 'render_aws_secret_settings_field' ),
        $settings_group_id,
        $aws_settings_section_id
    );
}

خط ۵ تا ۷: سه متغیر که با فیلد تنظیمات و بخش، همنام هستند را مقداردهی اولیه می‌کند. این اطمینان را به ما می‌دهد که غلط املای نداشته باشیم…

خط ۹: آیتم ‘wp-license-manager-settings’ تنظیمات را ثبت می‌کند. آرایه‌ای خواهد بود که تنظیمات aws-key و aws-secret در آن ذخیره خواهد شد.

خط ۱۱ تا ۱۶: بخش تنظیمات را که حاوی هر دو فیلد خواهد بود، اضافه می‌کند.

خط ۱۸ تا ۳۲: دو فیلد تنظیمات ما( aws-key و aws-secret) را در بخش تنظیمات قرار می‌دهد.

اکنون، تابع add_plugin_settings_page را اضافه کنید. این تابع با استفاده از تابع add_options_page صفحه تنظیماتی به عنوان فرزند منو تنظیمات اصلی ایجاد می‌کند.

/**
 * Adds an options page for plugin settings.
 */
public function add_plugin_settings_page() {
    add_options_page(
        __( 'License Manager', $this->plugin_name ),
        __( 'License Manager Settings', $this->plugin_name ),
        'manage_options',
        'wp-license-settings',
        array( $this, 'render_settings_page' )
    );
}

هر کدام از عناصر توبع Settings API بالا( صفحه تنظیمات، بخش تنظیمات و هر دو فیلد تنظیمات) تابع تفسیرکننده را به عنوان پارامتر می‌گیرند.

برای تکمیل نصب صفحه تنظیمات، توابع نمایش آنها را ایجاد کنید:

/**
 * Renders the plugin's options page.
 */
public function render_settings_page() {
    $settings_group_id = 'wp-license-manager-settings-group';
    require plugin_dir_path( dirname( __FILE__ ) ) . 'admin/partials/settings_page.php';
}
 
/**
 * Renders the description for the AWS settings section.
 */
public function render_aws_settings_section() {
    // We use a partial here to make it easier to add more complex instructions
    require plugin_dir_path( dirname( __FILE__ ) ) . 'admin/partials/aws_settings_group_instructions.php';
}
 
/**
 * Renders the settings field for the AWS key.
 */
public function render_aws_key_settings_field() {
    $settings_field_id = 'wp-license-manager-settings';
    $options = get_option( $settings_field_id );
    ?>
        <input type='text' name='<?php echo $settings_field_id; ?>[aws_key]' value='<?php echo $options['aws_key']; ?>' class='regular-text'>
    <?php
}
 
/**
 * Renders the settings field for the AWS secret.
 */
public function render_aws_secret_settings_field() {
    $settings_field_id = 'wp-license-manager-settings';
    $options = get_option( $settings_field_id );
    ?>
       <input type='text' name='<?php echo $settings_field_id; ?>[aws_secret]' value='<?php echo $options['aws_secret']; ?>' class='regular-text'>
    <?php
}

توابع تفسیر فیلد تنظیمات render_aws_key_settings_field و render_aws_secret_settings_field هستند، که اساسا همانند هم کار می‌کنند: ابتدا، گزینه‌های پلاگین را بازیابی کرده و سپس یک فیلد متنی را با نام و مقدار فعلی تنظیمات چاپ می‌کند.

توابع تفسیر صفحه تنظیمات( render_settings_page) و بخش تنظیمات(render_aws_settings_section) همانند هم هستند، ولی جای چاپHTML همانجا در تابع، از قالب‌های جداگانه HTML استفاده می‌کنند. این بدون شک راه درست نیست – بنده این رویکرد را انتخاب کردم زیرا این توابع چیزی فراتر از HTML را هم تفسیر می‌کنند، و امکان دارد که در آینده نیاز به تمدید آنها باشد.

در زیر قالب‌ها را مشاهده می‌کنید. ابتدا، admin/partials/settings_page.php که قسمتی از صفحه تنظیمات است:

<?php
/**
 * The view for the plugin's options page.
 *
 * @package    Wp_License_Manager
 * @subpackage Wp_License_Manager/admin/partials
 */
?>
 
<div class="wrap">
    <div id="icon-edit" class="icon32 icon32-posts-post"></div>
 
    <h2>
        <?php _e( 'WP License Manager Settings', $this->plugin_name ); ?>
    </h2>
 
    <form action='options.php' method='post'>
        <?php
        settings_fields( $settings_group_id );
        do_settings_sections( $settings_group_id );
        submit_button();
        ?>
    </form>
</div>

قسمت مهیج در انتهای فایل PHP است، جایی که فرم را ایجاد کرده و فیلدها، بخش‌ها، و دکمه ارسال را قرار می‌دهیم.

قسمتی از بخش تنظیمات( admin/partials/aws_settings_group_instructions.php) در حال حاضر تقریبا خالی است، دستورات کوتاه زیر را بنویسید:

<?php
/**
 * The view for the AWS settings section's description on the plugin's settings page.
 *
 * @package    Wp_License_Manager
 * @subpackage Wp_License_Manager/admin/partials
 */
?>
 
<?php _e( 'Enter your AWS credentials below.', $this->plugin_name ); ?>

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

settings page

قدم چهارم: گرفتن و مخفی سازی کلید AWS API
برای آزمایش عملکرد، هنوز به کلید API و مخفی سازی آن از دید AWS و ذخیره آن در فیلدهای تنظیمات نیاز است.

بدین منظور، به کنسول مدیر AWS بازگشته و روی نام کاربری خود در بالا سمت راست کلیک کنید. از منوی نمایش داده شده، Security Credentials را انتخاب کنید.

سپس، پنجره زیر نمایش می‌یابد:

Security Credentials

گزینه Get Started with IAM Users را انتخاب کنید. در این روش، به جای استفاده از اسناد محرمانه جهانی در هر جا، می‌توانید برای استفاده‌های مختلف از AWS، نام‌های کاربری گوناگونی ایجاد کنید.

سپس، برای نصب مدیریت لایسنس وردپرس‌تان یک کاربر جدید ایجاد کنید.

ابتدا، روی Create Users در بالای صفحه کلیک کنید. سپس، در صفحه بعدی، نام کاربری را وارد کرده( بنده نام ساده test_user را استفاده کردم، ولی گزینه بهتر احتمالا license_manager است، یا نامی که بین کننده وظیفه کاربر است) و روی Create کلیک کنید.

Create Users

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

security credentials

قدم پنجم: ایجاد تابع API
اکنون، ما همه بخش‌های موردنیاز را برای عملکرد API get ساختیم. بیایید آنها را کنار هم گذاشته و عملکرد خودشان را ایجاد کنید.

ابتدا، قطعه switch. .case که برای عملکرد get در تابع handle_request درون Wp_License_Manager_API قرار دادیم، پر کنید:

case 'get':
    $response = $this->verify_license_and_execute( array( $this, 'get_product' ), $params );
    break;

تابع verify_license_and_execute که پیش از این انجام شد، پس چه چیزی برای تابع کنترلکننده get_product می‌ماند.

تابع را در زیر مشاهده می‌کنید:

/**
 * The handler for the "get" request. Redirects to the file download.
 *
 * @param   $product    WP_Post     The product object
 */
private function get_product( $product, $product_id, $email, $license_key ) {
    // Get the AWS data from post meta fields
    $meta = get_post_meta( $product->ID, 'wp_license_manager_product_meta', true );
    $bucket = isset ( $meta['file_bucket'] ) ? $meta['file_bucket'] : '';
    $file_name = isset ( $meta['file_name'] ) ? $meta['file_name'] : '';
 
    if ( $bucket == '' || $file_name == '' ) {
        // No file set, return error
        return $this->error_response( 'No download defined for product.' );
    }
 
    // Use the AWS API to set up the download
    // This API method is called directly by WordPress so we need to adhere to its
    // requirements and skip the JSON. WordPress expects to receive a ZIP file...
 
    $s3_url = Wp_License_Manager_S3::get_s3_url( $bucket, $file_name );
    wp_redirect( $s3_url, 302 );
}

بیایید ببینیم این تابع چه کاری انجام می‌دهد:

خط ۷ تا ۱۰: نام فایل و باکت تنظیمات را از فراداده محصول می‌خواند.

خط ۱۲ تا ۱۵: اگر فراداده موجود نباشد، جواب خطا برمی‌گرداند.

خط ۲۱: از AWS SDK برای ایجاد URL علامت‌دار برای فایل قابل‌دانلود محصول استفاده می‌کند.

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

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

نتیجه

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

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

نظرات کاربران (۰)