Tag: Plugin Development

  • Making a SCUD Plugin

    I am working with a company who needs a nicely formatted way to display a group of employees. Currently, the team page is using hardcoded [author] shortcodes to format the page, but this makes it a pain for the staff to update the team information.

    So they don’t.

    So, I am creating a Simple Custom User Display, or SCUD, plugin.

    Did you think I was talking about missiles? Also, did you know there is a type of baby shrimp called a scud? You can learn about them here.

    I am sure there are already WordPress plugins which have a similar functionality to display users in a page archive. However, in this case, the company that I am working with doesn’t need a bunch of bells and whistles. Since they don’t have someone who regularly handles updating the site, keeping things light and less likely to run into update conflicts would be best.

    Also, I haven’t built a plugin from scratch in a bit. The majority of my recent work has been in digging through legacy code and surgically making improvements and refactors. Building something new seems like fun.

    Before I started writing any code, I spent some time thinking through the plugin and what this company needed. I thought it might be an interesting exercise to share.

    Problem Statement:

    The “Company” needs to improve their current “Team” page. Currently, it is out of date and is not easily updated by the staff at the Company. The current page is making use of the [author] shortcode in order to format contact information which is hard coded into the page directly. The metadata for each team member is not being pulled from a custom post type or user profile. This means that in order to edit a single piece of information (e.g. update a team member title), the user must sort through the page code to make changes.

    Solution:

    Create a lightweight plugin which uses as much core WordPress functionality as possible to make each team member information its own dataset. This way, the team member information can be easily pulled, sorted, filtered, and displayed on the front end. To make this easily editable in the future, utilize WordPress users to contain the sales rep information and metadata.

    Information store: Users

    The current website displays the team members grouped by their team and state. We can maintain this information if we can create a taxonomy for users. This looks to be a simple case of registering a custom taxonomy on the user type

    After creating the taxonomies, we want to limit the capabilities of the team member users. We can do this by creating a custom user role “Team Member” and limiting what they have access to. The role needs to only be added during the activation hook of our plugin and then we can begin to assign users to the role.

    The last piece of information we need to include is custom user meta fields. The team members have extra information, like their title and regions, which we need to be able to save. We can include this in the edit_user_profile hook

    The end goal here is that any team member could log in to edit their own profile information. If they don’t have their login, an administrator would also be able to update the contact information for them.

    Display

    Option 1: DataViews (Stretch)

    WordPress has recently introduced DataViews to core. This allows data sets (such as users) to not only be displayed, but also searched, filtered, and sorted. 

    DataViews has multiple layout options, including a table, grid, or list. Since the DataViews fields each render the component in custom React, we can customize the layout of the user information and how it is displayed.

    Additionally, since not all “fields” have to be displayed to be used for filtering, we can use the taxonomies to filter the users.

    The goal here is to allow users to be added to the website and then be automatically added to the Sales Team page without needing to edit the page content itself.

    If we contained the DataViews within a Block (for Divi or Gutenberg) then we would also be able to add custom content above or below the block without having to touch code.

    Divi can now display Gutenberg blocks. So this means we only need to create the block as part of Gutenberg.

    Option 2: Page Template

    This is basically the same principle as option 1, but with a custom page template. This is less flexible and doesn’t allow for searching, sorting, or filtering.

    Option 3: Divi Drag and Drop Page

    This option would be the most similar to the current implementation (the layout being created within the page editor). While we would still have the benefits of better user information control, it wouldn’t solve the long term-ease of use problem. It would likely be the least time consuming though.

    I am developing a boiler plate version of this plugin here: https://github.com/JessBoctor/simple-custom-user-display

    The goal is not to create a WYSIWYG plugin which allows a user to install and customize the new user role and display. Rather, it is a lightweight plugin with enough instructions on how to customize things that a dev can pick it up and make it their own.

    Which is what I will do for the company I am working with 🙂

    PS Before and after images will be coming soon once I have the website refresh completed.