# WordPress PHP Guzzle Gutenberg .cursorrules prompt file

Author: <redacted>

## What you can build
E-commerce Store Integration Plugin: Create a WordPress plugin that integrates various e-commerce platforms using the Guzzle-based HTTP client, allowing users to manage products, orders, and inventory directly from their WordPress dashboard. Include Gutenberg blocks for adding product listings and shopping cart functionality.Social Media Auto Poster: Develop a plugin that automatically shares new WordPress posts to connected social media accounts by utilizing the Guzzle HTTP client for API interactions. Provide Gutenberg blocks for social media settings and customization of post content.Custom Form Builder with REST API Submission: Design a WordPress form builder plugin that creates custom forms with Gutenberg blocks and submits entries via the WP REST API. Include options for saving entries to external databases or services through the Guzzle client.SEO Optimization Toolkit: Build a plugin that offers SEO analysis and recommendations using external APIs accessed via Guzzle. Implement Gutenberg blocks showing SEO scores and suggestions for improving content directly in the editor.Content Syndication Hub: Offer a plugin that enables easy content syndication across multiple WordPress sites and external platforms, leveraging GUzzle for HTTP requests and REST API endpoints for managing syndication settings.Custom Analytics Dashboard: Create a WordPress plugin that presents a personalized analytics dashboard, pulling data from multiple third-party services using Guzzle. Utilize Gutenberg blocks to display graphs, statistics, and insights directly within the WordPress admin.Dynamic Content Importer: Develop a plugin that periodically imports and updates content from specified external sources using Guzzle. Provide Gutenberg blocks for configuring import settings, schedules, and display options for the imported content.Advanced Newsletter Integration: Implement a plugin that connects WordPress to various newsletter services using the Guzzle client, enabling automated email campaigns based on website activity. Include Gutenberg blocks for subscription forms and campaign management.Multilingual Content Manager: Design a plugin for managing multilingual content in WordPress, using the Guzzle client to access and translate content via external translation APIs. Gutenberg blocks can be used for displaying translated content and managing language settings.Real-Time Cryptocurrency Ticker: Create a Gutenberg block plugin that displays real-time cryptocurrency prices and market data by leveraging Guzzle to fetch data from financial APIs. Offer users customizable ticker settings directly within the WordPress dashboard.

## Benefits


## Synopsis
WordPress developers can create a plugin that integrates external APIs using Guzzle, adds custom WP REST endpoints, and introduces Gutenberg blocks, adhering to WordPress coding standards and optimizing code readability.

## Overview of .cursorrules prompt
The .cursorrules file provides guidelines for developing a WordPress plugin that includes a Guzzle-based HTTP client, WP REST endpoint additions, and new Gutenberg editor blocks. It emphasizes using WordPress coding standards for PHP, JavaScript, and TypeScript, with a preference for TypeScript over JavaScript. The file promotes functional programming paradigms and composition over inheritance while ensuring consistency with WordPress ecosystem best practices. Additionally, it stresses the importance of optimizing code for readability and employing type hinting in PHP code.

---
description: Cursor Rules Location
globs: *.mdc
---
# Cursor Rules Location

Rules for placing and organizing Cursor rule files in the repository.

<rule>
name: cursor_rules_location
description: Standards for placing Cursor rule files in the correct directory
filters:
  # Match any .mdc files
  - type: file_extension
    pattern: "\\.mdc$"
  # Match files that look like Cursor rules
  - type: content
    pattern: "(?s)<rule>.*?</rule>"
  # Match file creation events
  - type: event
    pattern: "file_create"

actions:
  - type: reject
    conditions:
      - pattern: "^(?!\\.\\/\\.cursor\\/rules\\/.*\\.mdc$)"
        message: "Cursor rule files (.mdc) must be placed in the .cursor/rules directory"

  - type: suggest
    message: |
      When creating Cursor rules:

      1. Always place rule files in PROJECT_ROOT/.cursor/rules/:

2. Follow the naming convention:
- Use kebab-case for filenames
- Always use .mdc extension
- Make names descriptive of the rule's purpose

3. Directory structure:

4. Never place rule files:
- In the project root
- In subdirectories outside .cursor/rules
- In any other location

examples:
- input: |
# Bad: Rule file in wrong location
rules/my-rule.mdc
my-rule.mdc
.rules/my-rule.mdc

# Good: Rule file in correct location
.cursor/rules/my-rule.mdc
output: "Correctly placed Cursor rule file"

metadata:
priority: high
version: 1.0
</rule>

---
description: No Bazel
globs: *
---
# No Bazel

Strictly prohibits any Bazel-related code, recommendations, or tooling.

