acg-faka: a PHP card-selling storefront with an installer that fills in its own database

What acg-faka is for, and the licence line that decides most deployments

acg-faka is a PHP storefront for selling digital goods, primarily card codes (卡密). The README describes it as a personal card-selling system and lists the pieces you would expect from a small shop platform: product listings with images, member and guest pricing, email notification, card-code pre-selection so a buyer can pick a specific account or card number, an API for external integration, forced login before purchase, custom form controls, flash sales, wholesale discounts and coupons. On top of the shop it adds a sub-site system where front-end users open their own storefronts, a member system that merges members and merchants with customisable levels, a three-level distribution commission system, a shared-store mode that lets one shop stock goods from another by deducting balance, and an app store of plugins and templates.

The licence is MIT, but the README carries a legal notice that changes the practical picture. It states the project is open source under MIT and completely free, that its purpose is to give developers something to study and research, and that without the relevant legal qualification it is strictly forbidden to use the program for any commercial purpose, especially building a platform to sell goods. Those two statements sit awkwardly together, and the README does not reconcile them. If you intend to run a real shop, that paragraph is the first thing to resolve; it is not a footnote. If you intend to read PHP 8 code, the notice is irrelevant to you.

How the shop is put together: one entry point, a runtime directory, and plugins

The repository layout is a conventional PHP application rather than a framework skeleton. There is a single web entry point, index.php, with app/, kernel/, config/, assets/ and vendor/ alongside it. The bundled Nginx rules in the README make the intent explicit: they return 404 for anything under runtime, kernel, config or vendor, block dotfiles except .well-known, block archive and log extensions, and block composer.json, composer.lock and package.json. The Dockerfile comment states the same idea from the other direction, that because the program has only index.php as a web entry, the Nginx configuration can allow that one file and refuse to execute every other .php, so a .php file dropped into an upload directory will not run.

Persistence follows from that layout. The Dockerfile comment says the writable parts of the site (configuration, runtime, uploads, plugins, payment and the install lock) are symlinked to /data, so one volume covers all of them. The compose file warns against the older habit of mounting each of those paths individually under /var/www/html, because those paths are now symlinks and mounting over them breaks the site.

Payments are the extension surface. The README claims a plugin capability that already covers any platform and any payment channel. Treat that as a claim about the plugin interface, not a list of supported gateways; the README does not enumerate them, and the payment directory is where you would look to confirm what exists.

Installing acg-faka from source with composer

The README gives two routes. The manual route is to download the source to your server, or to use composer to create the project, which is one command:

composer create-project lizhipay/acg-faka

Before either route, the README states the environment requirements: php>=8.0 and MySQL version >=5.6, with 5.7 or 8.0 recommended because 5.6 may cause problems on later upgrades. The reason given for the PHP floor is that the code uses PHP 8 attributes and other PHP 8 features.

After the files are in place you configure URL rewriting. Apache needs nothing, because the repository root already contains .htaccess. On Nginx you add the rewrite rules the README supplies:

location ~* ^/(runtime|kernel|config|vendor)/                { return 404; }
location ~  /\.(?!well-known)                                { return 404; }
location ~* \.(log|sql|sqlite|db|db-wal|db-shm|bak|old|save|orig|swp|swo|tmp|ini|lock)$  { return 404; }
location ~* (~|composer\.(json|lock)|package(-lock)?\.json)$ { return 404; }
location / {
    try_files $uri $uri/ /index.php?s=$uri&$args;
}

With rewriting in place, you open the site root and the installer runs. The README states that the admin panel afterwards lives at https://your-domain/admin. Windows IIS users get a separate rewrite block in the README instead of these rules.

Running acg-faka with docker compose, and the ARM performance caveat

The compose file is written for a single command, with no .env and no file edits:

docker compose up -d

A secrets-init service runs the MySQL 5.7 image as a shell to generate a random database password on first start and store it in a secrets volume; the comment says an existing password is kept as is. The app service then reads that file through ACG_DB_PASSWORD_FILE and the installer pre-fills the built-in database connection, so you are not asked for credentials. The app is published on ${ACG_HTTP_PORT:-8080}, so http://localhost:8080 is the default address, and the compose file says the installer starts there. Redis is wired in through ACG_REDIS_HOST and ACG_REDIS_PORT, and the comment notes that when the variable is unset the entrypoint falls back to file-based sessions.

