Kandi Patterns

Architecture

A PHP backend built on the Yii MVC framework, serving both server-rendered pages and a decoupled React single-page application for the pattern designer. The pattern designer communicates with the backend exclusively over a RESTful JSON:API, authenticated via JSON Web Tokens. This separation allows the designer to operate as a standalone application while the main site handles content browsing, community features, and administration.

REST API & Serialization

The API follows the JSON:API specification, providing a standardised resource format with proper serialisation, pagination, sorting, and filtering.

Serializer classes decouple internal model structure from API response shapes. Attributes are conditionally exposed based on the requesting user’s relationship to the resource — owners see privacy and status fields, while public consumers receive a reduced attribute set. Meta blocks carry contextual permissions such as edit and delete capabilities, letting the frontend render UI controls based on server-authorised permissions rather than client-side role guessing.

Search

Site-wide search uses Sphinx Search, providing full-text search across six content indexes: patterns, photos, users, forum threads, forum replies, and blog posts. A single query counts results across all indexes simultaneously, routing the user to the most relevant content type while displaying per-index counts in a tabbed interface.

Pattern search supports faceted filtering by pattern kind, category, and pegboard type, with multiple match modes giving users control over result breadth. A fallback to database queries ensures search remains functional during maintenance.

Pattern Type Detection

The site has a large catalogue of legacy patterns that predate the current pattern maker and store only a flat image with no structured data. To bring these into the system, the platform automatically detects the pattern type using pixel-level image analysis. The algorithm checks image dimensions against a lookup table of known template sizes and pegboard shapes, then walks the edges pixel by pixel, measuring border extent and using the ratio of horizontal to vertical measurements to classify the pattern type. Patterns created in the modern designer store their type as structured data, so this analysis is only needed for legacy content.

Image Processing Pipeline

Pattern images are stored across two S3 buckets: one for user designer images and one for approved public patterns. When a design is approved, the image flows through a multi-stage pipeline: the source image is copied between buckets, numbered bead indicators are applied where needed, thumbnails are generated with aspect ratio preservation, and the original is kept for PDF generation. PDF export produces printable pattern sheets containing the pattern image, dimensions, creator attribution, and a colour-coded bead count table.

Content Approval Pipeline

User-submitted designs go through a community-driven approval workflow. Shared designs enter a pending state where other users vote on them. CLI commands handle batch approval with configurable criteria including vote threshold, voter quality weighting (based on account age and activity), and date range filtering. The approval process handles image processing and record creation as an atomic operation per design.

Community & Moderation

Content moderation operates at multiple levels - a configurable word filter for blocked terms, Akismet integration for automated spam detection, and a granular block system allowing per-user restrictions by content type and action. Users can also mute phrases and block other users.