标签：#Web

There is a quiet moment of panic every developer knows. You hit deploy, open the live site on your phone, and wait. One second. Two seconds. Four seconds. Still a blank white screen. A while back, I was working on a Next JS application that looked fast on high speed office Wi Fi. But when tested on a spotty mobile connection, it felt painfully slow. The initial page load was clocking in at nearly 8 seconds, and our main JavaScript bundle was a bloated 1.8 megabytes. Here is how we diagnosed the bloat, cut our load times by 47 percent, and the simple performance rules every developer should know. The Investigation: Where Was the Weight Coming From? When a website is slow, our first instinct is often to blame slow backend APIs or heavy database queries. But when I ran a performance audit, the backend was not the problem at all. The front door was just jammed with too much stuff. We were making three classic mistakes: First, we were packing for a long trip on a short walk. We were loading heavy charting libraries, complex admin tables, and pop up modals the second a user landed on the home page, even if that user only came to read a single line of text. Second, giant images were being served to tiny mobile screens, hogging precious bandwidth before any interactive buttons could even load. Third, a single state update at the top of our app was causing dozens of unseen child components to recalculate and re render unnecessarily behind the scenes. The Strategy: Trimming the Fat Instead of rewriting the entire codebase from scratch, we focused on three targeted fixes. 1. Don't Load It Until They Ask For It Why force a user to download a complex analytics chart if they have not even clicked on the dashboard tab yet? We split the app into smaller, independent code chunks. Now, the user downloads only the absolute bare minimum needed to view the immediate screen. The heavy features stay on the server until the exact moment the user interacts with them. 2. Smart Asset Delivery

21 build logs. Months of work. One shipped project. Here's the full journey—and how to set up the Phone Agent on your own device. The first build log was published months ago. "I'm building an AI agent that controls a phone." No code. No repo. Just an idea and a cracked phone. Today, after 21 build logs spread across months, the project is shipped. This wasn't a straight line. There were gaps. Weeks where the log went silent—not because the work stopped, but because life doesn't pause for build logs. I took breaks to survive exam season. I paused to ship 9 portfolio websites. I stepped away when the code refused to cooperate and my brain needed rest. But every time I came back, the agent was still there. Waiting. And every log picked up where the last one left off. What We Built An autonomous AI agent that controls an Android phone using natural language commands. It can parse your words into actions, read the screen, tap buttons, type text, switch between apps, verify financial data, and serve a web interface—all offline. The Real Timeline Phase What Happened Days 1-4 Foundation. Gemma 4 + ADB. First working pipeline. Days 5-8 Vision overhaul. UI tree. OCR. Template matching. Days 9-12 Accessibility audit. 30 apps scored. Days 13-16 Multi-app workflows. Task memory. Home reset. Days 17-19 Financial verification. Accuracy from 80% to 94%. Breaks Exams. Portfolio sites. Life. Days 20-21 Web interface. Flask backend. Shipped. 📖 FULL SETUP GUIDE: How to Install and Use the Phone Agent Follow these steps to get the agent running on your own Android phone. Prerequisites An Android phone (Android 7 or later) At least 6GB of free storage space A WiFi connection for the initial download Step 1: Install Termux Do NOT install Termux from the Google Play Store—that version is outdated. Install it from F-Droid instead. Open your phone's browser Go to f-droid.org Download and install the F-Droid app Open F-Droid and search for "Termux" Install Termux from F-Droid Step 2: Set Up

