Puock: a WordPress theme with dark mode, PJAX loading and a Vue admin panel

What Puock is for, and who ends up using it

Puock is a WordPress theme, not a plugin, and it bundles a large amount of behaviour that would otherwise be spread across a plugin list: dark mode, global no-refresh loading, homepage load-more, a front-end user centre, QQ, GitHub, Gitee and Weibo login, captcha options, custom SMTP, ad slots, widgets and page templates for an archive page, a reader wall, a book list, a site directory and a sitemap. The README lists three layout modes: blog, CMS and corporate. That framing tells you the intended audience. It is a solo blogger or a small site operator who wants a finished front end with a settings panel rather than a bare theme plus a dozen plugins to maintain.

The trade-off is visible in the same list. Anything bundled into a theme is updated when the theme is updated, and it disappears if you switch themes. A site that has accumulated comments, user accounts and third-party login bindings inside the Puock user centre is not a site you can casually move to another theme. That coupling is the price of the convenience, and it is worth naming before you install rather than after.

How the PJAX loading and the Vue settings panel fit together

Two mechanisms define the day-to-day feel of the theme. The first is global no-refresh loading, which the topics list identifies as PJAX. Instead of a full browser navigation, page transitions are fetched and swapped in, which is why the feature list also mentions a skeleton screen and lazy-loaded images and avatars. A loading placeholder and image lazy loading only make sense in that model: the new content arrives after the shell is already on screen.

The second is the admin side. The theme settings screen is built with Vue 3 and NaiveUI, and the repository carries a Node build pipeline rather than shipping only raw PHP and CSS. The package.json declares gulp and Babel as devDependencies, with build and dev scripts mapped to gulp build and gulp watch. So the front-end assets are compiled, not hand-edited in place. If you fork Puock and change the LESS or JavaScript sources, you are expected to run the build, not to patch the compiled output.

The server side is ordinary WordPress PHP: templates such as single.php, category.php, search.php and page.php sit at the repository root, with inc/, templates/ and pages/ holding the rest, and composer.json plus vendor/ indicating PHP dependencies are managed with Composer. There is also a timthumb.php at the root, a legacy thumbnail resizing script, which the README pairs with a note about thumbnail pseudo-static URLs. That file has a long history of security scrutiny in the WordPress world, so treat it as something to keep patched rather than something to expose casually.

Installing Puock from the release package

The README is explicit about the install path: download only the official package named Puock-VX.Y.Z.zip from the releases page, then in the WordPress admin go to Appearance, Themes, Add, upload that zip, install and activate. It then adds a warning in bold: do not clone the repository, and do not download the GitHub-generated Source code (zip) or Source code (tar.gz) entries, because those are source snapshots and not the official install package. That is unusual advice and it is worth following, since a raw snapshot will not have the compiled assets the theme expects.

The environment requirements are given as WordPress 6.0 or newer and PHP 7.4 or newer. There are no install commands to run. The only pre-install action the README asks for is a database backup, because of possible data field collisions when the theme writes its own options.

If you are working on the theme itself rather than just installing it, the repository's own toolchain is Node-based. The package.json defines these scripts:

{
  "scripts": {
    "build": "gulp build",
    "dev": "gulp watch"
  }
}

Run the build script for a one-off compile of the assets, and the dev script while iterating. Both assume the devDependencies are installed first. After activation, the configuration screen is where the feature list becomes real: colour mode, captcha, SMTP, login providers and the ad slots are all set there, and the README notes there is a reset option for the theme settings if a configuration goes wrong.

Where Puock gets in your way

The clearest limitation is stated by the project itself: keep the footer attribution, per the GPL-3.0 licence and the README's closing note. If a client site cannot carry that credit line, this is the wrong theme, and no amount of configuration changes that.

The second is the install constraint. Because the project asks you not to install from a Git clone or a source snapshot, your upgrade path runs through the releases page. That is fine for a site owner, less fine for a team that wants to pin a commit or run a CI deploy from the repository. There is no documented rollback procedure in the README either, which makes the pre-install backup the only stated safety net.

The third is scope. Puock carries ChatGPT and AI drawing integration, a MacOS-style code block, Dplayer support, Twemoji, a grayscale toggle and a one-line HTML compression option. Each is a small surface with its own configuration and its own chance of conflicting with a plugin that does the same job. If you already run a dedicated caching plugin, a dedicated SEO plugin and a dedicated login plugin, you are paying for features twice and will spend time deciding which layer wins.

Finally, the theme is not a block theme in the full-site-editing sense. It ships a gutenberg/ directory, so block editor support exists, but the layout model here is classic templates plus a settings panel. A team that has standardised on theme.json and site editing will find Puock pulling in the other direction.

Puock versus a plugin-assembled classic theme

The honest alternative is not another named theme; it is the approach most WordPress operators already use, a minimal classic theme plus plugins for the parts you actually need. The difference is architectural. With a plugin stack, PJAX comes from a caching or navigation plugin, dark mode from a small theme or a CSS toggle, social login from a dedicated OAuth plugin, and captcha from whichever service you prefer. Each piece updates on its own schedule, and removing one does not disturb the others.

Puock inverts that. One install gives you the whole set, with a single settings screen and one update channel, and the pieces are designed to work together rather than merely coexist. The cost is that the pieces are not separable. If Puock's captcha implementation does not match your needs, you cannot swap just that module; you either live with it or override it in a child theme.

There is a middle path worth considering: use Puock for the presentation layer and keep your own plugins for the functions you consider critical, such as SEO or caching. The feature list includes built-in WP optimisation and SEO functions, so you will need to decide which side owns those responsibilities before you go live, not after.

Maintenance, releases and what the licence means in practice

The repository is not archived, and the last push was on 2026-09-11. Recent releases are v2.11.0 on 2026-08-20, v2.10.3 on 2026-08-15 and v2.10.2 on 2026-05-31. The gap between v2.10.2 and v2.10.3 is roughly two and a half months, while v2.10.3 to v2.11.0 is five days, so the cadence is uneven rather than strictly periodic. There is a USAGE.md and a USAGE_EN.md in the repository alongside the README, and the project points to an external documentation site, which suggests the maintainer expects configuration questions to be answered there rather than in the README.

Upgrade cost is mostly the usual WordPress theme routine: download the new Puock-VX.Y.Z.zip, upload it through the themes screen, and keep the database backup the README recommends. Because the theme stores its own options and the user centre stores accounts and third-party bindings, a version that changes option keys is the scenario the backup warning is aimed at. The release notes are the place to check before upgrading, and the README directs readers there for feature changes.

The licence is GPL-3.0, stated in the README and present as a LICENSE file at the repository root. In practical terms, GPL-3.0 is a copyleft licence: derivative distributions carry the same licence, and the project asks that the footer attribution be preserved. That is a project request layered on top of the licence, and reasonable people read the boundary differently, so if attribution matters commercially for your site, raise it with the maintainer before you build on the theme. This is not legal advice; check the LICENSE file and, if the stakes are high, a lawyer.

Editorial conclusion

Puock fits self-hosted WordPress blogs and small CMS or corporate sites whose operators want dark mode, PJAX navigation, third-party login and a front-end user centre without wiring up separate plugins, and who are comfortable installing from the release zip rather than a Git clone. Skip it if you need a block-first theme with full site editing, or if you cannot accept that the GPL-3.0 licence plus the project's own request means the footer attribution stays. Before installing, confirm your host runs PHP 7.4 or newer on WordPress 6.0 or newer, and take a database backup, which the README itself asks for because of possible field collisions.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. Licoy/wordpress-theme-puock on GitHub
3. Project website
4. README
5. Releases