- How do I install dbout/wp-orm in a Laravel or WordPress project?
- Install it with Composer using composer require dbout/wp-orm. In a WordPress or plain PHP project, bootstrap Eloquent's Capsule against the WordPress $wpdb constants and define your models. In a Laravel host, register a second named connection for the WordPress database rather than creating a duplicate Capsule. Initialization must happen after WordPress is loaded, so avoid autoloading it before wp-config.php resolves.
- Which Laravel and PHP versions does dbout/wp-orm support?
- The package depends on a specific illuminate/database major, but the full compatibility matrix is not documented in the provided material. Check the package's composer.json for the exact illuminate/database constraint and PHP floor before adopting it. WordPress installs often pin older PHP versions than current Laravel supports, so verify both sides of the stack. Treat the package, Eloquent major, PHP, and WordPress version combination as something you own and test.
- What WordPress data can I model with dbout/wp-orm?
- It exposes WordPress core schema through Eloquent models for posts, users, terms, comments, options, and attachments. It is a data-access layer for wp_posts, wp_postmeta, wp_users, wp_options, and wp_terms-style tables, not a full WordPress abstraction. It does not handle hooks, rewrite rules, admin UI, or the template hierarchy. Custom tables can also be modeled with Eloquent.
- Does dbout/wp-orm work with WordPress multisite?
- Multisite behavior is not documented in the provided material and should be verified in a spike. Specifically, test whether the package honors $wpdb->base_prefix and switch_to_blog() correctly. If you run multisite, confirm how models resolve table prefixes before relying on it for cross-site reads or writes. This is one of the key questions to raise with the maintainer.
- How do relationships and eager loading work in dbout/wp-orm?
- The package supports Eloquent relationships and eager loading across WordPress postmeta and term relationships. That is where much of its value sits, because eager loading can measurably reduce the N+1 explosion common in hand-rolled get_post_meta loops. Define relationships on your models as you would in Laravel, then use with() to preload them. Test relationship queries against your actual WordPress data shapes and meta keys.
- Can I use dbout/wp-orm migrations with WordPress tables?
- The package advertises migrations, but treat schema changes to existing WordPress core tables as an advanced operation. Use migrations primarily for custom tables you own, and always back up and test against a copy of the WordPress database first. For core tables such as wp_posts, avoid schema changes that could break WordPress or plugins. Review generated SQL before running migrations in production.
- Is it safe to write to WordPress posts with Eloquent through dbout/wp-orm?
- Eloquent writes bypass important WordPress behavior, including save_post, wp_insert_post, revision creation, and object-cache invalidation. That makes any Eloquent write to wp_posts an advanced operation that should be reviewed and accompanied by explicit hook firing where needed. Reads are lower risk but can still return content the rest of the site considers filtered, translated, or private. Do not treat Eloquent writes as a drop-in replacement for WordPress APIs without testing plugin interactions.
- Does dbout/wp-orm respect WP_Query filters, plugins, and WordPress hooks?
- No. It is a data-access layer that queries the database directly, so it bypasses WP_Query and the hook layer where multilingual plugins, page builders, WooCommerce, and search indexers attach behavior. Eloquent reads can therefore return content that differs from what the front end would render. This is the main failure mode to evaluate for non-trivial WordPress sites, especially those dependent on WP_Query filters.
- Is dbout/wp-orm fast, and does it use the WordPress object cache?
- Eager loading helps performance by reducing N+1 queries compared with manual get_post_meta loops. However, the provided assessment flags cache-awareness as an open question: it is not documented whether reads use the WordPress object cache or persistent cache, or always hit MySQL. Benchmark your real query patterns and confirm cache behavior before using it on high-traffic sites. Also verify the package against your WordPress and PHP versions.
- Is dbout/wp-orm actively maintained, and what are the alternatives?
- The assessment describes a single-maintainer package with about 132 stars and zero dependents, so community validation is minimal and the maintainer is the entire support surface. The MIT license permits forking if needed. Alternatives include using WP_Query and $wpdb directly or evaluating another WordPress ORM, depending on whether you need Eloquent ergonomics or WordPress-native behavior. Verify release metadata and commit history before pinning the package.