Prompt injection is the security problem that defines LLM applications, and I kept running into the same wall when I tried to explain it: reading about it does not build intuition. You can describe "ignore previous instructions" all day, but until you actually watch a model spill a secret it was told to guard, none of it lands. So I built injection-arena, a self-hostable game where a sandboxed AI agent defends a hidden secret and you race to make it leak. The pitch is simple: guard a secret, break the guard, top the leaderboard. The learning is the side effect. The core idea Each level is a challenge. It has a system prompt that instructs an agent and hides a secret formatted like IARENA{...} , a canary token embedded in that same prompt, and a stack of defense layers. You send messages to the agent and try to make it reveal the secret. The game grades you on the server and tells you whether you cracked it. There are ten levels, and each one stacks a new defense on top of the last. Level 1 is barely defended so you can feel a plain attack working. By the time you reach level 10, only a combined attack (payload splitting plus delimiter confusion) gets through. The progression is the whole point: you feel exactly what each defense stops and exactly where it breaks. How the defenses work An attempt flows through a single server-side pipeline that looks like this: input-filter -> agent -> judge -> score -> persist The defenses attach at different stages of that pipeline: System guard lives in the prompt itself: hardened instructions telling the agent to refuse. Input filter runs before the model sees anything. It blocks loud override and system-leak payloads pre-agent. Roleplay block rejects persona-hijack attacks, the "pretend you are a different assistant" family. Encoding guard rejects base64, spell-it-out, and translation-based exfiltration attempts. Output filter runs after the agent responds and redacts the secret if it appears verbatim. Canary token is checked by

Most file-conversion workflows start with a trade-off that is easy to miss: Choose a file from your device. Upload it to a third-party server. Wait for processing. Download a new file. Trust that the original and the result are handled exactly as promised. That model is convenient, but it is not the only option. For a growing set of formats, a modern browser can read, transform, and export files directly on the user's device. The result is a different kind of tool: no upload queue, no account requirement, and no server-side conversion step. This post explains how browser-based file conversion works, where it is a strong fit, where it is not, and how we approach the problem in I Hate Converter , a free collection of locally run file converters. What “no upload” should mean “No upload” should be more than a reassuring line next to a file picker. For a browser converter, the useful promise is that the selected file is read and processed within the browser runtime. A tool can use browser APIs such as File , Blob , ArrayBuffer , Canvas , and Web Workers, as well as locally loaded WebAssembly modules, without sending the source file to an application server. That matters when a file contains information you would rather not place in another system: draft documents, customer exports, source assets, screenshots, scanned records, or internal media. It also reduces friction for quick conversions: choose a file, process it, download the result. The distinction is important: an app can have a website while still keeping the actual conversion local. A page load may fetch its code and assets, but the chosen file does not need to become a network request. Our no-upload file converter hub is built around that boundary: supported conversions run on-device, and formats that require a server are not presented as if they were local. The browser capabilities that make this possible Browsers are no longer just document viewers. Several stable platform features make useful local conversio

I launched a tiny productized conversion-copy service with a real Stripe checkout, then spent $58 trying to put it in front of founders. Revenue so far: $0 . That is not a case study. It is a useful measurement problem. What I spent Channel Spend What I bought LaunchPact starter ad $5 Seven-day founder-feed placement LaunchPact service campaign $24 Seven-day placement plus one founder-digest slot LaunchPact founder poll $10 One 24-hour purchase-intent poll LaunchBuff Premium $19 Immediate featured listing and permanent backlink I also opened 16 community tasks on Favors.dev using points earned inside that platform, submitted free directory listings, and published the build notes here on DEV. What happened The first LaunchPact ad reported 32 views and zero clicks. The second ad appeared in the public homepage HTML, but its dashboard continued to report zero impressions. That difference mattered. A dashboard counter was not enough, so I checked three separate layers: Was the sponsored card rendered publicly? Did my server receive a request carrying the campaign parameters? Did a visitor click a checkout route and create a Stripe Checkout Session? The service ad passed the first check but had not passed the second or third when I wrote this. LaunchBuff published the service immediately and placed it first among featured products. So far, my request log only contains its listing crawler, not a human referral. Favors.dev made the service the top upcoming launch for its date. None of the 16 paid-in-points helper slots have been filled yet. One earlier visitor reached the $19 starter checkout. The session remains open and unpaid, with no email entered. I cannot recover that checkout or honestly explain why it was abandoned. Cheap reach is not buyer intent The placements were inexpensive, but that did not make them qualified. A founder browsing launch tools may be willing to upvote, review, or inspect another product. That does not mean they currently have a B2B landing pag

