A Glossary of Dev-Speak

THIS IS A WORK IN PROGRESS

Terms

  • Handler:
    • catch-all term for a class that ‘handles stuff’
    • Often, a “controller” type class (see OOP) or “orchestration”
  • Scheduler: A class that wires up cron events
  • Notifier: A class that sends notifications (typically via wp_mail)
  • Frontend:
    • The browser (where javascript/css/html lives)
    • Also referred to as “client” or “client-side”
  • Backend:
    • Server side code (typically, PHP—occasionally Javascript via Node or Astro)
    • The WP-Admin views
  • Gutenberg: aka the “Block Editor,” this is the react-powered, block-based editor for WordPress posts (post, page, cpt, etc)
  • Orchestration/Orchestrator:
    • Coordination layer/method that helps wire together tasks
      • Orchestrators decide what happens next. i.e.
        1. Do a thing
        2. Do another thing
        3. Do a final thing
    • Also, Controller (see MVC)
  • Bootstrap:
    • UI Framework
    • A common function/method name for loading/initializing an app (plugin, site, service, etc)
  • Business:
    • Code / logic that is specific to one’s project. Wouldn’t necessarily have an WP/ACF-primitives (e.g. ‘the_title’ / ‘get_field’)
  • API
    • A way for software to programmatically interact with other software.
    • Examples:
      • a class’s public methods are its API—something can use its public methods to perform an action
      • A custom block’s controls for editors to mess with
      • A request for a developer to interact with a third-party system to move data around (e.g. “We need to build a portal via an API”)
  • Client:
    • A CNO party that is asking for work to be done (e.g. Housing, IT, Tourism, Cultural Center)
    • The browser (see frontend)
  • Payload
    • The data being sent via HTTP request as a collected object (i.e. $data array)
  • State
    • A type of memory at a given moment, i.e. “the current state of things.”

Concepts

Object Oriented Programming (OOP)

A way to write code that focuses on using classes to encapsulate state and actions.

Architecture

Model-View-Controller

A pattern that separates responsibilities:

  • Model: Data + business logic
  • View: UI / output—typically related to client-side code (e.g. HTML)
  • Controller: Handles input and coordinates actions

See something inaccurate?