Piotr Gołofit’s Post

PHP isn't dead for web scraping. It's just quiet about it. 🐘 Most servers already run it, database integration ships built-in via PDO, and Composer pulls in an HTTP client with 1 command. In this video, we build a full scraper with Guzzle and Symfony DOM crawler, targeting a sandbox site with 1K books across 50 pages, then export everything to CSV. We also cover: 🧑💻 Setting realistic headers and retry logic with backoff ❌ Rotating residential proxies to avoid IP blocks at scale 💡 When to reach for a headless browser instead of curl If PHP's already your stack, there's no reason to switch languages just to scrape. Watch the full video and grab the code in the comments 👇

FrankenPHP in Production: Worker Mode, Embedded Binaries, and Real Performance For twenty-plus years, “deploying PHP” meant the same uneasy triangle: Apache or Nginx in front, PHP-FPM behind, and a configuration file glued between them that nobody on the team really understood. FrankenPHP is the first genuinely different answer that stack has had in a long time, and after a couple of years of steady releases it has earned serious consideration for production workloads. If you have not looked at it since the 1.0 release, the project has moved considerably — worker mode is rock solid, embedded binaries have shipped for real apps, and the Laravel and Symfony integrations are boring in all the right ways. Here is what actually matters when you put FrankenPHP in front of a real application. Why FrankenPHP Exists FrankenPHP is an application server for PHP built on top of the Caddy web server, written in Go, with PHP embedded as a library rather than executed as a separate process. That architectural choice is the whole story. Because PHP runs inside Caddy’s process, there is no FastCGI hop, no socket negotiation, no separate lifecycle to monitor. You get a single binary that serves HTTP/1, HTTP/2, and HTTP/3 with automatic HTTPS, and it happens to run your PHP...

I noticed that the php-shared host version did not have functions to edit entities before approval. This has now been fixed. The PHP edition now has full entity editing: Changes committed:   • php/src/Router.php - Added entityEdit() and entityUpdate() handlers with routes   • php/templates/entity_edit.php (new) - Full edit form with Save/Save & approve/Save & reject   • php/templates/entities.php - Added Edit link column   • installers/php-host/bkbs-php-edition.zip - Rebuilt with changes Features added:   • Click "Edit" on any entity row → opens edit form   • Edit all fields: name, type, description, status, trust level, notes, JSON fields   • Three save buttons: "Save changes", "Save & approve", "Save & reject"   • Bulk approve/reject still works as before Github Repository: https://lnkd.in/dXuw_Uzx

PHP shipped security releases for four versions at once today, 8.2 through 8.5. The most boring sentence in tech, and the reason half the web keeps working. Two things worth saying about that. First, the practical one: if you run PHP, patch before lunch. Coordinated security releases exist because someone found something worth coordinating around. Second, the quiet one. People have been calling PHP dead for as long as I've been writing it. Dead platforms don't get four-branch security releases on the same day. That takes maintainers, a release process, and a community that still shows up. Maintenance is the least glamorous signal in this whole industry, and the most honest one. When I'm picking a stack to bet the next decade on, I don't look at the launch hype. I look at whether it's still boring in year eight. Release notes are here — patch before lunch 👇 https://lnkd.in/g2RF3SCe #php #laravel #softwareengineering #webdevelopment #developer

🚀 Breaking the PHP-FPM Concurrency Wall: Swoole vs Process Pooling 🛠️ Scaling PHP under high I/O workloads requires moving beyond the share-nothing model of PHP-FPM. While FPM offers isolation, it struggles with connection overhead. Adopting an event-driven, memory-resident architecture like Swoole changes how we manage application state and database pools. 🏗️ Here is the professional roadmap for a successful implementation 🛣️ 1️⃣ CONFIGURE CONNECTION POOLING In memory-resident PHP, opening database connections per request is an anti-pattern. We must implement persistent connection pools to reuse sockets across coroutines, reducing handshake overhead and socket exhaustion. 💻 PHP Code ⌨️ $pool = new Swoole\Database\PDOPool($config, 64); $pdo = $pool->get(); $pool->put($pdo); 2️⃣ ISOLATE STATEFUL SERVICES Because bootstrap happens once, global state persists across requests. Avoid injecting request-scoped dependencies into singleton services to prevent data leaks, using container resetting strategies instead. 💻 PHP Code ⌨️ $app->forgetInstance('request'); $app->bind('request', $newRequest); 3️⃣ OPTIMIZE ASYNC I/O OPERATIONS Leverage non-blocking coroutines for external HTTP calls. This allows the CPU to switch tasks during network wait times, drastically increasing overall system throughput. 💻 PHP Code ⌨️ Swoole\Coroutine\go(function() { $client = new Swoole\Coroutine\Http\Client('api.com', 80); $client->get('/data'); }); Principal PHP Architect Perspective 🎓 Transitioning to asynchronous PHP requires a shift to long-running processes. The performance gains are massive, but success lies in strict memory management, stateless design, and robust connection pooling. 🎯 #PHP #Laravel #SoftwareArchitecture #Swoole #WebDev #Backend #SystemDesign

