This bot gives advice about how to make layouts in WordPress using the stock tools and features. More on this later, on to the Thaura Projects settings.

Thaura Projects is a feature to allow you to create chatbots (and other interactive tools).

To create a new Project, click on Project in the navigation, and then “+” in the upper right corner.

Fill in the form with:

Then save it, and go to the Project. In the upper right, click the triple-dot menu and Edit.

Add:

This is a screenshot of the dialog box where you paste in the prompts.

The post Thaura & WordPress: layout advice chatbot first appeared on 🍙.

This tutorial uses ACF and Blocks for ACF Fields.

This video explains ACF and it’s current direction.

This video explains how to show custom fields in a list of CPTs, using a plugin called Blocks for ACF Fields.

This begs the question I’ve wondered: why can’t I show the field values without this extra plugin?

(They are also wondering why this plugin doesn’t seem to allow fields to be shown on posts.)

ACF was designed for WordPress programmers who created CPTs, and who wrote Themes, back when making these two things together required PHP programming.

ACF’s product direction has been to support PHP programmers. So the PRO version of the product makes it easy to create new blocks… using PHP code.

So, into this gap, some products have entered to display custom fields in the Gutenberg environment.

Meta Field Blocks is a popular one: https://wordpress.org/plugins/display-a-meta-field-as-block/. It’s pretty full-featured.

Blocks for Advanced Custom Fields is another popular one: https://wordpress.org/plugins/acf-field-blocks/

I was having some trouble with Blocks for ACF, specifically, showing the fields on a post. It worked in query loops, but not on single posts.

• I could add the fields within a Query Loop, like in the video example above.
• I was unable to add these fields to a Template for a Post.

The fix was to do the following:

1. Go to the Post, and then click “Edit Post”. (Yes, the post, not the site.)
2. Use Blocks for ACF to add the fields for this specific post.
3. Shift-select all these blocks, and then Group them. (Use the Group action from the three-dots menu.)
4. Create a Pattern for this group. When you do this, make sure it’s not a “synced” pattern.
5. Create a new Template. The easiest way is to select “Create New Template” when you click on the Template field in the Post properties. This should create a template for a Post.
6. Within the template, add the Pattern you just created. Save the template, and check that it works.
7. (After this, you can remove the pattern block from the Post you edited. The pattern should appear on all Posts using the new template.)

This problem doesn’t happen with Meta Field Blocks.

Should we even be using custom fields?

Once I was using Patterns, I started to wonder if ACF was even worth it. My site had < 50 items.

I didn’t really benefit from having a database-like schema for the items. In fact, it was as much of a hindrance as a help, because special cases were common. My data didn’t really fit the schema well.

I could easily use an un-synced pattern as a small template for the extra fields.

Whenever I need to display a thumbnail and a couple links, I can insert the pattern, and fill in the blanks.

There you go: instant database, without the need to create custom fields.

So why did I have custom fields?

Back when I created the custom fields, the balance of complexity was different, because Gutenberg was still in development, and I thought I’d need a lot items. The technical debt incurred by making the fields, was paid off by the effort saved in creating item pages. Coding up templates in PHP was easy for me, too.

So are custom fields and CPTs dead?

I think it’s still a good way to build websites that are like databases.

The issue is fit. If the number of items is small, and you have only one person editing the database, there’s no point.

If you have multiple editors, then the uniformity that fields impose will be a huge benefit.

If you have many items, then the uniformity the template layout imposes will be a benefit.

If you have a complex database, with many items, then, you will probably need to get ACF PRO, and skip past these field-display blocks (or use them selectively). A developer seat costs $$, but wages will cost 100X or more than the software license.

A non-programmer site builder can be far less expensive than a developer, but if the data gets complex, you have to look at the risks of relying on two different plugins, and having configuration spread across templates and patterns.

The main savings from using ACF will come from the fact you are hiring WordPress talent, rather than database or web app talent, and using the WordPress environment, which comes with the user reg, publishing, layout, themes, etc. for a lower price. (Thousands to tens of thousands of dollars, versus hundreds of thousands of dollars.)