Near the end of a release, every file transfer to the production server succeeded, and the version file that triggers distribution was updated too. With that confirmed, the release got reported as complete — except the local git repository never actually had those changes committed. Note: "Deploying" here means transferring changed files to the production server (via scp, for example) so they're actually live for users. "git push" is a separate operation that records the change history in a remote repository. What happened This release involved transferring seven files to the production server: five landing-page update-notice files, the version file that triggers distribution, and a progress-log file. The transfer itself succeeded completely, and the production site confirmed it was showing the new version number. The problem: after editing these files locally, the work moved straight to the transfer step without ever committing . The files on the production server were fully up to date, but the local git repository had no record of those changes — and the release got reported as complete in that state. Why this is easy to miss Transferring files with scp and recording them in the repository with git commit / git push are completely independent operations, both as commands and as goals. Verifying production (HTTP 200, checking the rendered content) confirms "did the deployment succeed" — a different question from "is the local change history recorded." Treat the first check as proof of "done," and the second check quietly never happens. When both steps get mentally bundled into one "release complete" state, there's no natural moment to notice that only one of them actually finished. In this case, it surfaced because someone else looking at the repo noticed it hadn't been committed yet. The fix — treat "uploaded" and "git synced" as two separate checks Add a git-sync verification step to the deploy checklist, independent from the file-transfer confirmation. # Commit

When a user logs out in one tab, the other tabs should follow. When they update their cart, every...

The Slack thread started with a screenshot of a green GitHub Actions run. By the third reply someone had pasted a Lighthouse JSON artefact, a link to a Chrome release note, and a question nobody wanted to own: "Which client repository still pins Lighthouse 10?" That is the week Lighthouse CI stopped being a merge gate and became a second job. The pipeline still passed and the portfolio still needed evidence, but the difference was who paid in hours: the developer shipping a feature, or the one person who inherited every lighthouserc file across client repositories. When does Lighthouse CI maintenance outgrow a CI/CD pipeline? Lighthouse CI earns its place early. You wire assertions on a preview URL, block a CLS regression, and the team trusts the red build. The cost is front-loaded configuration, not ongoing calendar time. The shift happens when success creates obligations a CI/CD pipeline was never designed to carry: Every new client repository needs a copied workflow, pinned Chrome, and preview URL rules that match their host. Assertions need tuning after flaky LCP on cold runners, so thresholds loosen until they barely catch real regressions. Account managers ask for client-ready reports, and the only export is a CI/CD artefact someone must turn into slides. Production URLs outside the two preview paths regress while the job stays green. At that point you are not "running Lighthouse CI in a pipeline." You are operating a small internal product: version pins, runner hygiene, assertion policy, and reporting glue. For a single product team that can be fine. For an agency portfolio it competes with billable delivery. How do you know Lighthouse CI in CI/CD became an unpaid side role? We treat these as signals to shrink CI/CD scope or add a managed monitoring layer, not as moral failure. Teams hit them around five to fifteen client sites, sometimes sooner when preview hosts differ wildly. Flaky Lighthouse CI runs on GitHub Actions Engineers merge after the third "Re-ru

Hey devs👋 I've been building OneToolBox : https://onetoolbox.dev/ It's a collection of free web utilities for developers and creators — JSON tools, YAML validation, hash generation, text diffing, image tools, converters, and more. The main idea is simple: do as much as possible directly in the browser, without requiring accounts or uploading users' files/data to a server. I'm still actively improving it, and I'd really appreciate feedback from developers here. What would you improve? Which tools are missing? Are there tools you use regularly that you'd like to see added? Any UX problems or annoying workflows? Is there anything you'd change about the interface? Are there performance, privacy, or technical improvements you'd recommend? I'd especially appreciate criticism from people who actually use developer utilities regularly. Don't hesitate to point out what's bad or unnecessary — that's more useful to me than compliments. If you have a minute, take a look and tell me what you'd change. Thanks! 🙏

