Open thegulshankumar opened 4 years ago
thegulshankumar
commented
4 years ago @leonstafford Update: I also tested on Linux machine with version. Same issues.
Clicking Delete button doesn't clear this directory.
/var/www/wordpress/wp-content/uploads/static-html-output
tomwalkr
commented
3 years ago Also ran into this - tried to delete a post, it refused to remove it from the site, or to empty the cache. First thought was a problem with static-html-output directory permissions, but can't get it to work even when world-writable.
tomwalkr
commented
3 years ago I'd also note that this is a bigger problem that it first appears, as it means that all a site's deleted posts remain published, silently, until you notice the issue.
diegoteliz
commented
3 years ago Same problem here... and as mentioned by @tomwalkr this is not a minor issue...
leonstafford
commented
3 years ago Thanks for reporting @diegoteliz and those from last year.
Couple of things to clarify here:
/wp-content/uploads/static-html-output (I will need to check code to confirm)Why it hasn't been a feature?
This probably comes down to my original preferences, where I didn't really care about any orphaned files left on a deployed site, as long as the actual site rendered fine. In the case of Bunny, if I really wanted to force reset the deployed site to remove any remnants, I could do via their UI/FTP, bulk delete the storage zone's contents and then publish again.
Obviously, from this issue (and some other mentions I recall over the years), it is a desired behaviour for users.
To help inform me for developing this feature out properly in this and WP2Static, could you please share me the main reasons for this and how you would expect it to behave?
One way it can function for some vendors, is to grab a list of all files in storage container, iterate them all, see if intended deployment file exists and (where applicable) has different hash. If option to delete files not within this deployment is enabled, it will delete those as needed and deploy the expected ones.
In Static HTML Output, this may be trivially possible (feels like I did something similar with an old GitLab deployment implementation, at least the file traversal part). In WP2Static, where this project's best parts will eventually migrate to into, we have other features which make this challenging to implement, such as partial deployments (deploy just a a post and it's linked assets when it changes, deploying only files changed since last deployment).
What would be terrible, is to end up with a partially working site due to trying to be too clever about what to deploy and delete, so I'm hesistant to rush into this implementation.
I suggest as a workaround for those finding this important to cleanup orphaned files, to choose a low traffic time for their site and delete everything in the site's storage container, then re-deploy, so you'll only have the latest full working site.
Please do let me know as much about your intended workflow re this issue to better inform my development.
tomwalkr
commented
3 years ago In my case the workflow was that we sometimes want to delete/unpublish a post from the site, either temporarily or permanently.
What we expected to happen is that the static HTML deployment would 'mirror' the current state of the Wordpress install. What happened is that the new publish (this was to Netlify in my case) included all posts, the new ones and the deleted ones.
I expected that clearing the cache would fix this because it would force the plugin to re-spider the whole site, but that does not fix it. For my purposes at least it is not really helpful to have any cache - I would prefer to start 'fresh' each time to know that the static version of the site exactly matches the current state of the site.
diegoteliz
commented
3 years ago Thanks @leonstafford for clarifying the expected behavior of 'Delete Deploy Cache' feature.
In regards to deleting files when deploying, I see it as a 'must have' rather than a 'nice to have' feature. As @tomwalkr mentioned, I would expect Static HTML or WP2Static to mirror the site after I press the "Start static site export" button. For certain pages like Sales, Promos, etc. you really want to have control over what's published and what is not. Same for other temporary or outdated content.
In terms of the solution itself, I don't think it should be overly complicated. To me, it's a matter of implementing an additional checkbox on the Deploying screen (disabled by default) asking if you want to ☐ Perform a clean export, alongside with a brief description about what will happen and what to expect (longer deploying time compared to partial deployment, site will be off while copying the files, etc). So when the option is selected and you press the export button, the plugin would:
As you can see, point number 2 is almost what you suggested as workaround, but automated within the plugin. The reason why some of us need this feature and can't go with your suggestion is because, although we (devs) build the site, the ones that use it and update it on regular bases aren't always tech-savvies, so you wouldn't expect them to connect to the server storage and manually delete files (after all, that's the main reason why they're using a CMS like WordPress). So the more we can automate it for them, the better.
I know this is not the most clever solution, but I'm pretty confident it should be relatively easy to implement, can be integrated in both; Static HTML / WP2Static and will satisfy the majority of us who need this feature :)
In any case, thanks for asking for our opinion and for taking time aside from your busy agenda. Keep up the great work!
Symptoms
This means, files are not deleting. As well as LIVE I checked by going to C:\xampp\htdocs\site1\wp-content\uploads directory, it doesn't delete.