- How do I install murdercode/laravel-shortcode-plus in a Laravel app?
- Install it with Composer using composer require murdercode/laravel-shortcode-plus. The package supports Laravel auto-discovery, so the service provider and facade are registered without editing config/app.php. Publish the configuration file if you need to adjust defaults, then register your shortcodes in a service provider. There is no database migration or queue setup, so the install is a single dependency plus your own registration code.
- Which Laravel and PHP versions does laravel-shortcode-plus support?
- The package targets Laravel applications that render content server-side through Blade, and it ships a publishable config plus a Blade directive. Check the require constraints in the package composer.json against your own Laravel and PHP matrix before adopting, since the release notes for recent patch versions do not document changes. If your application is pinned to an older Laravel version, verify compatibility in a branch before merging. Confirm the match as part of your dependency review rather than assuming patch releases are safe.
- How do I register a custom shortcode and handler?
- You register a tag name and a handler, typically from a service provider, and the handler receives the parsed attributes and enclosed content and returns a string of rendered output. Registration is explicit, which keeps your shortcode vocabulary in one place instead of scattered across Blade templates. Freeze that vocabulary (tag names, attributes, defaults) as a versioned registry so the set of supported shortcodes is reviewable and reversible. Keeping handlers small and side-effect free makes them easy to unit test.
- Can shortcodes have attributes, and how are they parsed?
- Yes, the package parses WordPress-style syntax such as [tag attr="value"]content[/tag], including quoted attribute values, and passes them to your handler. Attribute quoting and defaults are historically where shortcode parsers produce surprising results, so test the exact forms your content authors use, including single quotes, unquoted values, and extra whitespace. Always escape attribute values when you interpolate them into HTML output. Document the supported attribute grammar for anyone authoring content, since unquoted or malformed attributes may not behave as they expect.
- How do I render shortcodes in a Blade view?
- The package exposes a Blade directive and a facade, so you can expand shortcodes either inside a template or on a plain string before passing it to the view. Rendering at view time keeps your stored content free of hardcoded markup and lets editors use a compact tag vocabulary. For content stored in a database, expand it in a controller, view composer, or dedicated renderer rather than scattering calls across templates. Cache the rendered result if the same content is expanded repeatedly on high-traffic pages.
- Is it safe to render shortcodes from user-generated content?
- Treat shortcode expansion as an XSS review item, not a code-review footnote: any tag that outputs attribute values or content supplied by users is an injection vector. Escape handler output with e() or Blade's escaping, and sanitize the final HTML after expansion if the content comes from outside engineering. Restrict which shortcodes are available on user-authored surfaces, and never let a handler output raw user input unescaped. Validate attribute parsing against your actual content sources before enabling it on public forms.
- What happens with nested, unclosed, or unregistered shortcodes?
- Unclosed tags, nested shortcodes, shortcodes inside code fences, and unusual attribute quoting are the classic edge cases where regex-driven parsers produce unexpected output. Decide explicitly how an unregistered tag should behave: fail loudly, render as literal text, or strip it entirely. Silently passing unknown tags through as literal text is common with these libraries and often confuses editors, so document the chosen behaviour. Write tests for each edge case using real content samples before you ship.
- Should shortcode expansion run before or after Markdown and HTML sanitization?
- The package is a text-transformation layer and does not coordinate automatically with Markdown or HTML sanitizers, so the ordering contract is yours to define. Expanding shortcodes before Markdown lets handlers emit Markdown that is then processed, while expanding after Markdown means handlers emit final HTML. Sanitize after expansion if handlers can produce markup, and pin the order in code and tests so it cannot drift. Changing the order later can materially change the rendered output of existing stored content.
- Does it work with Livewire, Inertia, email templates, or SPA front ends?
- It fits any server-rendered surface: Blade views, Livewire components, mail and notification templates, and seeded CMS blocks all work because expansion happens in PHP before the response is sent. Inertia, React, and Vue client components do not get this for free and would need a server endpoint or SSR to expand shortcodes. For email, expand content at send time and cache the result since rendering happens once per message. Avoid using it as a substitute for a real block or templating system in fully client-rendered applications.
- Is laravel-shortcode-plus maintained, and is it a safe replacement for my hand-rolled regex or WordPress shortcodes?
- It is a single-maintainer open source package, so bus factor is one: acceptable for a contained feature, not acceptable as an unexamined dependency in a revenue-critical render path. Recent patch releases have shipped with only a compare link and no changelog, so read the commit diff before upgrading and pin the version. If you are migrating from WordPress or custom regex helpers, do not cut over blindly: run a shadow render through both paths, diff the HTML, and triage deltas against a frozen shortcode registry. Name an internal owner and keep a fork or vendored-patch path in case upstream stalls.