The Problem There are millions of people holding crypto who want to spend it on real things — hire a developer, buy a script, sell design work. But where do they go? Telegram OTC chats → chaotic, no protection, scam-heavy Forum classifieds → threads get buried in hours P2P exchange sections → designed for fiat conversion, not commerce I decided to build a dedicated marketplace for this. What I Built CryptoBoard — a classifieds platform with Web3 wallet authentication. 🔗 https://crypto.my-board.org/ Tech decisions: Auth : Wallet-only (MetaMask, Trust Wallet, WalletConnect). No backend user database with emails and passwords to get hacked. Listings : Icon-based instead of user-uploaded images. Keeps the UI clean and avoids the "flea market" look. Messaging : Built-in chat between buyers and sellers. Escrow : This is the interesting part (see below). The Escrow Problem with Digital Goods Traditional escrow works like this: Buyer sends money to escrow Seller delivers product Buyer confirms → escrow releases money But with digital goods (source code, design files), step 3 is broken: The buyer can receive the files, say "this isn't what I wanted," request a refund, and keep a copy The seller has no recourse The escrow service has no way to verify the claim My Solution: Human-Powered Escrow Instead of just holding funds, the platform admin becomes an active verifier: Seller sends product + testing instructions to admin Admin installs/runs the product on their own machine Admin performs agreed-upon tests and records a screencast Buyer watches the screencast — verified by a neutral party, not the seller If satisfied, buyer sends crypto directly to seller Admin verifies the on-chain transaction Admin delivers files to buyer Admin deletes all copies (per agreement) Is it scalable? Probably not infinitely. But for high-value digital transactions ($100–$10,000+), having a human in the loop is actually a feature, not a bug. Design Philosophy I deliberately chose not to allow user

Hey DEV community! 👋 If you've ever tried to embed a dynamic YouTube channel feed, a live stream detector, or playlist carousel on a client site, you've probably run into two major issues: Expensive SaaS widgets that slap watermarks on your site unless you pay a monthly fee. Leaking your YouTube API Key directly in the frontend script. To solve this, we built YT Widget —a free, self-hostable, dependency-free JavaScript library that handles YouTube feeds, playlists, channel stats, and live stream status seamlessly. 📦 Where to Get It The project is fully open-source and ready for your production projects: Source Code & Contributions: scott8462 / YT-Widget A free, self-hostable, dependency-free JavaScript library for embedding YouTube feeds, playlists, channel stats, single videos, and live stream status on any website. YT Widget — Free Open-Source YouTube Website Embed A free, self-hostable, dependency-free JavaScript library for embedding YouTube feeds, playlists, channel stats, single videos, and live stream status on any website — just like SociableKIT, but 100% free and open-source. Created and provided free to the developer community by R&S Development . ✨ Features 📺 5 Widget Types feed : Latest channel uploads grid or list live : Auto-detects live broadcasts and embeds the live player — shows a custom Offline Card with recent uploads when offline playlist : Show videos from any YouTube playlist stats : Channel metrics cards (Subscribers, Views, Videos count) single : Responsive single video player with metadata 🔒 Secure PHP Server Proxy ( proxy/ ) : Keep your YouTube API key hidden server-side with built-in CORS, rate limiting, and 5-minute response caching. 🎨 Full Color Customization Light & Dark themes Custom Accent / Button… View on GitHub Alternative Downloads & Mirrors: Download on SourceForge ✨ Core Features 📺 5 Widget Types: Switch layouts instantly ( feed grid/list, live stream detector, playlist fetcher, profile stats , or single responsive video). 🔒 Se

System Design is the process of planning how a software system should work before building it. Think about constructing a large building. Before workers start putting up walls, architects decide where the rooms, elevators, electricity, water systems, emergency exits, and entrances should go. Software works in a similar way. When developers build applications such as Amazon, Instagram, Netflix, Uber, or WhatsApp, they cannot simply start writing code and hope everything works. They first need to decide how millions of users, servers, databases, files, and requests will work together. A simple way to remember it is: System Design = The blueprint of a software system. What Do We Decide in System Design? During system design, engineers make decisions about things such as: How users connect to the application Where information is stored How different parts of the application communicate How images and videos are stored How the system handles millions of users How the application stays fast How failures are handled How user information stays secure For example, imagine designing WhatsApp. A user sends a message. That message must travel to WhatsApp's servers, reach the correct person, possibly be stored temporarily, appear on multiple devices, and trigger a notification. If millions of people send messages at the same time, the system must continue working without becoming extremely slow or crashing. That planning is system design. Why Does System Design Matter? A good software system should be: Fast Reliable Secure Scalable Affordable to operate Easy to maintain Imagine Instagram without good system design. Millions of users might open the application at the same time. Servers could become overloaded, photos might take several seconds to load, comments could disappear, and the application might frequently crash. System design helps engineers prepare for these situations before they become major problems. System Design in Software Interviews System design is also common i

