Tin tức và phân tích của tất cả các thiết bị di động

Tại sao dữ liệu người dùng trong WordPress có thể là một cơn ác mộng

Mỗi trang web chúng tôi tạo ra có những thách thức riêng của nó. Nhưng các công cụ chúng tôi sử dụng có thể giúp chúng tôi giải quyết chúng trực tiếp.

WordPress và hệ sinh thái plugin không bao giờ kết thúc của nó đã giúp các nhà thiết kế web thành thạo ngay cả những yêu cầu khó khăn nhất của khách hàng. Hầu như tất cả chúng ta cần chỉ là nhấp và đi. Và nếu nó không tồn tại, chúng ta có thể tự xây dựng nó.

Nhưng đối với mỗi giải pháp mà chúng tôi thực hiện, có một hậu quả tiềm ẩn. Một thứ chỉ tăng lên khi chúng ta đi sâu hơn một chút vào dữ liệu cụ thể của người dùng. Chỉ sau đó chúng ta mới nhận ra mớ hỗn độn bên dưới lớp vỏ ngoài xinh xắn đó.

Một khởi đầu đơn giản

Trong cài đặt WordPress mặc định, dữ liệu người dùng (ít nhất là loại bạn muốn xuất) thực sự khá sạch sẽ và gọn gàng. Dữ liệu được lưu trữ trong bảng cơ sở dữ liệu wp_usermeta. Bên trong, bạn sẽ tìm thấy những điều cơ bản như tên người dùng, cùng với vai trò / khả năng và tùy chọn tài khoản của họ.

Kết hợp điều này với những gì có trong bảng wp_users (tên người dùng, địa chỉ email, mật khẩu) và bạn có thể nhận được nhiều thông tin hữu ích cho mỗi người dùng trên trang web của mình. Ngoài ra, bạn có thể dễ dàng nhập danh sách CSV của người dùng mới nếu cần.

Tất nhiên, hầu hết các trang web không dừng lại ở một thiết lập mặc định. Thay vào đó, chúng tôi thường thêm bất kỳ số lượng bổ trợ nào để người dùng có thể làm nhiều hơn với trang web của chúng tôi.

Chúng tôi muốn họ làm những việc như có thông tin hồ sơ cá nhân, theo dõi đơn hàng và thuộc về các nhóm cụ thể. Hơn nữa, các tính năng như diễn đàn, cổng hỗ trợ và hệ thống quản lý học tập cũng được sử dụng rộng rãi ngày nay.

Và đó chỉ là trầy xước bề mặt. Có nhiều hơn nữa có thể được thêm vào một trang web WordPress điển hình. Điều đó tốt, cho đến khi bạn phải thử và thảo luận về dữ liệu.

Bảng meta người dùng WordPress.

Dữ liệu, dữ liệu, ở mọi nơi

Vấn đề trong câu hỏi không phải là lỗi của chính WordPress. Trong nhiều trường hợp, đó là nơi lưu trữ một phần dữ liệu nhất định cho các nhà phát triển trình cắm. Điều đó có thể khiến dữ liệu người dùng bạn muốn thu thập được lưu trữ ở mọi nơi. Đây la bản chât của động vật.

Hãy sử dụng một trang web gần đây mà tôi đã làm việc như một ví dụ. Nó sử dụng một plugin thành viên, cho phép mọi người tham gia vào tổ chức của khách hàng.

Thông tin được thu thập

Khi họ đăng ký, chúng tôi yêu cầu họ không chỉ là siêu dữ liệu người dùng WordPress tiêu chuẩn. Thành viên mới được yêu cầu thông tin như:

  • Địa chỉ giao hàng;
  • Số điện thoại;
  • Sở thích của bạn về cách họ nhận bản tin (email hoặc thư bưu chính);

Dữ liệu được tạo

Ngoài thông tin chúng tôi yêu cầu người dùng cung cấp, còn có rất nhiều dữ liệu được tạo bởi plugin thành viên, bao gồm:

  • Tình trạng thành viên (hoạt động hoặc không hoạt động);
  • Cấp thành viên;
  • Ngày hết hạn thành viên;

Không có gì trên đầu về các cài đặt. Nó có lẽ không khác nhiều so với hàng chục ngàn trang web khác đang chạy cùng một nhóm thành viên.

Mặc dù trang web không quá phức tạp, điều đó không có nghĩa là dữ liệu người dùng của bạn dễ tìm thấy. Chúng ta hãy xem làm thế nào một nhiệm vụ đơn giản có thể trở thành một thách thức tốn thời gian.

Mã HTML trên màn hình.

Thử thách

