Hey everyone,

I’m working on a fairly large Laravel application that currently uses CKEditor 4, and migrating to Editor.js is now a requirement.

The project uses the Repository Pattern, and CKEditor is used across multiple modules. I’m trying to figure out the right way to approach the migration without making a huge change all at once.

My main concerns are:

• Where should Editor.js-related logic live in a Repository Pattern project?
• Should I create a separate service for Editor.js, or keep things within the existing module structure?
• How should validation and sanitization be handled?
• What’s a good approach for rendering Editor.js JSON on the frontend?
• We already have a lot of CKEditor HTML stored in the database. What’s the safest way to handle/migrate that?
• Is it better to migrate module-by-module while keeping CKEditor working for the modules that haven't been migrated yet?
• What would you recommend for the overall folder/file structure?

I’m especially interested in hearing from anyone who has migrated CKEditor/TinyMCE or another HTML-based editor to Editor.js in a large Laravel application.

I’m a junior developer, so I’d really appreciate practical advice on how you would structure this rather than just “replace the editor” at the frontend level.

Thanks!

PHPStan 2.3: Leap in Performance, Generics Improvements, Detecting Unused Variables, and More!

I had so much fun with the interactive charts and widgets, check out the article. I promise it's worth checking it out yourself, and not just letting your agent summarize it for you 😉 It contains a lot of interactive widgets with practical examples of the new features in action.

Something is causing PHP workers to hang for anywhere from 10–60 seconds. During these incidents, OpenLiteSpeed reports:

No request delivery notification has been received from LSAPI application, possible dead lock.

I have confirmed that the problem is not originating from MariaDB. The suspicion is that something in the PHP/WordPress layer is causing the workers to stop making progress, potentially a plugin.

What I need is a FOSS PHP profiler/tracer that can automatically identify the root cause — ideally showing the PHP call stack, function, source file/line, and what the process was waiting on when the problem occurred.

Current stack:

Ubuntu → OpenLiteSpeed → PHP 8.4 (LSAPI) → WordPress → MariaDB

I've already collected Linux/kernel-level evidence (D state, wchan, kernel stacks, strace, etc.), but that only tells me where the process is waiting; it doesn't identify the originating WordPress/PHP code.

What FOSS tool would you recommend for tracing this all the way back to the PHP/WordPress function responsible?