Weave Code
Potter Laravel Package
potterywp/potter
Potter bridges Laravel and WordPress, offering a modern, structured workflow for building WordPress themes and plugins with cleaner code, reusable components, and less boilerplate. A handy toolkit for developers who want Laravel-style ergonomics in WordPress projects.
Conjunto de ferramentas que ajudam a criar sites WordPress mais facilmente.
Frequently asked questions about Potter
- What is Potter and how does it bring Laravel patterns to WordPress?
- Potter is a lightweight Laravel/PHP package from PotteryWP that replaces the WordPress template hierarchy with Blade-style views and adds Illuminate-derived pieces such as a service container and Laravel-style configuration. It wraps WP_Query, terms, and users in Eloquent-style models and supports PSR-4 autoloading via Composer. It is intended for a Laravel-fluent team building a bespoke, server-rendered theme where the theme is the product. Keep in mind its last release was April 2015.
- How do I install potterwp/potter with Composer?
- Require the package with Composer in your project root and wire Potter's service provider into your theme bootstrap. Because it pins Illuminate components from the Laravel 4.2 to 5.0 era, it expects PHP 5.4 to 5.6 and will not boot cleanly on a modern WordPress 6.x install running PHP 8.1 or newer without a fork. For a pilot, run it on a pinned, isolated PHP 7.4 stack.
- Which Laravel and PHP versions does Potter support?
- The pinned illuminate/* dependencies place Potter in the Laravel 4.2 to 5.0 range, which targeted PHP 5.4 to 5.6 and uses constructs removed or deprecated in PHP 7.x and 8.x. There have been no releases since 2015-04-25, so there is no upstream support for current PHP or Laravel 10/11. Upgrading the pins is non-trivial because the container's reflection and closure binding semantics and Blade's compiler directives changed materially across 5.x to 11.x.
- Is Potter compatible with WordPress 6.x, block themes, and Full Site Editing?
- Potter is explicitly a PHP-rendered template framework, which is the opposite of WordPress's direction toward theme.json, block templates, and Full Site Editing since 5.9. It is a poor fit for block-oriented builds, plugin-centric architectures, headless front ends, or multisite estates with centralized theme governance. It only fits a greenfield, server-rendered theme where stakeholders accept a locked-down editorial model.
- How does Potter's Blade templating differ from standard WordPress template files?
- Instead of procedural templates, Potter renders views/ with Blade, giving you expressive, DRY templates and reusable components. One important caveat: Blade escapes {{ }} by default, but WordPress post content must be emitted raw with {!! !!}, which is a routine XSS foot-gun in exactly the code path that renders user-authored HTML. Review every raw echo when porting existing theme markup.
- How do Potter's Eloquent-style models interact with WP_Query and third-party plugins?
- Potter wraps WP_Query, terms, and users in Eloquent-style models, which is a leaky abstraction over WordPress internals. Anything that bypasses WP_Query caching, pre_get_posts filters, query-monitor expectations, or multilingual plugins like WPML and Polylang becomes an integration incident. Audit your required plugin set for dependencies on the standard template hierarchy and query internals before committing.
- Is potterwp/potter safe and actively maintained for production use?
- No. It has roughly 18 stars, no release in about a decade, and no security disclosure process, so there is no upstream to patch a CVE in Blade's escaping or in the container. Treat it as reference architecture rather than a dependency, and approve it only for a scoped pilot with an explicit exit path. Maintained equivalents carry current PHP 8 support and active maintainers.
- What are maintained alternatives to Potter for Blade or Laravel-style WordPress themes?
- Roots Sage with Acorn gives you Blade in WordPress with current PHP 8 support, Themosis offers a Laravel-style WordPress framework, and Timber provides Twig-based theme logic. All three have active maintainers and current PHP support. You can keep Potter's ideas, namely Blade views, a container, and Composer-managed dependencies, without inheriting a decade-stale package.
- How do I handle Blade's compiled view cache on read-only hosts like WP Engine or WordPress VIP?
- Blade compiles views to disk, so hosts with read-only web nodes or non-standard writable paths, including WP Engine, WordPress VIP, Pantheon, and containerized or Kubernetes deploys, require a configured or pre-compiled cache path. This is a deployment-pipeline change rather than a config tweak. Confirm your target platform permits runtime writes to the theme's cache directory before you start.
- How should I test a Potter theme, and who maintains the fork if we upgrade it?
- Boot it on a pinned, isolated PHP 7.4 stack and exercise the code paths that render user-authored HTML, plus query behavior with your required plugins active. Decide up front which Illuminate version the package pins and whether anyone has actually booted it on PHP 8.x. Then agree who owns the fork and whether there is budget for an ongoing internal maintainer; if not, use Sage with Acorn, Themosis, or Timber instead.
Weaver
How can I help you explore Laravel packages today?