DEV Community: Vojta Biberle

How This Blog Works in 2026

Vojta Biberle — Fri, 13 Feb 2026 05:08:30 +0000

Back in 2019 I wrote about how this blog works. A lot has changed since then — automated deploys, dev.to sync, AI-generated tweets. Time for an update.

Still Grav

The foundation hasn't changed. Grav CMS, flat-file, PHP 8.2, Markdown, no database. Plugin updates and security patches aren't something I think about — Grav just runs.

The blog theme extends quark and adds custom styles — alternating white/gray section backgrounds, a tag cloud with CSS custom properties, article cards. Pure vanilla JS.

The site is bilingual — Czech (*.cs.md) and English (*.en.md). Every article has both files side by side.

Deploy via Deployer + GitLab CI

This hasn't fundamentally changed since 2019, just gotten more solid. Deployer 7.3 handles the actual deploy — symlink strategy, shared dirs for cache, automatic cleanup of old releases.

GitLab CI orchestrates everything:

Push to master triggers the pipeline
Build image — Docker image with PHP 8.2 and Deployer (only when Dockerfile.ci changes)
Deploy — dep deploy over SSH to biberle.cz
Maintenance — dev.to sync and cache clearing

The SSH key is stored as a base64 CI variable, decoded at runtime. The entire deploy is fully automatic.

Automatic dev.to Sync

English articles automatically get published to dev.to. The sync script scans all English articles, matches them against existing dev.to articles via canonical_url, and creates or updates as needed. Stateless — the canonical URL serves as the key. Runs in CI after every deploy and also on a schedule (for future-dated articles that become publishable).

The reverse works too — importing dev.to articles into the local blog, downloading cover images, and setting the canonical_url back to the blog.

AI-Generated Tweets

This is the new addition. When a new article goes live, it automatically gets tweeted. But not with some generic "New blog post!" — the tweet text is generated by OpenAI (gpt-4o-mini) following my writing style guide.

Here's how it works:

All English articles are scanned
Already tweeted articles get skipped based on a tracked list
For new articles, the title, excerpt, and tags are sent to OpenAI
OpenAI generates a tweet (max 250 chars) matching my tone
Tweet is posted via Twitter API v2 with OAuth 1.0a
The article URL is recorded and committed back to git

The writing style guide lives in a single file, so there's one source of truth for both the AI and me.

Tweets only go out on weekdays at 9:00 AM (Europe/Prague), via a separate GitLab CI schedule with the TWITTER_POST=true variable.

What Hasn't Changed

Some things just work and there's no reason to touch them:

Grav is still perfect for a personal blog — fast, simple, minimal maintenance
Markdown + Git is the best workflow for writing technical articles
Deployer does exactly what it should and nothing more

What's Next

Umami analytics instead of Google Analytics (the template placeholder is already there)
Better cover images for articles
Maybe add an RSS feed for Czech articles

But mostly — write more. Automation is great, but it's useless without articles.

WordPress Theme from Lovable HTML in One Day

Vojta Biberle — Tue, 10 Feb 2026 20:11:11 +0000

I took an HTML export from Lovable, opened Claude Code, and in one day had a complete WordPress theme -- 11 custom blocks, 4 custom post types, deployment pipeline. 83 files, over 7,300 lines of code. Without an AI agent? That would've taken a week at least.

The Brief

I needed a new website for the Czech ecological organization Stromy v krajine (Trees in the Landscape). Their old site was outdated and the client wanted to manage content themselves -- projects, events, team members, partners, and news. WordPress was the obvious choice.

I had Lovable generate the design -- an AI tool that creates a complete React SPA from a text description. The result looked great: responsive design, beautiful color palette (forest green + gold), Tailwind CSS, interactive components. But the client needed WordPress, not a React app.

Step 1: Analyzing the Lovable Export

Lovable generated a React/Vite SPA with dozens of components: HeroSection.tsx, AboutSection.tsx, AchievementsSection.tsx, pages for news, contact, photo gallery. The entire design system in Tailwind with HSL variables -- primary: 142 70% 25% (forest green), accent: 47 96% 53% (gold).

