This is a submission for the GitHub Copilot CLI Challenge
This post is for developers who like writing in WordPress but want the speed and safety...
For further actions, you may consider blocking this person and/or reporting abuse
Pascal, this is brilliant! Years ago I used to do some side work building WordPress sites for clients. That’s exactly why I chose WordPress — it was convenient, intuitive, and familiar to clients, and they never had trouble editing their own content.
But building the frontend always gave me this inner resistance: we have so many great tools now, so why are we still doing PHP on the frontend like it’s 20 years ago? 😄 Back then people talked about headless CMS and React frontends, but it all felt a bit clunky and immature.
So it’s nice to see I wasn’t the only one feeling this way! This is a wonderful solution. I don’t really build sites anymore, even for family (simply no time), but I’ll definitely be recommending and promoting approaches like this!
Thanks, Sylwia!
That inner resistance you describe — "why are we still doing PHP on the frontend like it's 20 years ago?" — I felt that hard for years. 😄
The headless CMS wave of the early 2010s promised to solve this, but you're right: it always felt clunky. GraphQL APIs, complex build pipelines, client authentication headaches... it was technically "better" but practically worse for solo developers or small teams.
What changed for me was realizing I didn't need a headless CMS. I just needed WordPress to stop being public-facing. Keep the admin, ditch the frontend. Once that clicked, the solution became obvious: let WordPress manage content, let static generators handle delivery.
The funny thing is, this workflow would've been impossible five years ago. GitHub Actions didn't exist, GitHub API rate limits were lower, and PHP image optimization libraries were primitive. Sometimes the right solution just needs the right moment in the ecosystem.
Really appreciate you sharing your experience — always good to know others were feeling the same friction!
I build Sanity on Netlify systems in that time. Most sites only required a single PHP script that fetched data from the Sanity API. I didn't even need a SSG.
The clunky part is developer error not finding the simplest solution.
CI/CD systems like Huston(Jenkins) existed long before GitHub Actions.
What does that even mean? The frontend frameworks are basically template engines, and Smarty exists since the early 2000's. UI frameworks existed since the introduction of the GUI on OS's. Web UI frameworks didn't invent something new, it is just an adaption for a specific use case.
I find it is sad people don't recognize the history of work their opinions are based on.
Wonderful, Pascal!
So now you write a draft in WordPress, then hit the Publish button, and the post will be published on dev.to and static website at the same time. Wow! It really reduces much time on uploading or editing front matter.
I haven't used WordPress yet. Do you write in rich content format instead of markdown format in WordPress?
Your work inspired me to think about simplifying my workflow. I'd also like to write in markdown and then deploy or upload in one command.
Thanks Julie! Yes, exactly—WordPress editor (Gutenberg) + one click =
published everywhere.
On your question: WordPress uses Gutenberg (block editor), but it has
native Markdown shortcuts! When you type:
## Title→ converts to H2 automatically> Quote→ becomes a quote block- List→ creates a bullet listSo you get the best of both:
It's not pure Markdown editing (like Obsidian), but the shortcuts make
it feel natural if you're used to Markdown syntax. The visual feedback
helps catch formatting issues before publishing.
For your workflow: If you prefer pure Markdown, Obsidian + git works
great. But if you want visual feedback while keeping Markdown habits,
Gutenberg's shortcuts might surprise you.
What's your current workflow? Always curious how others solve this!
The Gutenberg markdown shortcuts are the same as the ones in Markdown editing. Pretty good!
I really admire your workflow, very smooth!
I used Typora + git command to publish. I also use Obsidian, but I prefer writing in Typora for it looks better. "Obsidian + git", Do you mean integrating git in Obsidian?
I haven't try publish using dev.to api yet. From your post it looks very convenient.
Yes! The Gutenberg shortcuts are surprisingly good — I was pleasantly surprised
when I discovered them. Makes the transition from pure Markdown editors much
smoother than expected.
On Obsidian + git: I meant using Obsidian with manual git commands (like your
Typora setup), not a built-in integration. Though there are Obsidian plugins
that can automate git commits if you want that workflow.
Typora is beautiful — totally understand preferring it for visual appeal! The
live preview is unmatched.
On dev.to API: It's surprisingly easy! The plugin handles:
The nice part: you can preview on WordPress (visual editor), then publish to
dev.to with one click. No copy/paste, no manual image uploads.
Your current workflow sounds solid though — if Typora + git works for you,
that's the best setup! The plugin is really for people who want WordPress as
their writing hub but static sites as deployment targets.
Curious: what do you use Obsidian for if Typora is your main writing tool?
Knowledge base / notes?
Your guess is right!
Sometimes I use Obsidian as the local version of Evernote, because it's convenient to take notes and create a new file in it.
I mainly use Obsidian as the knowledge base. Sometimes I want to make an outline of the related articles I've written and find some missing topics to write, and Obsidian has the links to do it. What's more, the search function in Obsidian is very good. In our previous discussions, we both agree that search is important.
But I think I haven't made full use of Obsidian yet. What about you? How do you use these softwares? Like you, I'm also curious how others use these tools. The tips and experience are valuable.
When you mentioned Typora's live preview, it brought me the memory of the early days of using Typora. At the time I was using VS Code as the Markdown editor, which has two-columns view. ( One is the original text, the other is the preview.) When I first used Typora, it scared me. Why? Because I could only get the preview in it, and I wasn't familiar with Markdown, not to mention the Markdown shortcuts. When I needed change the file, I looked for the original text, but I didn't know where to start. Thus I returned to VS Code.
Later I saw many recommendations from bloggers and writers and I got some use tips in their articles or videos. As I used Typora more and got familiar with the Markdown shortcuts, I got to like Typora and regard it as a natural way of Markdown editor. Now I'm not used to the VS Code two-columns view mode. What a change, ha ha!
This comment was first written at noon, but I hit the "Dismiss" button by accident and lost the draft, so I rewrote it. Seems it's also important to save the draft haha.
Ha, I should clarify — I actually DON'T use Obsidian regularly! 😅
I tested it (along with Notion, Roam, and others) but never clicked with these
note-taking tools. I found myself spending more time organizing notes than
actually writing.
My actual workflow is simpler:
I prefer tools that get out of the way. WordPress works because I know it inside
out after years of use. Plain text works because it's zero friction — no
formatting decisions, no organizational systems to maintain.
Your Typora evolution story is fascinating though! The VS Code → Typora
transition mirrors so many tool adoption patterns. We often reject tools initially
because they break our mental models, then embrace them once we internalize
the new paradigm.
The "two-column preview" → "live WYSIWYG" shift is like going from manual
transmission to automatic. Feels wrong at first, then you can't imagine going back.
On saving drafts: YES! I've lost count of how many times I've hit "Dismiss"
or closed a tab by accident. That's actually one reason I like WordPress —
auto-save every few seconds. Paranoid writer syndrome 😄
Your Obsidian setup (links between articles, finding content gaps) sounds really
valuable for content strategy. Even if I don't use it, I respect the workflow!
Same case! From time to time, when the learning notes accumulated to a point, I planned to write articles. However, I found myself organizing notes...
So you have tested some famous note-taking softwares and finally chose a simple note-taking way: plain text files. Simplicity is the best!
I also considered this way, but I have some problems:
"Feels wrong at first, then you can't imagine going back." Absolutely! Your words depict the change vividly. Once we get used to a tool and change the mindset, it's hard to go back.
Same syndrome! What's more, I sometimes still press Ctrl+S to make sure😄.
Ha! Same problems, no real solutions 😅
I use plain .txt files and just... accept the limitations:
It's not optimal, but every "solution" I tried (Obsidian, Notion, etc.)
annoyed me more than the problems they solved.
For you though: Typora might actually work since you already like it.
Has code highlighting, WYSIWYG editing, and search within folders. Solves
your exact issues without being too heavy.
I'm too stubborn to switch from .txt, but you're probably smarter than me 😄
"Finally! Someone who gets it. 🙌
I wasted 6 months in Notion trying to build the 'perfect' system. Ended up with 47 empty databases and zero actual writing.
Now my setup:
VS Code + .md files for daily notes
GitHub Gists for quick snippets
Paper notebook for ideas (old school, I know 😅)
Tools should serve you, not the other way around.
Love the honesty! 🔥"
@harsh2644 YES! The "perfect system" trap is real.
I've been there too—spent weeks setting up Obsidian with tags, templates,
links... then realized I was organizing notes instead of taking them.
Your "47 empty databases" in Notion is painfully relatable 😅
Paper notebook for ideas is actually genius. Zero boot time, zero
organizational decisions, just write. Sometimes analog is the answer we
overthink away from.
The irony: I just built a WordPress plugin using GitHub Copilot CLI that
adds complexity (WordPress → GitHub → Static sites), but the whole point
was to remove friction from publishing. Same principle—tool serves workflow,
not the other way around.
Tools that make you think about the tool = wrong tool ✓
Hi, Pascal.
This was a great read — I really like how you reframed WordPress not as the problem, but as the best writing tool paired with the wrong deployment role. The way you broke down the real friction between writing and publishing felt very honest and relatable, especially the part about trading one set of problems for another with static generators.
What stood out to me is the clarity of the solution: keep WordPress where it shines and let static sites do what they do best. This feels like a very pragmatic middle ground, and honestly the kind of workflow more teams should aim for instead of chasing “pure” stacks.
Thanks, Art!
You nailed it — "the best writing tool paired with the wrong deployment role" is exactly the tension I've been feeling for years.
What surprised me most about this project wasn't the technical implementation, but how obvious the solution seems in hindsight. WordPress has spent 20 years perfecting content management. Hugo has spent a decade perfecting static output. Why force either one to do the other's job?
The "pure stack" mentality you mention is something I definitely fell into. I thought migrating meant choosing a side. Turns out the answer was "yes, and" instead of "either/or."
The real test will be six months from now — will I still be using this workflow, or will I have found new friction points? I'm optimistic, but I've learned to stay humble about these things. 😄
Thanks for reading!
Really enjoyed this perspective.
I like how you didn’t frame WordPress as “bad”, but more as “misused” in many scenarios.
For content-heavy sites that don’t need frequent dynamic interactions, going static with tools like Hugo + GitHub Pages feels like a no-brainer in terms of performance and security.
At the same time, WP still shines when non-technical editors are involved. Context matters a lot here.
Thanks Harsh — glad it resonated.
That’s really how I see it: WordPress isn’t the problem. It’s often just used in contexts where its strengths aren’t aligned with what’s actually needed on the public side.
For content-heavy sites with relatively stable publishing rhythms, static deployment just makes sense now — performance, security, portability… it removes a lot of unnecessary moving parts.
But as soon as non-technical editors are involved, WordPress still does something few tools do as well: it lets people write and manage content without friction. And that part is often underestimated in purely technical discussions.
So yes — context changes everything. The goal isn’t to replace WordPress, just to put it back where it’s strongest.
I really liked the contrast you drew here: functional but heavy global exports vs. a per-post, atomic publishing model. That shift alone explains why this feels better suited to real writing workflows.
Glad that contrast resonated.
The tooling was never really the problem — the mismatch with real writing workflows was.
Once publishing becomes atomic and per-post, it starts to feel natural again.
Static WordPress? Now that's a combo I didn't expect. Been using Gatsby for static sites but never thought about keeping WP as the backend. Might actually solve the "client wants familiar CMS" problem without the security nightmares.
Exactly — that “familiar CMS without the public-facing baggage” was the core idea.
Most clients don’t want a new editing interface, they just want their site to be fast and stable.
Keeping WordPress as a private writing environment while delivering a static frontend solves that surprisingly well.
I find it a bit mischievous that you not once mention JAMstack in the post. That is where you got the idea from. And there are quite a few JAMstack Wordpress plugins .
People reading the post, who don't know JAMstack, are likely to conclude you figured out the method yourself. While it was popularized in 2015.
The biggest drawback of JAMstack is the lack of page personalization. It is possible, but it much more convoluted than serving the personalized pages or page parts from the backend.
David, fair points on the historical context.
A few clarifications:
On JAMstack: The plugin is literally called atomic-jamstack-connector. I didn't hide the lineage — it's in the name and the repository. The article focuses on the implementation (atomic commits, WordPress.org compliance, universal adapters) rather than re-explaining JAMstack as a concept, which has been covered extensively since 2015.
On existing solutions: I researched WP2Static, Simply Static, and Strattic before building this. None offered the specific combination I needed: atomic commits via Trees API, universal front matter templates, async background sync, and WordPress.org compliance. That's the gap this fills.
On template engines and history: I'm well aware of Smarty and the evolution of template engines — I used Smarty extensively with Zend Framework 1.x. Modern frameworks didn't invent templating; they adapted it for different constraints. Sylwia's comment about "PHP on the frontend" was about her clients' perception and resistance, not a technical dismissal of PHP's capabilities. We both know the history.
On CI/CD: You're right that Jenkins and Hudson predate GitHub Actions. But GitHub Actions reduced friction enough to make this workflow practical for solo developers without infrastructure overhead. That's convenience driving adoption, not technical innovation.
I appreciate the technical rigor, but the condescending tone ("mischievous", "developer error", "sad people don't recognize") doesn't add much to the discussion. I'm happy to discuss trade-offs and acknowledge prior art, but let's keep it constructive.
Thanks for engaging.
the fact that that is the only mention, while the first part of your post is focused on the journey to get to the solution makes it more about you than about exploring what already existed.
That is why I called it mischievous.
I don't expect an explanation, an acknowledgment is good enough.
So only you can set a tone in your writing? That feels like measuring with two different weights.
There are a few biases in your post, so it is not a purely technical post.
When you read the other "condescending" words in their context they have a different meaning.
I think the solution is great, it is just parts of the wrapping that bothered me enough to react.
Fair enough — I can see how parts of the framing might read as more personal than exploratory.
The goal wasn’t to erase prior art but to document a concrete implementation path and workflow constraints from my side.
Glad you found the solution itself interesting. That’s ultimately what mattered here.