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, as I've been learning GitHub Actions, I reread your article and still find it very helpful. Thank you!😄
Do you mean that you publish to GitHub Pages and dev.to via their APIs, and that your tool transfers the post content to these two platforms?
May I ask two questions about that?
git add content\post\,git commit, andgit push. How is that different from using GitHub API? Are you saying that you put these commands into the tool and made them into a bash script, so we can run it by hitting the Publish button?2.Does dev.to still have an API? I couldn't find it; I only found the RSS feed option.
You're very welcome, Julie! 😄 And yes, there are two slightly different things involved here.
1. Git commands vs GitHub API
I'm actually not putting
git add,git commitandgit pushinto a Bash script.The tool talks directly to GitHub over HTTPS, using GitHub's REST API. There is no local Git CLI involved.
For example, when I publish/update a post, the WordPress plugin can send the file content directly to the repository through the GitHub API. For larger/multiple changes, I also use GitHub's lower-level Git Data API: get the current branch reference, create blobs, create a tree, create a commit, then move the branch reference to that commit.
So conceptually:
git add → git commit → git pushbecomes something closer to:
HTTP request → GitHub API → commit → branch updateThe important difference is that GitHub is doing the Git operation remotely. My tool doesn't need a local Git checkout at all.
Your current workflow is therefore perfectly valid:
The API approach is useful when the application itself needs to control that workflow programmatically — for example, a WordPress "Publish" button can update the repository without requiring Git to be installed or configured on the WordPress server.
2. Yes, DEV still has an API
Yes! 😄 It's just a little easier to miss because DEV is now documented under the Forem API V1 rather than simply "DEV API".
The current documentation is here:
Forem API V1 documentation
And the publishing endpoint is:
POST https://dev.to/api/articlesIt accepts the article as Markdown (
body_markdown), together with the title, tags, publication status, canonical URL, etc.So my publishing pipeline is essentially:
The Markdown remains the source content; the two APIs are simply two different destinations.
And that's actually one of the points I was trying to make in the article: once WordPress stops being the place where the final website has to live, it can become a perfectly reasonable interface for managing content while GitHub remains the source of truth for the site itself.
Pascal, thank you very much for the detailed explanation!😄 It was very clear!
After rereading your reply and discussing with AI over several rounds, I finally got the picture. So your WordPress plugin can push posts to GitHub via the API using the programs you wrote, and it doesn't require Git to be installed on the server. That's a really convenient approach! Wonderful! My Git-based approach works well for pushing posts from local machines that have Git installed. They each suit different use cases.
At first I was confused because I had recently come across the HTTPS approach when using the Git CLI. When I asked the AI agent to configure the GitHub Actions workflow for my Hugo site (I talked about it in this post), it said that the network access had failed. Then I took over the task and found that Git Credential Manager asked for authentication. It turned out to be the HTTPS approach of connecting to GitHub, whereas I usually use SSH. After the AI identified the cause of the network access failure, it gave me the SSH approach of connecting, and the connection succeeded. When I learned that the API approach also uses HTTPS, I confused it with the Git CLI approach. Now I know that HTTPS can be used in both approaches.
I had a look at your code, and it's not as easy as I imagined, haha. In my case, I just run three commands and debug if something goes wrong, whereas you need to consider all of that when writing programs. Fabulous!😄
I wonder whether the Forem API can still be used to publish posts. I signed up for my previous account using a Forem account, and now I can't use it to log in.
Exactly! 😄 And yes, the Forem API can still be used to publish articles — that's actually what I use in the plugin to publish to DEV.
The API has a
POST /api/articlesendpoint, so the plugin sends the Markdown content and the article metadata directly to DEV.I haven't found an equivalent public API endpoint for publishing comments, though. So for AJC Bridge, it's really the articles that I'm pushing through the API.
As for your login/API issue, I wonder if it might be related to the old Forem account rather than the publishing API itself. If you can still access your DEV account, you could check your API key under Edit profile → DEV Community API Keys and generate a new one if necessary.
And yes, I think your distinction is exactly right now: HTTPS isn't the distinction. Both Git CLI and the API can use HTTPS — the difference is what is speaking HTTP to GitHub: the Git protocol/CLI on your side in one case, versus my PHP code calling GitHub's REST API directly in the other. 😄
I found it!😄 Yes, the DEV Community API keys are where you said they were — in my current account. Maybe I'll give it a try later.
So you've been using your own product: writing in WordPress and publishing to dev.to. That must feel great!😄
Thank you very much, Pascal! Your post helped me understand the difference between the Git CLI approach and the API approach to connecting to GitHub over HTTPS.
You're very welcome, Julie! 😄
And yes, there's something quite satisfying about using your own tool for your own workflow. You get to experience the benefits yourself — and you also get to discover what still needs improving! 😂
I'm glad the post helped clarify the distinction. And if you give the Forem API a try, let me know how it goes! 😄
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!
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.
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!
Love the agent embed!
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.