First step was having Claude Code explore the entire React codebase -- every component, every design token, every breakpoint. It built a complete map of what needed to be converted.

Step 2: WordPress Theme in an Hour

From the React code analysis, Claude Code generated the entire theme structure:

11 custom blocks -- Hero, Quote + About, Achievements, Contact Info, Contact Form, Photo Gallery, listings for Projects, Events, Team, and Partners
4 custom post types with Czech labels -- Projects (status, location, tree count), Events (date and time), Team (social media), Partners (logo)
Tailwind pipeline via Vite -- identical design tokens as in Lovable
Custom Nav Walker for desktop and mobile navigation
Vanilla JS lightbox with arrow navigation

55 files, over 5,000 lines -- in a single commit.

Step 3: The Pivot -- ACF to Carbon Fields

The original plan was ACF (Advanced Custom Fields) for blocks and metadata. But ACF Free lacks:

Repeater fields (item lists)
Gallery fields (photo gallery)
Options pages (footer settings)

ACF Pro costs $199+/year. Instead I switched to Carbon Fields -- an open-source alternative with full functionality via Composer.

The migration happened the same day. Claude Code rewrote all 11 blocks from ACF API to Carbon Fields API, swapped get_field() for carbon_get_the_post_meta(), and added Docker Compose for local development. Zero licensing costs, 100% open-source.

Step 4: Polish

What remained was fine-tuning details to match the Lovable design:

Styling the Aktuality (blog) page to match the Lovable template
Contact form with validation replacing the placeholder
Editable footer via WordPress widget areas
CTA button moved from hardcoded header to WordPress menu system
Gallery with lightbox and arrow navigation
Editor styling -- blocks in Gutenberg get labels and borders

Step 5: Deployment

Finally, a Deployer pipeline:

Local build via Vite (Tailwind + JS)
rsync to production server with release management
Zero-downtime deploy via symlinks
Content sync scripts (WP-CLI export/import + search-replace)
Media sync via rsync to a shared uploads directory

Timeline

Time	What happened
0h	Lovable HTML export imported
1h	Complete WordPress theme + ACF blocks
2h	Pivot to Carbon Fields + Docker setup
3-6h	Styling, admin flexibility, interactions
7-8h	Deployment pipeline, documentation

24 commits over 2 days. 83 files. 7,300+ lines of code.

Why This Wouldn't Work Without Claude Code

This was a project where an AI agent really shined:

Codebase analysis -- explored the entire React export and understood the design system
Structure generation -- 55 theme files in a single step
Rapid pivot -- ACF to Carbon Fields migration in an hour instead of a day
Repetitive patterns -- controllers, template parts, CPT registration, block definitions
Tailwind conversion -- 1:1 transfer of design tokens from React to WordPress

Key decisions -- architecture, Carbon Fields vs ACF, deployment strategy -- required human judgment. But the actual execution? The AI agent sped that up maybe 5-10x.

One person + Claude Code = a complete WordPress theme in a day. The future of development is here.

Building a Supabase Driver for Keboola Connection

Vojta Biberle — Mon, 09 Feb 2026 09:09:08 +0000

I spent the past weeks integrating Supabase as an external data source into Keboola Connection. The result is a complete driver with OAuth 2.0, automatic schema discovery, and Supabase Marketplace integration. I also hit some bugs that nearly drove me crazy -- here's the whole story.

Supabase + Keboola

Supabase is an open-source Firebase alternative built on PostgreSQL -- authentication, real-time subscriptions, storage, and most importantly a full-featured PostgreSQL database. Keboola is a data pipeline platform for ETL processes over various data sources.

The goal was simple: let users connect their Supabase project as an external data source in Keboola and have data automatically flow into their pipelines.

From CLI to Web Controller

Originally I wanted a CLI command to register OAuth credentials. But testing a full OAuth flow from the terminal is painful -- you're copying URLs back and forth, handling redirects manually, no visual feedback at all.

