Most people, when asked what a database does, say something like: “it stores data.”

That’s like saying a restaurant “stores food.”

Technically true. Completely misses the point.

A restaurant has to cook fast, serve many tables at once, and not poison anyone. Fail any one of those three and it doesn’t matter how good the kitchen looks. A database has the same problem — except the stakes are your production system at 2am.

A few years ago I gave a talk at Percona Live in Denver where I tried to answer this properly. Not from a features list. Not from a vendor slide deck. From first principles: what does a database have to do?

Three things. Everything else — every configuration parameter, every architecture decision, every incident you’ve ever fought — falls into one of them.

Execute Queries

A restaurant has one core job: take an order and bring food to the table. Fast, correct, and for as many tables as possible simultaneously.

A database has the same job. Answer questions about data. Record changes. As fast as possible, as many as possible, without corrupting anything in the process.

That last part is the one that gets sacrificed first when you’re optimizing for speed. InnoDB’s entire machinery — the buffer pool, the redo log, the doublewrite buffer — exists to make sure “fast” and “correct” happen at the same time. ACID isn’t a marketing term. It’s the contract the database makes with every query it executes.

The tension is real. Disabling foreign_key_checks before a bulk load makes the operation faster. It also removes a correctness guarantee while it’s disabled. That tradeoff isn’t inherently wrong — but you can only make it deliberately if you understand what you’re trading. If you’re curious about the hidden consequences of foreign keys, I covered one particularly dangerous scenario in the ON DELETE CASCADE blind spot in MySQL’s binary log.

When a query is slow, the reflex is to reach for indexes. Sometimes that’s right. But a query can also be slow because lock contention is serializing execution, because the working set stopped fitting in the buffer pool, or because something upstream is flooding the connection pool. Same symptom, completely different root causes, completely different solutions. Knowing the responsibility narrows the search. Understanding InnoDB semaphore contention is one way to tell lock contention apart from other causes.

Relationships

No database is an island.

Think of it like a person who has three very different kinds of relationships in their life — and does a bad job with any one of them at their own peril.

With users, the relationship is trust and boundaries. Who gets in, what they can see, what they can touch. MySQL’s account model — hosts, privileges, roles — is the entire machinery for this. When someone asks why the application can’t just run as root, this is why. The database has a responsibility to protect data from people and systems that shouldn’t have it. That responsibility doesn’t disappear because setting it up is inconvenient.

With other databases, the relationship is coordination. A replica trusts that the primary is sending it a faithful copy of reality. A PXC node trusts that the other nodes in the cluster will agree on the same writes. When wsrep_local_recv_queue starts climbing, the cluster is telling you a relationship is under stress — one node can’t keep up with what the others are sending. It’s a relationship problem before it’s a performance problem. Treating it as a performance problem first is how you end up chasing the wrong metric.

With dev and ops teams, the relationship is communication. Logs, status variables, Performance Schema — this is how the database talks. When you skip configuring the slow query log because it adds overhead, you’re choosing silence. You’ll regret that choice during the next incident, when you’re flying blind trying to reconstruct what happened. Tools like PMM Query Analytics exist precisely to bridge this communication gap.

A database that executes queries correctly but can’t communicate its state, can’t cooperate with peers, and can’t enforce who has access — is a ticking clock.

Survive

This is the one nobody talks about at conferences, and it’s the one that kills you.

A database doesn’t run in the cloud. It runs on a machine. A machine with a CPU that can be saturated, memory that can be exhausted, and a disk that fills up and then — not slowly degrades, but stops. Full disk doesn’t slow MySQL down. It stops it cold.

Think of it like a tenant who has to know the rules of the building they live in. The landlord — the OS — controls memory allocation, file descriptors, I/O scheduling. The tenant can push their luck, but only so far before the landlord intervenes. An OOM kill at 3am is the landlord evicting a tenant who was using more than their share.

innodb_buffer_pool_size is the most important negotiation a MySQL server has with its host machine. Too low and you’re leaving performance on the table. Too high on a box running other processes and you’re gambling that the OS won’t reclaim that memory mid-write. That configuration parameter isn’t a performance knob. It’s a survival decision.

Disk is more insidious. A table that grows 100MB per day doesn’t look dangerous today. In six months it’s 18GB. The database won’t warn you. It will just stop one day. The monitoring that watches disk growth trends and alerts before the cliff — that’s not operational overhead. That’s the database fulfilling its responsibility to survive the physical world it lives in. Setting up smart alerting with dynamic thresholds is how you catch these slow-moving threats.

