Plus Laravel Package

Getting Started

Plus (ThinkSNS+) is not a Composer library you require into an existing app — it's a complete Laravel social-network application you fork and deploy. Your first step is to treat it as an app scaffold, not a dependency.

Minimal local spin-up:

1. Clone the repo and check composer.json first — the PHP/Laravel constraints there tell you which PHP runtime you need (it targets the Laravel 5.x era, last release Nov 2020).
2. composer install, copy .env.example to .env, set APP_KEY, and configure MySQL and Redis (Redis is used for cache/queue/session in most Plus deployments — do not skip it).
3. php artisan migrate --seed to get the base schema and demo users/feeds, then php artisan storage:link for uploaded media.
4. Build the front-end assets (npm install && npm run dev or the project's documented build script), then php artisan serve.
5. Run a queue worker in a second terminal — feeds, notifications, and wallet transactions are queued.

Where to look first:

• routes/ — the app is API-centric; the route files map out the whole surface (feeds, comments, users, wallet, notifications) faster than reading controllers.
• config/ — Plus-specific config files govern features, uploads, and currency/points behavior.
• app/ — service providers and domain models. This is where you extend behavior.
• The project's docs/README — expect substantial Chinese-language documentation; budget time for translation or community guides.

First real use case: stand it up locally, seed demo data, log in as a seeded user, and exercise the feed/post/comment/follow flows through the API. That single pass teaches you the domain model (users ↔ feeds ↔ comments ↔ likes ↔ follows) faster than any doc.

Implementation Patterns

Because you own the whole codebase, "integration" means editing the app, not hooking into a package. Plan for a fork-and-maintain workflow, not a composer update.

• Feature flags over code deletion. Use the package's config toggles to disable wallet, paid-content, or other modules you don't need, rather than ripping out migrations and controllers. Keeps you upgrade-friendly.
• Service provider extension. Register your custom bindings, event listeners, and route additions in your own provider under app/Providers, mirroring how Plus wires its own modules. This isolates your changes from core files where possible.
• Event/listener hooks for side effects. Feed creation, comments, likes, and follows fire domain events. Attach listeners for notifications, analytics, or third-party webhooks instead of editing core controllers.
• API-first customization. The front-end talks to JSON endpoints. When adding a field (e.g., a custom profile attribute), extend the model, migration, API resource/transformer, and validation request together — the transformer is what the client actually sees.
• Wallet/points as a sub-system. If you use Plus's currency feature, model your own transactions as new "types" through its existing wallet service rather than writing a parallel ledger. Mixing two balance systems is the fastest way to corrupt user balances.
• Queue everything heavy. Feed fan-out, media processing, and notification fan-out belong in jobs. Follow the existing ShouldQueue patterns rather than doing work synchronously in controllers.
• Theming via views/assets. Front-end customization is Blade + compiled assets; keep custom CSS/JS in your own asset pipeline so upstream merges stay clean.
• Version control discipline. Keep a upstream remote and your work on a long-lived branch. You'll be cherry-picking, not merging, given the age of the last release.

Gotchas and Tips

• License — read it before you build a business. The GitHub license field reports NOASSERTION; ThinkSNS+ is historically distributed under a copyleft (AGPL-family) license. "Free to use" is not "free to use in a closed SaaS." Confirm with legal before commercial deployment — this is the single biggest risk with this package.
• It's effectively unmaintained. Last release was 2020-11-04. Expect to own security patches for Laravel, dependencies, and PHP-version upgrades yourself. Audit composer.lock for known-vulnerable transitive packages.
• Not a package — no composer require. If you were hoping to bolt social features onto an existing Laravel app, you'll instead be extracting concepts (models, events, wallet logic) by hand. Budget for that.
• Redis is a hard dependency. Missing or misconfigured Redis surfaces as silently empty feeds, stuck queues, or failed logins (session/cache). Check QUEUE_CONNECTION, CACHE_DRIVER, and SESSION_DRIVER first when things "just don't work."
• Queue worker must be running. Half the app appears broken (no notifications, no feed items) simply because no worker is consuming jobs. In production, supervise it (Supervisor/systemd).
• Seed/migrate on a clean DB. Migrations from this era can be order-sensitive; running against a dirty schema produces confusing foreign-key errors. migrate:fresh --seed on a scratch database for local work.
• Chinese-first docs. Error messages, admin labels, and guides are often in Chinese. Search issues in both languages and keep translation notes.
• PHP/extensions. Watch for bcmath/gmp (wallet math), gd/imagick (media), and intl requirements — missing extensions fail at runtime, not install time.
• Debugging path: storage/logs/laravel.log → failed-jobs table → re-run the specific job → reproduce via the API route, not the browser, since the front-end may be a separate SPA. php artisan route:list is your map.
• Upgrade strategy: fork + upstream remote, isolate customizations in your own providers/config, and vendor-pin aggressively. Do not expect upstream fixes; plan to patch dependencies (especially Laravel) yourself as you move to supported PHP versions.
• Extension points to prefer: config flags, service providers, event listeners, and new API resources. Avoid editing vendor and core models directly — you'll lose those changes on the next sync.