If you are publishing a site (via sftp) and the system determines that there is a problem with the connection and aborts the publishing it can create incomplete images if it was attempting to transfer one when it aborted. The system will assume that the image has been successfully published even though it has broken it and there is no easy way to get the system to recreate the image and publish it again. This may be associated with the gallery object since that is where I largely use images that have broken (and both the image and thumbnail are broken) but this will impact the image if it is also used elsewhere when only a single copy exists in the resources.
An example of the problem. This is not a camera/memory card issue. This image was created from a RAW file in DxO PhotoLab and the JPG image on disk and in Elements is fine.
Yes you can force a complete republish of the site but that is inefficient and there is no guarantee that Elements won’t break a different image anyway.
I’m currently using version 1.6.3 which Elements claims is the current release. The Mac is running 15.7.3 and the remote web site is using Debian.
Also if you remove the image from the resources and put it back this doesn’t mark it as changed so that won’t update it.
Old resources in folders aren’t removed from the remote system either so if you do give it a new name in an attempt to make Elements update it you will need to go onto the remote web server to remove the old, broken image.
This is by design. RapidWeaver’s publishing engine is non-destructive, meaning it does not remove/delete files from the web server. This is dangerous territory and it was an intentional decision. Giving an app permissions to remove files/folders from the web server can have negative consequences.
RapidWeaver will only overwrite a file if it has the same name, or add new files with new names (as you said). It will not delete files and this is something that will not change. If you need to delete files, you’ll need to do that using an FTP client, or log into your web hosting control panel >> File Manager and delete the files manually from there.
Let us know if you have any troubles with the above.
Also while Elements should not delete files it didn’t create if I delete something within Elements and publish then it should remove those files. Not doing garbage collection is a crappy design.
Basically, RapidWeaver itself — whether Classic or Elements — has never been able to delete files such as images, Markdown files, or other assets from the server.
You’ve always had to do that manually via a file manager or similar tools. This is a process that still makes complete sense even after all these years — even if some people don’t like or understand it.
In general, it helps to clean up your web space from time to time and then republish all files from your project. That way, you can be sure that only the files actually needed by RapidWeaver are being used.
Regarding your image issue: how large is the image, and which format are you trying to upload?
Again, that’s an indication of a write error. You seem to have narrowed that down to the push to your server. Which means your server is not keeping up with the data push. Under your Publish settings, check to see what the Connections setting is. Slow it down from what it’s set at.
Again it’s a bug, a race condition. One process has decided to give up on the connection and has told the others to stop. The one processing the image has stopped processing the image but then transferred it anyway. There were only two processes so it’s not as if a third has told the others to restart.