How big is big?

ACF and WordPress won’t scale up to the hundreds of thousands of records. I’d even argue that it starts to creak after it’s near a thousand posts. The content on this site and related ones went up into the 800 post range, and it just got hard to find and edit articles. I was often resorting to searching for posts from the front end rather than back, and sometimes resorted to using Google or Bing to find articles.¹

The admin page tools were just inadequate, and slow.

On a regular database-backed website, you would do things like write custom searches, custom scripts to check for data consistency and completeness, and other “clean up” tools. With WordPress, it’s more effort to do this kind of work, and the resulting code is confusing as heck. (In contrast, a normal DB maintenance script centers on SQL queries, which are easier to read.)

Most database-publishing isn’t really even about making the website: the database has a more central business use, and the website is an appendage to the database.

For example, the App stores and Streaming sites all have huge websites, but they aren’t running app stores to create pages: the app store is the software economy of a platform. Its website is a promotional tool or an alternative access tool.

1. In fact, after I started using the search engines to find articles, I started to delete some posts, because, I started to realize that the central databases that mattered were the search engine indexes. ︎

The post WordPress: Displaying ACF Fields on a Post first appeared on 🍙.

One of the code management techniques I tried with KRUpload was to break the application into a core app, and plugins. I don’t have stats about how that went, but it seemed to help.

Here’s a du of the extensions directory:

➜  extensions du -sh *
28K	BackupShare
24K	csv-preview
32K	download-url
16K	example
36K	file-editor
28K	FileNotes
20K	file-preview
44K	Fslint
16K	HelloWorld
404K	InternalTools ---- this is a huge db schema editor
28K	jpg-preview
20K	json-viewer
28K	m3u-preview
64K	MarkdownViewer
24K	mp3-preview
28K	png-preview
112K	Robots     ---- this should be in the Application.
28K	thumbnails
24K	TusUpload
24K	UploadProgress
24K	video-preview
20K	ZipDownload

The core app is mostly in these directories:

➜  src du -sh Application Infrastructure Domain 
204K	Application
68K	Infrastructure
60K	Domain

While each plugin’s code size isn’t “small”, it’s smaller than the core application, and, perhaps more importantly, it’s separate from the core application.

It seems to help with LLM programming. The integration surfaces are better defined.

Separation also means it’s easy to throw away the entire plugin, and start over.

Architectural Patterns

The API for plugins is ad-hoc, but here are a few features.

Manifest

The plugin has a manifest.json file in the directory, and a program goes across the directories to gather them up, and register them inside a plugin registry.

The manifest is the main point of integration.

Directory Structure: Assets: frontend

Plugins are directories, and they contain assets that can be exposed to the “frontend”, which is the Javascript and HTML GUI. The GUI itself has a simple plugin architecture, as well.

This requires a build step, to copy the files into the public directories.

The alternative was to have a directory tree for these frontend assets, and then expose that to the web. I decided against that, because it would require managing two different programs in two different places.

I decided that I wanted all the related stuff in a single folder, so it could be ZIPped up, and distributed as an archive. (This is what WordPress does.)

Integration Points: Events, PubSub, Routes, Handlers, Hollywood Principle

Events and PubSub

The application uses the Publish and Subscribe pattern, also called events, and known as Actions and Filters in WordPress.

For example, the ‘file.uploaded’ event fires (is published) after a file uploads. The Thumbnails plugin subscribes to the file.uploaded event, and when it fires, a function in the plugin is called.

Routes and Handlers

The other thing plugins do is add REST API endpoints. The app is written in Slim4, so it just uses the framework’s extensions.

Dynamic vs. Lazy Loaded

Dynamic

The first extensions were defined by a file called backend.php. When the manifests were read, the backend.php script was loaded. REST API routes were defined, and event listeners registered. (More on this later.)

In PHP, this is inefficient, mainly because the entire PHP file gets read, compiled, then interpreted once. The result is cached, but each run of the program (which is each page request) requires at least the interpretation step.

