5

Vài ngày trước, có một bài viết thú vị trên Dire State of WordPress , nói về những vấn đề mà các nhà phát triển gặp phải khi làm việc với hệ thống quản lý nội dung cực kỳ phổ biến này :

Khi bạn học PHP từ WordPress như tôi (và có lẽ nhiều người khác) đã làm, bạn chỉ cho rằng tất cả các đặc điểm riêng và phi logic là ngang bằng với khóa học khi xây dựng một trang web điều khiển CMS. Phải mất vài năm tôi mới nhận ra rằng nó không phải như thế này. Trên thực tế, điều đó thực sự không xảy ra cho đến khi tôi bắt đầu tìm hiểu thêm về các nguyên tắc OO và làm việc với các khung mà tôi bắt đầu nhìn vào WP ở một khía cạnh khác. Tại sao mọi phiên bản của mọi mô hình được xử lý như một bài đăng? Tại sao tôi không thể mở rộng chức năng của loại bài đăng mà không viết toàn bộ mớ móc, bộ lọc và mã chức năng vào một tệp không liên quan về mặt ngữ nghĩa với bài đăng đó theo bất kỳ cách nào?

Những điều này nghe có vẻ giống như sự kìm kẹp của một người nào đó có nhu cầu sẽ không bao giờ được đáp ứng bởi một thứ như WordPress, nhưng việc thiếu logic cơ bản làm phát sinh các vấn đề trên là điều khiến WordPress trở nên rắc rối cho các nhà phát triển ở mọi cấp độ. Và bởi vì sự giao thoa trên sơ đồ venn của 'những người biết các thực tiễn phát triển ứng dụng tốt' và 'những người xây dựng trang web trong WordPress' là một mảnh nhỏ như vậy, nó chỉ dừng lại ở trạng thái hokey hiện tại, gây khó khăn cho cả những người không thành thạo và thành thạo nhà phát triển như nhau.

Đúng như dự đoán, điều này tạo ra một cuộc thảo luận sôi nổi trên Hacker News .

Nợ kỹ thuật

Bây giờ, tôi đã sử dụng WordPress bật và tắt kể từ khi nó vẫn được gọi là b2 cafelog , nhưng tôi không coi mình là nhà phát triển WordPress. Tuy nhiên, nhìn vào nó chủ yếu từ bên ngoài, rõ ràng nhiều vấn đề mà người dùng và nhà phát triển WordPress phải đối mặt ngày nay là do nợ kỹ thuật từ các quyết định kiến ​​trúc tồi được thực hiện cách đây một thập kỷ và thiếu ý chí để khắc phục những vấn đề đó.

WordPress vẫn đang trải qua quá trình chuyển đổi từ nền tảng blog sang CMS đa năng . Những thay đổi này đòi hỏi có nghĩa là nếu không có kiến ​​trúc âm thanh, các vấn đề với động cơ lót sẽ chỉ trở nên trầm trọng hơn.

Đây không phải là một cái gì đó độc đáo cho WordPress. Nhiều CMS phổ biến, bao gồm cả Drupal và TYPO3 đã gặp phải vấn đề tương tự. Tất cả chúng ta trong cộng đồng CMS nguồn mở đã ở đó. Tuy nhiên, sự khác biệt là các dự án này đã xác định được vấn đề này và đã thực hiện các bước để khắc phục nó.

Bắt đầu tách

Lý do tại sao các CMS trở nên lộn xộn là bởi vì tất cả chúng đều cố gắng để có rất nhiều thứ cùng một lúc. CMS là một khung web, CMS là một công cụ chỉnh sửa web và CMS là một kho lưu trữ nội dung. Nhưng mỗi trong số chúng là trong thực tế, các lĩnh vực chuyên biệt của riêng chúng, và do đó, nguyên tắc phân tách các mối quan tâm cho chúng ta biết rằng chúng nên được xử lý bằng các phần mềm riêng biệt.

Tôi đã viết một bài đăng vẫn còn phổ biến có tiêu đề Decoupling Content Management hai năm trước để tranh luận về điều đó. Các dự án như PHPCRCreat.js sau đó đã xuất hiện để chuyển ý tưởng đó từ ý tưởng sang thực tiễn và đã được nhiều CMS áp dụng.

