Weave Code
Weaver
Helps Laravel developers discover, compare, and choose open-source packages. See popularity, security, maintainers, and scores at a glance to make better decisions.
Feedback
Share your thoughts, report bugs, or suggest improvements.
Subject
Message

Laravel Wordpress Laravel Package

jeffersongoncalves/laravel-wordpress

Laravel WordPress integrates Laravel apps with WordPress, offering a simple way to connect to the WordPress REST API, fetch posts and content, and sync data between your Laravel application and a WordPress site without extra boilerplate.

View on GitHub
Deep Wiki
Context7

Getting Started

  1. Install with Composer and publish the config:
    composer require <vendor>/<package>
    php artisan vendor:publish --provider="...\WordpressServiceProvider"
    
  2. Populate the three config values: base URL (e.g. https://blog.example.com), credentials (WordPress username + Application Password), and REST namespace (default wp/v2). Keep these in .env and reference them from config/wordpress.php — never hardcode the password.
  3. Generate the Application Password in WP Admin → Users → Profile → Application Passwords. It is a 24-char spaced string; store it verbatim.
  4. First use case: read-only content pull. List posts and render them, or grab a page by slug for a marketing page. This exercises auth, base URL, and namespace in one call and fails fast if credentials are wrong.
  5. Look first at: the Wordpress facade (entry point for every resource group), then the config file, then the Boost guidelines/skill shipped with the package — those encode the resource/method map faster than reading source.

A good second step is a single write operation in a staging WP install: create a draft post. Drafts are cheap to clean up and prove the auth user has edit_posts.

Implementation Patterns

Wrap the facade, don't scatter it. Create a thin WordpressContent / WordpressRepository service that injects the client and exposes only the operations your app needs (latestPosts(), publishDraft()). The facade is convenient in tinker and artisan commands, but constructor-injected services keep controllers testable and give you one place to add caching and retries.

Cache every read. Posts, pages, categories, and tags change rarely relative to how often you render them. Wrap list/get calls in Cache::remember() keyed by resource + id/slug + query hash, and invalidate explicitly after your own create/update/delete calls. Do not rely on WP to tell you when a human edited content in wp-admin — add a scheduled refresh or a short TTL for anything editorial.

Featured-image pipeline. Media upload takes a raw body plus Content-Disposition (which carries the filename), so build one helper:

$media = $wordpress->media()->upload($contents, $filename, $mimeType);
// then pass $media['id'] as featured_media when creating/updating the post

Keep this in a single attachFeaturedImage() method; the two-step dance (upload → set ID) is the most error-prone sequence in the package.

Content sync jobs. For import/export between WordPress and Eloquent, put the work in queued jobs or an artisan command, not a web request. Store the WP id on your local model as a unique key, and make the job idempotent (updateOrCreate on that key) so retries don't duplicate.

Pagination and bulk operations. Iterate page-by-page rather than requesting everything at once, and drive bulk edits from a queued job with a small delay so you don't trip WP host rate limits or PHP execution limits.

Testing. The package is built on Laravel's HTTP client, so Http::fake() should intercept calls — assert on the outgoing URL, method, and body rather than on the package's return shape, which keeps tests stable across patch releases. For higher-level tests, bind a fake implementation of your own wrapper service into the container.

Comments and users are best treated as admin-panel concerns: build moderation screens on top of the full CRUD rather than exposing them publicly. /users/me is the natural "is my credential still valid?" health check — call it from a scheduled command and alert on 401.

Gotchas and Tips

  • Application Passwords require HTTPS. WordPress refuses to issue/accept them over plain HTTP (outside of local environments). If your base URL is http://, expect silent 401s. Also confirm the feature isn't disabled by a security plugin or host — many managed WP hosts do.
  • 401 vs 403 tells you everything. 401 = bad/missing credentials. 403 = credentials are fine but the user lacks the capability (an Author cannot manage categories or other users' posts). Application Passwords inherit the full role of the user, so create a dedicated integration user with the minimum role that works, not an Administrator.
  • delete is not delete. The default delete trashes; force-delete is permanent and unrecoverable. Never wire force-delete to a public route, and log it when you do use it.
  • Media upload failures are usually environmental. Mismatched Content-Type vs the actual file, a missing filename in Content-Disposition, an unsupported MIME type (WP has an allowlist), or the WordPress host's upload_max_filesize — not your Laravel app's. Check the WP-side limits first.
  • Rendered HTML vs raw. The content field is filtered/rendered by default; raw content needs context=edit, which in turn needs auth and the right capability. If you're round-tripping content, be explicit about which you're reading and writing, or you'll mangle shortcodes and block markup.
  • Retries on writes create duplicates. Laravel's HTTP retry is helpful for GETs; applying it to post/comment/media creation can produce duplicate records on timeout-after-success. Retry reads automatically, retry writes manually and idempotently.
  • Trailing slashes in the base URL are the classic cause of doubled slashes and 404s. Normalize the config value once (rtrim($url, '/')) rather than debugging per-call.
  • Namespaced routes. Changing the REST namespace in config breaks every path if the site runs a non-default namespace or a plugin registers custom routes. Change it only if the site genuinely needs it, and verify with a raw curl before blaming the client.
  • Debugging: log the underlying request/response (URL, status, body) in a local log channel when a call misbehaves; WP error responses carry a code and message in the JSON body that are far more informative than the HTTP status alone. Reproduce with curl -u user:app_password to isolate package issues from WordPress config issues.
  • Extension points: the publishable config is the main lever (base URL, credentials, namespace); the Wordpress facade can be swapped for a fake via the container for tests; and the shipped Boost guidelines/skill are the fastest way to teach an AI assistant (or a new teammate) the package's conventions rather than having them infer them from source.
Weaver

How can I help you explore Laravel packages today?

Conversation history is not saved when not logged in.
Prompt
Add packages to context
No packages found.
jinas/dhivatar
store-doc/laravel-storage-driver
plus-it/laravel-translation-manager
diephp/perhaps
diephp/telegraph
osmaviation/spreadsheet
microsoft/fluentui-system-icons
mmccook/php-json-canonicalization-scheme
middlewares/firewall
qubiqx/montapacking
nyoncode/laravel-package-console
pnscripts/filament-broadquill-lite
pnscripts/laravel-sentfold-lite
vleap/mx-sdk-laravel-internal
twidpay/utils
htetmyathlaing/scout-elasticsearch-driver
artisan-toolbox/front-awesome
ls/client-assistant
users-au/laravel-client
cgv/localized-resource