WordPress/WooCommerce Developer — deploy, verify & finish an EXISTING, already-tested plugin (full spec + full test suite provided)

Cliente Freelancer · Remoto · Remoto · freelance · mid · 30–250 USD

Publicada el 2026-07-22

Descripción de la oferta

We have a WordPress plugin that sells services on a CREDIT model. It is already CODED and already TESTED on a local machine: 31 of 33 smoke tests pass (the remaining 2 wait on OUR input data, not on defects) plus 6 of 6 payment-gate tests — including a real PayPal SANDBOX payment and refund. We need an experienced developer to take it onto a real staging domain and turn it into an accepted, live system: Stand up a fresh WordPress -> install & configure the plugin per the docs -> RE-RUN the provided acceptance suite on the real domain (30 smoke tests in M1; the 3 dataset tests complete the 33 in M2; plus 6 PayPal-gate tests) -> fix anything the real environment exposes -> go live on PayPal (one real transaction + refund) -> finish the operator docs -> hand over with a joint sign-off. What the system does: a visitor clicks Buy now, creates an account at checkout (if they don't have one — or signs in with Google), buys a credit pack through PayPal; the plugin credits their wallet; they paste a list and Submit; an external processing machine picks the job up over a REST API and returns an Excel file; the buyer downloads it. You do NOT build the plugin from scratch and you do NOT design anything — the code exists with a complete English spec it was built to (DB schema, API spec, UI contract, per-role flow maps). You configure, test, debug and fix until it passes; the only thing you WRITE new is the operator documentation at the final milestone. You also get a MOCK worker (Python) that plays the processing machine, so you can run the whole buy -> process -> download chain without our real system. THE ACCEPTANCE BAR: the core measure is the test suite passing on staging — plus the operator docs and the joint sign-off at the final milestone. "Test-and-fix on the delivered code" is part of the contract: a defect that makes a test fail is yours to fix whether it lives in the plugin, the config, or the mock app; we don't argue about its origin. In return, everything is specified and every test case is written for you — you never guess a requirement. SCOPE OF WORK 1. SITE SETUP on our staging domain from a clean WordPress: WooCommerce (guest checkout off, create-account-at-checkout on), PayPal Payments, an SMTP plugin (email must reach a real inbox), a self-hosted CRM plugin (opt-in checkbox), and a standard social-login plugin for Google sign-in (a NEW addition — you install from wordpress.org, pin its version, configure and smoke it). We supply every other plugin package at the tested versions. 2. PLUGIN INSTALL & CONFIG: activate (DB tables + seed + cron), create the fixed credit-pack products via the built-in product-editor tab, confirm the packages panel has no warnings, set the worker API key. 3. PAYMENT: on your own PayPal accounts until everything passes — see THE PAYPAL RULES below; it is the most unusual condition of this job, read it before you bid. 4. FULL ACCEPTANCE: re-run the smoke tests from the provided checklist (30 in M1; 3 dataset tests complete the 33 in M2) using the mock worker — from anonymous purchase to file download, admin/staff permissions, retention purge, email, CRM opt-in. 5. FIX UNTIL IT PASSES: any defect the tests expose is in scope; record each change in the deviation changelog. Fix rule: code that disagrees with the docs is a bug; a doc that looks wrong is a question for us. A failure caused by missing OWNER input (credentials, real seed, domain) is a blocker to log and raise — not counted against you. HOW CODE IS DELIVERED: every fix is COMMITTED to the private GitHub repository we provide, with clear messages — your commit history is how we review the work at each milestone. Code sent loose by zip or email is not accepted. 6. GO-LIVE + HANDOVER: PayPal Live (one real transaction + refund as evidence); WRITE the operator docs — 3 short guides (admin, staff, buyer) with real staging screenshots; the technical specs already exist, this final runbook is YOUR deliverable, no draft. Hand over per the joint checklist. THE PAYPAL RULES (read before you bid) a) SANDBOX: your own sandbox account on the public staging domain (needed for webhooks); re-run the 6 payment-gate tests there. The full sandbox flow is already proven and a setup how-to is included. b) LIVE-PATH REHEARSAL: before we connect anything of ours, prove the LIVE path end-to-end on YOUR OWN live PayPal account using a temporary low-value test pack (e.g. $0.10–$1, staging only, deleted after): one real purchase -> correct credit -> one real refund. Evidence required (transaction IDs + matching DB rows + screen capture). Price these micro-transaction costs into your bid — they are cents, and they prove your work is done. c) OWNER SWAP AT GO-LIVE: only after the full suite passes and your live-path evidence is accepted does the owner connect the production PayPal account — the owner enters those credentials personally; you never see or handle them. Then the final go-live check runs on it. NOT in scope: writing the plugin from scratch; designing UI/DB/API (done); rewriting UI copy or brand touchpoints (a fixed contract); coding the real data-processing worker (we run our own; a mock is provided); sales/marketing pages, a custom payment gateway, a data viewer, or analytics. YOU RECEIVE (on signed contract) - The full plugin source as a snapshot into a private GitHub repository we create and invite you into. No prior commit history — it starts with you (transparency, not a gap). You work IN this repo and deliver THROUGH it: the final repo state (fixed code + deviation log) is the code deliverable at each milestone. Plus the mock worker (Python, 1-page guide). - The complete English document pack the code was built to (product brief + 12-step journey; site/payment setup; DB/API architecture; UI spec; worker contract; acceptance checklist = 13-step deploy + 33 smoke + 6 payment tests; per-role flow maps; joint sign-off checklist; mock-worker spec) + 3 browser-openable HTML contracts (2 UI screens with backend annotations + 1 design-token file) + 6 sample spreadsheets defining each service's exact output columns. - Our local test evidence as a baseline (including the real PayPal sandbox run). - A real staging domain + hosting access (you install the fresh WordPress; clean activation is a sign-off item) + all base plugin packages at tested versions (the Google social-login plugin is the one exception: new addition, you install and pin it). The package has NO credentials: you use your OWN PayPal accounts (see THE PAYPAL RULES) and your OWN Google OAuth test app for staging; the owner's PayPal and production Google OAuth enter only at go-live, connected by the owner. - Note: the shipped service seed is a small placeholder on purpose; the real one is owner input, and its row count is NOT an acceptance condition. MILESTONES & ACCEPTANCE - M1 — ASSET LANE LIVE (30 of the 33 smoke tests): site on staging; sandbox purchase -> correct credit -> submit -> mock worker -> buyer downloads; 6/6 payment gates pass; every exposed defect fixed; live-path rehearsal on YOUR own PayPal account (with evidence); then go-live of the asset lane — one real transaction + refund on the owner's production account. - M2 — DATASET/REVIEW LANE + docs: the 3 dataset tests pass (33/33); operator docs finished; joint sign-off. Code deliverable = the final repo state (fixed source + full deviation log), not a zip. In one line: M1 = the main lane earning for real; M2 = the review lane, the docs, and the signatures. - MANDATORY EVIDENCE: every test group comes with a screencast or screenshot; money/credit/order tests also carry the transaction ID + matching DB row. No evidence = not accepted. REQUIRED SKILLS - MOST IMPORTANT: reading, debugging and fixing a WordPress plugin someone else wrote (hooks, custom $wpdb tables, capabilities, WP-Cron, REST API, admin-ajax). This is finish-existing-code, not greenfield. - WooCommerce at the hook/lifecycle level (payment_complete, refund, product meta). No payment-gateway internals needed. - Test discipline with evidence capture; atomic UPDATE, idempotency and race conditions understood so fixes land in the right place. - WordPress security basics: nonces, current_user_can, prepared SQL, output escaping. - Reads English technical docs and follows a contract exactly (ask when unsure — do not invent). - Runs a simple Python app (the mock worker; guide provided). - Git basics (clone, branch, commit, push) — all delivery is repository-based, never by zip. TO APPLY, PLEASE SEND 1. One or two projects where you TOOK OVER existing WordPress/WooCommerce code to fix/finish (describe your role). 2. Concrete experience with custom DB tables + REST API in WordPress. 3. Your BID: a fixed price for M1, your timeline, and the warranty period you offer (e.g. 30 days) — after reading the above. 4. Confirm you can test with your OWN PayPal accounts as described in THE PAYPAL RULES (sandbox + a low-value live rehearsal). If you cannot, say so plainly and we will discuss before signing. 5. Start your reply with the word "CREDIT" so we know you read this fully. Pricing: fixed price per milestone — YOU bid it (see #3 above); payment is released per gate, never by the calendar. We work in English. Contract terms, up front: code ownership (all work transfers on milestone payment) and no-reuse of this project's source, documents and data — your general skills and experience are of course not restricted. Signed before source and docs are shared.

Skills

Fuente original: freelancer

Análisis JobHunter