WordPress Abstraction: Các phương pháp hay nhất và các plugin WordPress trừu tượng

WordPress là một CMS cũ, nhưng cũng là một CMS được sử dụng nhiều nhất. Nhờ vào lịch sử hỗ trợ các phiên bản PHP lỗi thời và mã kế thừa, nó vẫn còn thiếu sót trong việc thực hiện các phương pháp mã hóa hiện đại – WordPress trừu tượng là một ví dụ.

Ví dụ: sẽ tốt hơn rất nhiều nếu chia cơ sở mã lõi WordPress thành các gói do Composer quản lý. Hoặc có thể, để tự động tải các lớp WordPress từ các đường dẫn tệp.

Bài viết này sẽ hướng dẫn bạn cách trừu tượng mã WordPress theo cách thủ công và sử dụng các khả năng của plugin WordPress trừu tượng.

Các vấn đề với việc tích hợp các công cụ WordPress và PHP

Do kiến trúc cổ xưa của nó, đôi khi chúng tôi gặp sự cố khi tích hợp WordPress với công cụ cho cơ sở mã PHP, chẳng hạn như trình phân tích tĩnh PHPStan, thư viện kiểm tra đơn vị PHPUnit và thư viện phạm vi không gian tên PHP-Scoper. Ví dụ, hãy xem xét các trường hợp sau:

• Trước phiên bản WordPress 5.6 có hỗ trợ PHP 8.0, một báo cáo của Yoast đã mô tả cách chạy PHPStan trên lõi WordPress sẽ tạo ra hàng nghìn vấn đề.
• Do vẫn hỗ trợ PHP 5.6, các bộ thử nghiệm của WordPress hiện chỉ hỗ trợ PHPUnit lên đến phiên bản 7.5, phiên bản này đã hết tuổi thọ.
• Việc xác định phạm vi các plugin WordPress thông qua PHP-Scoper là rất khó khăn.

Mã WordPress trong các dự án của chúng tôi sẽ chỉ là một phần nhỏ trong tổng số; dự án cũng sẽ chứa mã doanh nghiệp bất khả tri của CMS cơ bản. Tuy nhiên, chỉ cần có một số mã WordPress, dự án có thể không tích hợp với công cụ đúng cách.

Do đó, có thể hợp lý khi chia dự án thành các gói, một số gói chứa mã WordPress và một số khác chỉ có mã doanh nghiệp sử dụng PHP “vani” và không có mã WordPress. Bằng cách này, các gói sau này sẽ không bị ảnh hưởng bởi các vấn đề được mô tả ở trên nhưng có thể được tích hợp hoàn hảo với công cụ.

Mã trừu tượng là gì?

Sự trừu tượng hóa mã loại bỏ các phụ thuộc cố định khỏi mã, tạo ra các gói tương tác với nhau thông qua các hợp đồng. Sau đó, các gói này có thể được thêm vào các ứng dụng khác nhau với các ngăn xếp khác nhau, tối đa hóa khả năng sử dụng của chúng. Kết quả của sự trừu tượng hóa mã là một cơ sở mã được phân tách rõ ràng dựa trên các trụ cột sau:

1. Mã chống lại các giao diện, không phải việc triển khai.
2. Tạo các gói và phân phối chúng qua Composer.
3. Keo tất cả các bộ phận với nhau thông qua tiêm phụ thuộc.

Mã hóa chống lại giao diện, không phải triển khai

Mã hóa các giao diện là việc sử dụng các hợp đồng để các đoạn mã tương tác với nhau. Hợp đồng chỉ đơn giản là một giao diện PHP (hoặc bất kỳ ngôn ngữ nào khác) xác định những chức năng nào có sẵn và chữ ký của chúng, tức là chúng nhận được đầu vào và đầu ra của chúng.

Một giao diện tuyên bố mục đích của chức năng mà không giải thích cách chức năng sẽ được triển khai. Bằng cách truy cập chức năng thông qua các giao diện, ứng dụng của chúng tôi có thể dựa vào các đoạn mã tự quản để thực hiện một mục tiêu cụ thể mà không cần biết hoặc quan tâm đến cách chúng thực hiện điều đó. Bằng cách này, ứng dụng không cần phải điều chỉnh để chuyển sang một đoạn mã khác hoàn thành cùng mục tiêu – ví dụ: từ một nhà cung cấp khác.