𝗨𝗻𝗱𝗲𝗿𝘀𝘁𝗮𝗻𝗱𝗶𝗻𝗴 𝘁𝗵𝗲 𝗣𝗛𝗣 𝗱𝗼-𝘄𝗵𝗶𝗹𝗲 𝗟𝗼𝗼𝗽 Loops help you run the same code multiple times. This saves time and prevents mistakes. In PHP, the do-while loop works differently than other loops. It runs your code first. Then it checks your condition. This means the code inside your loop runs at least one time. This happens even if your condition is false from the start. Use a do-while loop when you must execute an action before you check a rule. Common uses include: - Showing a menu to a user. - Validating input data. - Retrying a failed task. How it works: 1. The computer runs the code inside the do block. 2. The computer checks the condition. 3. If the condition is true, it repeats the loop. 4. If the condition is false, it stops. Compare this to a standard while loop. A while loop checks the condition first. If the condition is false at the start, a while loop never runs. A do-while loop always gives you one attempt. Choosing the right loop makes your PHP code clean and efficient. Source: https://lnkd.in/gzhVsTY5

🚀 Mastering PHP for Database & Software Engineering 🛠️ Context: As a Principal PHP Architect, I see many projects struggling with inefficient PHP code. This leads to performance issues and scalability problems. Effective PHP implementation is crucial. 🏗️ Here is the professional roadmap for a successful implementation 🛣️ 1️⃣ OPTIMIZE PERFORMANCE 💨 PHP code optimization is key to improving application speed. 💻 PHP Code ⌨️: echo phpversion

Today, I got stuck on a small but important Laravel configuration issue. I was accessing the Stripe secret key directly inside my application: $stripeSecretKey = env('STRIPE_SECRET_KEY'); It worked initially, but after running: php artisan config:cache the value was no longer available. The issue was that I was calling env() directly in the application code. ❌ Incorrect approach $stripeSecretKey = env('STRIPE_SECRET_KEY'); ✅ Correct approach First, create a dedicated Stripe configuration file: // config/stripe.php return [ 'secret_key' => env('STRIPE_SECRET_KEY'), ]; Then access the value anywhere in the application using: $stripeSecretKey = config('stripe.secret_key'); After updating the configuration, rebuild the cache: php artisan config:cache My takeaway: Use env() only inside Laravel configuration files, and use config() inside controllers, services, jobs, commands, and other application code. A small issue, but an important Laravel best practice—especially when deploying with cached configuration. #Laravel #PHP #Stripe #WebDevelopment #SoftwareDevelopment

A closure that looks identical to another one can behave completely differently depending on one tiny detail: use ($var) versus use (&$var). This single distinction has caused more "why is this value stale" bugs than almost anything else in PHP closures, and most developers only learn it the hard way, usually inside a loop. Here's the trap: $count = 0; $byValue = function () use ($count) { $count++; return $count; }; $byValue(); // 1 $byValue(); // 1 again $byRef = function () use (&$count) { $count++; return $count; }; $byRef(); // 1 $byRef(); // 2 use ($count) snapshots the value at the exact moment the closure is created. Every call after that reads from that frozen copy. use (&$count) binds to the actual variable, so every call mutates the real thing. Neither is wrong. They just answer different questions: Do you want this closure to remember what things looked like when it was born, or do you want it to stay wired into the live variable forever? Where this actually bites people: loops. $closures = []; for ($i = 0; $i < 3; $i++) { $closures[] = function () use ($i) { return $i; }; } This is safe. Each iteration captures its own copy of $i by value, so calling these later returns 0, 1, 2 as expected. Swap in use (&$i) and every closure would return the same final value, because they'd all be pointing at the same variable. Arrow functions add another layer worth knowing: fn() => $i auto-captures by value implicitly, no use needed, but you lose the option of capturing by reference at all. If you need reference semantics, you're back to a full closure. None of this is exotic PHP. It's foundational. But it's exactly the kind of foundational thing that quietly breaks production code written by someone who was confident they understood closures. Where has capture-by-value versus capture-by-reference caught you off guard? #PHP #SoftwareEngineering #CleanCode #BackendDevelopment #Symfony

This is a truly amazing article on PHP attributes. It goes over ways to simplify the codebase and, equally important, when not to use them and which pitfalls to avoid.