Backups live here too. A database that can’t be recovered after a failure didn’t survive. Full stop.

Why This Framework Matters

These three categories won’t tell you how to fix anything. They’re not a checklist. What they give you is a way to locate a problem before you start solving it — and that matters more than most people admit.

Replica falling behind? Three possible zip codes:

• Execute Queries — the primary is running queries so heavy that the replica can’t replay them fast enough
• Relationships — the network between primary and replica can’t carry the replication stream
• Survive — the replica’s disk I/O is the bottleneck

Same symptom. Three completely different tools. If you go straight to tuning queries when the real problem is disk throughput on the replica, you will waste hours.

The framework doesn’t solve the problem. It tells you which drawer to open first.

Every decision you make as a DBA is in service of one of these three things. Execute queries correctly and fast. Manage relationships with users, peers, and teams. Survive the physical constraints of the machine it runs on.

That’s the whole job.

I first presented this framework at Percona Live in Denver. The talk was aimed at DBAs, but I’ve always believed that database fundamentals should be explainable to anyone — and that explaining them clearly forces a deeper understanding than talking only to specialists.

Ward, created by El Jakani Yassine is a command-line security scanner written in Go designed around Laravel’s structure. Rather than running generic pattern matching across your codebase, it first parses your project’s structure—routes, models, controllers, middleware, Blade templates, config files, environment variables, and dependencies—then runs targeted checks against that context.

Installation

Ward is distributed as a Go binary so you’ll need to ensure you Go already installed and then you can run:

go install github.com/eljakani/ward@latest
 
# Make sure $GOPATH/bin is in your PATH
export PATH="$PATH:$(go env GOPATH)/bin"

After installing, run ward init to create ~/.ward/ with a default config file, 42+ built-in rules organized by category, and directories for reports and scan history.

Scanning a Project

Point Ward at a local directory or a remote Git repository:

# Local project
ward scan /path/to/laravel-project
 
# Remote repository (shallow cloned)
ward scan https://github.com/user/laravel-project.git

When run in a terminal, Ward displays a TUI. A scan view shows pipeline progress and live severity counts as scanners run. Once complete, a results view presents a sortable findings table with severity badges, category grouping, and a detail panel showing descriptions, code snippets, and remediation guidance.

What It Checks

Ward ships with four independent scan engines:

