Addblock Extension Laravel Package

Getting Started

visiosoft/addblock-extension is an OpenClassify/PyroCMS-style addon, not a general-purpose Laravel package. It is designed to be dropped into an existing OpenClassify install to add a UI for placing content blocks onto pages. Treat it as a module you wire into that host application, not something you composer require into an arbitrary Laravel app.

Minimal steps:

1. Inspect before installing. Read composer.json first. Confirm:
   • "type" — likely an addon/extension type that an OpenClassify installer expects.
   • "require" — the pinned OpenClassify/PyroCMS and Laravel versions. Since the last release is 2023-11-11, expect older Laravel constraints (8/9) and plan your host app accordingly.
   • The service provider / providers array — this tells you the namespace for views, routes, and migrations.
2. Install into an OpenClassify project, either via the admin Addons screen or by adding the repo as a VCS/path repository in the host app's composer.json, then running composer update visiosoft/addblock-extension.
3. Run the installer/migrations — typically php artisan addon:install visiosoft.extension.addblock-extension (or the OpenClassify admin install button), followed by php artisan migrate.
4. Clear caches — php artisan cache:clear, php artisan view:clear, and any OpenClassify-specific cache command. Extension registration is cached aggressively in these systems.

Where to look first: the service provider (registrations, view namespaces, routes), the resources/views/ directory for the admin UI and the front-end block partial, and src/ for the block definition/controller classes. The admin UI is usually the fastest way to understand the intended workflow.

First use case: log into the OpenClassify admin, open a page in the page editor, and look for the new "Add Block" control. Create a block (title + body/HTML), assign it to a region/partial on a page, save, and confirm it renders on the front end.

Implementation Patterns

Because this is an addon, the patterns are about composition inside OpenClassify, not standalone service classes.

• Admin-driven content authoring. The primary workflow is editors adding reusable blocks to page layouts through the admin page editor. The extension supplies the UI control and the persistence wiring; your job is usually to make the available block types and the regions they can target match the site's design.
• View partial override. Front-end rendering almost always goes through a Blade partial. Publish/override it into the host theme so you control markup and CSS classes rather than editing vendor files. Locate the view namespace in the service provider (e.g. addblock::partials.block) and shadow it in your theme's views directory.
• Block type extension. To add a new block type (image, CTA, video), follow whatever registration mechanism the extension exposes — a config array of block types, a tagged service, or a convention-based directory scan. Mirror an existing block's files (definition + form view + render view) rather than inventing a new structure.
• Pairing with sibling addons. This extension is typically used alongside the OpenClassify blocks/pages modules. Check Dependents/suggested packages in the host's addon list; installing it in isolation often yields a UI that saves data nothing renders.
• Repeatable per-page assignment. Standard pattern: define the block once, assign it to N pages/regions via a pivot-style table. If you need "same block, different content per page," create distinct block records and assign each — do not expect per-assignment overrides unless the schema exposes them.
• Deploy pattern. Commit the composer lockfile, run migrations and addon:install in the deploy script, and re-publish assets on every release since the addon is unversioned in practice and may not declare asset publishing.

Gotchas and Tips

• Zero stars / zero dependents = zero community surface. There is no issue history to mine, no Stack Overflow answers, and likely no tests. Budget time for reading source rather than searching for documentation.
• It is version-coupled to OpenClassify. Do not assume it works on a stock Laravel app or a newer OpenClassify release without verifying the composer constraints. Test on a staging clone first; a failed addon install can leave the admin bootstrapping broken.
• 2023 release date. Expect Laravel 8/9-era conventions: older service provider registration style, possibly $defer, and Blade syntax that may warn under newer PHP versions (8.2+ deprecations around dynamic properties are common in older addons).
• Caches will lie to you. After any change to the extension's registration, routes, or views, clear the application, view, route, and (if present) addon caches. Most "it doesn't show up" reports are cache artifacts, not bugs.
• Migrations and uninstall are often asymmetric. Verify the extension ships a clean uninstall path. If not, snapshot the DB before installing so you can drop its tables manually.
• Asset publishing. Admin JS/CSS for the "Add Block" control frequently needs an explicit publish step (vendor:publish --tag=... or the OpenClassify assets command). A blank control in the editor usually means unpublished assets, not a broken install.
• View namespace collisions. If two addons register a similarly-named namespace (addblock, blocks, pages), Blade resolution order decides which partial wins. Override in the theme, not by editing vendor views, so upgrades don't clobber your work.
• Extension points to lean on: view overrides, block-type config, and event/hook listeners the host exposes. Avoid patching src/ directly — with no upstream activity, your patches become permanent maintenance debt with no merge path.
• Maintenance risk is the headline. With 0 stars, 0 dependents, and a single stale release, treat this as vendored code: fork it into your org, pin the fork in composer.json, and own the upgrades yourself.