LikeShop: Docker Setup and Architecture for a PHP Commerce Suite

LikeShop's Single-Merchant Commerce Scope

LikeShop addresses the cost and duplication involved in building a storefront, customer center, transaction system, and operations console for several client platforms. The free enterprise edition is identified in the README as v3.5.1 and is positioned as a B2C system similar to a self-operated storefront. It is intended for commerce companies, software delivery teams, developers, teachers, and students. The repository description also lists social commerce, distribution commerce, B2B2C, ERP, CRM, and other broad scenarios, but the specific product description in the README calls this release a single-merchant system. That distinction matters. A buyer should not treat the topic tags as proof that every listed business model is implemented equally in this checkout.

The documented modules include a PC storefront, H5 storefront, WeChat mini-program, mobile applications, and a PC management console. Business functions include distribution, flash sales, group buying, price cutting, coupons, lottery drawings, daily sign-in, receipt printing, points, membership pricing, and several withdrawal options for commissions. Notifications can cover system messages, SMS, app push, WeChat template messages, and mini-program messages. These features make the repository broader than a simple catalog or storefront theme. It is a commerce foundation that connects merchandising, ordering, users, payments, marketing, and administration.

The intended user is therefore someone who expects to configure and customize a full transaction system rather than embed a small checkout component. Teams seeking a narrowly scoped library, a headless commerce API by itself, or a SaaS storefront will find that LikeShop imposes a much larger application structure.

PHP, ThinkPHP, and Multi-Client Request Flow

Based on the repository layout and technical-stack section, LikeShop divides the system into a `server/` backend, a `pc/` administration interface, and a `uniapp/` mobile client. The README identifies PHP 7.4, ThinkPHP 5.1, MySQL 5.7, and Redis 6 on the server side. The administration interface uses Layui 2.7 with server-side rendering. The mobile client uses uni-app and Vue.js, with separate frontend and backend code adapted for WeChat mini-programs, mobile H5, Android, and iOS. The PC storefront uses Vue.js and Nuxt.js with separate frontend and backend code.

This structure implies a shared commerce backend with different presentation layers. Product, order, member, payment, promotion, and operational configuration would need consistent identity and state across each client, rather than separate implementations for H5 and mini-program use. The README states that the terminals share data and that the PC management console manages them centrally. It also documents APIs, a data dictionary, directory structure, and development conventions at the project documentation site.

The architecture is practical for a conventional server-rendered operations console and multi-platform client suite. It also creates a coupling point: all channels depend on the compatibility of the shared API and business rules. During customization, developers must determine whether a change belongs in the ThinkPHP service layer, the Vue admin, the Nuxt PC frontend, or the uni-app client. The README does not provide a request-level sequence diagram, endpoint example, database schema excerpt, or compatibility matrix, so those details would need confirmation before committing to an implementation plan.

Docker Installation and the First Storefront Visit

The quickest documented local start uses Docker. Run the following command after installing Docker. It starts a detached container named `likeshop`, maps host port `20208` to container port `80`, and sets the MySQL root password environment variable for the supplied image.

docker run -d --name likeshop  -p 20208:80 -e MYSQL_ROOT_PASSWORD=root  registry.cn-guangzhou.aliyuncs.com/likeshop/php-b2c:latest

The README says to allow up to one minute because each Docker deployment downloads the latest source. Once the service is reachable, open the installer at `http://127.0.0.1:20208`. It lists default installation credentials as username `root` and password `root`. After installation, the documented entry points are the PC administration login at `/admin/login`, the PC storefront at `/pc/`, and the mobile storefront at `/mobile/`.

The first useful verification is therefore not merely whether the container starts. Check that the installer completes, the administration login opens, and both storefront paths return pages backed by the same installation. Then review payment, WeChat, SMS, and object-storage settings before creating live orders. Those integrations require credentials and external accounts that are not bundled with the local demonstration.

For durable local data, the README proposes mounting both database storage and application code, but it does not provide a verified production compose workflow in the visible instructions. The repository does contain a `docker/` directory, yet its contents are not documented here. Do not infer backup, restore, TLS, process supervision, or upgrade behavior from the existence of that directory.

Operations Configuration Across WeChat and Payment Services

LikeShop centralizes several external service configurations in the PC administration interface. The README names WeChat public-account and mini-program setup, WeChat Pay and Alipay, SMS providers from Alibaba Cloud and Tencent Cloud, and object storage through Qiniu Cloud, Alibaba Cloud OSS, or Tencent Cloud COS. It also states that CDN configuration is available. These are practical choices for a Chinese commerce deployment because customer interfaces, payments, messages, media, and distribution mechanisms often cross several providers.

The design reduces the amount of custom administration code needed for common storefront operations. Scheduled jobs can be configured through the management console, and task execution logs are recorded. Storage configuration matters because product images and other uploaded assets can otherwise be tied to one deployment. The system also documents multiple commission withdrawal methods, including WeChat balance transfers.