<rule>
name: no_bazel
description: Strictly prohibits Bazel usage and recommendations
filters:
  # Match any Bazel-related terms
  - type: content
    pattern: "(?i)\\b(bazel|blaze|bzl|BUILD|WORKSPACE|starlark|\\.star)\\b"
  # Match build system recommendations
  - type: intent
    pattern: "build_system_recommendation"
  # Match file extensions
  - type: file_extension
    pattern: "\\.(bzl|star|bazel)$"
  # Match file names
  - type: file_name
    pattern: "^(BUILD|WORKSPACE)$"

actions:
  - type: reject
    message: |
      Bazel and related tools are not allowed in this codebase:
      - No Bazel build files or configurations
      - No Starlark (.star/.bzl) files
      - No Bazel-related tooling or dependencies
      - No recommendations of Bazel as a build system

      Please use Nix for build and dependency management.

  - type: suggest
    message: |
      Instead of Bazel, consider:
      - Nix for reproducible builds and dependencies
      - Make for simple build automation
      - Language-native build tools
      - Shell scripts for basic automation

examples:
  - input: "How should I structure the build?"
    output: "Use Nix for reproducible builds and dependency management. See our Nix documentation for examples."
  - input: "Can we add a Bazel rule?"
    output: "We use Nix overlays instead of Bazel rules. Please convert this to a Nix overlay."

metadata:
  priority: critical
  version: 2.0
</rule>

---
description: Depot Add License Header
globs: *
---
# Add License Header

Automatically add license headers to new files.

<rule>
name: add_license_header
description: Automatically add license headers to new files
filters:
  - type: file_extension
    pattern: "*"
  - type: event
    pattern: "file_create"
actions:
  - type: execute
    command: "depot-addlicense \"$FILE\""
  - type: suggest
    message: |
      License headers should follow these formats:

      Go files:
      ```go
      // Copyright (c) 2025 Geoffrey Huntley <ghuntley@ghuntley.com>. All rights reserved.
      // SPDX-License-Identifier: Proprietary
      ```

      Nix files:
      ```nix
      # Copyright (c) 2025 Geoffrey Huntley <ghuntley@ghuntley.com>. All rights reserved.
      # SPDX-License-Identifier: Proprietary
      ```

      Shell files:
      ```bash
      # Copyright (c) 2025 Geoffrey Huntley <ghuntley@ghuntley.com>. All rights reserved.
      # SPDX-License-Identifier: Proprietary
      ```
metadata:
  priority: high
  version: 1.0
</rule>

# Git Conventional Commits

Rule for automatically committing changes made by CursorAI using conventional commits format.

<rule>
name: conventional_commits
description: Automatically commit changes made by CursorAI using conventional commits format
filters:
  - type: event
    pattern: "build_success"
  - type: file_change
    pattern: "*"

actions:
  - type: execute
    command: |
      # Extract the change type and scope from the changes
      CHANGE_TYPE=""
      case "$CHANGE_DESCRIPTION" in
        *"add"*|*"create"*|*"implement"*) CHANGE_TYPE="feat";;
        *"fix"*|*"correct"*|*"resolve"*) CHANGE_TYPE="fix";;
        *"refactor"*|*"restructure"*) CHANGE_TYPE="refactor";;
        *"test"*) CHANGE_TYPE="test";;
        *"doc"*|*"comment"*) CHANGE_TYPE="docs";;
        *"style"*|*"format"*) CHANGE_TYPE="style";;
        *"perf"*|*"optimize"*) CHANGE_TYPE="perf";;
        *) CHANGE_TYPE="chore";;
      esac

      # Extract scope from file path
      SCOPE=$(dirname "$FILE" | tr '/' '-')

      # Commit the changes
      git add "$FILE"
      git commit -m "$CHANGE_TYPE($SCOPE): $CHANGE_DESCRIPTION"

  - type: suggest
    message: |
      Changes should be committed using conventional commits format:

      Format: <type>(<scope>): <description>

      Types:
      - feat: A new feature
      - fix: A bug fix
      - docs: Documentation only changes
      - style: Changes that do not affect the meaning of the code
      - refactor: A code change that neither fixes a bug nor adds a feature
      - perf: A code change that improves performance
      - test: Adding missing tests or correcting existing tests
      - chore: Changes to the build process or auxiliary tools

      The scope should be derived from the file path or affected component.
      The description should be clear and concise, written in imperative mood.

examples:
  - input: |
      # After adding a new function
      CHANGE_DESCRIPTION="add user authentication function"
      FILE="src/auth/login.ts"
    output: "feat(src-auth): add user authentication function"

  - input: |
      # After fixing a bug
      CHANGE_DESCRIPTION="fix incorrect date parsing"
      FILE="lib/utils/date.js"
    output: "fix(lib-utils): fix incorrect date parsing"

metadata:
  priority: high
  version: 1.0
</rule>


<!--
 Copyright (c) 2025 Geoffrey Huntley <ghuntley@ghuntley.com>. All rights reserved.
 SPDX-License-Identifier: Proprietary
-->