The constraint worth reading twice is the platform line. MySQL 5.7 official images are amd64 only, so the compose file pins platform: linux/amd64 and states that ARM machines (Apple Silicon, Ampere, Graviton) will run it through qemu emulation: it works but is slow. The comment offers mariadb:10.6 as the swap for native performance. The Dockerfile adds a second caveat for anyone pinning the PHP version: 8.0 and 8.1 base images sit on Debian bullseye, which the comment says has moved to archive, so the build redirects apt to archive.debian.org and disables validity checks, at the cost of no further security updates for system packages including nginx. The default build argument is PHP_VERSION=8.2 on bookworm.

Where acg-faka is the wrong tool

The licence notice is the largest limitation, and it is not a technical one. A shop that sells goods needs whatever qualification your jurisdiction requires, and the README says plainly that without it commercial use is forbidden. No amount of configuration fixes that, and the MIT grant does not override the author's stated restriction in the README. If your plan is a live commercial storefront, this project is the wrong starting point until that is settled.

The second limitation is environmental. The code requires PHP 8.0 or newer because of PHP 8 attributes and features, so any host still on PHP 7 cannot run it. The README recommends MySQL 5.7 or 8.0 and warns that 5.6 may cause upgrade problems later, which means a 5.6 deployment is a migration you have scheduled rather than avoided. On ARM hardware the default compose stack runs MySQL under emulation; the compose comment is honest that this is slower, and the fix is a different database image rather than a configuration tweak.

The third is scope. The README lists a wide feature surface (sub-sites, three-level commissions, shared stores, an app store) but does not document how any of it behaves under load, what happens when a payment plugin fails mid-order, or how upgrades interact with a customised template. The README describes a cloud update path from the shop admin panel but gives no rollback procedure. If you need documented failure semantics before you commit, that documentation is not in the README.

What acg-faka is not: a comparison with a generic PHP shop platform

The obvious alternative for a PHP storefront is a general-purpose e-commerce platform such as WooCommerce or OpenCart. The difference is not the language, it is the model of the product being sold. A general platform treats a product as a physical or downloadable item with stock, shipping and tax rules; selling a card code means generating or importing a pool of codes, reserving one at checkout, and delivering it. acg-faka is built around that second model from the start: the README lists card-code pre-selection, where the buyer can choose the specific account or card number, and an API for integration, which are the operations a code pool needs and a shipping-oriented platform does not provide out of the box.

The trade-off runs the other way too. A general platform has a wider plugin and theme ecosystem, formal release notes and a longer track record of running commercial shops, which is exactly the ground the acg-faka README closes off with its commercial-use restriction. If you need a shop where the licence clearly permits selling, the general platform is the safer choice even though you will write the code-delivery logic yourself. If you are studying how a code-pool storefront is structured in PHP 8, acg-faka is the more direct example.

Maintenance, upgrades and what the licence means in practice

The repository is not archived, and the last push was on 2026-09-21, the same day as the 3.7.9 release; 3.7.8 and 3.7.7 landed on 2026-09-21 and 2026-09-18. That is a fast release cadence, and the version numbers suggest incremental patches rather than long-lived branches. The README describes a cloud update path: when a new version exists, the shop admin panel can complete the upgrade without manual steps. The README does not document what happens to a modified template or a custom plugin during that upgrade, and it does not describe a rollback. Before you rely on it, take a database dump and keep the previous release archive, because the upgrade path itself is the only mechanism the README offers.

The licence is MIT, which normally permits commercial use, modification and redistribution with the copyright notice retained. The README's legal notice adds a restriction the licence text does not contain, and the two documents disagree. This is a question for a lawyer in your jurisdiction, not something to settle from a README. What can be said without legal advice is that the disagreement exists, that the README is explicit about forbidding commercial sales without qualification, and that anyone planning to sell should treat the README's notice as the operative statement until told otherwise.

Editorial conclusion

acg-faka suits developers who want to read and extend a PHP card-selling codebase, and anyone evaluating it as a live shop should first resolve the licence question, since the README forbids commercial use without legal qualification. Verify PHP 8.0 or newer, MySQL 5.7 or 8.0, and the Nginx rewrite block before installing, and read the payment plugin code before connecting a real merchant account.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. lizhipay/acg-faka on GitHub
4. README
5. Releases