Remember when "AI coding" just meant inline tab-completion suggesting a for loop in VS Code? Those were simpler times. 😅 Fast forward to this week, and we’ve officially crossed the threshold into the Autonomous Multi-Agent Era . The industry is shifting away from single-turn autocomplete prompts toward async, parallelized agentic workflows that inspect, plan, write, test, and validate code across entire repositories. Three major developments dropped almost simultaneously: ⚡ Meta launched Muse Code (powered by Muse Spark 1.2) in beta, introducing parallel sub-agent execution. ☁️ AWS added an Agentic Workspace to Kiro , enabling async background task delegation for developers. 🎓 New Academic Research surfaced on how AI coding agents leverage structured "Agent Plans" for full-lifecycle repo maintenance, design, construction, testing, and validation. Let's break down why this is a massive engineering paradigm shift and what it actually means for our daily developer workflows. 🧬 1. Meta Muse Code & Parallel Sub-Agent Swarms Meta’s latest drop— Muse Code , driven by their Muse Spark 1.2 model—takes aim at one of the biggest bottlenecks in single-agent LLM systems: context dilution and linear execution delays . When you ask a traditional LLM to refactor a complex microservice, it processes everything sequentially. It reads your files, thinks, writes code, tries to debug, and eventually runs out of context space or hits token output limits. How Parallel Sub-Agent Execution Changes the Game Muse Code doesn't just run one linear chat session. Instead, a primary orchestrator agent decomposes a high-level goal into specialized sub-agents running concurrently: ┌──────────────────────────────┐ │ PRIMARY ORCHESTRATOR AGENT │ └──────────────┬───────────────┘ │ ┌──────────────────────────┼──────────────────────────┐ ▼ ▼ ▼ ┌─────────────────┐ ┌─────────────────┐ ┌─────────────────┐ │ SUB-AGENT A │ │ SUB-AGENT B │ │ SUB-AGENT C │ │ AST Parsing & │ │ Unit Test Suite │ │ Static Analysis

A few days ago, I went for an internship opportunity that I was genuinely excited about. I had been looking forward to it for a long time. When I got the opportunity to attend a 3-day demo/trial period , I went in with a lot of excitement. I wanted to prove myself, learn as much as possible, and hopefully turn those three days into something bigger. And honestly, I gave it my best. I showed up, worked, learned, asked questions, and tried to contribute wherever I could. Then came the moment I had been hoping for. I received the offer letter. ❤️ For a moment, I was extremely happy. After being out of college and working hard to build my skills, finally getting an offer felt like a big step forward. But then I had to look at the practical side. The internship was work from office , and the stipend was ₹7,000/month . The biggest challenge was the distance. I live around 90 km away from the office. When I calculated the daily travel, food, and other expenses, I realized that accepting the internship would put a huge financial burden on me every month. And that was a very difficult realization. Because emotionally, I wanted to say: "Yes, I got an internship. Let's do this!" But practically, I had to say: "I can't afford this right now." So I rejected the offer. And honestly? It hurts. Not because the company did something wrong. Not because I didn't want to work. But because I finally got an opportunity I was excited about, gave it my best during the trial period, received the offer… and still had to walk away from it. I've been feeling pretty bad about it. There is always this thought in the back of my mind: "What if I had just accepted it?" But I'm also trying to remind myself that rejecting one opportunity doesn't mean I've failed. Sometimes an opportunity can be good and still not be right for your current situation. I'm taking this experience as a lesson: Getting an offer is not the final goal. Salary/stipend matters. Location and travel expenses matter. Your time ma

