Attendize

1. Summary

Attendize is a self-hosted event ticketing platform: organisers publish events, sell tickets with Stripe or offline payment, email PDF tickets, check attendees in, and export attendee and order lists. It is a real, mid-sized product with about 43,500 lines of PHP and 210 views, and roughly 4,300 stars on GitHub.

It runs on Laravel 6.18 and PHP 7.3, shipped in a Docker image built on PHP 7.4. Laravel 6 left security support in September 2022 and PHP 7.3 in December 2021. The last commit is from January 2023. The dependency lock holds 97 production packages, several of them abandoned, including the HTML form helper that 63 views depend on and the PDF engine that generates every ticket.

The application code is conventional Laravel and the automated tools find little PHP-language breakage. The work is in three places: six framework releases, a dozen third-party packages that need replacing or crossing major versions, and the checkout flow, which stores objects in the session and talks to Stripe through an abstraction that must be tested end to end. We recommend PHP 8.4 and Laravel 13, delivered in six stages over about six weeks behind characterization tests, with the current runtime kept in production until cutover.

2. What we looked at

• The public repository at its development branch, cloned 22 October 2026. Version 2.8.0, last commit 25 January 2023.
• Size: 132 application files (12,005 lines), 210 Blade views (11,466 lines), 52 migrations and 10 seeders, 19 model factories, 24 config files. 756 PHP files and 43,557 lines in total, excluding vendor code.
• Dependencies: 97 production and 52 development packages in the lock file.
• Tests: 16 test files, of which 8 sit in a deprecated folder and are not run. The live suite covers order cancellation and refunds with and without tax, and a version-parsing utility.
• Build tooling: Bower, Grunt and LESS for the front-end, with Laravel Mix 5 and a Laravel Elixir remnant also present. Vue 1.0 and Bootstrap 3 in the browser.
• Deployment: a multi-stage Dockerfile, nginx config, and a web installer at /install that writes the environment file and runs migrations.
• Not available to us: a production database, real Stripe credentials, and the hosting environment.

3. Dependency health

Direct production dependencies with a decision attached. Status comes from Packagist on the assessment date.

4. What breaks on the target

PHP 7.3 to 8.4

Automated results are in the appendix. From reading the code, the PHP-level work is small and specific:

• Undeclared properties assigned at runtime in the two Stripe gateway classes, the attendee export and the attendee import. PHP 8.2 deprecates dynamic properties; declare them.
• number_format() and string functions receiving null from nullable columns raise deprecations on 8.1 and later; the money helper and several views need null guards.
• Method-name case mismatches such as Str::Random work but should be normalised.
• Direct $_ENV lookups depend on the server's variables order; use env().

Laravel 6 to 13, release by release

Limited to what this codebase touches, from the official upgrade guides.

• Laravel 7. The exception handler must type-hint Throwable. Eloquent JSON serialization switches to ISO-8601 dates, which changes the read API's output; override serializeDate on the base model to preserve the old format. Markdown mail templates are re-published. MAIL_DRIVER becomes MAIL_MAILER, and the installer writes the old key, so the installer changes too.
• Laravel 8. Nineteen legacy model factories: keep them running with the legacy-factories package or rewrite as classes. The seeds folder is renamed and namespaced. The paginator defaults to Tailwind, so Bootstrap pagination must be switched on for the Bootstrap 3 UI. Guzzle 7. Route files already use class references.
• Laravel 9. Symfony 6 removes the forwarded-headers constant used in TrustProxies. Flysystem 3 changes the S3 disk configuration. Swift Mailer becomes Symfony Mailer; the seven Mail::send closures and six Mailables use only standard methods and should carry over. The wording of every validation failure changes: the top-level message of a 422 becomes a summary of the first error instead of the fixed string, while the per-field errors object stays the same. The checkout runs on AJAX responses, so whether the browser code reads that field has to be checked; if it does, the old wording is restored with a short override and the decision recorded.
• Laravel 10. PHP 8.1 minimum. The $dates property is deprecated in favour of casts; ten models use it and three override getDates(). No release of Laravel 10 can be installed. Composer blocks all of 10.0 to 10.50, because every one carries security advisories with no patched release in that line, so this version is passed through rather than rested on.
• Laravel 11. PHP 8.2 minimum. $dates is gone: convert to casts. The framework no longer requires Doctrine DBAL. Carbon 3: diffInSeconds now returns a float and can be negative, and the checkout countdown uses it. This is also where the form helper stops working, so the view rewrite lands here at the latest. No release of Laravel 11 can be installed either, for the same reason as 10. The earliest installable Laravel is 12.69.
• Laravel 12. The container honours nullable class defaults; no affected call sites found.
• Laravel 13. PHP 8.3 minimum. The CSRF middleware becomes PreventRequestForgery with origin checks, which matters for the embedded checkout iframe used on third-party sites. Session serialization defaults to JSON in the new config, but the checkout stores Eloquent models and the account's payment gateway object in the session, so either the session config stays on PHP serialization or the checkout is refactored to store ids. We recommend the refactor. PHPUnit 12. On the origin check, one thing is worth stating plainly because it changes how this stage is verified: Laravel switches the request-forgery middleware off entirely while tests run, so no test suite can prove the embedded checkout iframe still works. We verify it by driving a running server over HTTP the way a browser does, from a third-party origin. A related change goes in the handover note: Laravel 13 accepts a same-origin form post with no CSRF token at all, where 6 to 12 refused it.

