Couple of weeks I did not worked on my Rapidweaver project. Just now wanted to add new pages and before made the latest updates (Stack 4). I’m using Foundry.
After the update when I opened my project I noticed that ALL my pictures from the existing pages disappeared. I looked that this topic has been here very often but could not find a solution.
What I have to do? Now when adding new pages and then Publish, will all pictured be removed from the live site? I hope that the only solution is not that I have to add man tally all pictures again (having 40+ pages) in my project.
I always upload any resources to the server and link to them, then it doesn’t matter what happens within RW regarding resources. As I don’t do what you do with the resources, I’m taking a guess that you selected to “Leave in Place” your resources, which means they on your hard drive rather than in the RW project itself. You can check by going to the Advanced settings on the left hand side and seeing what you’ve selected there.
If you have “Copy into the document” selected, I can’t see why you have this issue.
Yes indeed I have Copy into the document selected by me. What are my options & action in this case. This was always on Copy into the document, I never used Leave in place…and had now issues until the last update…
The project is on my Mac…I tried Norton antivirus, but had problems with the sync of my Dropbox so remove it…maybe that could be the problem? I do not have a TimeMachine…will look for a back up file…In case I do not have what I can do? Add all pictures on the server and then manually add them in the project as warehouse pictures?
I found an older copy and also start checking the latest saved file from the project…no difference and further when checking page by page, on some page all the pictures are there and on other not, while both pages have been made with the same combination of stacks.
Normally the already created pages will not change (maybe only some links)…Only new pages with new information/pictures will be added. I would like to know whether if now I push to publish my project with a new page/information, whether the pictures which are missing on the pages in the project opened in Rapidweaver will be also missing on the live site, since now all pictures are visible on the live site? So now based on the replies I will get I have to 1st adapt all missing pictures before adding a new page and Publishing OR if there will be NO impact on the old(existing pictures) then I can add the new pages and just Publish…
You can set how often it uploads, Plus you can download via FTP or just use the download button. I also archive my project names. Some projects I’m working on for 4 months (they are course websites). So I typically rename every 2 weeks or so with a new date. For example, myclass-2020-12-15.rw which is different from myclass-2020-12-01.rw. Both of them are then uploaded to my server area as backups.
Bottom line: this missing resources issue is crazy. I don’t know exactly why it happens but it has been happening to folks for awhile now (i.e. more than 1 or 2 years). But learning how to put your resources directly on your server (e.g. in a folder named “myresources”) makes your RW project file much smaller and protects against this issue. It “shouldn’t” happen … but does for some unknown reason (to me). If it only happened when resources were “leave in place” per @Fuellemann then that would explain it all. But it also happens even with “copy into document” is selected. Weird.
@Mathew Thanks for your detailed reply. I will definitely check and try to use to upload backup…and I will put all images on the server (have enough place) and will use then via warehousing…It’s more work then just drag & drop, but maybe is better…
The project file is now 184MB…it was bigger before but I did not looked at it and had no issues during publishing…
If there is another way to have back the images of course I will take it @dan? If it’s necessary I can also send the project file…
@Balmidor While we don’t seem to know what creates this problem … another theory is that it happens more often when the project file is in a synced folder (e.g. Dropbox or iCloud). This syncing does not impact most folks, but your file size of 184 mb is relatively large. Is the file in a Dropbox or iCloud or other syncing folder?
@Mathew the project file is on the MAC HD not on a sync folder from Dropbox. Anyway each problems shows better ways to work for the future in order to avoid problems, so I will start page per page to add picture on the server and from there to link them in the project as warehouse image…takes time but it’s maybe the best way…
and is still possible to publish only any new page that I have to add to the project at least until the whole project pages are OK.
The good point is that the live site is OK and all images are there…
I have used the built-in resources in RapidWeaver 8 extensively, even done a bunch of stress testing and have never seen an issue.
In fact, the revamped RW8’s built-in resources used more by most RapidWeaver users.
All the following use the re-engineered RW8 resources:
Any image dragged and dropped on a stacks 4 page (the new default image stack- the site image stack)
Any of the new theme banners
any image dragged onto a styled text page (probably the most used plugin)
any image on the built-in blog page
etc, etc, etc
So there’s probably millions upon millions of resources being used every day that are working problem free. So I think declaring that you shouldn’t use the resource manger just because a few people have had issues with it is a bit premature.
If you viewed Isaiah’s talk on last year’s Weaver Summit where he talked about the technical differences between how the site image stack using RW8 resources and the other methods work, then you’d probably think differently about resources.
The speed difference between the old stacks image stack, the new site image stack, and warehoused images is close to unbelievable. The new site image stack is the hands-down winner. In edit mode, it’s close to instantaneous in responsiveness. No jumping or slow scrolling. The images are actually queuing in memory. And previews are much faster as well.
Now that’s it for my pro resources speech, let’s talk about the project and the problem.
What image stack are you using?
If it’s the standard Foundry image stacks (where you drop an image into the stacks sidebar) then you aren’t using the updated RW8 resources. If you drag an item into the sidebar, the stack’s plugin stores the item for you. So I don’t think @dan could help you out much. It would be more of a @isaiah thing to look at.
You can tell this by dragging an item into the image stack you are using and then checking the Resources window, and you won’t find the image.
So responses given about site resources like “Copy into document” wouldn’t apply. This option is strictly for the Site Resources.
It really sounds like you have a corrupted project file. It’s so important to use some sort of incremental backup process like TimeMachine. Here it appears you have lost images. Next time something else can happen that makes any file on a computer unuseable.
Working without a backup is never a good practice. They build TimeMachine into your macOS and the costs of USB drives are cheap.
@teefers Thank you very much for your time to reply. Really appreciate, since most probably you hear mane of the questions very often and still you take the time to reply in details. For the users like me who are just users I have any IT background at all your support is very important. So thanks again.
I started 2 years ago with RW + Stacks 3 and all packs from Foundry, now updated with the Foundry 2 and Stacks 4. The drag & drop function was really one of the options that push me to start with RW.
I had no issues until now and I made copies of my project file on a USB stick, but as I said the issue is the same on my “old” file.
I’m using all available image stack from Foundry (Display, Backdrop, PopUp Gallery, Lazy Load Image, Image and also Joe’s Impact stack). On some pages I tried and worked with a warehouse image but it’s easier to drag & drop image on the page. To be honest I never looked at the Resources window to check whether each image is there (sometime since I have a lot of images is better to take it from the HD on the Mac and drop it then to scroll in the Resources to find it…I know is not the best practice…
I put the question just to know what is the best option for a user like me in this kind of situation. My live site is working and has all pictures (my last publishing was 2-3 months ago), so I just want to follow the action steps, which will allow me to be able still to add new pages and/or adapt existing pages without loosing all images when I push the Publish button, because if I understood it well if I push now Publish button with pages where there are no images (in the RW project) those images will be then removed from the live site too after the Publishing, correct?
As proposed above I can publish ONLY the new pages, not the whole project, which is a plus…So I can make time to prepare the file before be ready to publish again the whole project and that’s why wanted to have your expert opinion what’s the best action to do…Of course the idea is when making the adaptation not to get the same issue next time when there is again an update…
RW does not delete files on the server. Even if you remove an image from the page, the image is not removed from the server. Even if you delete a page in RW, it is not removed from the server.
You may still have an issue publishing existing pages if one of the updates (RW or Stacks) changed the link to the image in the HTML. If that’s the case, the image will still be on the server, but the link will be wrong, so the image won’t load.
You could try right-clicking on a page with missing images and select the “Publish Page” option. That will publish that page only. You can then check the live site. If the images are missing on that page, then you’d have to fix that page and re-publish it, but at least it’s only one page versus all of them that is temporarily missing images on the live site.