So I pivoted early: instead of CLI, I built a web-based test harness at /supabase/connect. A simple form where you enter client_id and client_secret, it generates the redirect URL, sends you to Supabase for authorization, and handles the callback. This turned out to be crucial -- the iterative debugging that followed would have been impossible from a terminal.

The Stateless OAuth Puzzle

The first real challenge came from Symfony's security architecture. Routes with #[AsPublicAction] run on a stateless firewall -- no session available. But OAuth flows typically need to store the PKCE verifier between the authorization request and the callback. Symfony threw: "Session was used while the request was declared stateless."

So what do you do? Encode everything -- client credentials, PKCE verifier, redirect URI -- directly into the OAuth state parameter, signed with HMAC-SHA256 using kernel.secret. The callback decodes the state, verifies the signature, and extracts the PKCE verifier. No session, no database, HMAC prevents tampering, and the state parameter inherently protects against CSRF. Elegant.

OAuth API Quirks

Then came two smaller hurdles:

The approval_prompt mystery. The League OAuth2 library adds approval_prompt to authorization requests by default (a Google OAuth convention). Supabase rejected it: "Unrecognized key(s) in object: 'approval_prompt'." Fix: override getAuthorizationParameters() and filter it out.

Project vs. account OAuth apps. I created the OAuth app at project level (/project/{ref}/auth/oauth-apps) and kept getting "Unrecognized client_id." Turns out Supabase has two distinct OAuth scopes -- project-specific apps and integration apps at the account level (/account/integrations). For a marketplace integration with cross-project access, you need the latter. Easy to miss in the docs.

The PKCE Double-Handling Bug

This was the trickiest bug of the entire project. After solving the stateless flow and API quirks, token exchange kept failing: "Invalid or expired OAuth authorization."

I tried everything systematically:

Detailed error logging -- same error
HTTP Basic Auth for the token endpoint -- still nothing
Accept: application/json header -- still nothing
A completely custom exchangeCodeForTokens() bypassing the library -- still nothing

The authorization flow worked. The callback received the code. But token exchange kept returning the same cryptic error. I was going mad.

The breakthrough: the League OAuth2 library has built-in PKCE support. My code was also handling PKCE manually for the stateless flow. Two correct PKCE implementations running simultaneously -- the library sent one code_verifier, my stateless code sent a different one. Supabase saw a mismatch and rejected the exchange.

The fix? One line:

protected $pkceMethod = null; // Disable library's built-in PKCE

A classic integration bug -- two systems, each correct on its own, breaking when combined. Debugging took hours because every individual piece looked fine.

Two Connection Modes

The driver supports two ways to access Supabase data:

Direct PostgreSQL connection -- the classic approach via connection pooler (port 6543). Full SQL access, good for larger data volumes.

REST API (PostgREST) -- via Supabase REST endpoint with a service_role key. Simpler setup without exposing database passwords.

Both modes support encrypted credential storage with separate encryption keys for passwords, API keys, and OAuth tokens.

Automatic Schema Discovery

After a successful OAuth connection, a SupabaseProjectSetupJob runs in the background:

Calls ListSchemasCommand on the Supabase driver via protobuf
Discovers available database schemas
Creates an external bucket in Keboola for each schema
Sets up auto-refresh every 6 hours

The protobuf communication is architecturally neat -- commands are defined in a shared storage-driver-common monorepo and implemented in storage-driver-postgres. Clean boundaries, no direct coupling.

Users see their data in Keboola immediately after connecting, no manual configuration needed.

Supabase Management API

The integration includes a client for the Supabase Management API:

Project details (region, configuration)
API keys (anon, service_role)
Connection pooler configuration
List of projects and organizations

This data is used during automatic credential setup after the OAuth flow.

The Full User Flow

Here's what the end-to-end experience looks like:

User clicks "Connect Supabase" and authorizes via OAuth
Callback stores tokens, redirects to setup page
User picks their Supabase project, optionally provides a PostgreSQL DSN
Keboola creates an organization and project with a Supabase backend
Background job discovers tables, registers buckets, sets up auto-refresh
User lands on their project dashboard with data already flowing

Scale

The entire driver was built in one week, roughly 60 hours of intensive work with Claude Code. The result is around 25,000 changes -- classes, controllers, migrations, tests, CLI commands, and documentation. From zero to a complete integration.

The workflow was highly iterative: figure out what's needed, implement it, test immediately in the browser, debug from real error messages. Fast feedback loops made it possible to crack even the PKCE double-handling issue in hours rather than days.

The AI agent massively accelerated repetitive patterns (controllers, DTOs, tests), boilerplate generation, and navigating the large Keboola codebase. But key architectural decisions and the security model obviously required human judgment.

What I Learned

Stateless OAuth works -- encode everything in an HMAC-signed state parameter, no session needed
Watch your libraries -- the PKCE double-handling taught me to always check what the library does automatically behind your back
OAuth APIs differ wildly between providers -- approval_prompt, auth methods, app scopes, nothing is standard
PKCE is a must for flows where the client secret can't be fully secured
A web test harness beats CLI testing for OAuth flows by an order of magnitude
AI agents change the game -- 25,000 changes in a week wouldn't have been possible without one

The integration is currently in pull request and going through code review. Looking forward to seeing it in production.

KDE Plasma Activities on stereoides

Vojta Biberle — Fri, 05 Apr 2024 19:38:18 +0000

I used to regard KDE Plasma Activities as merely pointless and dull—like fancy workspaces with added overhead. However, I couldn't have been more mistaken!

Regrettably, this functionality isn't readily visible to the average user, which is a drawback for Activities.

Activities support running scripts for four actions:

Activated: Executes when the activity is selected or focused.
Deactivated: Triggers when switching to another activity.
Started: Runs upon activity initiation.
Stopped: Executes when the activity is halted.

However, there's no graphical user interface (GUI) for this functionality. While there's a Brainstorming discussion in the KDE forum from June 2023, there doesn't seem to be any subsequent development on this front.

So, let's set up scripts manually.

Setting Up Scripts

First, you need to identify the IDs of the activities you're running. You can do this with the following command:

kactivities-cli --list-activities