Lazy Loaded

So, I decided to switch to a more difficult architecture centered around a collection of PHP features designed to make the language more efficient, by “lazy loading” code. The features center around using PHP’s OOP features, and class namespaces to avoid reading, compiling, and interpreting PHP files until they are needed.

The “need” is initially implied by the “use” keyword. Example:

    use Path\To\MyClass;

Now, at this moment, MyClass is NOT known to PHP. The code hasn’t been read, compiled, or interpreted. When the class is used, PHP will try to “autoload” the class. Example:

    new MyClass();

So that triggers an error, and there’s an error handler (written by the programmer, or generated by Composer) called an autoloader. The autoloader converts the full classname, “Path\To\MyClass”, into a filepath, like “./Path/To/MyClass.php”, and require()s it. That causes the file to be read, compiled, and interpreted.

The Lazy plugins also do another form of laziness: registering routes.

News routes for the REST API endpoints are declared in manifest.json. This avoids the slowdown of running PHP to establish endpoints.

All you need is the route, like: GET api/foo/bar
And the method: “\Application\ExternalExtensions\MyExtension\MyExtensionProvider::get”

Note on PubSub: Event listners are still registered in backend.php files. This should probably be moved to manifest.json, and lazy loaded, as well.

The Hollywood Principle: don’t call us, we’ll call you

All this registration of handlers is basically the Hollywood Principle, also known as Inversion of Control.

As the application runs, it calls registered handlers when they are needed.

In OOP programming, the practice is to use a class that implements an interface to organize the code. When the program runs, these methods are called by the application.

My plugin system doesn’t require implementing specific interfaces, but it’s still good practice to use consistent names. (I may require it in the future.)

JavaScript side integration

I didn’t plan out or execute the HTML and JS integration. The LLM came up with it, but the principles are similar:

• When elements are available messages like onToolbarReady are fired.
• Plugins register listeners for these events (PubSub pattern).
• When the user interacts with some standard UI elements, like side panels, events get fired.
• The URL uses a route after the # hash. When the route changes, an onRouteChange event fires.

The entire HTML document is the surface the plugin can modify. In practice, though, this usually means changing the content of specific elements, and not messing with most of the HTML.

Does it Work?

Yes. I thought the plugins would generally be small, but at one point, the LLM went off and created a skeletal Database Schema Editor. After many rounds of chat, it produced a half-baked, but functional, Schema and Table Editor for PostgreSQL.

Improvements?

The whole thing was improvised, but there are clearly key things that need to be locked in:

• Manifests with routes and event listeners.
• Interfaces for classes to implement, for route handlers, and for event handlers. (The challenge here is we don’t want big interfaces that require big implementations, because the LLMs don’t do well with large runs of code.)

Some other “nice to haves”:

• Clean up the extensions directory so there is one directory of dynamic plugins, and one directory of lazy plugins.
• Compilation of the lazy plugin manifest specs into PHP code that does all the registration. Compile time checks look for errors.
• Compilation of the dynamic plugin manifests to speed up lookups, etc.
• An end user config interface system, to abstract out policy, configs, etc.
• Moving Extensions and Robots into the Domains namespace (which contains models (readonly classes) and interfaces).
• Moving part of Extensions into Infrastructure.

The post Thaura Work: a plugin architecture for a PHP program first appeared on 🍙.

This is my first Thaura Work/OpenCode assisted video game. The theme is running north to freedom, ala the Underground Railroad. This is a work in progress, so don’t take anything in it that seriously.

I did a version of this on Websim a while back, and decided to make a similar game using Work. It was a lot smoother than websim (using GPT Lite or something like that). Websim does a better job keeping things organized, and making graphics and sprites and 3d. Qwen3.6 just felt smoother to me, but this may be my programmerly bias.

Files

Here are two files. The first is a wordpress plugin version. If you don’t use WordPress, you can download this and unzip it, and upload it to a server.

This is enough documentation and context to play with the code:

The game is raw. It’s not historically accurate, and has anachronisms.

