Dycms Laravel Package

Getting Started

This is not a Composer package you require into an existing app — DYCMS is a full Laravel application (a website-navigation/directory CMS). Treat it as a starter codebase or reference implementation, not a library.

Minimal steps to get it running:

1. Check compatibility first. Open composer.json and confirm the Laravel/PHP version constraints. The last release was 2020-09-22, so expect Laravel 6/7-era code and a PHP 7.2–7.4 target. Spin up a matching PHP container/PHP version before running anything.
2. Clone or fork the repo, then composer install, copy .env.example → .env, configure the database and APP_URL, generate a key, then php artisan migrate --seed.
3. Run php artisan storage:link and php artisan serve, then log into the admin panel (find the admin route in routes/ and the seeded credentials in the seeders).
4. Where to look first: routes/web.php (and any admin route file), app/Http/Controllers, app/Models (categories, sites/links, articles), database/migrations, config/, and resources/views for the Blade templates.
5. First use case: build the canonical flow end-to-end — create a category, add a few site/link entries under it, and verify they render on the frontend listing and detail pages. That single loop touches every layer you'll be extending.

Because the project is archived and thinly documented, budget time for reading source rather than docs. Read the migrations before the models — the schema is the fastest way to understand the domain.

Implementation Patterns

Category-tree navigation. The core data model is hierarchical categories (parent/child) driving the nav. Expect a parent_id-style tree; render recursively in a Blade partial and cache the assembled tree rather than querying per request. When you add categories, invalidate that cache on save.

Directory/listing pages. Frontend listing pages are category-scoped, paginated site/link lists. The day-to-day pattern is: admin CRUD writes to the sites table, the frontend controller queries by category with pagination, and the Blade view renders cards. Search/filter is usually a query-string scope on the same controller — extend it there rather than adding a parallel endpoint.

View overrides for branding. Since you're forking the app, the cleanest customization path is Blade: swap layouts, partials, and CSS under resources/views and public/. Keep your changes in a fork or a dedicated branch so upstream diffs stay readable (even though upstream is dormant).

Admin-as-workflow-engine. All content management runs through the admin controllers. If you need a new content type (e.g., a "featured tool" flag), follow the existing pattern: migration → model → admin controller action → form request validation → Blade form field. Don't invent a new admin abstraction.

SEO and routing. Navigation/directory sites live or die on URLs and meta tags. The URL scheme is defined in the route files and controllers; slugs and meta descriptions are set in the Blade layouts. Audit these early — retrofitting SEO after launch is painful.

Caching for read-heavy traffic. Directory homepages and category trees are read far more than written. Cache the homepage lists, category tree, and hot detail pages with a short TTL, and clear keys inside the admin save/delete actions.

Cherry-picking into an existing Laravel app. If you only want the directory feature inside your own project, copy the relevant migrations, models, controllers, and views rather than adopting the whole application. This is the most realistic "leverage" path given the project's age.

User submissions (if present). If the build includes public site submissions, keep the moderation gate: submissions land in a pending state and only appear after admin approval. Never let user-submitted URLs render unescaped.

Gotchas and Tips

• Archived means unmaintained. There are no security patches, no dependency updates, and no issue triage. Treat this as a fork-and-own codebase: run composer audit, pin your composer.lock, and never expose the admin panel on the public internet without auth hardening, rate limiting, and IP restrictions.
• PHP/Laravel version drift is the #1 blocker. 2020-era code frequently breaks on PHP 8.2+ (deprecated dynamic properties, stricter type handling, old framework APIs). Use a pinned PHP version in a container; upgrade the framework deliberately, not by accident when your host bumps PHP.
• Chinese-first codebase and docs. Comments, variable names, and README content may be in Chinese (or pinyin). Keep a short glossary of the domain terms (category, site, link, submission) mapped to their table/column names so you and your team stay oriented.
• No documented extension API. Extend by overriding controllers and Blade views, not via events, service providers, or published config. Any "extension point" you find is incidental — document your own.
• Config quirks. Watch for hard-coded asset paths, a missing storage:link, and assumptions about cache/queue/session drivers (often file/sync). Set these explicitly in .env for production; the defaults may silently degrade under load.
• Debugging workflow. Enable APP_DEBUG=true locally, tail storage/logs/laravel.log, and if migrations fail, check seeder ordering and foreign-key constraints — seed data often depends on category IDs existing first.
• Don't depend on it as a package. There is no stable API surface and no release cadence. Vendor the code into your repo, add tests around the pieces you rely on, and keep an upgrade path open to a maintained alternative if the directory feature becomes business-critical.