set "Folder" deployment option to just generate and leave in wp-contents/uploads/static-html-output

[leonstafford]

removes a bunch of code, directory is already there. basically everything but the zip from zip deployment

[crstauf]

What's the difference between this and "Subdirectory on current server" deployment option?

[leonstafford]

@crstauf sorry, tried to reply via email last night:

That option allowed to copy the files to a different directory, which is still easy enough to achieve with WP_CLI or we can add a hook.

It's extra code, due to checking the directory is either empty or has been blessed by a special file to avoid users inadvertently overwriting their WP root or such. Less code, less complexity, hopefully less bugs :)

[leonstafford]

have just removed the option altogether and mention on the zip deploy page where the exported path site is within this PR https://github.com/WP2Static/static-html-output-plugin/pull/87

[crstauf]

@leonstafford Clearly I did not understand this when I was asking about it... I personally use the "Folder" option for deploying my portfolio site.

repository: WordPress install └ submodule: /static folder

Deployment is set to the static folder in the root, which I then commit and push to GitHub, which triggers a GitHub Action to deploy to Netlify.

[leonstafford]

@crstauf so you should still be OK with that workflow using the files in wp-content/uploads/static-html-output? You can just ignore the zip for now.

Will likely allow for non-zip deployment, too, but chose to simplify things for now

[crstauf]

@leonstafford Is that something that may come in the next version, or may be a few versions out? I'll probably just sit on 6.6.17 until the "folder" option is restored; I'm a little nervous about moving submodules around (perhaps unnecessarily).

[leonstafford]

@crstauf I'd say a few versions out. It will work just like it does now, with the zip and static files dirs where they are.

Until there's Crawl Caching like in WP2Static project, I don't want to add an additional deployment directory target.

That said, you could also use a post-deploy hook to achieve the same copying of files (can help with this).

How about a symlink on your system the export dir? Should then behave same as prior setup?

[crstauf]

could also use a post-deploy hook

I'll look into this, see what's involved.

How about a symlink on your system the export dir?

Yeah, I briefly thought about a symlink, but I've never been able to get them working quite the way I expect them too; will play with that too.

[crstauf]

@leonstafford Creating a symlink did not work.

$ ln -s /static /wp-content/uploads/static-html-output

Export log is filled with "Failed saving ... to ..." entries.

[crstauf]

Success with post-process action:

add_action( 'statichtmloutput_post_deploy_trigger', function( $archive ) {
    if ( !WP_Filesystem() )
        return;

    global $wp_filesystem;

    $destination = trailingslashit( ABSPATH ) . 'static';
    $wp_filesystem->mkdir( $destination, 0777 );

    $copied = copy_dir( $archive->path, $destination );

    if ( $copied )
        StaticHTMLOutput\Logger::lines( array( sprintf( 'Copied to %s', $destination ) ) );
} );

[leonstafford]

@crstauf beautiful!

I hadn't seen the WP_Filesystem before - looks interesting!

I think you've just made yourself 50% of the first Static HTML Output add-on plugin :D

[crstauf]

@leonstafford I was actually wondering about that... are custom deployment options possible?

[leonstafford]

@crstauf should be, if not, we can add any needed hooks and such to make it so.

There was a cool fork of this by someone, who just hid all the options and made simpler UI.

https://github.com/WP2Static/wp2static was really built from ground-up with aim for extensibility and add-ons, but with this repo's codebase getting tidier, it should also be possible to add in support for other add-ons, really, your code is already doing just that, would only need an option in UI to choose the directory, maybe an option to delete it (scope creep, sorry!).

There was an "in the middle" rebuild between 6.6.7 and /wp2static, which had a very nice UI from @fransallen and ability to override the UI to inject new deployment options in.

Anyway, if you open up your own repo for add-on, I'll help out where needed, including with publishing to wp.org (few things that can be annoying first time).