I never used embed projects in Blocs file originally because last time I used it, it took a while to save and I’m someone who saves constantly! I believe Norm has made it better now since I last used it. The other problem I had was once you embed them all, how do you switch back to normal without relinking all images as I have over 1500.
Either way the linking method works well for me and I have no complaints
That’s insanely large and may even be a Blocs record. Like @Brocky120 I host assets remotely where possible and never embed them in the project file. I have a hundred page site in development and it’s only about 20mb. Most project files are around 2mb, so something is obviously very different with yours.
Regarding the remove duplicate function, depending on the size of the project this can take some time to complete so when you run it, please be patient.
You can upload assets to the server via FTP in a specified folder e.g _images and then bulk import them Asset Manager – Blocs – User Documents. N.B These should be web optimised to ensure fast loading times.
As long as you have disabled the embedding of assets all the weight is basically held on the server and site updates are also much faster because you are only uploading code.
The big question is how many images would need to be re-linked inside Blocs if you disabled the embedded assets. If it’s a few dozen you could have the whole procedure sorted relatively quickly, but if you are looking at thousands it could become more trouble than it is worth.
A further explanation here for why I avoid embedding assets:
If you clear out the embedded assets and host images or video remotely I reckon your new project file will likely be under 2mb and your MBP will be plenty fast enough. For that number of images it wouldn’t be a problem though if you choose to store them locally either.
One good practice is to keep the files on the server and link to them remotely, however it is still advisable to keep a local copy of the same web ready images. On projects with a lot of pages I tend to create sub folders for each page within a general resources folder that is all stored alongside the project file. That’s useful for referencing as well and keeps it all nicely organised.
I’ve come to the conclusion that the feature to package images with the blocs file should only be used to transfer projects and never outside of that use case.
I think it really needs to be made crystal clear about that features purpose and usefulness.
Should Blocs really ever ask you if you want to bundle these things? I don’t think so. It should just be an option you can find and use as needed.
In the past people have got into a lot of trouble because they tried moving blocs files around and then the projects were screwed because blocsapp couldn’t locate resources.
So don’t dismiss the helpfulness too soon of having everything in one file so it can’t be messed up.
I take your point, but surely we should be encouraging good workflow practices. I found it a pain working with embedded assets because you lose the ability with right click to refresh or find in finder.
As I mentioned earlier, I host remotely, but back up locally with the same files. Everything should be accessible within a main project folder, including all project file versions, notes and assets. That way it doesn’t matter where you store the main folder, since the relative positions are maintained, even if you choose not to host remotely. I think the problems occur when users just drag in files randomly from the desktop or an external drive.
Completely disagree here. If you move a project and you want to bundle it should be a concious choice and not a suggestion. especially if the result is what we have now. A disconnect of the actualyly purposefulness of the feature.
Choice is great, but the prompt happens very early and it’s been clearly stated here that it has to be removed misdway through project anyway.
At present the option to embed is preselected when starting a new project and there is a brief explanation if you click the question mark icon, but I think it fails to explain some of the pros and cons.