jfinal_cms ships a full Chinese CMS admin panel on JFinal

Four technologies, one content site

jfinal_cms is an information and publishing website for the Chinese market, and the readme describes its stack in one sentence: the JFinal framework as the web layer, beetl as the template engine, MySQL as the database and Bootstrap for the front end.

The interesting part for an engineer is not the stack, which is conventional for a Java site, but how complete the thing is out of the box. The feature list covers OAuth2 authentication, account registration, password encryption, comments and replies, message prompts, visit statistics, per article comment counts and view counts, reply management and permission management. That is the feature set of a working publishing product rather than a skeleton.

The repository layout supports this. The top level holds .gitignore, ChangeLog.md, LICENSE, README.md, docs/, pom.xml, sql/ and src/, which is a standard Maven project with the database scripts kept outside the source tree. The project publishes both a GitHub address and a Gitee address, and the homepage is http://mtg.jflyfox.com/, which doubles as the demo site.

One metadata detail is worth flagging before you read the rest: the project listing records the primary language as JavaScript, while the description describes a Java web application using JFinal, Maven and a MySQL database. The backend is Java by any reading of the deployment steps, so treat the language field as an artefact of how the repository is indexed.

The admin module list is the actual feature specification

Chinese CMS projects are often judged by their module list, and jfinal_cms publishes a long one. It covers column management, column announcements, scrolling images for a column, article management, reply management, feedback messages, a personal album, album management, image management, collection management, video management, cache update, friendly links, visit statistics, contact management, template management, organization management, user management, role management, menu management, parameter configuration and data dictionary management.

Read as a system, that list describes a site with a role and permission model, a configurable navigation structure, a dictionary for site-wide parameters and a cache layer that has to be refreshed when content changes. The presence of a cache update module in the admin area is the detail that matters most operationally, because it tells you content is cached and that publishing is not instantly visible until the cache is refreshed.

Two more modules are unusual. Template management implies that the templates can be edited through the admin interface rather than only from the file system, and organization management implies that the site models companies or departments rather than a flat list of authors. Both are the kind of feature that separates a publishing platform aimed at institutional sites from a simple blog engine.

Multi-site mode runs several sites from one install

The deployment notes describe a multi-site capability with two levels of configuration. The system defaults to single site mode, and individual sites can be switched between through the site management entry under the other management section of the admin interface. To run more than one site at once, a flag called the multi-site marker, held under system management, has to be changed to true.

Multi-site also requires configuration outside the admin panel. Each site needs its own domain, with the domain resolution pointing at a different site template. That is the mechanism, and it is a template-per-domain model rather than a shared layout with per-site overrides, which means sites differ in appearance rather than only in content.

The consequence is that the multi-site setup is a deployment task rather than an admin task. Someone has to set up domain resolution, assign templates to domains and then create the site records in the admin interface, in that order. The readme does not describe the order, which is the kind of gap that turns into a support question the first time somebody enables the flag.

The admin interface itself lives under a configurable path, given in the readme as an address built from the host, the port and the project name, ending in /admin. Keeping that suffix off a fixed route is a small but sensible precaution for an internet facing admin panel.

Deploying means Maven, a SQL import and a Tomcat run

The deployment and configuration notes are numbered and concrete, which is unusual and useful. The steps are to download the project code and install jdk, maven and mysql; run the build in the project directory with `mvn install` and wait for the BUILD SUCCESS message; create a MySQL user and database and run the corresponding jfinal_cms_v4.sql script from the sql directory; then set the database configuration and, if OAuth2 is needed, the OAuth configuration.

The run step is `mvn tomcat:run`, which starts the site on a local Tomcat for development. For a real deployment the readme does not describe packaging a war, which is the first thing to establish for yourself if you intend to run this under an application server rather than in development mode.

Two configuration files are named in the notes. The database properties live at src/main/resources/conf/db.properties, and the OAuth settings at src/conf/oauth.properties, which is the file to edit if you enable the OAuth2 login path. The readme gives the paths but not the keys inside them, so those values have to come from the files themselves.

The readme also names default credentials for the admin area, admin with the password admin123 and a test account with the password 123456. Those exist in the source for a reason, and they must be changed before the site is exposed to a network.

Template sets for the admin panel and for the public sites

The project ships two template sets, one for each audience. The back end templates include the Bootstrap default style, a Bootstrap dark style and a flat-ui style, so the admin interface can be rebranded without writing CSS from scratch. The front end templates cover default content publishing, an official website template, a picture template and a video template.

That front end list lines up with the module list. Albums and video management need somewhere to publish their results, and the templates correspond to those content types rather than being generic skins.

Live examples exist for each of them. The main site is at http://mtg.jflyfox.com/, and there are separate addresses for the website template, the blog template, the photo album template and the video template. Being able to see the multi-site feature working across four domains is more informative than the template names alone.

The engine underneath is beetl, and the acknowledgements section credits JFinal, beetl and oschina. Template management in the admin panel implies templates are editable at runtime, which is convenient for an operator and a real risk for a deployment where nobody has thought about who can edit them.

The API client lives in a separate repository

There is a companion project for API work, and it is not part of this repository. The readme lists source addresses for an API client project under both GitHub and Gitee, named jfinal_cms_api_client, which means the CMS and its client are released and versioned separately.

That separation is a reasonable design for a CMS whose public surface is web pages, with a separate client for the data behind it. It also means the two have to be matched by version, and the readme does not say which release of the API client corresponds to version 5.2.0 of the CMS.

What is missing from the CMS repository itself is an API layer, so anyone planning a headless deployment, a mobile client or a front end that talks to the backend as an API should look at the client repository before assuming the CMS ships the endpoints they need. The module list in the admin area, article, reply, album and video management, is the closest description of the data model available in the documentation.

Documentation is thin in another way as well. The readme points to a Word document in the doc folder as the manual for the project, and the ChangeLog.md at the top level is the other reference. There is no structured API documentation in the repository, so anyone integrating against the system will be reading a binary document and the source.

Apache-2.0 licence, an uneven release history and a friendly default

The licence is Apache-2.0, with the text in the LICENSE file at the top level of the repository. That is a permissive grant with an explicit patent clause and attribution requirements, and it places no copyleft obligation on a site you build with the project. Whether it suits your own product terms is a question for your legal team.

The release history is uneven. Version 5.2.0 was published on 2026-06-10, while the previous two tags, v5.1.0 and v5.0.1, date from 2019-10-30 and 2019-06-15. That gap is worth noticing, because it means the project moved a long way between 5.1 and 5.2 rather than shipping regularly. The last push was on 2026-08-10 and the repository is not archived.

For an adopter, the practical questions are what changed in 5.2.0 and whether an upgrade path exists from an older install. The ChangeLog.md file is the place to start. The project also points at a developer group chat, and accepts donations with the list of contributors in docs/donate.md, which is a sign of an active but small community around it.

Editorial conclusion

Adopt jfinal_cms if you need a working Chinese content site with an admin panel, article, comment, album and video management already in place, and you are comfortable with a Java stack built on JFinal, beetl and MySQL. Skip it if you need a modern front end framework, a REST-first API as the primary surface, or support you can escalate to a vendor. Before deploying, change the default admin credentials listed in the readme, run the jfinal_cms_v4.sql script against a fresh database, and set the values in src/main/resources/conf/db.properties and src/conf/oauth.properties, since the project ships an Apache-2.0 licence and no security advisory process is described.

Frequently asked questions

Official sources

1. jflyfox/jfinal_cms on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases