Why Real-Time WordPress Is the Future - CourtneyR.dev's 2nd Brain

Why Real-Time WordPress Is the Future ![rw-book-cover](https://img.youtube.com/vi/qFTRZr2_s8k/maxresdefault.jpg) 🔗 **Source:** [Why Real-Time WordPress Is the Future](https://www.youtube.com/watch?v=qFTRZr2_s8k) > [!note]+ Document Notes > tags: [real-time-web, wordpress-core, websockets, ai-and-wordpress, developer-tools, wordpress-hosting] > author: The WP Minute (Matt Medeiros, host) with Jared Rehtman (guest) > source: The WP Minute (YouTube) > reference: https://www.youtube.com/watch?v=qFTRZr2_s8k > date created: 2026-08-17 > > > [!info] Generated analysis — not the author's words. Sections below are machine-written > > from the captured source. Only text inside `> [!quote]` blocks is verbatim from the author. > > Do not quote or attribute any other line to the named author. > > # 🏷️ Title: Why Real-Time WordPress Is the Future >  ## 🧭 Table of Contents - [📝 Summary](#-summary) - [📖 Main Content](#-main-content) - [🗒️ Notes](#️-notes) - [📚 References](#-references) - [🗣️ Paraphrase](#️-paraphrase) - [📰 Newsletter](#-newsletter) - [✅ Action Items](#-action-items) - [🧪 Hypotheses](#-hypotheses) - [📊 Methodology](#-methodology) - [❓ Questions](#-questions) - [🔮 Future Research](#-future-research) - [💡 Implications](#-implications) - [🧠 Learning Styles Assessment](#-learning-styles-assessment) - [📊 Accessibility Assessment](#-accessibility-assessment) - [🌍 DEIB Assessment](#-deib-assessment) - [✅ Logical Validity](#-logical-validity) - [🛡️ DARVO Analysis](#-darvo-analysis) - [🎯 Conclusion](#-conclusion) ### 🔗 References - [WP Signal](https://wpsignal.io) — Jared Rehtman's WebSocket relay plugin for WordPress - [World House](https://worldhouse.dev) — Jared Rehtman's boutique WordPress/AI engineering agency - [The WP Minute](https://wpminute.com) — host Matt Medeiros's outlet; courses at wpminute.com/courses - [Pusher](https://pusher.com) — hosted WebSocket relay service cited as a non-WordPress-specific comparator - WordPress Core Real-Time Collaboration initiative (targeted originally for version 7.0, discussed as unlikely for 7.1) ## 📝 Summary - **What happened.** Matt Medeiros of The WP Minute interviews Jared Rehtman — a 15-year WordPress developer (10up, Automattic, now founder of World House) — about WP Signal, a WebSocket relay plugin he built after learning WordPress core was pursuing real-time collaborative editing. The conversation moves from WP Signal's mechanics to a wide-ranging discussion of AI's effect on the WordPress plugin economy, WordPress's long-standing identity problem, and the technical shortcomings of core's real-time collaboration polling approach. - **Why it matters.** WordPress core's in-progress Real-Time Collaboration feature (targeted at v7.0, now uncertain for 7.1) uses HTTP polling every ~3 seconds to keep collaborators' browsers in sync — by Rehtman's account, roughly 90% of those poll requests return "nothing changed." That is a real, quantifiable performance/scalability concern for a feature core intends to ship widely, and it is being surfaced not by a core contributor but by a third-party plugin author building an alternative transport (WebSockets) that plugs into core's own provider architecture. - **Key stakeholders.** WordPress Core / Core Performance (owns the DB load and editor-crash risk of the current polling implementation), the Real-Time Collaboration initiative team (owns the provider-architecture extension point Rehtman says he can plug into), hosting companies (the majority reportedly lack WebSocket/SSE support, which is the market gap WP Signal exploits), plugin developers broadly (facing what Rehtman frames as AI-driven margin compression), and WooCommerce/Automattic (discussed as a plausible in-house competitor to WP Signal's category). - **Risks and tradeoffs.** Technical: shipping real-time collaboration on the current polling design risks DB load spikes and editor crashes as concurrent editors scale past 2–3 people (per Rehtman's account). Business: WP Signal's own "moat" is thin by the guest's own admission — "anyone with technical know-how in a couple of months could probably build something like WP Signal" — and its differentiation rests on a hosting-support gap that could close. Rhetorical: several claims (AI as "hype," plugin sales declining, WordPress market share shrinking) are offered as personal impression/anecdote rather than data, which the Logical Validity section below flags. - **Bottom line.** Real-time behavior — via WebSockets, not polling — is presented as an infrastructure layer WordPress needs regardless of whether core's own Real-Time Collaboration initiative ships on schedule, because the same primitive underwrites e-commerce inventory sync, live chat/chatbots, and breaking-news alerts, not just collaborative editing. ## 📖 Main Content The episode opens with host introduction and Jared Rehtman's background: 15+ years in WordPress, agency work in South Africa, a stint at 10up, a period at Automattic, and now his own shop, World House, which does WordPress work with an increasing focus on AI engineering. Rehtman says the idea for WP Signal came about roughly a year before the recording, when he learned WordPress core intended to introduce real-time collaborative editing and recognized there was no formal path to real-time behavior on the traditional WordPress/LAMP stack. WP Signal, at its technical core, is a WebSocket relay: a WordPress site sends an HTTP request to WP Signal, and WP Signal relays that as a real-time message back to connected clients over a WebSocket connection. Rehtman frames the addressable use cases broadly — not just collaborative editing but chat/chatbot interfaces, live-typing indicators (comparable to iMessage/WhatsApp), e-commerce inventory updates visible to a shopper before they leave the page, flash-sale/Black-Friday urgency messaging, and breaking-news pop-ups in publishing contexts. He has also built a proof-of-concept real-time poker game between two logged-in WordPress users as an exploration of the bidirectional-chat use case. On the business question of defensibility, Rehtman is candid that WP Signal's technical moat is shallow — competent engineers could replicate it in a couple of months, and WooCommerce/Automattic could plausibly ship equivalent server-sent-events or WebSocket capability in core. The actual moat he identifies is on the hosting side: he estimates the "vast majority, 99%" of WordPress hosting companies don't support WebSockets or server-sent events, which pushes real-time capability out to a relay service rather than the origin server. The conversation pivots to AI's effect on the WordPress ecosystem. Rehtman characterizes much of the "WordPress is dying" chatter as hype, while acknowledging some plugin developers report declining sales and rising churn tied to AI-assisted or "vibe-coded" replacements. He argues technical depth (debugging a white-screen-of-death from a PHP syntax error, for instance) remains a differentiator that AI-assisted "vibe coders" won't quickly acquire, predicting a bifurcation where a subset of vibe coders migrate toward genuine engineering skill while plugin sales broadly decline for commodity functionality. Medeiros draws a historical parallel to prior WordPress "disruption" cycles — the Envato theme marketplace, page builders — arguing each shortened the gap between non-technical users and a working WordPress site, and that AI simply accelerates the same pattern. Medeiros also raises a values concern: that AI erodes the historical WordPress-and-open-source value of being able to "unpack" a theme, a plugin, or the codebase to learn from it, versus AI simply producing the output directly. Discussion turns to WordPress core's own AI investments — a core decision to add AI connectors inside wp-admin, and the broader ambition (referenced via MCP — the Model Context Protocol) of being able to "talk in plain English" to a WordPress site the way one might prompt a coding agent against a static site generator. Rehtman characterizes core as moving "at breakneck speeds" on AI and sees the connector approach as creating near-term opportunity for third-party plugin developers to build the natural-language-to-block-markup layer core doesn't yet provide out of the box. On market share, Rehtman predicts WordPress's long-cited ~43–45% CMS market share will shrink, and frames that as potentially healthy: it may finally force WordPress to resolve an identity question it has never definitively answered — blogging platform, application framework (via custom post types and the REST API), general-purpose CMS, or something else. Medeiros counters that WordPress's REST API already made it, in practice, an application framework for many of his clients' mobile app backends, and that he doesn't expect wholesale migration away from WordPress so much as new site volume flowing to non-WordPress stacks (Astro and similar). The conversation returns to WP Signal's direct relationship to core's Real-Time Collaboration initiative. Rehtman says he was racing to ship WP Signal ahead of a planned version 7.0 landing for real-time collaboration, but concluded during that build-up that core's approach wouldn't make it on schedule because of DB load from keeping multiple browsers in sync (with editor-crash risk cited as an observed issue as participant count scales), and now believes it's unlikely to land in 7.1 either. Rather than treating that as a threat, he has diversified WP Signal into bidirectional chat, the poker demo, and e-commerce examples. He describes core's Real-Time Collaboration implementation as using a provider architecture that a WebSocket relay could plug into as an alternative transport to the current HTTP polling mechanism, which he says polls roughly every 3 seconds and returns an empty "nothing changed" response about 90% of the time — the specific inefficiency a persistent WebSocket connection avoids by only sending messages when state actually changes. Rehtman positions WP Signal's long-term ambition against hosted WebSocket relay services like Pusher, aiming to be the WordPress-native equivalent — integrated via familiar WordPress hooks rather than requiring developers to learn a general-purpose platform. He notes it remains a free passion project pending any cost pressure to monetize, with contact-us pricing tiers left undefined for enterprise-scale usage. The episode closes with personal background (Rehtman's move from South Africa to Kentucky via a 10up company event) and calls to action for The WP Minute's newsletter, Slack community, and free courses. ### 🗒️ Notes #### ⏱️ [00:00](https://www.youtube.com/watch?v=qFTRZr2_s8k?t=0) Introduction and guest background - Host Matt Medeiros introduces Jared Rehtman, citing his LinkedIn background: 10up, Automattic, now World House and WP Signal. - Rehtman: 15+ years in WordPress, started in publishing in South Africa, later worked at US-based 10up, a stint in crypto, then Automattic, then founded World House (a boutique WordPress agency now leaning into AI engineering). #### ⏱️ [02:31](https://www.youtube.com/watch?v=qFTRZr2_s8k?t=151) Genesis of WP Signal from real-time collaboration - Learning core intended real-time collaborative editing exposed the lack of a formal path to real-time behavior on the traditional LAMP-based WordPress stack. - WP Signal was "birthed" from that gap — a WebSocket relay that accepts HTTP requests and relays them to clients in real time. #### ⏱️ [04:17](https://www.youtube.com/watch?v=qFTRZr2_s8k?t=257) Chatbots, typing indicators, e-commerce and publishing use cases - Real-time behavior enables chatbot interfaces, live-typing indicators (iMessage/WhatsApp-style), live inventory updates before a shopper leaves the page, flash-sale urgency messaging, and breaking-news pop-ups for publishers. #### ⏱️ [07:15](https://www.youtube.com/watch?v=qFTRZr2_s8k?t=435) The moat question: hosting infrastructure gap - Medeiros presses on defensibility: could WooCommerce/core ship this natively? - Rehtman: at its core WP Signal is "just an infrastructure layer" that a competent team could replicate in a couple of months; the real moat is that an estimated 99% of hosting companies don't support WebSockets or server-sent events. #### ⏱️ [08:51](https://www.youtube.com/watch?v=qFTRZr2_s8k?t=531) AI market chatter and the "WordPress is dying" narrative - Medeiros surfaces social-media sentiment: "WordPress can't survive this AI phase," plugin sales down, churn up, fear of AI-replaced plugins. #### ⏱️ [10:31](https://www.youtube.com/watch?v=qFTRZr2_s8k?t=631) Is AI the "WordPress killer"? Separating hype from signal - Rehtman: recurring "WordPress killer" narratives have appeared for years; he sees current AI disruption as real but currently overhyped, expecting most "vibe coders" to plateau at commodity output while a subset develop genuine engineering skill. #### ⏱️ [11:19](https://www.youtube.com/watch?v=qFTRZr2_s8k?t=679) What "vibe coding" doesn't teach - Debugging a white-screen-of-death from a plugin syntax error is cited as the kind of "scar tissue" that builds real technical understanding and that vibe coding skips. #### ⏱️ [12:57](https://www.youtube.com/watch?v=qFTRZr2_s8k?t=777) Historical disruption cycles: Envato themes, page builders, AI - Medeiros frames AI as the latest iteration of a repeating WordPress pattern — Envato themes, then page builders — each lowering the skill floor to "build something." - Concern raised: AI may remove the historical WordPress/open-source value of being able to unpack and learn from a theme or plugin's code. #### ⏱️ [15:12](https://www.youtube.com/watch?v=qFTRZr2_s8k?t=912) Nostalgia, "vibe coding" a personal app, and eroding technical literacy - Rehtman relates his wife building an app by "vibe coding" and storing state in a markdown file rather than a database — illustrating that deep technical understanding is becoming optional for a growing share of builders, at least for the next 5–10 years by his estimate. #### ⏱️ [17:21](https://www.youtube.com/watch?v=qFTRZr2_s8k?t=1041) AI connectors in wp-admin and the coming "chat with your site" era - Core made a decision to add AI connectors inside the admin; Rehtman expects "a lot more AI slop" content as a byproduct. - Medeiros: the core criticism from some users is "I just want to open Claude Code and chat to my website" rather than manipulate the block editor/site editor. #### ⏱️ [19:11](https://www.youtube.com/watch?v=qFTRZr2_s8k?t=1151) MCP and "talking in plain English" to WordPress - Medeiros predicts a near-term inflection where plain-English MCP connections to WordPress become easy, closing the gap with "chat with your codebase" tools used on static-site stacks (Astro, etc.). - Rehtman: core is moving "at breakneck speeds" on AI; the connector approach creates near-term opportunity for third-party plugins to build the natural-language-to-block-markup layer. #### ⏱️ [22:22](https://www.youtube.com/watch?v=qFTRZr2_s8k?t=1342) Predicted WordPress market-share decline - Rehtman predicts WordPress's long-standing ~43–45% CMS market share will shrink, and frames that as potentially healthy for forcing identity clarity. #### ⏱️ [23:02](https://www.youtube.com/watch?v=qFTRZr2_s8k?t=1382) WordPress's identity crisis - Rehtman: WordPress has struggled with "who should be using it" for ~20 years — blogger tool, agency platform, e-commerce store, portfolio site — and this AI moment may be the forcing function that resolves it. - Medeiros counters that WordPress already found partial identity as an application framework via custom post types and the REST API (cited client mobile-app backends as evidence). #### ⏱️ [25:32](https://www.youtube.com/watch?v=qFTRZr2_s8k?t=1532) Core's Real-Time Collaboration status: pulled from 7.0, uncertain for 7.1 - Rehtman was racing to ship WP Signal alongside a planned v7.0 landing for real-time collaboration but concluded during development it likely wouldn't make it, due to DB load from keeping multiple concurrent editors in sync and at least one observed editor-crashing bug. - He does not expect it to land in 7.1 either, though he's uncertain about timing. #### ⏱️ [28:01](https://www.youtube.com/watch?v=qFTRZr2_s8k?t=1681) Provider architecture: WP Signal as a pluggable transport - Core's Real-Time Collaboration implementation uses a provider architecture; Rehtman says a WebSocket relay (like WP Signal) could plug in as a provider instead of the current HTTP polling transport. #### ⏱️ [28:32](https://www.youtube.com/watch?v=qFTRZr2_s8k?t=1712) The 90%-empty-polling problem - The current polling mechanism runs roughly every 3 seconds; Rehtman estimates about 90% of those requests return no change ("has anything changed? has anything changed?"). - A WebSocket relay keeps an open connection and only sends messages when state actually changes, avoiding that redundant polling load. #### ⏱️ [31:01](https://www.youtube.com/watch?v=qFTRZr2_s8k?t=1861) Pusher comparison and WP Signal's long-term vision - Pusher is cited as an existing general-purpose hosted WebSocket relay usable with any architecture. - Rehtman's differentiation goal for WP Signal: integrate idiomatically with WordPress developer workflow via hooks, rather than requiring developers to learn a general platform like Pusher; long-term ambition is to become the go-to WebSocket relay infrastructure for WordPress real-time needs, not necessarily a hosting company. - Pricing: still free/passion-project; enterprise tiers are "contact us" pending monetization pressure. #### ⏱️ [31:59](https://www.youtube.com/watch?v=qFTRZr2_s8k?t=1919) Personal closing and outro - Rehtman's move from South Africa to Kentucky, tied to meeting his wife (also a 10up employee) at a company event, arriving just before COVID. - Outro: WP Signal at wpsignal.io, Rehtman's agency at worldhouse.dev, and The WP Minute's newsletter/Slack/courses at wpminute.com. ## 📚 References - [WP Signal](https://wpsignal.io) — primary source discussed throughout - [World House](https://worldhouse.dev) — Rehtman's agency - [The WP Minute](https://wpminute.com) — host outlet, publisher of this interview - [Pusher](https://pusher.com) — comparator hosted WebSocket relay service - WordPress Trac / core dev blog — primary source for the Real-Time Collaboration initiative's actual roadmap status (not linked in the transcript; recommended for fact-checking the 7.0/7.1 timeline claims made informally in this conversation) ## 🗣️ Paraphrase - WP Signal exists because WordPress's traditional stack has no formal path to real-time behavior, and Rehtman built a WebSocket relay to fill that gap after learning core planned real-time collaborative editing. - The plugin's real-world use cases extend well past collaborative editing: chat, typing indicators, live inventory, flash-sale urgency, breaking news. - Rehtman openly concedes the technical moat is thin — anyone competent could rebuild it in months — and locates the actual moat in hosting infrastructure: most WordPress hosts don't support WebSockets/SSE. - On AI: Rehtman sees real disruption potential but calls the current "WordPress is dying" narrative largely hype, predicting commodity plugin sales decline while genuine engineering skill remains a durable differentiator. - Medeiros frames AI as the latest in a long line of WordPress skill-floor-lowering shifts (Envato themes, page builders) and worries specifically about losing the "unpack and learn" ethos of open source. - Both expect WordPress's market share to shrink and see that as potentially forcing a long-overdue identity resolution, disagreeing mildly on whether the REST API/custom-post-type era already answered that question. - Core's Real-Time Collaboration effort, per Rehtman, is behind schedule (pulled from 7.0, uncertain for 7.1) due to DB load from an HTTP-polling design that wastes ~90% of its requests on "nothing changed," a problem a WebSocket relay like WP Signal is architected to plug into and solve via core's own provider architecture. ## 📰 Newsletter Real-time WordPress is having a moment — and not just because of the shiny new collaborative editing feature everyone's been watching for 7.0. In this WP Minute conversation, Jared Rehtman (World House, WP Signal) makes the case that WebSockets, not HTTP polling, are the actual infrastructure gap in WordPress hosting today: he estimates 99% of hosts don't support them, and says core's own Real-Time Collaboration polling implementation burns roughly 90% of its requests confirming that nothing changed. If you build for WordPress and haven't thought about where real-time fits — chat, live inventory, breaking-news alerts — this is worth 35 minutes, especially the back half on core's provider architecture and why it's built to be pluggable. Bonus: a genuinely thoughtful, hype-skeptical take on AI's effect on plugin sales and WordPress's 20-year identity question. Check out [WP Signal](https://wpsignal.io) if you want to kick the tires yourself, and catch the full episode plus free courses at [wpminute.com](https://wpminute.com/courses). ## ✅ Action Items #### DevRel - Developer advocacy: a talk or demo comparing HTTP-polling vs. WebSocket-relay costs for real-time WordPress features (concrete DB-load numbers, not just Rehtman's estimate) would give the community data to act on. - Developer experience: document core's Real-Time Collaboration provider architecture publicly so third-party relay plugins (like WP Signal) have a stable, documented integration point rather than relying on informal knowledge from one plugin author. - Community management: convene a session at the next WordCamp/contributor day specifically on real-time-infrastructure options for hosts, since the "99% of hosts don't support WebSockets" claim — if roughly accurate — is a hosting-ecosystem gap DevRel can help close. #### OSPO - Security Management: any WebSocket relay architecture (WP Signal or a future core-shipped equivalent) needs a documented threat model — open persistent connections are a different attack surface than request/response HTTP, and this wasn't discussed in the interview. - Software Inventory: if core ships a provider-architecture extension point for real-time transport, track which third-party providers (Pusher, WP Signal, others) plug into it as a de facto ecosystem dependency. #### Community - Maintainers: the Real-Time Collaboration initiative's release-timeline uncertainty (pulled from 7.0, uncertain for 7.1) should be communicated clearly on the official make.wordpress.org/core channel rather than left to podcast-level speculation, to avoid rumor becoming the record. - Ecosystem: WP Signal is one data point; DevRel/Community should track whether other real-time-relay plugins emerge to plug into the same provider architecture, since a healthy ecosystem here reduces single-vendor risk. #### WordPress - **Core:** Prioritize resolving or clearly re-scoping the Real-Time Collaboration polling-load problem before any future release target; the ~90%-empty-poll figure, even if approximate, is the kind of performance-budget red flag Core Performance should independently verify. - **Core Performance:** Commission a proper profiling pass (not anecdote) on the current HTTP-polling implementation's DB load under realistic concurrent-editor counts (2, 5, 10+), and publish the numbers — this directly informs whether WebSocket-relay providers are a stopgap or the long-term answer. - **Core AI:** As core adds AI connectors to wp-admin, define evaluation criteria for what "chat with your WordPress site" should and shouldn't be able to do, given both Rehtman's and Medeiros's expectation that MCP-style natural-language control is coming soon. - Hosting: Publish or crowdsource an accurate accounting of which major WordPress hosts do/don't support WebSockets and server-sent events — the 99%-unsupported figure cited here is asserted, not sourced, and the hosting subteam is best positioned to verify or correct it. - Documentation: If core's Real-Time Collaboration provider architecture is meant to be pluggable by third parties, it needs DevHub-level documentation, not just tribal knowledge from one plugin author's exploration. - Plugins: Review-team guidance for real-time/WebSocket-relay plugins (WP Signal being an early example) may be needed as this category grows — persistent external connections are a different security review surface than typical plugin code. #### The WPOCC - Programs: a microgrant or fellowship track for open, host-agnostic real-time-infrastructure tooling would reduce reliance on any single third-party relay vendor for a capability likely to become foundational (real-time editing, live commerce, live publishing alerts). ### FAIR - Technical independence: a real-time transport layer that most hosts can't natively support is exactly the kind of centralization risk FAIR's technical-independence principles are meant to flag — if WebSocket relay becomes load-bearing infrastructure for core features, provenance and portability of that layer matter. ## 🧪 Hypotheses - H1: WordPress core's current HTTP-polling implementation for Real-Time Collaboration will not ship in a mainline release without either a polling-interval increase, a debounce/backoff mechanism, or a pluggable WebSocket-relay provider replacing polling as the default transport. - H2: The claim that "99% of WordPress hosting companies don't support WebSockets/SSE" is directionally correct for shared/budget hosting but substantially overstated for managed WordPress hosting (WP Engine, Kinsta, Pressable, etc.), most of which run modern infrastructure capable of WebSocket support. - H3: Plugin sales declines attributed to AI/vibe-coding substitution are concentrated in commodity-utility plugin categories (simple form builders, basic SEO tweaks) rather than plugins requiring deep domain logic (e-commerce, real-time infrastructure, security). - H4: WordPress's CMS market-share decline (from ~43–45%) will correlate more strongly with the rise of AI-native site builders capturing *new* site creation than with existing WordPress sites migrating away. - H5: A third-party WebSocket-relay plugin ecosystem (WP Signal and successors) will emerge as a stopgap layer that gets partially obsoleted once/if WooCommerce or core ships native real-time transport, mirroring the earlier "backup plugin → native core feature" pattern. ### 📊 Methodology - H1: Audit make.wordpress.org/core Trac tickets and props for the Real-Time Collaboration feature to independently verify the "pulled from 7.0, uncertain for 7.1" claim and any documented performance-mitigation plans. - H2: Survey the top 20 WordPress hosts (by market share) for documented WebSocket/SSE support in their infrastructure docs or via direct outreach; compare against the 99%-unsupported figure. - H3: Compare wp.org plugin-directory active-install and sales trend data (where available via partner programs) across commodity-utility vs. domain-specific plugin categories over the past 12–18 months. - H4: Cross-reference W3Techs/BuiltWith market-share time series against new-site-creation data from AI-native builders (e.g., publicly reported user counts) to separate migration from new-market capture. - H5: Track wp.org plugin directory for new WebSocket-relay-category plugins over the next 12 months and note any deprecation/consolidation events tied to core or WooCommerce feature releases. ### ❓ Questions - Is the "90% of polling messages are empty" figure Rehtman's estimate from personal testing, or does it come from a published core benchmark? - What specifically caused the editor-crashing bug Rehtman references when describing multi-user Real-Time Collaboration testing, and has it been triaged/fixed since this recording? - Has WooCommerce or Automattic publicly signaled any intent to ship native WebSocket/SSE support, or is that purely Rehtman's speculation as a competitive threat framing? - What does core's Real-Time Collaboration provider architecture actually expose as an extension API today, and is it documented anywhere a third-party developer could act on without a personal conversation with the initiative's contributors? - If WordPress's identity has genuinely never been resolved in ~20 years, what would "resolving" it even look like in practice — a narrower core, opinionated official starter kits, or something else? ### 🔮 Future Research - A rigorous, sourced comparison of WordPress hosting providers' real-time-transport support (current state is asserted anecdotally in this episode and needs independent verification). - Longitudinal tracking of WordPress CMS market share against AI-tool adoption to test whether the "shrinking is healthy" framing holds up against actual ecosystem health metrics (contributor counts, plugin directory growth, hosting revenue). - A technical deep-dive (blog post or contributor-day session) on core's Real-Time Collaboration provider architecture, written by an actual core contributor rather than reconstructed secondhand from a podcast interview. - Case studies of WP Signal or comparable plugins in production e-commerce/publishing contexts to validate the claimed use cases (live inventory, breaking-news pop-ups) beyond the demo/proof-of-concept stage described here. ### 💡 Implications - **Practice.** Developers building real-time features for WordPress today have to choose between waiting on core's still-uncertain native support or adopting a third-party relay (WP Signal, Pusher, or similar) — a build-vs-wait decision worth flagging explicitly to clients rather than assuming core will "just handle it." - **Policy.** If core's Real-Time Collaboration initiative is genuinely blocked on DB-load/performance grounds, the Core Performance team's release-readiness criteria should be made explicit and public, both to set community expectations and to give third-party relay developers like Rehtman a clear signal about how long the gap will persist. - **Security.** Persistent WebSocket connections change WordPress's attack surface relative to traditional request/response HTTP; any plugin review guidance and core provider-architecture design should treat this as a first-class security consideration, not an afterthought. - **Education.** The vibe-coding discussion has direct Training/education relevance: if "the calluses of debugging a white-screen-of-death" are a real skill-building mechanism per Rehtman, WordPress training content could deliberately preserve some of that friction rather than abstracting it all away. - **Funding models.** WP Signal's free/passion-project pricing (with no monetization pressure yet) is a fragile foundation for infrastructure other developers might come to depend on — a cautionary pattern the WPOCC's funding-transparency and sustainability work is directly relevant to. ### 🧠 Learning Styles Assessment - Reading level estimate: approximately Flesch-Kincaid grade 8–9 for the spoken conversational content (informal, conversational vocabulary, moderate technical jargon around WebSockets/polling/DB load). #### 👀 Visual learners - Present: none — this is audio/video with a transcript only, no diagrams, charts, or labeled code in the source. - Improve: a simple sequence diagram contrasting HTTP-polling (client → server every 3s, mostly empty responses) vs. WebSocket-relay (persistent connection, push-on-change) would make the core technical claim immediately legible. #### 🔊 Aural learners - Present: the source itself is a podcast/video interview — well-suited to aural learners as-is. - Improve: a 2–3 minute audio pull-quote of the "90% empty polling" segment could work as a standalone clip for social/newsletter use. #### 🗣️ Verbal learners - Present: conversational analogies (financial-ticker digits, iMessage typing indicators, "has anything changed?" framing) aid verbal learners. - Improve: a short glossary distinguishing WebSocket, Server-Sent Events (SSE), and HTTP polling would help listeners who conflate the three terms, which the guest himself blends at points ("web socket or server-side... service and events capabilities"). #### 🧩 Kinesthetic learners - Present: WP Signal's own site (wpsignal.io) presumably offers a hands-on demo, though not shown in this transcript. - Improve: a companion "build a real-time WooCommerce inventory badge in 20 minutes with WP Signal" walkthrough would convert the abstract use cases into a reproducible exercise. #### 🧠 Logical learners - Present: the moat/business-model line of questioning (can WooCommerce ship this, what stops replication) offers a clear decision-tree structure. - Improve: a simple table mapping use case (chat, inventory, breaking news) → required transport → current core support status → WP Signal support status would sharpen the logical structure already implicit in the conversation. #### 🧑‍🤝‍🧑 Social learners - Present: this is a two-person conversational interview format, naturally suited to social learners following a dialogue. - Improve: a discussion-prompt companion (e.g., in the WP Minute Slack) asking listeners to weigh in on the "is AI hype or real threat" question would extend the social-learning value past passive viewing. #### 🧘‍♀️ Solitary learners - Present: none explicitly — no self-check or reflection prompts included in the source. - Improve: a short self-assessment ("does your current hosting support WebSockets? have you audited your own plugin sales trend?") would give solitary learners something to act on individually. #### 🌿 Naturalistic learners - Present: none — no sustainability or ecosystem-lifecycle framing in the source. - Improve: a brief note on the resource-efficiency angle (polling every 3 seconds at scale burns real server cycles/energy compared to event-driven push) would connect the technical content to a naturalistic/sustainability lens. ### 📊 Accessibility Assessment #### Screen reader semantics - Present: the Reader-scraped transcript is plain paragraph text with timestamps; no heading structure in the source video/description itself. - Improve: publish an official, properly-headinged show-notes page (as this note now provides) so screen-reader users can navigate topics instead of scrubbing a 35-minute audio track. #### Keyboard navigation - Present: not applicable — no interactive UI in the source content itself. - Improve: not applicable to a video/podcast transcript. #### Contrast and readability - Present: not evaluated — this analysis is based on the transcript, not the original video's on-screen visuals/captions styling. - Improve: if WP Minute publishes auto-captions, verify caption contrast against WCAG 2.2 AA (4.5:1 minimum) on their video platform. #### Text resizing and reflow - Present: not applicable to audio/video content directly. - Improve: ensure the WP Minute site's transcript/show-notes page (if published) reflows correctly at 200% zoom. #### Media and captions - Present: this document is itself effectively a detailed, timestamped transcript-derived summary, which functions as an accessibility improvement over the raw video. - Improve: request or verify official closed captions (not just YouTube auto-captions) are available for the source video, and add audio descriptions if any on-screen visuals (e.g., a WP Signal dashboard demo) were shown but not verbally described. #### Forms and interactions - Present: not applicable — no forms in the source content. - Improve: not applicable. #### Standards reference - Gaps identified above (captions, contrast, structured navigation) map to WCAG 2.2 AA success criteria 1.2.2 (Captions), 1.4.3 (Contrast Minimum), and 2.4.6 (Headings and Labels). ### 🌍 DEIB Assessment #### Cultural breadth - Present: Rehtman's own South Africa-to-Kentucky background adds an international dimension to an otherwise US-centric WordPress-business conversation. - Improve: the discussion of hosting support and market share is entirely US/global-market-generic; explicit examples from non-US hosting markets (e.g., regional WordPress hosts in Africa, Asia, Latin America) would broaden the analysis. #### Inclusive language - Present: generally plain, jargon-explained language ("web socket relay... what that boils down to is"). - Improve: terms like "moat," "vibe coding," and "AI slop" are insider tech/VC-adjacent slang used without definition; a brief glossary would help listeners outside that subculture. #### Neurodiversity support - Present: conversational, meandering structure typical of unscripted podcast dialogue (frequent false starts, "um," topic drift) may be harder to follow for some neurodivergent listeners than a structured piece. - Improve: this document's timestamped, headed structure is itself the accessibility improvement; a similarly structured official show-notes page from WP Minute would help future episodes. #### Representation - Present: both participants are men in senior technical/business roles; no other voices represented in this episode. - Improve: future episodes on real-time WordPress infrastructure could include perspectives from hosting-company engineers (to verify the WebSocket-support claims) or from Core Performance contributors directly involved in the Real-Time Collaboration initiative. #### Psychological safety - Present: the conversation is collegial and low-stakes; Rehtman is candid about business vulnerabilities (thin moat) without apparent discomfort. - Improve: no notable gaps — tone is respectful throughout. ### ✅ Logical Validity #### Strong reasoning - Rehtman's moat analysis (WP Signal at ~[07:15](https://www.youtube.com/watch?v=qFTRZr2_s8k?t=435)) is a clear, well-structured causal argument: technical replicability is low-barrier, but the hosting-support gap creates a real, if narrow, market position. This is strong because he explicitly separates "what's technically hard" from "what's actually scarce," which is the correct framing for assessing a moat. - The polling-vs-WebSocket explanation (~[28:32](https://www.youtube.com/watch?v=qFTRZr2_s8k?t=1712)) is a strong analogical/causal argument: it names a specific mechanism (3-second interval, ~90% empty responses) and a specific alternative (event-driven push), making the claim falsifiable and technically legible rather than vague. #### Fallacies - **Hasty generalization** — "the vast majority, 99% of hosting companies don't support web sockets" (~[08:01](https://www.youtube.com/watch?v=qFTRZr2_s8k?t=481)): presented as a precise statistic with no cited source or methodology. Fix: qualify as a personal estimate, or replace with a sourced figure (see Methodology H2 above). - **Appeal to hype/anecdote** — the "WordPress is dying" vs. "it's just hype" exchange (~[10:31](https://www.youtube.com/watch?v=qFTRZr2_s8k?t=631)) relies on social-media sentiment and personal impression on both sides rather than data (plugin-directory trends, actual sales figures). Fix: ground the claim in wp.org active-install trends or a plugin-vendor survey before asserting a direction. - **False dichotomy (mild)** — Medeiros's framing of "is it WordPress and AI, or WordPress and some other stack, or WordPress as it's always been" (~[08:51](https://www.youtube.com/watch?v=qFTRZr2_s8k?t=531)) presents three options as though exhaustive and mutually exclusive, when in practice hybrid outcomes (WordPress with AI-assisted authoring alongside traditional workflows) are the more likely reality and are in fact where the conversation eventually lands. #### Tone of voice - Conversational, informal, and candid throughout — both speakers use hedged language ("I think," "personally," "I don't know") that signals opinion rather than assertion, which is honest framing but also means several claims in this document are speculative by the speakers' own admission and should be treated accordingly. ### 🛡️ DARVO Analysis - Not applicable to this source — this is a collegial interview with no accusation, conflict, or defensive posture present. No deny/attack/reverse-victim-offender pattern occurs in the transcript. ## 🎯 Conclusion - **Bottom line.** Real-time infrastructure for WordPress — via WebSockets rather than HTTP polling — is a genuine, underserved technical gap that both core's own Real-Time Collaboration initiative and third-party tools like WP Signal are independently trying to solve, with core's current polling-based approach carrying a real (if informally quantified) performance cost that has reportedly delayed its ship date. - **Practical next steps.** Core Performance should publish sourced benchmarks on the polling implementation's actual DB load rather than leaving the "90% empty" figure as podcast anecdote; hosting providers and DevRel should jointly clarify actual WebSocket/SSE support across the hosting market rather than relying on the unsourced "99% unsupported" estimate; and developers evaluating real-time features for client sites today should treat third-party relay plugins as a pragmatic bridge, not a permanent architecture, given core's own provider-architecture extension point is explicitly designed to make that bridge replaceable. ## 🔄 Refactor Appendix — Why Real-Time WordPress Is the Future > Density: 2–5 Literature atoms (H3), 0–3 Permanent candidates (H4). > Defaults: 3 Literature, 1 Permanent. Resonance filter: if you can't > articulate in one line why a claim matters, drop it. > > Konik claim-header rules: present tense, declarative, ≤10 words when > possible, searchable, unique, mirrors annotation focus if present. > > Atomicity: one declarative sentence per atom. "and"/"also" → split. > > Tag pool: #bmf · #addendum · #xref · #articleseed · #storystem · #share · #aphorisms ### 📚 Literature Atoms (H3) #### [H1] Core's real-time polling wastes ~90% of requests > [!quote] ID:rw_qFTRZr2_s8k_1712 > So, 90% of those messages are empty because it's saying, "Has anything changed? Has anything changed?" **Context & use**: - [28:32](https://www.youtube.com/watch?v=qFTRZr2_s8k?t=1712) — Rehtman explaining core's Real-Time Collaboration HTTP-polling transport. - Matters because it's a specific, falsifiable performance claim about a core feature's current implementation, directly explaining a reported ship-date slip. **Tags**: #xref **Highlight**: [view highlight](readwise://)  #### [H2] WP Signal's real moat is hosting, not code > [!quote] ID:rw_qFTRZr2_s8k_481 > I would say the vast majority 99% of hosting companies don't support web sockets and service and events. **Context & use**: - [08:01](https://www.youtube.com/watch?v=qFTRZr2_s8k?t=481) — Rehtman answering the direct "what's your moat" question. - Matters because it reframes the competitive question from "is the code hard to copy" (it isn't, by his own admission) to "is the underlying capability scarce" (allegedly yes, at the hosting layer). **Tags**: #xref **Highlight**: [view highlight](readwise://)  #### [H3] Core's provider architecture is built to be pluggable > [!quote] ID:rw_qFTRZr2_s8k_1681 > in using a provider architecture where you can as as a provider as a web socket um real-time collaboration I mean a real-time web socket relay, I can just plug into that provider architecture and instead of using the the polling mechanism that's that's kind currently implemented. **Context & use**: - [28:01](https://www.youtube.com/watch?v=qFTRZr2_s8k?t=1681) — describing how WP Signal could plug into core's Real-Time Collaboration transport layer. - Matters because it means the polling-vs-WebSocket choice isn't a fork in core's architecture — it's a designed extension point, which lowers the cost of eventually fixing the performance problem named in [H1]. **Tags**: #xref **Highlight**: [view highlight](readwise://)  ### 🧠 Permanent Candidates (H4) #### [P1] Real-time transport is a hosting-layer gap, not a WordPress-core gap **Claim** (one sentence, Courtney's voice): The reason WordPress needs third-party WebSocket relays for real-time features isn't that core can't build the feature — it's that most WordPress hosts don't support the transport core's feature would need. **Evidence pointer**: [[#H2]] **Scope & conditions**: Holds as long as budget/shared hosting dominates the WordPress hosting market and doesn't natively support WebSockets/SSE; breaks if major hosts add native support or if core standardizes on a fallback transport that works everywhere. **Links** (≥1 with annotation): - [[WordPress hosting infrastructure]] — because applies-in the hosting-provider capability gap this claim depends on **Optional**: `proof_state: working` — falsifiable via a hosting-support audit (see Methodology H2)  ### ✏️ Fleeting Queue - [F1] Verify whether core's Real-Time Collaboration Trac tickets confirm the "pulled from 7.0" and "uncertain for 7.1" timeline Rehtman describes informally — https://make.wordpress.org/core/ #xref - [F2] Look into whether WooCommerce has any public roadmap signal toward native WebSocket/SSE support, which Rehtman treats as a plausible future competitive threat to WP Signal — #articleseed ### → Things 3 (max 2 actions) - [ ] Check make.wordpress.org/core Trac for the current Real-Time Collaboration release-target status and DB-load discussion — WordPress core research #things  📄 **Full text:** [[Full Document Contents/Articles/Why Real-Time WordPress Is the Future.md|Why Real-Time WordPress Is the Future by YouTube]] ## Highlights - uh just some of the limitations that come with a with traditional WordPress stack the LAMP stack. Um and knowing that there isn't really a um a formal um journey to to get to real-time behavior on a WordPress stack. So I I uh the WP Signal was was birthed from that from the idea of creating real-time infrastructure for WordPress sites >> [clears throat] >> which would allow ([View Highlight](https://read.readwise.io/read/01m07y2ey15zzcry78zffx2n2q)) - Note: Genesis of WP Signal: born from the gap between WordPress's traditional LAMP stack and real-time behavior, prompted by core's real-time collaboration work. - Tags: wordpress-core, atom/literature/h2 - anyone with technical know-how in a couple of months could probably build something like WP Signal. WooCommerce shipping with a web socket or server-side um I mean service service and events capabilities is possible. I think they might do I mean they they could potentially do it, but the I would say the vast majority 99% of hosting companies don't support web ([View Highlight](https://read.readwise.io/read/01m07y2m6eykegb9apktzen54w)) - Note: The real moat: WP Signal's code is easily replicable, but Rehtman claims ~99% of WordPress hosts don't support WebSockets/SSE — an unsourced but load-bearing claim (see Hypotheses H2). - Tags: wordpress-hosting, atom/literature/h1 - >> [sighs] >> is going to kill WordPress. It's the WordPress killer. I think AI has real potential to disrupt that market and we've already seen stuff like N-dash um come to light. But I think at the moment, I think it's it's hype. Personally, this is how I feel about it. I feel like it's it's really hyped up right now and we've got a lot of vibe coders thinking that they can build the next WooCommerce ([View Highlight](https://read.readwise.io/read/01m07y2st5r41kwt5chhn1bky4)) - Note: "WordPress killer" AI narrative called out as recurring hype rather than proven disruption — flagged in Logical Validity as an appeal-to-hype exchange lacking supporting data. - Tags: atom/literature/h2, ai-and-wordpress - with that identity. And I think that this is an opportunity where WordPress can land on an identity and like be an open source tool for a thing. I don't know what the thing is yet. >> [laughter] >> But I think it will be a thing soon and that's just my own thoughts. I I don't know if you cuz you have a a breadth of knowledge. Like you've seen large media scales large scale media sites at at 10 up in your other jobs. And and and I just think that maybe ([View Highlight](https://read.readwise.io/read/01m07y2zfhqx9fmgte4vd6z1jy)) - Note: WordPress's ~20-year identity question — Rehtman frames shrinking market share as a potential forcing function for WordPress to finally define its use case. - Tags: wordpress-core, atom/literature/h3 - to 3 seconds. So, 90% of those messages are empty because it's saying, "Has anything changed? Has anything changed?" Um, what the web socket relay allows is that you've got this open connection and only when things change, only when things need to be synced are messages synced across that that wire. Um Yeah, I kind of I kind of lost my thought there. Uh my kind of but but basically that's ([View Highlight](https://read.readwise.io/read/01m07y35cbpsmffb7k036s2vzy)) - Note: Strongest technical claim in the episode: core's Real-Time Collaboration HTTP-polling transport wastes ~90% of its requests confirming nothing changed — the specific inefficiency a WebSocket relay avoids. - Tags: wordpress-core, atom/literature/h1 - companies that web socket relay companies like Pusher is one of them. >> Pusher, right? That's one of them. >> Yeah. So Pusher is just like a general you can through any sort of architecture use Pusher. I wanted to create WP Signal that it worked really well within uh it's one of the way that you're you're comfortable and familiar working with in in WordPress as a developer. Um so it like it uses hooks to be able to fire off HTTP requests when you're ([View Highlight](https://read.readwise.io/read/01m07y3bmartnm30pxb7tv66qb)) - Note: Positioning against Pusher: WP Signal's differentiation is idiomatic WordPress-hooks integration rather than a general-purpose relay platform. - Tags: developer-tools, atom/literature/h3