This command provides you with a table containing the Activity ID, Activity Name, and Activity Icon. You just need the Activity ID. Next, navigate to the folder .local/share/kactivitymanagerd/activities/ (create it if any part of the path doesn't exist). Inside this folder, create a subfolder with the same name as the Activity ID you'd like to script. Then, create subfolders for each action you want to script: activated, deactivated, started, or stopped. You can create folders for all of them if needed. Then, any script placed in one of these action folders will be executed accordingly.

Enhanced Functionality

With these scripts in place, you have fully automated activity switching in Plasma. What's next? For example, you can customize the default browser for each activity.

For this, let's utilize the utils.sh script, which you can place wherever you prefer:

#!/bin/bash

function writeconf() {
  kwriteconfig5 --file ~/.config/kdeglobals --group General --key BrowserApplication "$1"
  xdg-settings set default-web-browser "$1"
  xdg-mime default "$1" x-scheme-handler/https
  xdg-mime default "$1" x-scheme-handler/http
  xdg-mime default "$1" text/html
}

function readconf() {
  kreadconfig5 --file ~/.config/kdeglobals --group General --key BrowserApplication
}

Then, create separate scripts for activating Chrome and Firefox:

activate-chrome.sh - placed in activated:

#!/bin/bash

source ~/.bin/activities/utils.sh

service=org.kde.ActivityManager
interface=$service.Activities
path=/ActivityManager/Activities
signal=CurrentActivityChanged

curact=$(qdbus $service $path $interface.CurrentActivity)
name="$(qdbus $service $path $interface.ActivityName $curact)"
echo "Switched to activity $name"
echo "Previous browser: $(readconf)"
echo "Setting browser to Chrome"
writeconf google-chrome.desktop
echo "Current Browser: $(readconf)"

activate-firefox.sh - placed in deactivated:

#!/bin/bash  

source ~/.bin/activities/utils.sh  

service=org.kde.ActivityManager  
interface=$service.Activities  
path=/ActivityManager/Activities  
signal=CurrentActivityChanged  

curact=$(qdbus $service $path $interface.CurrentActivity)  
name="$(qdbus $service $path $interface.ActivityName $curact)"  
echo "Switched to activity $name"  
echo "Previous browser: $(readconf)"  
echo "Setting browser to Firefox"  
writeconf firefox.desktop  
echo "Current Browser: $(readconf)"

Imagine these scripts being applied to your Work activity. When you switch to Personal, your default browser switches back to Firefox. This setup gives you tailored browser switching for different activities in Plasma.

If you prefer browsers other than Firefox or Chrome, you can easily modify the scripts accordingly.

Additional Tips

I often find it useful to have certain applications pinned to the taskbar across all activities. By default, applications are only shown in the activity where they were launched. However, you can create a KWin window rule with the condition "All activities" to ensure these applications are always accessible.

In Conclusion

This setup has been a significant game-changer for me. As someone who heavily uses Slack for both work and personal communication, having automated browser switching based on activities has streamlined my workflow immensely.

Next, I plan to further customize my Slack experience by separating work-related Slack workspaces from others, allowing for even greater efficiency and organization.

Browser Switching Alternatives

If you're interested in alternative methods for activity switching and scripting, you might want to explore Browsers, an intuitive context menu that appears when you click a link in an app other than a web browser.

Taskfile - really simple task runner

Vojta Biberle — Mon, 06 Jan 2020 21:42:17 +0000

Not so long ago I discovered the Taskfile runner from Adrian Cooney. Adrian hasn't worked on the repository for about 3 years, so I decided to improve it a little bit for my own usage.

There isn't much to fork and I didn't want to open a pull request, so I just copied everything I found useful, prepared one more template (there will be even more templates soon) and published the repository.

I'll be happy if anybody finds it useful. Here is my version of Taskfile. Enjoy!

I discovered a new WordPress local dev-env

Vojta Biberle — Wed, 11 Dec 2019 01:12:41 +0000

Opening

From time to time I have to build WordPress pages. WordPress is not bad. It's actually good, but I use Docker for development and the official docker images are not great.

I actually managed my own PHP WordPress images about 2 years ago, but they are now deprecated (PHP 7.0 and PHP 7.1) and I don't have time or strength to manage them again.

Let's search for some ready-made solution!

Wodby

Managed stacks and infrastructure for post-container world -- that's their marketing claim.

And not only that. These guys provide us with local development stacks with everything I missed from the official WordPress image.
For example:

UID/GID out of the box
xDebug
tooling for wp-cli
tooling for composer

And much more. Just check their guide for WordPress: https://wodby.com/docs/stacks/wordpress/local/ -- it's very easy to follow and start developing in WordPress.

Are you interested in Drupal, PHP, Ruby or Python? They have them too.

And bonus? You can use their deployment stack as a developer for free! Great for showing your work to your clients ;-)

Installation

The installation process is pretty clear, here are just a few adjustments I made.

Do not clone/fork wodby/wordpress-composer but just run composer create-project wodby/wordpress-composer some-dir --stability dev --no-interaction as written in the repository README.md
I changed $PROJECT_BASE_URL to just $PROJECT_NAME.local -- this is shorter :-)
I uncommented mounted volumes for MariaDB, because persistent data are better (you can mount it with just - ./database:/var/lib/mysql)
If you have an issue with MariaDB not starting, just try another MariaDB tag in your .env
You don't need to manually change wp-config.php. Just point your browser to WordPress and let the installer do everything for you
Uncomment the Adminer section in docker-compose.yml -- just my personal preference
Uncomment NGINX_SERVER_ROOT for Nginx and add /web to the end
Run make up
Profit

Closing

This took me more time than I expected for the first run. But now I'm very happy with the dev environment. I have prepared my own template for future projects and I hope I will only need to update dependencies going forward.

Thanks, guys from Wodby!