Xetaravel Laravel Package

Getting Started

Xetaravel is a CMS layer for Laravel — it ships blog, forum, user/role management, and settings on top of a standard Laravel app. The v5.0.2 release is a patch on the 5.x line, so start by matching your Laravel version to the package's 5.x requirements before installing.

1. Install via Composer alongside a fresh Laravel app, then publish the package assets and config:

   composer require xetaio/xetaravel
   php artisan vendor:publish --provider="Xetaio\Xetaravel\XetaravelServiceProvider"
   php artisan migrate
   

2. Seed the baseline roles/permissions and an admin user — the CMS's authorization layer assumes these exist before you can reach the admin panel.
3. Look first at config/xetaravel.php (or the published config namespace) and the package's route/service-provider registration. That's where feature toggles and route prefixes live.
4. First use case: stand up the blog module (posts + categories) behind the admin panel, confirm an article renders on the front end, then check /sitemap.xml — the new sitemap generator in this release should be live without extra configuration.

Implementation Patterns

• Patch-level upgrade: v5.0.2 is a bugfix/feature-patch combination, not a breaking release. Run composer update xetaio/xetaravel and re-publish only the assets that changed (icons/meta views), not your whole config.
• Sitemap integration: The new generator hooks into robots.txt automatically. Pattern: keep your own public/robots.txt out of source control or let the package own it — if you hand-maintain a Sitemap: line you'll end up with a duplicate. Prefer the package's route for /sitemap.xml and override the generator's model/URL list via the published config or a service-container binding rather than editing vendor code.
• Meta tags: The "Optimize Meta tags" change means the package now emits meta tags more centrally. If you were previously injecting per-page OG/Twitter tags manually in Blade layouts, audit for duplicates — put custom tags in the package's meta configuration/seo fields on the model, and strip your hand-rolled @section('meta') blocks where the package now covers them.
• Icons: Route all icon rendering through the package's icon helper/component rather than raw <img>/<i> tags — the "old icon not rendering" fix implies a cached or legacy icon path, so anything you've hardcoded may still display stale assets.
• Content workflow: Use the admin panel for editorial content and reserve code changes for module extension (custom controllers, policies, view overrides under resources/views/vendor/).
• Upgrade checklist in CI: run migrations, clear view:cache and config:cache after updating — icon and meta changes are view/config-cache sensitive.

Gotchas and Tips

• Cache is the #1 culprit for both fixes in this release. After upgrading, run php artisan optimize:clear (or at minimum view:clear + config:clear). A "still broken icon" or "meta tags not updating" report is almost always stale compiled views or a cached config.
• robots.txt auto-injection can conflict with an existing file. Check public/robots.txt after the upgrade; if your deploy pipeline ships its own copy, the package's sitemap line may be overwritten on every deploy — move the sitemap reference into your deploy-time robots template instead.
• Sitemap on large sites: the generator will enumerate published content. Verify it respects your publication scopes and doesn't emit draft/unpublished URLs; add the generator to your performance budget check if you have thousands of posts.
• Meta tag duplication: after the optimization change, validate with a head-inspection or an OG debugger — duplicate og:title/description tags are a common post-upgrade artifact of layout-level overrides.
• Config publishing overwrites: use --force sparingly; diff the published config against your own before overwriting, since patch releases occasionally add new keys.
• Extension points: prefer overriding via published config, view namespaces, and container bindings over editing vendor files — this package's rapid patch cadence (5.0.2 within days of 5.0.1) means you'll be updating often.
• Watch the changelog cadence: PRs numbered 97–99 landing in a single patch suggests active development. Pin the minor version (~5.0.2) and read release notes before each update, since "fixes" touching icons/meta can shift rendered markup your tests assert against.