The tasks for this plugin will be split into three components: back-end setup, front-end structure and front-end user experience, or PHP, HTML/CSS and JavaScript, respectively.

Dev Night Timeline: 4 hrs work, .75 hours fun. 12 hours dev time

  • 5:30 — eat some dinner, drink some beers, unwind a bit. Crack knuckles.
  • 6:00 — get started on tasks.
  • 7:45 — break for frisbee, or whatever.
  • 8:00 — get back to it.
  • 10:15 — go home.


Before we start coding, you’ll need to do the following:

  1. Install VVV & VV for faster local environment setup.
  2. Set up a local environment named “search-plugin” using VV.
  3. Import the theme unit test data from Automattic.
  4. Pull down the plugin repo from Bitbucket (that I will create soon…)

Back-End PHP (Sam)


  1. Build the User-Generated Content Array. See Data Structure for more details.
  2. General plugin setup using The WordPress Plugin Boilerplate.
  3. Set up action to update the User-Generated Content Array, which will run on save for any piece of user-generated content, including posts, taxonomy terms, media items, etc.
  4. Cache the User-Generated Content Array using WordPress transients.

Front-End JavaScript (Glenn)


  1. Create JSON array of basic WordPress Admin Actions. See Data Structure for more details.
  2. Create a) a keyboard shortcut and b) a link that trigger the search modal.
  3. Use Fuse.js or another fuzzy-searching JavaScript plugin to search for matches from the 3 JSON arrays: User-Generated Content, WordPress Admin Pages, and WordPress Admin Actions.
  4. In general, append matches to the search modal with the following structure:
    • Keep matches separated by content type. Begin with the current content type if possible.
    • Include a sub-head for the content type to separate the matches. This subheading should ideally be selectable as well, and include the Dashicon if possible.
  5. Matches from the User-Generated Content array should be a link to the Edit Screen, selectable by the mouse, or by the keyboard arrows and return key.
  6. Matches from the Admin Pages array will be kept separate under a “Admin Pages” subheading.
  7. Matches from the Actions Array will be kept separate under an “Admin Actions” subheading. A match selected from this array will use the trigger type of the matched object on that object’s selector.

Front-End HTML/CSS Tasks (Josh)

  1. Create JSON array of WordPress Admin Pages using get_post_types for starters — cache and clear on activated_plugin, deactivated_plugin, and generate_rewrite_rules. It might be best to follow the $GLOBALS[‘menu’] variable. See Data Structure for more details.
  2. Create a settings page that allows users to opt-out of specific content types.
  3. Create UI for search field and style results.

Data Structure

Since we’re dealing with three separate arrays that need to work together (like the Triforce), keeping our data structure consistent is going to be the only thing that’ll keep the JavaScript dev from going mad. Here’s my proposed structure for each array:

User-Generated Content Array

  • Title
  • ID
  • Object Type (post type, taxonomy term, etc)
  • Object Name (post, page, category, nav menu item, etc)
  • URL (if it saves us processing speed)


WordPress Admin Pages Array

  • Title
  • Object Type
  • Object Name
  • URL
  • Dashicon (if a top-level admin page)


WordPress Admin Actions Array

  • Title
  • Target Selector (i.e., input[type=”submit”]#publish)
  • Trigger type (i.e., click, focus, etc.)
  • Shortcut