Ví dụ về hợp đồng

Đoạn mã sau sử dụng hợp đồng CacheInterface của Symfony và hợp đồng Khuyến nghị Chuẩn PHP (PSR) CacheItemInterface để triển khai chức năng bộ nhớ đệm:

use PsrCacheCacheItemInterface; use SymfonyContractsCacheCacheInterface; $value = $cache->get('my_cache_key', function (CacheItemInterface $item) { $item->expiresAfter(3600); return 'foobar'; });

$cache thực hiện CacheInterface , định nghĩa phương thức get để lấy một đối tượng từ bộ đệm. Bằng cách truy cập chức năng này thông qua hợp đồng, ứng dụng có thể không biết vị trí của bộ nhớ đệm. Cho dù đó là trong bộ nhớ, đĩa, cơ sở dữ liệu, mạng hoặc bất kỳ nơi nào khác. Tuy nhiên, nó phải thực hiện chức năng. CacheItemInterface định nghĩa phương thức expiresAfter khi khai báo khoảng thời gian mục phải được lưu trong bộ đệm. Ứng dụng có thể gọi phương thức này mà không cần quan tâm đối tượng được lưu trong bộ nhớ cache là gì; nó chỉ quan tâm nó phải được lưu trong bộ nhớ cache trong bao lâu.

Mã hóa chống lại các giao diện trong WordPress

Bởi vì chúng tôi đang trừu tượng hóa mã WordPress, kết quả là ứng dụng sẽ không tham chiếu trực tiếp mã WordPress mà luôn thông qua một giao diện. Ví dụ, hàm get_posts trong WordPress có chữ ký này:

/** * @param array $args * @return WP_Post[]|int[] Array of post objects or post IDs. */ function get_posts( $args = null )

Thay vì gọi phương thức này trực tiếp, chúng tôi có thể truy cập nó thông qua OwnerMyAppContractsPostsAPIInterface :

namespace OwnerMyAppContracts; interface PostAPIInterface { public function get_posts(array $args = null): PostInterface[]|int[]; }

Lưu ý rằng hàm get_posts của WordPress có thể trả về các đối tượng của lớp WP_Post , dành riêng cho WordPress. Khi trừu tượng hóa mã, chúng ta cần loại bỏ loại phụ thuộc cố định này. Phương thức get_posts trong hợp đồng trả về các đối tượng kiểu PostInterface , cho phép bạn tham chiếu đến lớp WP_Post mà không cần nói rõ về nó. Lớp PostInterface sẽ cần cung cấp quyền truy cập vào tất cả các phương thức và thuộc tính từ WP_Post :