Khách hàng có một nhu cầu rất cơ bản. Họ muốn xuất khẩu từ tất cả các thành viên tích cực, những người muốn có một bản in của bản tin của tổ chức gửi cho họ. Dựa trên những gì chúng ta có, việc này chỉ mất vài phút để ứng biến. Đó là cho đến nay.

Điều này khó khăn hơn nhiều so với tôi tưởng tượng. Dữ liệu chúng tôi cần đã có trong cơ sở dữ liệu. Nhưng cố gắng xây dựng lại nó hóa ra là một nhiệm vụ gần như hoành tráng đối với một người không phải là một thuật sĩ truy vấn cơ sở dữ liệu.

Tuy nhiên, đó là lý do tại sao chúng ta có plugin, phải không? Và có hàng tấn các tùy chọn khác nhau, cả miễn phí và cao cấp. Nhưng, bất kể tôi đã cố gắng gì, tôi không thể có được chính xác những gì xuất khẩu yêu cầu. Đây là lý do tại sao:

  • các dữ liệu cá nhân mà chúng tôi yêu cầu các thành viên cung cấp chúng tôi là đủ dễ dàng để có được. Nó nằm trong bảng wp_usermeta, mà người dùng thường xuất các plugin. Do đó, việc tạo một danh sách người dùng muốn bản sao của bản tin được in khá đơn giản.
  • các dữ liệu liên quan đến thành viên khácTuy nhiên, nó được lưu trữ trong một bảng khác là duy nhất cho plugin thành viên. Ngay cả một plugin giao dịch khá mạnh mẽ mà tôi đã sử dụng cũng không thể giúp tôi ở đây.

Kết quả là tôi đã có thể tìm ra ai đã yêu cầu phiên bản bưu chính của bản tin, nhưng tôi không thể tìm hiểu xem tư cách thành viên của họ có hoạt động hay không, điều này không hữu ích lắm.

Chắc chắn, thông tin đó đã được lưu trữ trong một bảng liền kề trong cùng một cơ sở dữ liệu, nhưng nó cũng có thể có trên Sao Mộc cho mục đích của tôi. Cảm giác như đang tìm chìa khóa trong nhà, chỉ để phát hiện ra rằng người hàng xóm của mình có chúng để tìm kiếm sự giải cứu.

Cuối cùng, tôi tìm thấy một plugin xuất khẩu, một plugin bao gồm một plugin cho plugin thành viên, có thể giúp tôi thu thập dữ liệu tôi cần. Nếu điều đó không tồn tại, bạn vẫn sẽ bị mắc kẹt chỉ với một nửa giải pháp.

Người xem bảng tính trên máy tính xách tay.

Kinh nghiệm có thể được cải thiện?

Tất cả điều này khiến tôi tự hỏi làm thế nào những tình huống này có thể được cải thiện hoặc tránh ở nơi đầu tiên. Đó là một quyết định khó khăn.

Đầu tiên, tôi thừa nhận rằng những loại thử thách này không phải là điểm mạnh của tôi. Một người có nhiều kinh nghiệm về PHP và MySQL có thể tìm thấy một giải pháp tùy chỉnh. Tôi? Tôi còn lại để thử nghiệm các plugin và rên rỉ khi chúng không hoạt động như mong đợi.

Nhưng một câu hỏi đáng được hỏi là: Trong trường hợp cần có kinh nghiệm như vậy để xuất một bộ dữ liệu người dùng hoàn chỉnh? Có vẻ như nên có một cách dễ dàng hơn để sử dụng điều này để làm việc.

Việc WordPress cho phép các plugin tạo các bảng cơ sở dữ liệu của riêng chúng là điều dễ hiểu và thậm chí có lợi. Nó đảm bảo rằng chúng ta có thể cài đặt và gỡ cài đặt plugin mà không sợ làm hỏng thứ gì đó.

Tuy nhiên, trong khi tất cả điều này hoạt động bằng mắt thường, nó là bất cứ điều gì ngoại trừ những người trong chúng ta đang cố gắng truy cập dữ liệu cơ bản.

Có lẽ nên có một API cho phép chúng tôi có được mọi thứ liên quan đến một người dùng cụ thể, bất kể nó được lưu trữ ở đâu trong cơ sở dữ liệu. Nhưng tôi sẽ để lại cuộc thảo luận đó cho những người biết những ưu và nhược điểm của một tính năng như vậy.

Cho đến lúc đó, tôi sẽ tiếp tục đặt mọi thứ lại với nhau vì khách hàng cần chúng, hy vọng một quy trình sạch hơn trong tương lai.

Mục lục