Culture, Ethics, Logistics, & Technology (The "SEC" Way)

⌘K
  2. Home
  4. Culture, Ethics, Logistic...
  6. Web Development & Ho...
  8. Plugin Development at SEC

Plugin Development at SEC

Part 1: Leveraging Cursor for Custom Plugin Development

AI-powered Integrated Development Environments (IDEs) like Cursor (a fork of VS Code with native AI integration) or tools like GitHub Copilot allow our agency to rapidly prototype and build highly specific, custom plugins. Instead of relying on bloated third-party plugins that drag down client site speed (a critical SEO metric), we can generate lightweight, purpose-built solutions.

1. Ideation and Contextualization

Before asking the AI to write code, define the exact scope of the plugin. For our SEO clients, common custom plugins might include:

  • Dynamic Schema Markup generators based on custom post types.
  • Lightweight 301 redirect managers to handle site migrations.
  • Automated Open Graph tag injectors.

2. Prompting the AI for Boilerplate Code

When starting a new project in Cursor, use the AI chat or inline generation features (typically Ctrl+K or Cmd+K) to generate the foundational structure.

  • Best Practice Prompting: Be highly specific about the CMS (e.g., WordPress), the PHP version, and the desired functionality.
  • Example Prompt: “Generate the boilerplate PHP code for a WordPress plugin named ‘Agency SEO Schema Builder’. It needs to register a custom settings page under the standard WP Settings menu and include secure nonces for saving a single text field.”

3. Iterative Development and Code Review

AI is an excellent assistant, but it is not infallible. It can hallucinate functions or use deprecated code.

  • Highlight and Refine: If you need a specific function modified, highlight the code block in Cursor and ask the AI to “refactor this to improve database query efficiency” or “ensure this input is properly sanitized against XSS attacks.”
  • Mandatory Human Review: Never blindly deploy AI-generated code. You must review the logic to ensure it adheres to secure coding standards. Verify that all user inputs are sanitized (sanitize_text_field()) and all outputs are escaped (esc_html()).

Part 2: The Emergency Protocol – When a Plugin Breaks the Site

Despite thorough testing in staging environments, deploying a custom plugin to a live client site can sometimes trigger a fatal error. This is often due to unforeseen conflicts with the client’s existing theme, other plugins, or specific server configurations.

The Symptom: Immediately upon activating the new plugin via the CMS dashboard, the website crashes. This usually presents as the “White Screen of Death” (WSOD) or a 500 Internal Server Error. Consequently, you will be locked out of the CMS dashboard and unable to click “Deactivate.”

The Rule: Do not panic. The site’s data is safe; the PHP compiler has simply halted due to a fatal error in your plugin’s code. You must bypass the CMS and interact directly with the server infrastructure.

Part 3: Using FileZilla to Force-Deactivate a Rogue Plugin

When you are locked out of the website dashboard, FileZilla and your FTP/SFTP connection are your lifeline. By altering the file structure directly on the server, you can force the CMS to recognize the plugin as “missing” and automatically deactivate it, instantly restoring the website.

Step 1: Establish the Emergency FTP Connection

  1. Open FileZilla.
  2. Using the Site Manager or Quickconnect bar, input the client’s server credentials (Host, Username, Password, and Port 22 for SFTP).
  3. Click Connect. Check the Top Pane (Message Log) to ensure the connection is successful.

Step 2: Navigate to the Plugins Directory

Once connected, focus on the Right Pane (Remote Site). You need to locate where the CMS stores its active plugins.

  • For WordPress (our agency standard), navigate through the folders: public_html (or the root web folder) > wp-content > plugins.
  • Double-click the plugins folder to open it. You will see a list of folders, each representing an installed plugin.

Step 3: Isolate and Rename the Culprit Folder

  1. Locate the exact folder for the plugin you just uploaded (e.g., agency-seo-schema-builder).
  2. Right-click that specific folder.
  3. Select Rename from the context menu.
  4. Append text to the end of the folder name to break the file path. The standard best practice is to add _DEACTIVATED or -broken to the end.
    • Example: Rename agency-seo-schema-builder to agency-seo-schema-builder_DEACTIVATED.
  5. Press Enter to save the new folder name.

Step 4: Verify Site Recovery

  1. Open your web browser and navigate to the client’s live website.
  2. Hard-refresh the page (Ctrl+F5 or Cmd+Shift+R).
  3. Because the CMS looks for the exact folder name defined in its database, it will fail to find it. The CMS handles this gracefully by disabling the plugin and allowing the rest of the site to load normally. The fatal error is bypassed, and the site will be back online.

Step 5: Debugging the Code

Now that the crisis is averted and the site is live, you can use FileZilla to download the _DEACTIVATED plugin folder back to your local machine. Open the code in Cursor, check the server error logs (often found in the root directory as error_log), and feed the error output back to the AI to help you identify and patch the fatal flaw before re-testing on a staging environment.

How can we help?