- What is as247/wp-eloquent and what does it do?
- as247/wp-eloquent is a standalone Eloquent ORM layer for WordPress that lets you define models and query WordPress data with Laravel-style fluent syntax. It is intended for custom-domain tables and complex data access where WP_Query and $wpdb become cumbersome. It should be treated as a data-access layer alongside WordPress core APIs, not as a replacement for them.
- How do I install as247/wp-eloquent in a WordPress plugin or theme?
- Install it with Composer using composer require as247/wp-eloquent, then bootstrap an Eloquent connection using your WordPress database credentials. You will typically define model classes for your custom tables and include the Composer autoloader in your plugin or theme. The initial integration is moderate effort because you need to handle bootstrap, table naming, and model definitions carefully.
- Does as247/wp-eloquent require Laravel or illuminate/database?
- It does not require a full Laravel application, but the 'without dependencies' description should not be read as zero Composer dependencies. It likely depends on Illuminate database components such as illuminate/database, so you should inspect the Composer tree and confirm the exact version constraint. Pinning both as247/wp-eloquent and its Illuminate dependency is important for production stability.
- Which PHP, WordPress, and MySQL versions are supported by as247/wp-eloquent?
- The exact supported PHP, WordPress, and MySQL versions should be confirmed from the package composer.json, README, and release history. The technical evaluation flags compatibility testing for WordPress 6.x, PHP 8.2 and 8.3, multisite, custom table prefixes, and $wpdb behavior. Run a staging matrix before committing to the package in production.
- How does as247/wp-eloquent connect to the WordPress database and handle table prefixes?
- You typically bootstrap Eloquent with the same database credentials WordPress uses, then configure model table names to match your WordPress prefix. You must verify that it respects custom table prefixes and does not assume a hard-coded wp_ prefix. For multisite, test blog switching and prefix changes explicitly because Eloquent connections may not automatically follow WordPress site context.
- Can I use as247/wp-eloquent models for WordPress posts, users, and terms?
- Yes, the package is described as letting you query posts, users, terms, and custom tables with Eloquent-style syntax. However, WordPress core tables have their own schema and behavior, so models must be mapped carefully and tested against WordPress APIs. For simple content queries, WP_Query and WordPress functions are usually the safer and simpler choice.
- Does as247/wp-eloquent work with WordPress multisite?
- Multisite support is a compatibility risk that must be validated in your own staging environment. Confirm that the Eloquent connection respects the current blog prefix and that switching sites updates the table prefix correctly. Do not assume it handles multisite switching automatically without testing.
- Can as247/wp-eloquent coexist with other plugins that bundle Illuminate components?
- It can coexist only if you manage Composer autoloading and Illuminate versions carefully, because other plugins may already load Illuminate classes. Class collisions and version conflicts are a real risk in WordPress installations with multiple Composer-managed plugins. Isolate autoloading where possible and pin a consistent illuminate/database version across dependencies.
- Is as247/wp-eloquent actively maintained and safe for production?
- The package has limited community validation, with around 44 stars and a last release in November 2023, so maintenance risk should be treated seriously. Its MIT license allows you to fork if needed, but you should budget for internal ownership, dependency monitoring, and security advisories. Pin versions and have a fallback plan before relying on it for critical production data.
- When should I use as247/wp-eloquent instead of WP_Query or $wpdb?
- Use it when you need Eloquent-style models, relationships, eager loading, casts, and query builder ergonomics over custom tables, especially if your team already knows Laravel. Prefer WP_Query and $wpdb for simple custom post type queries, legacy tables, and core WordPress content paths. A strangler approach works well: start with one low-risk custom table or read-only sidecar model and keep WordPress responsible for authentication, hooks, options, and content APIs.