This breadth does not mean that every provider is automatically usable. The README supplies no environment variables, callback URLs, credential fields, settlement rules, retry behavior, or reconciliation procedures. It also does not document sandbox behavior. Engineers must map each provider's account requirements onto the available administration screens and confirm how orders, refunds, withdrawals, and asynchronous callbacks are recorded before accepting real payments.

The lack of an explicit online upgrade mechanism is especially relevant here. The free enterprise edition does not support online upgrades or automatic updates. That removes an attractive convenience but also means operators need a controlled source update and migration process if they expect changes after installation.

Free Edition Boundaries and Upgrade Cost

The current repository is not archived, and its last push was on 2026-09-24. That is recent repository activity, but it does not establish a release cadence because the repository has no GitHub releases. The README's free enterprise version is fixed at v3.5.1 and excludes online upgrades and automatic updates. The paid enterprise edition is described as receiving continuing updates and offering online upgrade services, removal of the copyright mark, and more extensive technical support.

This split changes the upgrade calculation. Adopting the free edition may avoid a paid edition fee, but source changes require the team to handle integration, data compatibility, regression checks, and deployment itself. The README does not document the migration format or tooling for applying a newer paid source tree to a free installation. It also does not define release artifacts because GitHub has no releases.

The Apache-2.0 license permits use and modification under its conditions. The README separately says the free enterprise edition supports commercial use if copyright information is retained. The paid edition says it can remove the copyright mark. Operators should therefore treat source-license obligations and edition branding requirements as separate deployment facts, and review the `LICENSE` file plus the edition terms before redistribution.

A custom version of LikeShop may also remain coupled to commercial modules or update services. Because the README mentions paid editions without listing a complete price or change schedule, upgrade budgeting cannot be reduced to a documented subscription number. The team must obtain current commercial terms directly from the vendor.

Where LikeShop Is the Wrong Commerce Base

LikeShop is a poor fit when the system must begin as a headless API or a small component embedded into another application. Its value comes from a broad application boundary that includes storefronts, administration, transactions, promotions, and client-specific presentation. Removing or replacing that structure may cost more than writing a focused service.

The single-merchant positioning is another boundary. A marketplace with independent merchant onboarding, merchant settlement, catalog isolation, permissions, and commission accounting requires more than selecting a distribution feature. Although the repository description mentions single-merchant and multi-merchant scenarios, the README section supplied for this release specifies a B2C, single-merchant product. A prospective multi-merchant operator should request evidence of the required merchant and settlement workflows before selecting it.

The fixed free version also creates a source-maintenance decision. Teams comfortable with schema migrations, deployment automation, custom patch review, and multi-client regression testing can accommodate manual updates. Teams expecting the vendor to deliver a controlled upgrade path through the free edition may prefer the paid edition or a different product. Documentation on rollback is also absent, so restoring a known-good database and source tree must be part of the adoption plan rather than an assumed capability.

Finally, the visible README does not state production support boundaries for the Docker command. It expressly warns against production use by users unfamiliar with Docker because of possible data loss. That makes the command suitable for evaluation, not evidence of a production deployment topology.

Separating LikeShop from a Custom-Layer Commerce Build

The closest architectural alternative visible from the repository structure is not another named commerce package, but a custom backend assembled with ThinkPHP or another PHP framework and paired with a uni-app mobile frontend. That approach starts with selected domain services and channels instead of LikeShop's complete mall, operations console, promotions, distribution features, messages, scheduled jobs, and payment integrations. It offers more control over boundaries and schema choices, but the developer becomes responsible for implementing and integrating the missing commerce behavior.

LikeShop changes that balance by providing several documented clients under one administration model. Its PC admin, PC storefront, H5, mini-program, and mobile application paths already form a delivery baseline. The documented configuration options also cover services commonly required after launch. A team that needs these capabilities soon is buying a functional starting point, not merely a PHP package.

The trade-off is source coupling and release governance. The free edition does not update itself, and its fixed version may not match changes already developed by a software company. A custom build can be designed around exact requirements, but the README gives no evidence that it will arrive faster or cheaper after accounting for catalog, cart, order, payment, refund, membership, promotion, notification, storage, admin, and multi-platform work.

LikeShop is therefore more defensible as an application foundation when its existing module boundaries align with the business. It is less defensible as a long-lived base if the team cannot tolerate manual upgrades or needs a multi-merchant model that the supplied product documentation does not confirm.

Editorial conclusion

LikeShop fits developers and commerce teams that want a configurable, single-merchant system with PC, H5, mini-program, and app clients managed through one backend. It is less suitable for projects that require a documented online upgrade path in the free edition or that cannot accommodate its shared administration model. Before adoption, verify the exact channel requirements, payment and storage credentials, database backup procedure, and the source of future updates.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. likeadmin-likeshop/likeshop on GitHub
4. Project website
5. README