Tóm lại, quá trình chuyển đổi tôi muốn CMS - bao gồm WordPress - thực hiện là:

<br>

Chúng tôi cũng nói về sự hợp tác chéo CMS cho phép trong video ra mắt TYPO3 Neos .

Hãy nghĩ về nó, các nhà phát triển từ Midgard CMS và TYPO3 làm việc cùng nhau và chia sẻ các phần quan trọng của cơ sở mã giao diện người dùng, trong khi vẫn cho phép mỗi dự án giữ lại một giao diện độc đáo!

Không có ai tham gia

Trong hai năm qua, tôi đã có hàng chục cuộc nói chuyện về Quản lý nội dung tách rời trong các hội nghị nhà phát triển và CMS khác nhau. Trong các sự kiện này, tôi đã nói chuyện với rất nhiều nhà phát triển từ nhiều CMS khác nhau từ cả thế giới nguồn mở và độc quyền. Nhưng mặc dù phổ biến, các nhà phát triển cốt lõi WordPress đã vắng mặt.

Nhà hoạt động Symfony Lukas Smith đã nhận thấy điều tương tự :

Tôi nghĩ rằng bước đầu tiên sẽ là các nhà phát triển cốt lõi WordPress bắt đầu hòa nhập với cộng đồng PHP. Tôi chỉ đơn giản là chưa gặp một nhà phát triển cốt lõi WordPress nào tại bất kỳ hội nghị PHP nào và tôi có xu hướng đến 6-10 một năm ở nhiều quốc gia khác nhau trên thế giới.

Tôi cũng chưa thấy bất kỳ nhà phát triển cốt lõi WordPress nào tham gia vào một cuộc thảo luận nội bộ về php-src chứ đừng nói gì đến một cái gì đó giống như Nhóm Khả năng Tương tác Khung ngoài PSR.

Nhưng không có giao tiếp, cơ hội hợp tác rất thấp và không có sự hợp tác, thật khó để WordPress xác định và đánh giá tiềm năng cho những hướng đi mới.

Tiến về phía trước

Mặc dù WordPress vẫn là con chó hàng đầu của thế giới CMS, nhưng đó là một vị trí bấp bênh không nên ru ngủ họ. Web di chuyển về phía trước, mọi thứ thay đổi, và tất cả các khoản nợ kỹ thuật cuối cùng phải được thanh toán. Và đó là những gì có thể làm chậm một dự án.

Giải quyết các vấn đề kiến ​​trúc là một khối lượng lớn công việc, và vì vậy tôi sẽ bắt đầu bằng cách kiểm tra xem các dự án khác như Drupal đã thực hiện chuyển đổi như thế nào . Các thành phần Symfony để giải cứu các dự án PHP của bạn trên liveblog Symfony Live Paris của tôi là một nơi tốt để bắt đầu.

Đối với WordPress, giống như bất kỳ hệ thống quản lý nội dung PHP nào, chương trình nghị sự bí mật của tôi về các CMS PHP nên được áp dụng. Nếu bạn là nhà phát triển cốt lõi WordPress, tôi rất thích trò chuyện về cách tiến về phía trước.

Ngày 22 tháng 3 năm 2013 tại Berlin, Đức

Quản lý nội dung tách rời

Quản lý nội dung tách rời là một phong trào nhằm mang lại sự phân tách rõ ràng các mối quan tâm vào các CMS. Với nó, Hệ thống quản lý nội dung có thể tập trung tốt hơn vào các chức năng cốt lõi của họ và có được các phần còn thiếu thông qua chia sẻ mã và cộng tác.

Đối với tôi, câu chuyện CMS tách rời bắt đầu trong kỷ nguyên OSCOM đầu những năm 2000 và đạt đến đỉnh điểm trong bài viết Quản lý nội dung tách rời vẫn còn phổ biến mà tôi đã viết vào năm 2011. Các công cụ được đề cập ở đó - Creat.js , VIEPHPCR - đã đạt đến khá một mức độ tốt đẹp của việc áp dụng trong các CMS chính thống.

|