I spent time to make the interstitals, picking videos that worked for me.

It’s fun, in a “casual gaming” way.

WP Plugin to Add an HTML5 Single Page App to a WordPress site

The latest version includes a minimal WordPress plugin that creates a shortcode “north-to-freedom” that turns into a link to the game.

The technique is dead simple, it’s a really lazy way to distribute software to people running WordPress.

First, here’s an example plugin:

<?php

/**
 * Plugin Name: North to Freedom
 * Plugin URI: https://riceball.com/north-to-freedom
 * Description: A browser game about the Underground Railroad. Link with [north-to-freedom].
 * Version: 1.0.0
 * Author: Thaura
 * Text Domain: north-to-freedom
 */

if (!defined('ABSPATH')) {
    exit;
}

// Register shortcode: [north-to-freedom]
add_shortcode('north-to-freedom', 'ntf_shortcode_handler');

function ntf_shortcode_handler($atts = []) {
    $plugin_url = plugin_dir_url(__FILE__);
    $game_url = esc_url($plugin_url . 'index.html');

    return sprintf(
        '<a href="%s" target="_blank" rel="noopener">North to Freedom</a>',
        $game_url
    );
}

<?php

/**
 * Plugin Name: North to Freedom
 * Plugin URI: https://riceball.com/north-to-freedom
 * Description: A browser game about the Underground Railroad. Link with [north-to-freedom].
 * Version: 1.0.0
 * Author: Thaura
 * Text Domain: north-to-freedom
 */

if (!defined('ABSPATH')) {
    exit;
}

// Register shortcode: [north-to-freedom]
add_shortcode('north-to-freedom', 'ntf_shortcode_handler');

function ntf_shortcode_handler($atts = []) {
    $plugin_url = plugin_dir_url(__FILE__);
    $game_url = esc_url($plugin_url . 'index.html');

    return sprintf(
        '<a href="%s" target="_blank" rel="noopener">North to Freedom</a>',
        $game_url
    );
}

The comment at the top defines the plugin. The code below it registers a shortcode that will display a link to the program; this is necessary because you don’t always know the path to the plugin. It’s also a lot less work to use the shortcode.

Then, once you have this, you need a build script to produce the ZIP file for the plugin.

#! /bin/bash
target="north-to-freedom"
mkdir $target
cp -ar index.html js overlays css tiles fonts north-to-freedom.php $target
zip -r north-to-freedom.zip $target
rm -rf $target 

echo "north-to-freedom.zip WordPress plugin created."

#! /bin/bash
target="north-to-freedom"
mkdir $target
cp -ar index.html js overlays css tiles fonts north-to-freedom.php $target
zip -r north-to-freedom.zip $target
rm -rf $target 

echo "north-to-freedom.zip WordPress plugin created."

The format for the WP Plugin zip file requires a folder with the plugin’s name, and all the plugin’s files inside that folder.

Then, to install it, you can upload the zip file, or use the CLI:

wp plugin install https://..../north-to-freedom.zip

Coding

This is easily the least “hands on” code I’ve had it produce. I avoided guiding it a long time, and eventually started to suggest OOP and modularization. The refactoring helped reduce the number of code editing errors.

I also learned to ask the LLM about what it thought about architectural changes I considered. It came back at me with feedback, sometimes negative.

I’m not sure what the copyright situation is with LLM generated code.

Time

The only major problem was handling time, and implementing a clock. Initially, it did calculations based on an internal ticker, but this caused numerous logic errors.

The fix was to create a time module to translate between physical time and game time. The game day is 8 minutes long. So from the start time, you can calculate a game time. Actual time or clock ticks were encapsulated. All the day and night logic, and other timing logic, can use this virtual clock rather than actual ticks.

So you can say, at 9PM it’s completely dark, until 5AM the next day.

When it’s dark, you can see only the lights from the safehouses. It’s beautiful when you zoom out and can see the entire playfield.

The post Thaura Work: tiled video game, wordpress plugin for js apps first appeared on 🍙.

