Nơi lưu trữ các trường cài đặt plugin

Tôi đang phát triển plugin ngay bây giờ và tôi có một câu hỏi về best practicesvà quy ước.

Tôi cân gi ?

Plugin của tôi sẽ lưu trữ một số đối tượng được xác định trước, danh sách các đối tượng (hoặc chỉ các mảng / cặp giá trị khóa) và có thể thêm đối tượng mới và điền vào các trường của nó.
Ví dụ: đối tượng của tôi sẽ có nội dung sau

{
  "id": 123,
  "url": "http://google.com/",
  "enabled" : true,
  "name": "hello_world",
  "api_key" : "api_key"
}

JSONĐối tượng đơn giản .

Và trên Plugin Admin configuration pageđó sẽ có thể thêm, chỉnh sửa hoặc loại bỏ các đối tượng đó.

Câu hỏi của tôi là gì?

Cách tốt nhất để lưu trữ dữ liệu đó là gì. Tôi đã cài đặt rất nhiều plugin khác nhau để xem dữ liệu tùy chỉnh từ cài đặt được lưu trữ như thế nào. Có một số tùy chọn tôi đã thấy

1. Sử dụng Settings APIđược cung cấp bởi Wordpress. Thậm chí UIđược xử lý bởi wordpress, bạn chỉ cần gọi hàm và nó sẽ tạo trường nhập liệu phù hợp và hơn là lưu tất cả các cài đặt vào bảng tùy chọn. Tất cả các kiểm tra và bảo mật được xử lý bởi wordpress là tốt. Nhưng có thể tạo trang quản trị động nơi bạn có thể thêm các mục mới không?

2. Sử dụng cũ Options APIcũng được lưu trữ trong bảng tùy chọn, nhưng mang lại nhiều tự do hơn cho nhà phát triển để xử lý tất cả xác nhận.

3. Tạo bảng cơ sở dữ liệu mới và lưu dữ liệu trong đó.

Tôi không nghĩ rằng tôi sẽ sử dụng phương pháp thứ ba.

Vui lòng đề xuất cách tốt hơn để làm điều này hoặc có thể bạn biết plugin đã triển khai chức năng đó một cách đúng đắn. Tôi sẽ biết ơn bất kỳ sự giúp đỡ.

Nó phụ thuộc vào cách bạn sẽ sử dụng dữ liệu được lưu trữ.

Nếu bạn muốn chạy các truy vấn phức tạp đối với các giá trị, hãy sử dụng bảng tùy chỉnh với các chỉ mục được tối ưu hóa cho các truy vấn đó.

Nếu bạn sẽ luôn tìm nạp tất cả các giá trị cho một đối tượng nhất định, hãy tạo một loại bài đăng tùy chỉnh không công khai và lưu trữ dữ liệu dưới dạng meta bài đăng.

Không lưu trữ dữ liệu trong một chuỗi nối tiếp, giống như API tùy chọn thực hiện. Đây là một cơn ác mộng khi bạn muốn thay đổi nó trên mỗi dòng lệnh SQL, bởi vì định dạng nối tiếp là đặc thù của PHP.

"API cài đặt" áp đặt một số đánh dấu rất lỗi thời và mã cho đăng ký và lưu trữ là khá trực quan. Tôi không khuyên bạn nên sử dụng nó.

Nơi lưu trữ các trường cài đặt plugin?

Bảng tùy chọn FTW. Nó được lưu trữ và dễ dàng để làm CRUD.

API cài đặt hoặc API tùy chọn?

Về cơ bản, bạn có thể sử dụng API tùy chọn mà không cần API cài đặt nhưng bạn không thể sử dụng API cài đặt mà không có API tùy chọn. Ngay cả khi bạn chỉ cần thêm một số trường vào trang WordPress hiện có, bạn vẫn cần get_option () để truy xuất dữ liệu cho mẫu xem của bạn.

Nhưng bằng cách sử dụng một trang WordPress hiện có, dữ liệu của bạn sẽ bị phân mảnh và khó lấy / duy trì vì nó được lưu trữ với sự khác biệt option_name. Nó cũng có thể gây nhầm lẫn cho người dùng cuối.

Khi chỉ sử dụng API tùy chọn, với tư cách là tác giả của plugin, bạn có thể thêm các phần / trường tin tức bất cứ khi nào bạn muốn nhưng người khác không thể. Bởi vì mẫu xem được mã hóa cứng mà không có các hook hoạt động như do_sinstall_sections () và do_sinstall_fields () . Tất nhiên, bạn có thể sử dụng do_action () nhưng nó sẽ phức tạp hơn nhiều.

Sử dụng API tùy chọn mang lại nhiều tự do hơn cho nhà phát triển để xử lý tất cả xác thực là không chính xác. API cài đặt sanitize_callbackcũng cho phép nhà phát triển làm bất cứ điều gì họ muốn với dữ liệu đầu vào.

Vậy tại sao không sử dụng cả hai?

Ví dụ, chúng ta hãy nói một trang thiết lập sử dụng cả hai API cài đặt và tùy chọn API với option_grouplà my_app_groupvà option_namelà my_app:

$options = get_option('my_app');

?><div class="wrap">
    <h1><?= __('Plugin Settings', 'textdomain') ?></h1>
    <form class="form-table" method="post" action="options.php">
        <?php settings_fields('my_app_group') ?>
        <table>
            <tr>
                <td>
                    <label for="my_app[name]">
                        <?= __('App Name', 'textdomain') ?>
                    </label>
                </td>
                <td>
                    <input type="text" name="my_app[name]" value="<?= $options['name'] ?>">
                </td>
            </tr>
            <tr>
                <td>
                    <label for="my_app[app_key]">
                        <?= __('App Key', 'textdomain') ?>
                    </label>
                </td>
                <td>
                    <input type="text" name="my_app[app_key]" value="<?= $options['app_key'] ?>">
                </td>
            </tr>
            <?php do_settings_fields('my_app_group', 'default') ?>
        </table>
        <?php do_settings_sections('my_app_group') ?>
        <?php submit_button() ?>
    </form>
</div><?php

Bây giờ, tất cả dữ liệu được lưu trữ trong bảng tùy chọn dưới my_apptên tùy chọn, sau đó dễ dàng truy xuất / bảo trì. Các nhà phát triển khác cũng có thể thêm các phần / trường mới vào plugin của bạn.

1. Đúng

2. điều này thực sự giống như điểm 1, chỉ cần không có người trợ giúp

3. Bây giờ điều này phụ thuộc vào cách bạn muốn sử dụng cài đặt của bạn. Bản năng là ở 99% các trường hợp, điều này sẽ chỉ thêm sự phức tạp không cần thiết vào mã của bạn và làm giảm hiệu suất.

Miễn là chúng ta đang nói về cài đặt và không phải nội dung hoặc widget, API cài đặt là thứ bạn nên sử dụng. Phải mất một thời gian để làm quen với nó, nhưng nó không áp đặt bất kỳ giới hạn nào đối với loại GUI hoặc cấu trúc cài đặt bạn có thể có. Bất cứ điều gì bạn có thể làm với biểu mẫu html, bạn cũng có thể làm với API cài đặt.

Nhưng chờ đã, có một cách khác, và đó là sử dụng tùy biến. Nếu cài đặt của bạn có ý nghĩa giao diện người dùng, bạn nên xem xét sử dụng nó