Most embeddable widgets are surveillance with rounded corners. You paste one script tag, it opens a socket back to someone else's server, drops analytics, fingerprints the page, and turns your article into their funnel. I wanted the opposite. I had built a small screen-time calculator for an iPhone side project. You enter daily phone hours, how much of that time you'd actually want back, and your age. It returns the number not just as hours per year, but as waking years of the life you have left . The surprising part was not the maths. The surprising part was that the calculator itself was the first marketing asset I had built that people might reasonably link to. So the next step was obvious: make it embeddable. Constraints I gave myself four rules: No tracking script No backend callback No cookie or storage requirement Useful standalone, but with a real reason to click through That ruled out the normal widget pattern immediately. I did not want a script that asks the host page for DOM access. I did not want the embed to send typed values back to me. And I did not want to bolt analytics onto a tool whose whole public claim is "nothing leaves your device". So the widget became a single static iframe page. The embed snippet This is the whole thing: <iframe src= "https://shantj.github.io/sproutguard/embed.html" width= "100%" height= "620" style= "border:0;max-width:600px" loading= "lazy" title= "Screen time calculator" ></iframe> <p style= "font-size:13px;opacity:.7;margin:6px 0 0" > <a href= "https://shantj.github.io/sproutguard/screen-time-calculator.html?ct=embed-credit" > Screen Time Calculator </a> — free, no signup, runs in your browser. </p> No JavaScript include. No SDK. No npm package. Just an iframe and a credit link. The iframe points at a page that contains the calculator UI and the arithmetic. Because it is a static page, the host site never has to trust my script with its DOM. The actual calculator logic The core number is intentionally boring: const LIF

description: "Fixes for the 22 errors developers hit most often on Redbelly Network — RPC and chain ID conflicts, MetaMask setup, USD-pegged gas, permissioned-network reverts, Hardhat deployment, Routescan verification, and the Eligibility SDK." tags: blockchain, web3, ethereum, solidity canonical_url: https://dev.to/isaac_atunbi_c2ed2489e89c/redbelly-network-troubleshooting-guide-22-common-developer-errors-and-their-fixes-1g26/edit cover_image: published: true Redbelly Network Troubleshooting Guide 22 common developer errors, with the exact command that fixes each one. Redbelly Network is an EVM-compatible L1 built for compliant asset tokenisation. "EVM compatible" gets you most of the way, but three things about Redbelly are genuinely different from every other EVM chain, and they account for most of the time developers lose here: It is a permissioned network. An address that has not claimed a network access credential cannot write to the chain. Transactions from it fail in a way that looks like an ordinary revert. Gas is priced in US dollars, not gwei. eth_gasPrice returns roughly 165,000 gwei . That is about four orders of magnitude above Ethereum, it is correct, and it breaks any tool with a hardcoded fee cap or a "that can't be right" sanity check. The two official documentation sites disagree with each other , including on the mainnet chain ID. One of them is stale. Every entry below follows the same shape — Symptom → Root Cause → Solution → Prevention — and every command is copy-pasteable. Every chain ID, URL, contract address and package name was read from a live source on the date in the footer, not from memory. Sources read: 8 August 2026. Every chain ID, URL, contract address and package name below was read from a live source on that date and is traced in sources.md . Execution status: the fixes here are derived from those sources and from the documented behaviour of the tooling; they have not yet been executed end-to-end against Redbelly Testnet . A ver

Half your code is now written by an AI that hallucinates the other half's package names. That's not a joke. Across 576,000 samples, 19.7% of the packages AI coding models suggested didn't exist — and attackers have started pre-registering those exact hallucinated names, waiting for someone to npm install a package that was never real to begin with. Meanwhile, public registries catalogued 454,600 new malicious packages in 2025 alone, pushing the cumulative total past 1.2 million. A modern web app now pulls in 1,200+ dependencies once you count the full transitive tree — for software that, ten years ago, would have shipped with a fraction of that. That's precisely what Zero Dependency 2026 is about. Organized by Hackathon Raptors , Zero Dependency is a 72-hour online global hackathon where participants build genuinely useful software — CLIs, parsers, servers, databases, security tools — using nothing but their programming language's standard library. No frameworks. No packages. No supply chain to inherit. Just your language and your engineering skill. Why Zero Dependency? Modern AI coding assistants can generate code fast, and they reach for a dependency by reflex — sometimes one that doesn't exist. But real engineering isn't judged by how many packages you imported. It's judged by questions like: Do you actually understand what the library you'd normally import is doing underneath? Can you build the thing yourself, correctly, from primitives? Does your code handle the edge cases a package would've handled for you? Is the implementation idiomatic, or a fight against the standard library? Could a judge verify your dependency manifest is empty in five seconds? Zero Dependency is designed around these questions. Instead of rewarding whoever pulls in the most packages the fastest, the hackathon rewards teams who can prove they didn't need to. About the Hackathon 🌍 Global Online Hackathon ⏳ 72 Hours 💰 $1,800 Prize Pool 👥 Solo or Teams of up to 4 🎓 Open to students, profess