namespace OwnerMyAppContracts; interface PostInterface { public function get_ID(): int; public function get_post_author(): string; public function get_post_date(): string; // ... }

Việc thực thi chiến lược này có thể thay đổi hiểu biết của chúng tôi về vị trí WordPress phù hợp trong ngăn xếp của chúng tôi. Thay vì nghĩ WordPress là chính ứng dụng (qua đó chúng ta cài đặt các chủ đề và plugin), chúng ta có thể nghĩ nó đơn giản như một phần phụ thuộc khác trong ứng dụng, có thể thay thế như bất kỳ thành phần nào khác. (Mặc dù chúng tôi sẽ không thay thế WordPress trên thực tế, nhưng nó có thể thay thế được theo quan điểm khái niệm.)

Tạo và phân phối các gói

Composer là một trình quản lý gói cho PHP. Nó cho phép các ứng dụng PHP lấy các gói (tức là các đoạn mã) từ một kho lưu trữ và cài đặt chúng dưới dạng các gói phụ thuộc. Để tách ứng dụng khỏi WordPress, chúng ta phải phân phối mã của nó thành các gói có hai loại khác nhau: gói chứa mã WordPress và gói khác chứa logic nghiệp vụ (tức là không có mã WordPress).

Cuối cùng, chúng tôi thêm tất cả các gói làm phụ thuộc trong ứng dụng và chúng tôi cài đặt chúng thông qua Composer. Vì công cụ sẽ được áp dụng cho các gói mã doanh nghiệp, các gói này phải chứa hầu hết mã của ứng dụng; tỷ lệ phần trăm càng cao càng tốt. Để họ quản lý khoảng 90% mã tổng thể là một mục tiêu tốt.

Trích xuất mã WordPress thành các gói

Theo ví dụ trước đó, các hợp đồng PostAPIInterface và PostInterface sẽ được thêm vào gói chứa mã doanh nghiệp và một gói khác sẽ bao gồm việc triển khai WordPress của các hợp đồng này. Để đáp ứng PostInterface , chúng tôi tạo một lớp PostWrapper sẽ lấy tất cả các thuộc tính từ một đối tượng WP_Post :

namespace OwnerMyAppForWPContractImplementations; use OwnerMyAppContractsPostInterface; use WP_Post; class PostWrapper implements PostInterface { private WP_Post $post; public function __construct(WP_Post $post) { $this->post = $post; } public function get_ID(): int { return $this->post->ID; } public function get_post_author(): string { return $this->post->post_author; } public function get_post_date(): string { return $this->post->post_date; } // ... }

Khi triển khai PostAPI , vì phương thức get_posts trả về PostInterface PostInterface[] , chúng ta phải chuyển đổi các đối tượng từ WP_Post thành PostWrapper :

namespace OwnerMyAppForWPContractImplementations; use OwnerMyAppContractsPostAPIInterface; use WP_Post; class PostAPI implements PostAPIInterface { public function get_posts(array $args = null): PostInterface[]|int[] { // This var will contain WP_Post[] or int[] $wpPosts = get_posts($args); // Convert WP_Post[] to PostWrapper[] return array_map( function (WP_Post|int $post) { if ($post instanceof WP_Post) { return new PostWrapper($post); } return $post }, $wpPosts ); } }

Sử dụng phương pháp tiêm phụ thuộc

Phun phụ thuộc là một mẫu thiết kế cho phép bạn dán tất cả các bộ phận ứng dụng lại với nhau theo cách liên kết lỏng lẻo. Với tính năng tiêm phụ thuộc, ứng dụng truy cập các dịch vụ thông qua hợp đồng của chúng và việc triển khai hợp đồng được “tiêm” vào ứng dụng thông qua cấu hình.

Chỉ cần thay đổi cấu hình, chúng tôi có thể dễ dàng chuyển từ nhà cung cấp hợp đồng này sang nhà cung cấp hợp đồng khác. Có một số thư viện tiêm phụ thuộc mà chúng ta có thể chọn. Chúng tôi khuyên bạn nên chọn một thư viện tuân theo Khuyến nghị Tiêu chuẩn PHP (thường được gọi là “PSR”), vì vậy chúng tôi có thể dễ dàng thay thế thư viện bằng một thư viện khác nếu có nhu cầu. Liên quan đến việc tiêm phụ thuộc, thư viện phải đáp ứng PSR-11, cung cấp đặc điểm kỹ thuật cho “giao diện vùng chứa”. Trong số những thư viện khác, các thư viện sau tuân thủ PSR-11:

• Symfony’s DependencyInjection
• PHP-DI
• Aura.Di
• Vùng chứa (Tiêm phụ thuộc)
• Yii Dependency Injection

Truy cập Dịch vụ qua Vùng chứa Dịch vụ

Thư viện chèn phụ thuộc sẽ tạo sẵn một “vùng chứa dịch vụ”, giải quyết một hợp đồng thành lớp triển khai tương ứng của nó. Ứng dụng phải dựa vào vùng chứa dịch vụ để truy cập tất cả các chức năng. Ví dụ, trong khi chúng tôi thường gọi các hàm WordPress trực tiếp:

$posts = get_posts();

… Với vùng chứa dịch vụ, trước tiên chúng ta phải có được dịch vụ đáp ứng PostAPIInterface và thực thi chức năng thông qua nó:

use OwnerMyAppContractsPostAPIInterface; // Obtain the service container, as specified by the library we use $serviceContainer = ContainerBuilderFactory::getInstance(); // The obtained service will be of class OwnerMyAppForWPContractImplementationsPostAPI $postAPI = $serviceContainer->get(PostAPIInterface::class); // Now we can invoke the WordPress functionality $posts = $postAPI->get_posts();

Sử dụng Symfony’s DependencyInjection

Thành phần DependencyInjection của Symfony hiện là thư viện tiêm phụ thuộc phổ biến nhất. Nó cho phép bạn định cấu hình vùng chứa dịch vụ thông qua mã PHP, YAML hoặc XML. Ví dụ, để xác định hợp đồng PostAPIInterface được thỏa mãn thông qua lớp PostAPI được cấu hình trong YAML như thế này:

services: OwnerMyAppContractsPostAPIInterface: class: OwnerMyAppForWPContractImplementationsPostAPI

Symfony’s DependencyInjection cũng cho phép các phiên bản từ một dịch vụ được tự động đưa vào (hoặc “tự động”) vào bất kỳ dịch vụ nào khác phụ thuộc vào nó. Ngoài ra, nó giúp dễ dàng xác định rằng một lớp là một triển khai dịch vụ của chính nó. Ví dụ: hãy xem xét cấu hình YAML sau:

services: _defaults: public: true autowire: true GraphQLAPIGraphQLAPIRegistriesUserAuthorizationSchemeRegistryInterface: class: 'GraphQLAPIGraphQLAPIRegistriesUserAuthorizationSchemeRegistry' GraphQLAPIGraphQLAPISecurityUserAuthorizationInterface: class: 'GraphQLAPIGraphQLAPISecurityUserAuthorization' GraphQLAPIGraphQLAPISecurityUserAuthorizationSchemes: resource: '../src/Security/UserAuthorizationSchemes/*'

Cấu hình này xác định những điều sau:

• Hợp đồng UserAuthorizationSchemeRegistryInterface được thỏa mãn thông qua lớp UserAuthorizationSchemeRegistry
• Hợp đồng UserAuthorizationInterface được thỏa mãn thông qua class UserAuthorization
• Tất cả các lớp trong thư mục UserAuthorizationSchemes/ là một triển khai của chính chúng
• Các dịch vụ phải được tự động tiêm vào nhau ( autowire: true )

Hãy xem cách autowiring hoạt động. Lớp UserAuthorization phụ thuộc vào dịch vụ có hợp đồng UserAuthorizationSchemeRegistryInterface :

class UserAuthorization implements UserAuthorizationInterface { public function __construct( protected UserAuthorizationSchemeRegistryInterface $userAuthorizationSchemeRegistry ) { } // ... }

Nhờ autowire: true , thành phần DependencyInjection sẽ tự động có dịch vụ UserAuthorization nhận được phần phụ thuộc cần thiết của nó, đây là một phiên bản của UserAuthorizationSchemeRegistry .

Khi nào cần tóm tắt

Mã trừu tượng có thể tiêu tốn đáng kể thời gian và công sức, vì vậy chúng ta chỉ nên thực hiện nó khi lợi ích của nó lớn hơn chi phí. Sau đây là những gợi ý về thời điểm trừu tượng hóa mã có thể đáng giá. Bạn có thể làm điều này bằng cách sử dụng các đoạn mã trong bài viết này hoặc các plugin WordPress trừu tượng được đề xuất bên dưới.

Có được quyền truy cập vào công cụ

Như đã đề cập trước đó, việc chạy PHP-Scoper trên WordPress rất khó. Bằng cách tách mã WordPress thành các gói riêng biệt, việc phân bổ trực tiếp một plugin WordPress trở nên khả thi.

Giảm thời gian và chi phí dụng cụ

Chạy bộ thử nghiệm PHPUnit mất nhiều thời gian hơn khi nó cần khởi tạo và chạy WordPress hơn là khi không. Ít thời gian hơn cũng có thể dẫn đến việc tốn ít tiền hơn để chạy các bài kiểm tra – ví dụ: GitHub Actions tính phí cho những người chạy được lưu trữ trên GitHub dựa trên thời gian sử dụng chúng.

Tái cấu trúc nặng không cần thiết

Một dự án hiện tại có thể yêu cầu cấu trúc lại nhiều để giới thiệu kiến trúc cần thiết (chèn phụ thuộc, tách mã thành các gói, v.v.), gây khó khăn cho việc lấy ra. Mã trừu tượng khi tạo một dự án từ đầu làm cho nó dễ quản lý hơn nhiều.

Sản xuất mã cho nhiều nền tảng

Bằng cách trích xuất 90% mã vào một gói CMS-bất khả tri, chúng tôi có thể tạo phiên bản thư viện hoạt động cho CMS hoặc khung công tác khác bằng cách chỉ thay thế 10% cơ sở mã tổng thể.

Di chuyển sang một nền tảng khác

Nếu chúng ta cần di chuyển một dự án từ Drupal sang WordPress, WordPress sang Laravel hoặc bất kỳ sự kết hợp nào khác, thì chỉ 10% mã phải được viết lại – một khoản tiết kiệm đáng kể.

Thực hành tốt nhất

Trong khi thiết kế các hợp đồng để tóm tắt mã của chúng tôi, có một số cải tiến mà chúng tôi có thể áp dụng cho cơ sở mã.

Tuân thủ PSR-12

Khi xác định giao diện để truy cập các phương thức WordPress, chúng ta nên tuân thủ PSR-12. Đặc điểm kỹ thuật gần đây này nhằm mục đích giảm bớt ma sát nhận thức khi quét mã từ các tác giả khác nhau. Tuân thủ PSR-12 có nghĩa là đổi tên các chức năng WordPress.

WordPress đặt tên cho các hàm bằng solid_case , trong khi PSR-12 sử dụng camelCase . Do đó, hàm get_posts sẽ trở thành getPosts :

interface PostAPIInterface { public function getPosts(array $args = null): PostInterface[]|int[]; }

…và:

class PostAPI implements PostAPIInterface { public function getPosts(array $args = null): PostInterface[]|int[] { // This var will contain WP_Post[] or int[] $wpPosts = get_posts($args); // Rest of the code // ... } }

Phương pháp tách

Các phương thức trong giao diện không cần phải là bản sao của các phương thức từ WordPress. Chúng ta có thể biến đổi chúng bất cứ khi nào nó có ý nghĩa. Ví dụ: hàm get_user_by($field, $value) của WordPress biết cách truy xuất người dùng từ cơ sở dữ liệu thông qua tham số $field , hàm này chấp nhận các giá trị "id" , "ID" , "slug" , "email" hoặc "login" . Thiết kế này có một số vấn đề:

• Nó sẽ không bị lỗi tại thời điểm biên dịch nếu chúng ta chuyển một chuỗi sai
• Tham số $value cần chấp nhận tất cả các kiểu khác nhau cho tất cả các tùy chọn, mặc dù khi truyền "ID" , nó yêu cầu một int , khi chuyển "email" , nó chỉ có thể nhận một string

Chúng ta có thể cải thiện tình trạng này bằng cách chia hàm thành nhiều hàm:

namespace OwnerMyAppContracts; interface UserAPIInterface { public function getUserById(int $id): ?UserInterface; public function getUserByEmail(string $email): ?UserInterface; public function getUserBySlug(string $slug): ?UserInterface; public function getUserByLogin(string $login): ?UserInterface; }

Hợp đồng được giải quyết cho WordPress như thế này (giả sử chúng tôi đã tạo UserWrapper và UserInterface , như đã giải thích trước đó):

namespace OwnerMyAppForWPContractImplementations; use OwnerMyAppContractsUserAPIInterface; class UserAPI implements UserAPIInterface { public function getUserById(int $id): ?UserInterface { return $this->getUserByProp('id', $id); } public function getUserByEmail(string $email): ?UserInterface { return $this->getUserByProp('email', $email); } public function getUserBySlug(string $slug): ?UserInterface { return $this->getUserByProp('slug', $slug); } public function getUserByLogin(string $login): ?UserInterface { return $this->getUserByProp('login', $login); } private function getUserByProp(string $prop, int|string $value): ?UserInterface { if ($user = get_user_by($prop, $value)) { return new UserWrapper($user); } return null; } }

Xóa chi tiết triển khai khỏi chữ ký hàm

Các hàm trong WordPress có thể cung cấp thông tin về cách chúng được triển khai trong chữ ký của chính chúng. Thông tin này có thể được loại bỏ khi đánh giá chức năng từ góc độ trừu tượng. Ví dụ: lấy họ của người dùng trong WordPress được thực hiện bằng cách gọi get_the_author_meta , làm rõ ràng rằng họ của người dùng được lưu trữ dưới dạng giá trị “meta” (trên bảng wp_usermeta ):

$userLastname = get_the_author_meta("user_lastname", $user_id);

Bạn không cần phải chuyển thông tin này vào hợp đồng. Các giao diện chỉ quan tâm đến cái gì chứ không phải như thế nào. Do đó, thay vào đó, hợp đồng có thể có một phương thức getUserLastname , phương thức này không cung cấp bất kỳ thông tin nào về cách nó được triển khai:

interface UserAPIInterface { public function getUserLastname(UserWrapper $userWrapper): string; ... }

Thêm các loại nghiêm ngặt hơn

Một số hàm WordPress có thể nhận các tham số theo nhiều cách khác nhau, dẫn đến sự mơ hồ. Ví dụ: hàm add_query_arg có thể nhận một khóa và giá trị duy nhất:

$url = add_query_arg('id', 5, $url);

… Hoặc một mảng key => value :

$url = add_query_arg(['id' => 5], $url);

Giao diện của chúng tôi có thể xác định một mục đích dễ hiểu hơn bằng cách chia các chức năng như vậy thành một số chức năng riêng biệt, mỗi chức năng trong số chúng chấp nhận một sự kết hợp duy nhất của các đầu vào:

public function addQueryArg(string $key, string $value, string $url); public function addQueryArgs(array $keyValues, string $url);

Xóa nợ kỹ thuật

Hàm get_posts WordPress không chỉ trả về “bài đăng” mà còn trả về “trang” hoặc bất kỳ thực thể nào thuộc loại “bài đăng tùy chỉnh” và những thực thể này không thể hoán đổi cho nhau. Cả bài đăng và trang đều là bài viết tùy chỉnh, nhưng một trang không phải là bài đăng và không phải là trang. Do đó, việc thực thi get_posts có thể trả về các trang. Hành vi này là một sự khác biệt về khái niệm.

Để làm cho nó phù hợp, get_posts thay vào đó nên được gọi là get_customposts , nhưng nó không bao giờ được đổi tên trong lõi WordPress. Đó là một vấn đề phổ biến với hầu hết các phần mềm lâu năm và được gọi là “nợ kỹ thuật” – mã có vấn đề, nhưng không bao giờ được khắc phục vì nó tạo ra những thay đổi đột phá.

Tuy nhiên, khi tạo hợp đồng, chúng tôi có cơ hội tránh được loại nợ kỹ thuật này. Trong trường hợp này, chúng ta có thể tạo một giao diện mới ModelAPIInterface có thể xử lý các thực thể thuộc các kiểu khác nhau và chúng ta thực hiện một số phương pháp, mỗi phương thức xử lý một kiểu khác nhau:

interface ModelAPIInterface { public function getPosts(array $args): array; public function getPages(array $args): array; public function getCustomPosts(array $args): array; }

Bằng cách này, sự khác biệt sẽ không xảy ra nữa và bạn sẽ thấy những kết quả sau:

• getPosts chỉ trả về các bài đăng
• getPages chỉ trả về các trang
• getCustomPosts trả về cả bài đăng và trang

Lợi ích của mã trừu tượng

Những ưu điểm chính của việc trừu tượng hóa mã của một ứng dụng là:

• Công cụ chạy trên các gói chỉ chứa mã doanh nghiệp dễ thiết lập hơn và sẽ tốn ít thời gian hơn (và ít tiền hơn) để chạy.
• Chúng tôi có thể sử dụng công cụ không hoạt động với WordPress, chẳng hạn như xác định phạm vi một plugin với PHP-Scoper.
• Các gói chúng tôi sản xuất có thể được tự chủ sử dụng trong các ứng dụng khác một cách dễ dàng.
• Việc di chuyển một ứng dụng sang các nền tảng khác trở nên dễ dàng hơn.
• Chúng ta có thể chuyển tư duy của mình từ tư duy WordPress sang tư duy theo logic kinh doanh của mình.
• Các hợp đồng mô tả mục đích của ứng dụng, làm cho nó dễ hiểu hơn.
• Ứng dụng được sắp xếp thông qua các gói, tạo ra một ứng dụng tinh gọn chứa mức tối thiểu và nâng cao dần khi cần thiết.
• Chúng tôi có thể xóa nợ kỹ thuật.

Vấn đề với mã trừu tượng

Những bất lợi của việc trừu tượng hóa mã của một ứng dụng là:

• Nó liên quan đến một lượng công việc đáng kể ban đầu.
• Mã trở nên dài dòng hơn; thêm các lớp mã bổ sung để đạt được kết quả tương tự.
• Bạn có thể kết thúc việc sản xuất hàng chục gói mà sau đó phải được quản lý và duy trì.
• Bạn có thể yêu cầu một monorepo để quản lý tất cả các gói cùng nhau.
• Việc tiêm phụ thuộc có thể là quá mức cần thiết đối với các ứng dụng đơn giản (lợi nhuận giảm dần).
• Việc trừu tượng hóa mã sẽ không bao giờ được thực hiện đầy đủ vì thường có một sở thích chung tiềm ẩn trong kiến trúc của CMS.

Tùy chọn Plugin WordPress Tóm tắt

Mặc dù thông thường tốt nhất là trích xuất mã của bạn sang môi trường cục bộ trước khi làm việc trên nó, nhưng một số plugin WordPress có thể giúp bạn đạt được mục tiêu trừu tượng của mình. Đây là những lựa chọn hàng đầu của chúng tôi.

1. WPide

Được sản xuất bởi WebFactory Ltd, plugin WPide phổ biến mở rộng đáng kể chức năng của trình soạn thảo mã mặc định của WordPress. Nó hoạt động như một plugin WordPress trừu tượng bằng cách cho phép bạn xem mã của mình tại chỗ để hình dung rõ hơn những gì cần chú ý.

WPide cũng có chức năng tìm kiếm và thay thế để nhanh chóng định vị mã lỗi thời hoặc hết hạn và thay thế nó bằng một phiên bản đã được cấu trúc lại.

Trên hết, WPide cung cấp vô số tính năng bổ sung, bao gồm:

• Cú pháp và tô sáng khối
• Sao lưu tự động
• Tạo tệp và thư mục
• Trình duyệt cây tệp toàn diện
• Quyền truy cập vào API hệ thống tệp WordPress

2. Trình quản lý DB cuối cùng

Plugin Ultimate WP DB Manager từ WPHobby cung cấp cho bạn một cách nhanh chóng để tải toàn bộ cơ sở dữ liệu của bạn xuống để trích xuất và tái cấu trúc.

Tất nhiên, các plugin kiểu này không cần thiết cho người dùng Kinsta, vì Kinsta cung cấp quyền truy cập cơ sở dữ liệu trực tiếp cho tất cả khách hàng. Tuy nhiên, nếu bạn không có đủ quyền truy cập cơ sở dữ liệu thông qua nhà cung cấp dịch vụ lưu trữ của mình, Ultimate DB Manager có thể hữu ích như một plugin WordPress trừu tượng.

3. Plugin WordPress trừu tượng tùy chỉnh của riêng bạn

Cuối cùng, lựa chọn tốt nhất để trừu tượng hóa sẽ luôn là tạo plugin của bạn. Nó có vẻ như là một nhiệm vụ lớn, nhưng nếu bạn có khả năng hạn chế để quản lý trực tiếp các tệp lõi WordPress của mình, thì điều này cung cấp một giải pháp thân thiện với trừu tượng.

Làm như vậy có lợi ích rõ ràng:

• Tóm tắt các chức năng của bạn từ các tệp chủ đề của bạn
• Bảo quản mã của bạn thông qua các thay đổi chủ đề và cập nhật cơ sở dữ liệu

Bạn có thể tìm hiểu cách tạo plugin WordPress trừu tượng của mình thông qua Sổ tay dành cho nhà phát triển plugin của WordPress.

Bản tóm tắt

Chúng ta có nên trừu tượng hóa mã trong các ứng dụng của mình không? Như với mọi thứ, không có “câu trả lời đúng” được xác định trước vì nó phụ thuộc vào từng dự án. Những dự án đòi hỏi một lượng lớn thời gian để phân tích bằng PHPUnit hoặc PHPStan có thể được hưởng lợi nhiều nhất, nhưng nỗ lực cần thiết để thực hiện nó có thể không phải lúc nào cũng xứng đáng.

Bạn đã học mọi thứ bạn cần biết để bắt đầu trừu tượng hóa mã WordPress.

Bạn có kế hoạch thực hiện chiến lược này trong dự án của mình không? Nếu vậy, bạn sẽ sử dụng một plugin WordPress trừu tượng chứ? Cho chúng tôi biết trong phần ý kiến!