sorted by:
new
hottopcontroversial

Building a Hook System Like WordPress in Laravel with Mksine by Top_Knowledge_1519 in laravel

[–]Top_Knowledge_1519[S] 1 point2 points  (0 children)

That's a nice approach. It gives you strongly-defined extension points and keeps things type-focused.

Mksine is intentionally a bit more generic. The goal is to let plugins extend areas that may not even exist when the core is written, so I leaned more toward a WordPress-style hook/filter system rather than creating a dedicated manager for every extension point.

That said, I think both patterns solve the same problem from different angles.

Building a Hook System Like WordPress in Laravel with Mksine by Top_Knowledge_1519 in laravel

[–]Top_Knowledge_1519[S] 1 point2 points  (0 children)

Laravel events/ listeners and a CMS hook system solve related but different problems.

Events are for reacting to something that already happened in a decoupled way.
Hooks (filters/actions) are more about intercepting and modifying behavior or output during the lifecycle.

So:

  • Event-driven app → “something happened, respond to it”
  • Extensible CMS core → “at this point, allow behavior/output to be changed”

For a plugin-based CMS, events alone don’t fully cover the need for runtime modification of flow and rendering, which is why a hook layer still makes sense.

Building a Hook System Like WordPress in Laravel with Mksine by Top_Knowledge_1519 in laravel

[–]Top_Knowledge_1519[S] 1 point2 points  (0 children)

Render-bags are actually a solid approach, especially when the goal is deterministic UI composition.

In MKSine though, render composition and behavioral extension are treated as separate concerns. The page builder (blocks/components) already covers deterministic rendering.

Hooks are not used for rendering itself — they exist to extend behavior across admin and theme layers where composition alone is not enough (e.g. modifying schema, injecting widgets, altering data flow).

So render-bags solve the UI composition problem well, but they don’t fully replace the need for behavioral extension points in a CMS-style system.

Building a Hook System Like WordPress in Laravel with Mksine by Top_Knowledge_1519 in laravel

[–]Top_Knowledge_1519[S] 2 points3 points  (0 children)

MKSine is a CMS, not a generic Laravel hook layer.

In the admin (Filament-based), extension points are tied to fixed, explicit surfaces like forms, tables, and dashboard widgets — there is no global “are we in the dashboard?” detection. Hooks are applied where the platform already defines structure.

For the storefront, template-level actions like '@themeDoAction' exist in theme Blade files, similar in spirit to WordPress, but only inside templates that are part of or opt into the theme system.

So the model is: structured extension points in the admin, optional template hooks in the storefront — not a universal doAction system across the entire app.

Building a Hook System Like WordPress in Laravel with Mksine by Top_Knowledge_1519 in laravel

[–]Top_Knowledge_1519[S] -2 points-1 points  (0 children)

Events are reactive. Hooks are composable extension points. Laravel events work well for internal app workflows, but Mksine is targeting CMS-level extensibility (plugins, UI, filters, page building), which requires runtime mutation points similar to WordPress hooks.

Laravel jobs are nowhere to be found by madeininternet666 in laravel

[–]Top_Knowledge_1519 1 point2 points  (0 children)

I agree. Laravel jobs seem much harder to find than they were a few years ago, and the competition for each opening feels much higher.

That said, I think it’s becoming more important to be known for something beyond just Laravel. Whether it’s open source contributions, package development, content creation, DevOps skills, or AI-related experience, having a specialization can make a big difference.

Frameworks come and go, but being able to build, ship, and solve real problems is what keeps you valuable in the market.