Most i18n tutorials stop at "put your strings in a JSON file". That covers labels. It does not cover the thing that actually breaks: URLs. I run a personality test site in five locales (French, English, Brazilian Portuguese, European Portuguese, Spanish). Same site, five language trees, roughly 96 articles each. The first version had the shape every project seems to grow by accident: $prefix = $locale === 'en' ? '/en' : '' ; That line, or a cousin of it, spread across controllers, views and helpers. Every one of them was correct when written and wrong the moment a third locale showed up. The bug it produces is the worst kind: nothing throws, the page renders, and the Spanish version quietly links to French URLs. The rule that fixed it One rule, enforced by a test: no locale literal anywhere outside the config file. Not in controllers, not in views, not in helpers. If code needs to know something about a locale, it asks the config. Adding a locale then becomes: content files, plus one entry in config/locales.php . Nothing structural. 'default' => 'fr' , 'available' => [ 'fr' , 'en' , 'pt-br' , 'pt-pt' , 'es' ], Three helpers cover essentially every call site: locale_prefix () // '' for the default locale, '/es' otherwise locale_url ( '/disc' ) // prefixed, canonical, ready to print locale_slug ( 'groupe' ) // the localized route segment The part nobody warns you about: slugs are data Labels translate. Slugs are a different problem, because a slug is simultaneously a URL, a cache key, an SEO asset and a foreign key into your own content. The decision that saved me: one locale is canonical, always. French, in my case. Every slug in every other language resolves back to a French slug before anything else happens. $slugs = app ( SlugService :: class ); $slugs -> toLocale ( 'quatre-tendances' , 'es' ); // 'cuatro-tendencias' $slugs -> resolveToCanonical ( 'cuatro-tendencias' ); // 'quatre-tendances' Without that pivot you get N-to-N translation tables and, eventually, two

Two pages on my site went live on July 22. On August 8 they had zero impressions in Google. Not low. Zero, across three weekly exports. URL Inspection didn't say "crawled, not indexed." It said Google could not recognise the URL. Referring sitemap: none detected. Referring pages: none detected. Last crawl: not applicable. Never discovered. Seventeen days. The pipeline was green the entire time My deploy is a small chain: rsync the file, import it into MySQL, restart the service, ping IndexNow. Every step returned success. The last step returned 200 on every URL, every deploy, for three weeks. Here's what I'd never examined: IndexNow doesn't feed Google. It's Bing, Yandex, Seznam, Naver. My green light was real — it was just about a different search engine than the one whose console I was reading. That's the whole bug, and it isn't an SEO bug. It's the generic one: system A returns 200 → I conclude something about system B → nothing in the response object ever objected If you've ever read a webhook 202 as "the downstream processed it," or a CDN purge 200 as "the edge is cold," it's the same shape. What actually broke Search Console's Sitemaps report: Submitted: 2026-07-22 Last read: 2026-07-22 ← seventeen days ago Discovered: 101 URLs ← the file has had 117 for weeks The two pages went live on July 22 — the same day as the only read. Google fetched the sitemap and moved on, within hours of the file changing. Then nothing brought it back, because a sitemap changing on your server notifies nobody. There is no push. It's a pull-only resource with no cache invalidation, and if the consumer doesn't happen to return, your new URLs live in a document no one is reading. Resubmitting took two minutes. Read immediately, 117 URLs. So I wrote the check. It doesn't catch the bug. This is the part worth more than the fix. I wrote a post-deploy verifier. It does two things: // 1. every published, non-redirected page appears in the live sitemap const missing = published.filter((p) =

Hello, I'm Maneshwar. I'm building git-lrc, a Micro AI code reviewer that runs on every commit. It is...