Front-end build

Bower, Grunt, LESS, Vue 1.0 and Bootstrap 3 date from 2015 and 2016. Bower is retired and the pinned packages have known vulnerabilities, but the compiled assets are committed and the application runs without rebuilding them. We propose leaving the browser code as is during the migration and quoting a front-end modernization separately.

5. Risk register

6. Findings beyond the upgrade

Found while reading the code. Not part of the migration price; the owner decides. Items 1 to 3 touch money and we recommend fixing them during stage 1.

1. A misspelled catch block swallows nothing.payments
   The order-creation method catches \Exeption, so any gateway exception during payment surfaces as a server error with no logging and no friendly message.
2. The order-completion rollback never fires.data
   Order completion wraps its database transaction in a catch for Exception, but the file imports a test-tool class under that name. Real database or model errors are not caught, the transaction is left open, and a half-written order can remain. The same import appears in two other production files.
3. PDF tickets are served from a public folder.security
   Tickets live under the public directory named by order reference, which is five random characters plus the day and month. Anyone who can guess or enumerate a reference can download a ticket. Move tickets to private storage with signed links.
4. The tenant scope builds SQL by string concatenation.security
   The value is the authenticated account id today, but it should be a query binding.
5. A controller calls exit()bug
   when JavaScript is disabled, ending the request outside the framework; return a response instead.
6. Translated yes/no strings are interpolated into SQLhygiene
   in the attendee and order exports. Safe today, fragile tomorrow.
7. Test card data and a dummy gateway ship in configpayments
   and are selectable when test payments are enabled; ensure production pins it off.
8. API tokens are a plain columndesign
   compared by the legacy token guard; acceptable, but a candidate for Sanctum once on Laravel 13.
9. Hygiene.hygiene
   A deprecated tests folder, three build systems for the front-end, and an unused Socialite dependency.

7. Test coverage and verification plan

Today: three live test files covering refunds and a utility, eight disabled tests, and no automated coverage of checkout, ticket generation, imports, exports or check-in.

Before any change we write characterization tests that pin current behaviour and run them on the old runtime in Docker (PHP 7.4, the locked dependencies, MySQL 5.7):

• Checkout: reserve, validate, create order with the dummy gateway, free tickets, offline payment, affiliate credit, survey answers; the JSON shape of each AJAX response and the session contents at each step.
• Stripe: a scripted run against Stripe test mode through both gateway classes, including the Payment Intents redirect return.
• Refunds: the existing suite, kept green.
• Orders and attendees: message, cancel, resend; spreadsheet import creates orders, items, attendees and stats; exports produce the expected columns and row counts.
• PDF tickets: generation succeeds and the output contains the attendee reference and QR code.
• Check-in, installer refusal when installed, API lists, and a rendered-HTML snapshot of each screen that uses the form helper, taken before the rewrite.

Roughly 120 tests. They ship with the project.

8. Staged plan

Two rules shape this sequence, and both are corrections to how such plans are usually drawn. The runtime rises in step with the framework, never ahead of it, because each Laravel release caps the PHP version it accepts: Laravel 8 does not run on PHP 8.4. And no stage ends on a release that cannot be installed, which rules out resting on Laravel 10 or 11.

Six weeks in total, unchanged from the first issue of this report. The work is the same; only its order is. Each stage is a pull request with the suite green. Production stays on the old runtime until stage 7.

9. Estimate and options

Excluded: new features, hosting changes beyond the Docker image, the front-end rebuild.

Appendix A. Laravel 13 dependency probe

Run 23 October 2026. Each of the 28 non-framework production dependencies was resolved on its own against php ^8.3 and laravel/framework ^13.0, at any version, with the resolver platform pinned to PHP 8.4.27 and Composer's security-advisory policy left on. That policy is now part of what "installable" means: it is what blocks every release of Laravel 10 and 11.

Resolving is not the same as being safe. Two of the 26 carry caveats the resolver cannot see: nitmedia/wkhtml2pdf resolves only because it declares almost no constraints, and the real risk is its bundled 2013-era binary meeting a new OS or an ARM host (risk 2); superbalist/php-money resolves but is abandoned and needs ext-bcmath in the target image.

Measured scale of the critical path, counted from the repository rather than estimated: 583 Form:: and 63 Html:: call sites across 63 of 210 views, behind just 25 distinct helper methods and 5 custom macros. Form::label and Form::text alone account for 307 of the 646 call sites. The concentration matters more than the total: 25 methods is a small surface to reimplement once and then apply mechanically, which is what makes a fixed price on this item possible.

Appendix B. Static scan output

Produced by Rector 2 with the PHP 8.3 set and the Laravel level set up to 12, and PHPStan 2 at level 1, against a copy of the repository with its locked dependencies installed.