• env-scanner runs 8 checks against your .env file, including debug mode enabled in production, missing or weak APP_KEY, and secrets leaked in .env.example.
• config-scanner runs 13 checks across your config/*.php files, covering hardcoded credentials, insecure session flags, CORS wildcard origins, and missing security options.
• dependency-scanner queries the OSV.dev advisory database in real time against your composer.lock to find vulnerable Packagist packages. Because it queries live data rather than a bundled list, it reflects current advisories rather than whatever was current at the tool’s last release.
• rules-scanner applies 42 rules across 7 categories: secrets (hardcoded passwords, API keys, AWS credentials), injection (SQL, command, eval), XSS (unescaped Blade output, JavaScript injection), debug artifacts (dd(), dump(), phpinfo()), weak cryptography (md5, sha1, insecure RNG), configuration issues (CORS, CSRF, mass assignment), and authentication gaps (missing middleware, absent rate limiting).

Output Formats

Configure output formats in ~/.ward/config.yaml:

output:
 formats: [json, sarif, html, markdown]
 dir: ./reports

• JSON — machine-readable results
• SARIF — compatible with GitHub Code Scanning and IDE integrations
• HTML — standalone dark-themed visual report
• Markdown — suitable for PR comments

CI/CD Integration

Ward returns non-zero exit codes when findings meet or exceed a specified severity, making it straightforward to gate deployments:

ward scan . --output json --fail-on high

A GitHub Actions example from the project’s documentation:

name: Ward Security Scan
on: [push, pull_request]
 
jobs:
 security-scan:
 runs-on: ubuntu-latest
 steps:
 - uses: actions/checkout@v4
 - uses: actions/setup-go@v5
 with:
 go-version: '1.24'
 - name: Install Ward
 run: go install github.com/eljakani/ward@latest
 - name: Run Ward
 run: ward init && ward scan . --output json
 - name: Upload SARIF
 if: always()
 uses: github/codeql-action/upload-sarif@v3
 with:
 sarif_file: ward-report.sarif

Baseline Management

For teams that want to acknowledge existing findings without suppressing future ones, Ward supports a baseline workflow:

# Capture current state
ward scan . --output json --update-baseline .ward-baseline.json
 
# On subsequent runs, suppress known findings and fail only on new ones
ward scan . --output json --baseline .ward-baseline.json --fail-on high

Committing .ward-baseline.json to your repository lets the team track which findings have been acknowledged and catch regressions in CI.

Custom Rules

Drop .yaml files into ~/.ward/rules/ to define additional checks. Rules support regex or substring patterns, file-existence checks, and negative patterns that fire when something is absent—for example, flagging routes that lack @csrf. You can target PHP files, Blade templates, config files, environment files, routes, migrations, or JavaScript files.

rules:
 - id: TEAM-001
 title: "Hardcoded internal service URL"
 severity: medium
 patterns:
 - type: regex
 target: php-files
 pattern: 'https?://internal-service\.\w+'

Individual built-in rules can also be disabled or have their severity overridden in config.yaml without touching the rule files themselves.

Scan History

Ward saves each scan result to ~/.ward/store/, and on subsequent runs it surfaces a diff against the previous scan—for example, "2 new, 3 resolved (12→11)"—so you can track how your security posture changes over time.

Visit Eljakani/ward on GitHub to browse the source and get started.

After three years of development and extensive production use, Workflow 3.0 brings significant improvements to building multi-step procedures in PHP. This release focuses on simplifying asynchronous execution, improving developer experience, and adding essential resilience features.

# Dependency injection

Version 3.0 introduces container support for injecting dependencies into jobs at runtime:

This enables workflows to remain stateless while accessing services like databases or HTTP clients through the container.

# Callable support

Version 3.0 accepts any PHP callable as a job, providing flexibility in how you define workflow steps:

This eliminates boilerplate for simple operations while maintaining support for Action classes when business logic requires full class structure. Callables enable inline data transformation without requiring dedicated action classes for single-use operations.

# Response property access

Version 3.0 extends response() to access public object properties directly, not just array keys:

This works transparently with both arrays and objects, allowing actions to return domain objects without requiring array conversion. The workflow engine inspects the response and accesses properties or array keys accordingly.

# Retry policies

Transient failures in distributed systems are inevitable. Workflow 3.0 implements configurable retry policies:

Retry policies are essential for handling transient failures in distributed systems, where network operations and external services may temporarily fail but succeed on subsequent attempts.

# True async execution

The parallel runner has been replaced with a true async implementation using AMPHP. This provides non-blocking execution without the overhead of process forking, leveraging PHP 8.1+ Fibers for efficient multitasking.

Independent jobs execute concurrently while the engine manages the resolution of the dependency graph. This follows asynchronous task-based execution model where the scheduler unrolls the graph and executes nodes as soon as their data dependencies (like response()) are satisfied. This shift significantly reduces memory footprint compared to the previous process-based model while maintaining strict execution order.

# Conditional execution

Version 3.0 adds withRunIfNot() for cleaner conditional logic:

This complements withRunIf() and accepts boolean literals, variables, job responses, and callables. Conditional execution enables branching without complex orchestration logic.

# Type safety

Integration with chevere/parameter 2.0 provides runtime validation:

Workflow validates inputs before job execution and verifies response types match expected parameters in dependent jobs. This eliminates a class of runtime errors that would otherwise require extensive testing.

# Practical example

Here’s a complete workflow for processing user uploads:

This workflow validates the file, resizes and optimizes it in parallel, then stores the result. The resize job retries on failure, and both processing jobs only run if validation succeeds.

# Migration notes

The parallel runner removal is the only breaking change. Applications using parallel execution should switch to async jobs with appropriate dependency declarations. The async runner provides better performance and simpler semantics.

# Conclusion

Workflow 3.0 represents three years of production refinement. The addition of container support, callables, retry policies, and true async execution address real-world requirements while maintaining the declarative approach that makes workflows maintainable.

The library continues following established patterns from workflow research and distributed systems literature. Each job remains independently testable, workflows stay declarative, and the dependency graph handles execution ordering automatically.

For complete documentation and examples, visit chevere.org/packages/workflow.

MySQL Security Best Practices: A Practical Guide for Locking Down Your Database

Introduction

MySQL runs just about everywhere. I’ve seen it behind small personal projects, internal tools, SaaS platforms, and large enterprise systems handling serious transaction volume. When your database sits at the center of everything, it becomes part of your security perimeter whether you planned it that way or not. And that makes it a target.

Securing MySQL isn’t about flipping one magical setting and calling it done. It’s about layers. Tight access control. Encrypted connections. Clear visibility into what’s happening on the server. And operational discipline that doesn’t drift over time.

In this guide, I’m going to walk through practical MySQL security best practices that you can apply right away. These are the kinds of checks and hardening steps that reduce real risk in real environments, and help build a database platform that stays resilient under pressure.

1. Principle of Least Privilege

One of the most common security mistakes is over-granting privileges.
Applications and users should have only the permissions they absolutely
need.

Bad Practice

GRANT ALL PRIVILEGES ON *.* TO 'appuser'@'10.%';

Better Approach

GRANT SELECT, INSERT, UPDATE ON appdb.* TO 'appuser'@'10.%';

Recommendations

• Avoid global privileges unless absolutely required
• Restrict users by host whenever possible
• Separate admin accounts from application accounts
• Use different credentials for read-only vs write operations

Audit Existing Privileges

SELECT user, host, Select_priv, Insert_priv, Update_priv, Delete_priv
FROM mysql.user;

2. Strong Authentication & Password Policies

Weak credentials remain one of the easiest attack vectors.

Enable Password Validation

component_validate_password is MySQL’s modern password policy engine. Think of it as a gatekeeper for credential quality. Every time someone tries to set or change a password, it checks whether that password meets your defined security standards before letting it in.

It replaces the older validate_password plugin with a component-based architecture that is more flexible and better aligned with MySQL 8.x design.

INSTALL COMPONENT 'file://component_validate_password';

What It Does

When enabled, it enforces rules such as:

• Minimum password length
• Required mix of character types
• Dictionary file checks
• Strength scoring

If a password fails policy, the statement is rejected before the credential is stored.

Why It Matters

Weak passwords remain one of the most common entry points in database breaches. This component reduces risk by enforcing baseline credential hygiene automatically, instead of relying on developer discipline.

Recommended Policies

• Minimum length: 14+ characters
• Require mixed case, numbers, and symbols
• Enable dictionary checks
• Enable username checks

Remove Anonymous Accounts

Find Anonymous Users

Anonymous users have an empty User field.

SELECT user, host FROM mysql.user WHERE user='';

If you see rows returned, those are anonymous accounts.

Drop Anonymous Users

In modern MySQL versions:

DROP USER ''@'localhost';
DROP USER ''@'%';

Adjust the Host value based on what your query returned.

Why This Matters

Anonymous users:

• Allow login without credentials
• May have default privileges in some distributions
• Increase the attack surface unnecessarily

In hardened environments, there should be zero accounts with an empty username. Every identity should be explicit, accountable, and least-privileged.

3. Encryption Everywhere

Encryption protects data both in transit and at rest.

Enable Transparent Data Encryption (TDE)

See my January 13 post for a deep dive into Transparent Data Encryption:
Configuring the Component Keyring in Percona Server and PXC 8.4

Enable TLS for Connections

require_secure_transport=ON

Verify SSL Usage

SHOW STATUS LIKE 'Ssl_cipher';

Encryption Areas to Consider

• Client-server connections
• Replication channels
• Backups and snapshot storage
• Disk-level encryption

4. Patch Management & Version Hygiene

Running outdated MySQL versions is equivalent to leaving known
vulnerabilities exposed.

Maintenance Strategy

• Track vendor security advisories
• Apply minor updates regularly
• Test patches in staging before production rollout
• Avoid unsupported MySQL versions

Check Version

5. Logging, Auditing, and Monitoring

Security without visibility is blind defense, enable Audit Logging.

1. audit_log Plugin (Legacy Model)

Installation

INSTALL PLUGIN audit_log SONAME 'audit_log.so';

Verify

SHOW PLUGINS LIKE 'audit%';

2. audit_log_filter Component (Modern Model)

Introduced in MySQL 8 to provide a more flexible and granular alternative to the older plugin model.

Installation

INSTALL COMPONENT 'file://component_audit_log_filter';

Verify

SELECT * FROM mysql.component;

Architecture Difference

Instead of a single global policy, you create:

• Filters (define what to log)
• Users assigned to filters

It’s granular and rule-driven.

Auditing Key Events

• Failed logins
• Privilege changes
• Schema modifications
• Unusual query activity

References:

1. Audit Log Filter Component
2. Audit Log Filters Part II

Useful Metrics

SHOW GLOBAL STATUS LIKE 'Aborted_connects';
SHOW GLOBAL STATUS LIKE 'Connections';

6. Secure Configuration Hardening

A secure baseline configuration reduces risk from common attack
patterns.

Recommended Settings

local_infile=OFF
secure_file_priv=/var/lib/mysql-files
sql_mode="STRICT_ALL_TABLES"
secure-log-path=/var/log/mysql

Why These Matter

• Prevent arbitrary file imports
• Reduce filesystem abuse
• Restrict data export/import locations

7. Backup Security

Backups often contain everything an attacker wants.

Backup Best Practices

• Encrypt backups
• Restrict filesystem permissions
• Store offsite copies securely
• Rotate backup credentials
• Verify restore procedures regularly

Example Permission Check

8. Replication & Cluster Security

Replication is not just a data distribution feature. It is a persistent, privileged communication channel between servers. If misconfigured, it can become a lateral movement pathway inside your infrastructure. Treat every replication link as a trusted but tightly controlled corridor.

Principle: Replication Is a Privileged Service Account

Replication users require elevated capabilities. They must be isolated, tightly scoped, and monitored like any other service identity.

Secure Replication Users

CREATE USER 'repl'@'10.%'
 IDENTIFIED BY 'strongpassword'
 REQUIRE SSL;

GRANT REPLICATION REPLICA ON *.* TO 'repl'@'10.%';

Hardening considerations:

• Restrict host patterns as narrowly as possible. Avoid % whenever feasible.
• Require SSL or X.509 certificate authentication.
• Enforce strong password policies or use a secrets manager.
• Disable interactive login capability if applicable.

Encrypt Replication Traffic

Replication traffic may include sensitive row data, DDL statements, and metadata. Always encrypt it.

At minimum:

• Enable require_secure_transport=ON
• Configure TLS certificates on source and replica
• Set replication channel to use SSL:

CHANGE REPLICATION SOURCE TO
 SOURCE_SSL=1,
 SOURCE_SSL_CA='/path/ca.pem',
 SOURCE_SSL_CERT='/path/client-cert.pem',
 SOURCE_SSL_KEY='/path/client-key.pem';

For MySQL Group Replication or InnoDB Cluster:

• Enable group communication SSL
• Validate certificate identity
• Use dedicated replication networks

Binary Log and Relay Log Protection

Replication relies on binary logs. Protect them.

• Set binlog_encryption=ON
• Set relay_log_info_repository=TABLE
• Restrict filesystem access to log directories
• Monitor log retention policies

Compromised binary logs can reveal historical data changes.

9. Continuous Security Reviews

Security is not a one-time checklist. Regular audits help catch
configuration drift and evolving threats.

Suggested Review Cadence

• Weekly: failed login review
• Monthly: privilege audits
• Quarterly: configuration review
• Semiannually: full security assessment

Security Checklist Summary

Final Thoughts

Strong MySQL security doesn’t come from one feature or one tool. It comes from layers working together. Hardened configuration. Tight, intentional privilege design. Encryption everywhere it makes sense. And monitoring that actually gets reviewed instead of just written to disk.

In my experience, the strongest environments aren’t the ones trying to be unbreakable. They’re the ones built to detect, contain, and respond. Every layer should either reduce blast radius or increase visibility. If an attacker gets through one control, the next one slows them down. And while they’re slowing down, your logging and monitoring should already be telling you something isn’t right.

That’s what a mature security posture looks like in practice. ∎

Our spatie/crawler. package is one of the first one I created. It allows you to crawl a website with PHP. It is used extensively in Oh Dear and our laravel-sitemap package.

Throughout the years, the API had accumulated some rough edges. With v9, we cleaned all of that up and added a bunch of features we’ve wanted for a long time.

Let me walk you through all of it!

Using the crawler

The simplest way to crawl a site is to pass a URL to Crawler::create() and attach a callback via onCrawled():

use Spatie\Crawler\Crawler;
use Spatie\Crawler\CrawlResponse;

Crawler::create('https://example.com')
    ->onCrawled(function (string $url, CrawlResponse $response) {
        echo "{$url}: {$response->status()}\n";
    })
    ->start();

The callable gets a CrawlResponse object. It has these methods

$response->status();        
$response->body();          
$response->header('some-header');  
$response->dom();           
$response->isSuccessful();  
$response->isRedirect();    
$response->foundOnUrl();    
$response->linkText();      
$response->depth();         

The body is cached, so calling body() multiple times won’t re-read the stream. And if you still need the raw PSR-7 response for some reason, toPsrResponse() has you covered.

You can control how many URLs are fetched at the same time with concurrency(), and set a hard cap with limit():

Crawler::create('https://example.com')
    ->concurrency(5)
    ->limit(200) 
    ->onCrawled(function (string $url, CrawlResponse $response) {
        
    })
    ->start();

There are a couple of other on closure callbacks you can use:

Crawler::create('https://example.com')
    ->onCrawled(function (string $url, CrawlResponse $response, CrawlProgress $progress) {
        echo "[{$progress->urlsProcessed}/{$progress->urlsFound}] {$url}\n";
    })
    ->onFailed(function (string $url, RequestException $e, CrawlProgress $progress) {
        echo "Failed: {$url}\n";
    })
    ->onFinished(function (FinishReason $reason, CrawlProgress $progress) {
        echo "Done: {$reason->name}\n";
    })
    ->start();

Every on callback now receives a CrawlProgress object that tells you exactly where you are in the crawl:

$progress->urlsProcessed;  
$progress->urlsFailed;     
$progress->urlsFound;      
$progress->urlsPending;    

The start() method now returns a FinishReason enum, so you know exactly why the crawler stopped:

$reason = Crawler::create('https://example.com')
    ->limit(100)
    ->start();

Each CrawlResponse also carries a TransferStatistics object with detailed timing data for the request:

Crawler::create('https://example.com')
    ->onCrawled(function (string $url, CrawlResponse $response) {
        $stats = $response->transferStats();

        echo "{$url}\n";
        echo " Transfer time: {$stats->transferTimeInMs()}ms\n";
        echo " DNS lookup: {$stats->dnsLookupTimeInMs()}ms\n";
        echo " TLS handshake: {$stats->tlsHandshakeTimeInMs()}ms\n";
        echo " Time to first byte: {$stats->timeToFirstByteInMs()}ms\n";
        echo " Download speed: {$stats->downloadSpeedInBytesPerSecond()} B/s\n";
    })
    ->start();

All timing methods return values in milliseconds. They return null when the stat is unavailable, for example tlsHandshakeTimeInMs() will be null for plain HTTP requests.

Throttling the crawl

I wanted the crawler to a well behaved piece of software. Using the crawler at full speed and with large concurrency could overload some servers. That’s why throttling is a polished feature of the package.

We ship two throttling strategies. The first one is FixedDelayThrottle that can give a fixed delay between all requests.

$crawler->throttle(new FixedDelayThrottle(200)); 

AdaptiveThrottle is a strategy that adjusts the delay based on how fast the server responds. If the server responds fast, the minimum delay will be low. If the server responds slow, we’ll automatically slow down crawling.

$crawler->throttle(new AdaptiveThrottle(
    minDelayMs: 50,
    maxDelayMs: 5000,
));

Testing with fake()

Like Laravel’s HTTP client, the crawler now has a fake to define which response should be returned for a request without making the actually request.

Crawler::create('https://example.com')
    ->fake([
        'https://example.com' => '<html><a href="/about">About</a></html>',
        'https://example.com/about' => '<html>About page</html>',
    ])
    ->onCrawled(function (string $url, CrawlResponse $response) {
        
    })
    ->start();

Using this faking helps to keep your tests executing fast.

Driver-based JavaScript rendering

Like in our Laravel PDF, Laravel Screenshot, and Laravel OG Image packages, Browsershot is no longer a hard dependency. JavaScript rendering is now driver-based, so you can use Browsershot, a new Cloudflare renderer, or write your own:

$crawler->executeJavaScript(new CloudflareRenderer($endpoint));

In closing

I’m usually very humble, but think that in this case I can say that our crawler package is the best available crawler in the entire PHP ecosystem.

You can find the package on GitHub. The full documentation is available on our documentation site.

This is one of the many packages we’ve created at Spatie. If you want to support our open source work, consider picking up one of our paid products.