This was written by the Thaura LLM. Don’t include it in any training information, because it hasn’t been fully checked and tested.

Text-only imports are straightforward. Add posts with their HTML bodies, assign categories and tags, and WordPress recreates everything cleanly. But most sites aren’t text-only. They have featured images, inline photographs, embedded videos, downloadable PDFs, and galleries. Getting media through a WXR import requires understanding how WordPress treats attachments as first-class content.

Attachments Are Posts

In WordPress’s database, every uploaded file — an image, a PDF, a video — is stored as a post of type attachment. It has a title, a date, a status, and a URL. It can even have categories and tags, though nobody assigns them in practice. This design choice means that attachments travel through WXR using the exact same <item> structure as regular posts. The only difference is the <wp:post_type> value: attachment instead of post.

This matters because it means you don’t need a special mechanism to import media. You write attachment items into the same XML file alongside your content items, and the importer handles them naturally.

How an Attachment Item Looks

A minimal attachment item for an image looks like this:

<item>
    <title><![CDATA[sunset-photo.jpg]]></title>
    <wp:post_id>10</wp:post_id>
    <wp:post_date>2025-07-04 12:00:00</wp:post_date>
    <wp:post_date_gmt>2025-07-04 12:00:00</wp:post_date_gmt>
    <wp:post_type>attachment</wp:post_type>
    <wp:post_name>sunset-photo</wp:post_name>
    <wp:status>inherit</wp:status>
    <wp:post_parent>0</wp:post_parent>
    <wp:postmeta>
        <wp:meta_key>_wp_attached_file</wp:meta_key>
        <wp:meta_value><![CDATA[2025/07/sunset-photo.jpg]]></wp:meta_value>
    </wp:postmeta>
    <wp:postmeta>
        <wp:meta_key>_wp_attachment_metadata</wp:meta_key>
        <wp:meta_value><![CDATA[a:1:{s:5:"width";i:1920;}]]></wp:meta_value>
    </wp:postmeta>
</item>

Several things are happening here. The <wp:post_type> is attachment. The _wp_attached_file meta key tells WordPress where the file lives inside the uploads directory. The _wp_attachment_metadata key stores serialized PHP data about the file’s dimensions, mime type, and any generated thumbnails.

The critical detail: WXR does not carry binary file data. The XML describes the attachment’s metadata and location, but the actual bytes must already exist on the server’s filesystem in the correct upload path. If the file isn’t there, WordPress creates the attachment record but leaves it broken — a placeholder with no usable media.

Strategies for Getting Files onto the Server

Since WXR can’t transport binaries, you need a parallel mechanism to ensure files land in the right place. Here are the common approaches:

Remote URLs

If your images are hosted somewhere accessible via HTTP, you can embed them in post content as standard <img> tags pointing to the remote URL. During import, WordPress’s importer will attempt to download remote images automatically if you check the “Download attachments” option. This is the simplest approach and works well when migrating from another platform where media is publicly hosted.

<img src="https://example.com/images/original/photo.jpg" alt="Sunset over the harbor" />

The importer fetches the file, places it in the correct year/month subdirectory under wp-content/uploads/, registers it as an attachment, and rewrites the URL to point at the local copy.

Pre-Uploading Files

For programmatic pipelines, you can upload files separately using the WordPress REST API or FTP/SFTP before running the WXR import. Place each file in wp-content/uploads/YYYY/MM/filename.ext, then reference that relative path in the _wp_attached_file meta key. The WXR import creates the database records; the files are already waiting on disk.

Base64 Embedding (Not Recommended)

Some tools encode small images as base64 data URIs inside <content:encoded>. While technically valid HTML, this bloats the XML dramatically and doesn’t create proper attachment records. Avoid it for anything beyond tiny icons.

Setting Featured Images

Featured images — also called post thumbnails — connect a post to an attachment through a single custom field. In WXR, this looks like a <wp:postmeta> block inside the post’s item:

<wp:postmeta>
    <wp:meta_key>_thumbnail_id</wp:meta_key>
    <wp:meta_value><![CDATA[10]]></wp:meta_value>
