Packaging HTMXPress based plugin as a single zip

[jasalt]

Thinking how to package a plugin leveraging HTMXPress as a single installable zip that could be sent to client (or eventually to plugin directory).

Here is a quick proof of concept version, simply loading the main htmxpress repo as submodule under htmxpress-serverside-block, requiring it in htmx-server-block.php::17 and removing the nested plugin header comments from htmxpress.php::2 that otherwise give a warning on install.

Sources (including a couple other fixes separated in fix-1 branch): https://github.com/jasalt/htmxpress-serverside-block/tree/standalone-test

It does not take into account if there are multiple similar plugins installed (each would try to load htmxpress.php etc), but it should be quite straightforward to update and maintain this way as a single plugin for a single site. The zip also has .git and other development related files. I'll probably update on this as I experiment more. All kind of comments are welcome.

Steps

Building

git clone https://github.com/jasalt/htmxpress-serverside-block.git
# or git clone git@github.com:jasalt/htmxpress-serverside-block.git

cd htmxpress-serverside-block
git checkout standalone-test
git submodule init && git submodule update
npm install && npm run build

Packaging

# Remove nested plugin header in htmxpress to fix a (non-breaking) warning "The plugin does not have a valid header." during activation.
# (GPT-3): with awk, remove first section in file between `/*` and `*/` from file htmxpress/htmxpress.php

awk '/\/\*/,/\*\//{next} 1' htmxpress/htmxpress.php > temp_file && mv temp_file htmxpress/htmxpress.php

zip -r ../htmxpress-serverside-block-standalone-test.zip ./* -x "*node_modules/*"

Creates a single plugin zip (example) in parent folder that can be installed on WordPress and works on fresh installation after permalink setting changed from "Plain" to something else (cause of current issue).

[svandragt]

Hey jasalt thanks for the brainstorming. I think the current setup of HTMXpress as a plug-in requirement is fine for now. and it being difficult to ship something relying on it, is actually a feature. This is because it’s not production ready, and I wouldn’t recommend shipping something to the plug-in directory with it.

IIRC the directory team were looking into specifying plug-in dependencies in the plug-in header and notifying the user in the admin so they can one click install it. That might be the way to go.

Also it should be possible to add a function exists check before bootstrapping in the plug-in. However it would move the burden to support backwards compatibility to the implementer as you can’t guarantee the version that’s already loaded is a current one. So that’s a worse idea.

[svandragt]

Also you could look at a composer based workflow as it allows you to set up requirements in composer.json. On a project level that could manage the plug-in and any plugins or themes relying on it.

[jasalt]

Thank's for input. Yes, definitely needs to be tested further in many aspects before releasing something out for wider public.

Comparing to earlier git submodule idea in my case, I think Composer would probably benefit when having multiple PHP dependencies.