elementor
Deployment to another folder?
I guess it’s simple to do — it’d be very useful to have a deployment add-on that would deploy the static site to another folder on the same server, which could be very fast.
@twardoch - nothing makes me happier than seeing a new contributed addon! Many thanks! Will bring it into the mix with the others when I next sit down properly with pushing out new releases.
I should also mention, you can totally keep this as your own thing - charge $ for it, etc. No need to decide now, anyway
No no — I’ll happily hand it off. It was my first WordPress plugin and pretty much the 2nd or 3rd time I’ve done anything in PHP lately, but I’m usually lost in the woods (although I must say — I’ve always maintained that the PHP documentation is the best that ever is, the mix of the core spec with the user-contributed notes is unparalleled).
So feel free to fork and, well, not sure what would be the best way to make your fork upstream. Perhaps I’d just remove my repo, and then I’d fork yours. After all, my repo is a fork of your S3 anyway, and I heavily re-used the code from there!
Awesome, thanks again!
If you like complete documentation, it's just one of the core features of OpenBSD operating system - my favourite OS, but currently mainlining macOS due to Docker requirements...
I've created a new repo and started some renaming to Directory Deployment.
I put as both as authors in the composer.json - not sure if that's possible in the PHP Doc Comment's @author tags, but I won't forget who wrote it and can add in a few other places!
I haven't built/tested it yet, so likely a few more places to rename, then there was the TBC CLI options, if you'd like to fork from that repo now for future changes.
One Q: does the rmdir() work? I recall PHP's native methods not handling removing non-empty directories
oh and removed the install instructions from README for now, we should add to wp2static.com (and more complete instructions for the repo, as can do via manual git clone or via packagist, etc) - I'll invite you to that repo in case it's still private for whatever reason.
rrmdir and xcopy are functions, provided by the community and included in the Deployer. Both are recursive :) My whole code is copy-paste programming 😀
I'll remove the release thing.
Ps. I think the "copy extra stuff from another folder" could be part of every post-processor/Deployer. It’s very useful — sometimes you want to include a custom .htaccess or some extra images or whatever extra static files for which you have a link in the WP but which are not built by WP nor then by wp2static. I made it as a very simple thing — basically it now all works on https://blog.fontlab.com/ , which is now the static site while the WP site is now password-protected and is only used for publishing.
100%!
I'm sure the additional includes/excludes stuff isn't working now besides via programmatic filters. It's a bit challenging to present via UI to the user. Would be cool to have some visual file browser, like those ones you add/remove between the sides.
IIRC, excludes should come first, so can exclude whole dir, then includes, to force one file from an excluded dir to be included....
Altogether, wp2static a superbly handy system.
- WordPress is excellent for CMS, product pages — anything you want to build visually.
- Comments/discussions etc. can be better done with an external service that works just as well with statics.
- Same goes for search: we use simple Google Search to search across all our sub-sites
- Store — well, we’re remodeling it right now, but again, I’ve opted for an external service to guarantee uptime. Same for a support site etc.
I don’t want to be bothered with speed & security issues around a full-blown WP site. I consider it kind of passé. :) Dedicated service providers for various aspects of a business is actually way better if you run a small biz like FontLab. And I’m already seeing great relief on our web server since I’ve deployed the wp2static-made site. So — thank you once again!
I think a simple "copy over" will work in most cases. Ideally, it should be "merge" (for folders), I need to check what the xcopy function does. This is also how I deploy some other sites like https://fontlab.com/ — this is done in Webflow and deployed as a static, and I have a simple extra folder for "permanent" files like .htaccess that I merge into what comes out of Webflow.
I can manage "exclusions" in WordPress, I think. I mean, the general idea for wp2static, in my view, is that I can take everything that’s made in WP and make it static — but then I can make "override copies" of some of the assets for whatever reasons. I can manage the rest with something like .htaccess (like extra redirects etc.). So it’s fine.
Anything else becomes complex, I think. So it sort of gets you where WordPress is — too complex :) I’m sure some people would want more control, but the ability to merge one set of external statics into the post-processed site is just enough for 99% (while not having it certainly affects some 20% of users who might benefit from it).
For example I have some old results from tag etc. showing up in the Google search but I can eliminate them easily with 301 redirects in .htaccess. Not a problem, Google will learn this. :)
Because of how wp2static works, I’ve decided to eliminate the over the top stuff like tags from our WP website, to have as few URLs as I can. But all that should be up to the web developer. If I really want some magic, I’d write some extra code myself that I can run after deployment. If I deploy to GH pages, well, there are Github Actions that can do other things. I like that wp2static is simple. I only thought of the "post-processing merge from a static extra folder" as a very thin extra step that solves many limitations of what the core wp2static gives me.
I’d even say: the "Directory Deployment" method could become the primary one — because after that, any code can take over. Deployment to GH pages, S3, ZIP etc. is nice for sure, but these steps can be done using different code. But OK, I’ve custom-tailored it to my own needs anyway, other folks may have other prefs. But I intentionally kept it simple!
Well, that sounds like a great case study! Want to be the first in a new Case Studies section on the site? Should be some crossover in users who'd be interested in Fontlab's offerings, too!
Yep, I was about to offer some case study as well :) I’ll gladly write some notes, also about which plugins I’ve ended up using vs. discarding on the website (e.g. for minification). Quite a few security of optimization techniques become obsolete with wp2static and even interfere with it (for example extensive caching). I’ll happily share what I learned. Of course my blog.fontlab.com site could be optimized even much further — but for that, there are other techniques :)
Heh, I’ve decided to dump the separate blog site. At FontLab, we use Webflow to design the graphically-intense product pages, and I realize Webflow makes a WordPress plugin where you can import the Webflow pages as WordPress pages. So I get the Webflow-made static pages that appear as WordPress pages, and then I have additional WordPress-made pages that are a bit more schematic and lightweight.
And then everything gets exported with wp2static. It’s very cool! So I now deploy everything onto just the main site. Pages like this:
- https://www.fontlab.com/
- https://www.fontlab.com/font-editor/fontlab/
- https://www.fontlab.com/about/
are made in Webflow and then come to WordPress via Webflow’s plugin, and then pages like:
- https://www.fontlab.com/terms/
- https://www.fontlab.com/news/fontlab-72-dec-2020/
are done with WordPress (using a theme that is pretty old now).
I realize that one can use WordPress to make very graphically intense pages, but our team is more comfortable with the explicit HTML control one gets in Webflow. But on the other hand, Webflow gets tedious when you add really many pages, and the supporting pages that should be more template-driven, there WordPress is great.
So overall, this is now a very smooth process and very easy to use for us.
And the extra bit is: previously, we were deploying the Webflow-made pages kind of manually, and I did make a "patch over" folder which got merged into whatever Webflow generated. And since I did implement the same functionality in my "directory" wp2static deployer, I just use the same "patch over" folder there. This is really neat, I have full control over the URLs and the assets combined with the flexibility of both Webflow and WordPress GUIs. Great!
@leonstafford TODO:
- test and release new addon
- put case study up on wp2static.com for Adam's approval