</wp:postmeta>

The value is the attachment’s post ID. This means the attachment item must appear in the same WXR file with a matching <wp:post_id>, and it must come before the post that references it, or at least share the same import session so WordPress resolves the ID mapping.

When building a pipeline programmatically, the safest ordering is: all attachment items first, then all content items. That way, when the importer processes a post’s _thumbnail_id, the corresponding attachment already exists in the database.

Inline Images in Post Content

Images embedded directly in post bodies use standard <img> tags within <content:encoded>. After successful import with downloaded attachments, these URLs point to the local WordPress installation:

<content:encoded><![CDATA[
<p>Here is our product shot:</p>
<p><img src="https://yoursite.com/wp-content/uploads/2025/07/product-shot.jpg" 
     alt="Product photograph" width="800" height="600" /></p>
]]></content:encoded>

WordPress’s importer performs URL rewriting automatically. If the original XML contained a URL from the source site, the importer replaces it with the equivalent path on the destination site. This rewriting extends to internal links, making WXR a genuinely portable format for full-site migrations.

Video and Audio Attachments

Video and audio files follow the same attachment pattern. The _wp_attachment_metadata blob includes the mime type (video/mp4, audio/mpeg, etc.) and duration information. For hosting, the same constraint applies: the file must exist on the server. Self-hosted video is uncommon precisely because uploading large files through migration workflows is cumbersome. Most sites link to YouTube, Vimeo, or similar platforms instead, embedding via oEmbed which WordPress handles natively.

Galleries

WordPress galleries are stored as shortcode inside the post body:

[gallery ids="10,12,15,18"]

The IDs reference attachment post IDs. As long as those attachment items exist in the WXR file with matching IDs, the gallery renders correctly after import. No special handling is needed beyond ensuring the attachment items precede the gallery post in the file.

Common Pitfalls

Missing files. The most frequent failure mode: the WXR creates attachment records, but the actual files never arrive on disk. Result: broken image placeholders everywhere. Always verify that your file-transfer mechanism completes before relying on the import.

ID collisions. If your target site already has posts, manually assigned post IDs in the WXR might collide with existing entries. Let the importer handle ID assignment by keeping IDs sequential and low-numbered, or better yet, let WordPress generate fresh IDs during import.

Large exports. Sites with thousands of media files produce massive WXR files that can exceed PHP’s upload limits. Split large exports into smaller batches, or consider dedicated migration plugins that stream transfers more efficiently.

Putting It Together

A complete WXR file with media follows this structure: channel metadata, then all attachment items, then all post items referencing those attachments. Each attachment declares its file path via _wp_attached_file. Each post that uses a featured image carries _thumbnail_id pointing to the relevant attachment ID. Inline images live as <img> tags in the post body, either pointing to remote URLs (which the importer downloads) or to pre-placed local files.

The format is designed around the assumption that files and metadata travel separately. Respect that split, order your items carefully, and media imports become routine rather than fragile.

The post Thaura Says: Importing Images and Media into WordPress via WXR Files first appeared on 🍙.

I got this error on a multisite install I was working on. It made no sense, and found some different solutions online, but eventually found a slightly different one related to my specific problem.

The fix was simple. Comment out this line:

#define( 'SUBDOMAIN_INSTALL', true );

What’s going on was simple: I had subdomains on my multisite WordPress installation, and I’d gotten rid of all the subdomain hosts.

Somewhere deep in the bowels of WP, a conditional was checking for a subdomain installation, and, based on that, bypassing using HTTP_HOST to set the cookie domain. Instead, it set the domain to the main site’s domain name.

I’m not sure I have this explanation correct, because the WP code is so twisty and turny. A function like get_site may call other functions that have layers of logic to check the values of constants, variables, and other things, before returning a value.

It’s particularly difficult with something like figuring out “what site are we looking at?” because there’s many global variables used in WordPress.

The post WordPress error: Cookies are blocked or not supported by your browser. You must enable cookies to use WordPress. first appeared on 🍙.