I’ve used RapidWeaver for years, but want to switch to Blocs for more modern web site construction/code and fewer headaches from certain stacks not generating the correct results in various browsers. Before pulling the trigger, I’ve been using the trial but I cannot get thumbnails/previews to show in the Asset Manager and this makes it rather hard to place images without trial and error. I’m running 4.4 on Big Sur 11.6, and I have read about people having issues on older OS releases, but I see no recent Big Sur issues. Is this a disabled feature of the trial that isn’t listed in the trial limitations?
That sounds strange. What format are the images and how are they being added to the asset manager? I am running the same OS/Blocs combination with no problems.
I think the only known problems with older OS versions might be with High Sierra in certain scenarios. Mojave and Catalina should be fine.
They are JPGs and an MP4. I have also added HEIC and M4V via drag-and-drop from a background Finder window, but have since removed them without any change in behavior of the manager for this project. I have also opened a new project and added only local JPG assets, but I still get no previews/thumbnails for them - I only see the truncated file name in the square tile.
As an aside, being a veteran Mac dev myself, the file type filtering on drag-and-drop is an oversight in Bloc’s code, but I absolutely know that I was bending the rules with unsupported file types. I just mention this in case my actions caused something to go awry with Blocs.
The only odd configuration of my system is that I do not have my user folder on the default data volume. I always keep my user folder separate from the boot volume, and I have continued to do so with macOS 11 out of habit and to make sure I handle directory structure code properly in my own in-house code. What this means is that my user folder sits on another partition, and the Users & Groups system pref points to my relocated home directory using the Advanced Options. I also have a soft symlink in /Users that points to my home folder on the other volume, which has been needed historically because not all devs do the proper thing and ask for the user’s home location before constructing absolute file paths. Devs can make too many assumptions about directory structure, and I have an inkling that my home folder may be related to the thumbnail generation issue.
OK I think I know the issue here because I had it myself a few years ago and still use symlinks for certain purposes. Your user folder and data volume are separated and I believe this causes problems.
It was a while back, so I cannot remember the exact reason but I think it was something related to OS security that was blocking images showing in the asset manager. To cut a long story short I ended up reconfiguring my computer to keep the user data and the OS on the main startup drive then everything worked perfectly. @Norm could clarify the situation here.
Some of those formats you mentioned would not work with Blocs but I think it would simply fail to add or recognise them. Their presence wouldn’t break anything as such.
So I have an update… I’ve been trying to create projects under my primary user in various locations (root and mounted volumes) with no change in asset manager behavior. But I just used a second user that has its home folder on the default data partition (the usual spot) and previews indeed show up. So the user home on another volume is likely the issue, as you also just mentioned while I am posting
Yes that will be the issue and I think this is beyond the control of Blocs. It’s an OS thing. I did this originally at a time when SSD drives were more expensive.
After moving a lot of data to external drives and moving to a more default setting I have to say everything has worked far more smoothly in general. This was all on my old Mac Pro that originally came with SATA drives.
BTW There are quite a few former RW users here, including myself. It takes a bit of adjustment and the biggest challenge is really just accepting that it’s different and not trying to make it work like RW. Once you become familiar with the new workflow you should find Blocs very capable. The forum is generally helpful and Norm is developing Blocs at a far faster pace than RW.
Thanks for the confirmation. In the pre-APFS days, putting home folders on the boot partition made it difficult to install betas or keep multiple OS versions for dev purposes. Moving the home folder to another volume made swapping OS versions much easier without needing to migrate data. Now that the OS is protected and on its own volume, there is at least some separation of data and OS so that the OS partition can be wiped and reinstalled. Depending on whether Blocs uses regular file paths or security-scoped bookmarks, there may be a solution I could help with.
I’m enjoying Blocs so far, mostly because the page elements behave as expected, which is something I despise about some stack plug-ins that I’ve used in RW. And the code that Blocs generates seems to be very well behaved. I also really like the way you can toggle between device widths and adjust settings for each layout. Very nice.
One oddity that I’m already fighting with is that clicking on an asset will background of whatever bloc just happens to be currently selected… This has already caught me quite a few times while chasing the missing-thumbnail issue by clicking and right-clicking a lot on the asset manager tiles. I feel like the background image/video well in the UI should be focused before a click in the asset manager will change it, but that’s not the way the app’s code has been written. So some element always seems to be selected, and any click on an asset is going to set that elements image/video property whether you wanted to or not. I’m going to have to get used to this
After a little bit of sleuthing, I’m gonna say this isn’t a permissions issue but rather a file path coding issue in Blocs where different methodologies are used in different parts of the app.
Each time you open a project, Blocs reads all of the project’s embedded assets and linked assets from disk wherever they may be, and it makes a working copy of every asset in structured paths below the following path…
Blocs appears to wipe this path clean every time you close a project, then it reconstructs temp copies of each and every asset when a project is re-opened.
On my machine, I have 1) a test account where the home folder is under /Users on the default volume as it should be, and 2) my primary account which has its home folder relocated on another volume with the advanced sys pref setting pointing to the new location, plus a symlink from /Users to the new location.
Under both users, Blocs correctly locates all of each projects’ assets and generates copies below the tempAssetStorage folder. I have tested using one project under my primary user and a second project on an external volume accessible to both users. My primary user behaves identically when opening either project and the test user behaves properly on the shared project. If Blocs has permission to access and read the assets with no issue under either user, then it must be using a different coding methodology when it generates, stores and uses previews of those assets within the UI settings and the asset manager window.
So my bet is that Bloc’s code has evolved overtime to have slightly different file path or URL construction methodologies in different parts of the app. It definitely happens, especially when Apple changes frameworks over time and their suggested uses of file paths and URLs… New frameworks may not even support file paths, so a dev is forced to mix file path handling and URL handling within an app. This is a part of Mac app development that is definitely not fun, so no blame on Bloc’s devs. I’m just hoping to help point out an issue that might be easily resolved and might eliminate potential problems elsewhere.
I would suggest you file a bug report with a link to this thread and just see if anything can be done to improve the situation. As far as I can tell though this only impacts a small number with user accounts and OS on separate drives.
When SSD drives were new and prohibitively expensive splitting was a fairly common practice due to space constraints. I would wager it happens far less frequently nowadays and I wouldn’t be surprised if Apple closed down this option entirely.
As far as I know, you and I are the only ones to have hit this issue and in my case I reconfigured my setup to accommodate Blocs. The system became more responsive in general and it was never needed on the newer mini that came with a larger drive. It sounds like your workflow requires more a more custom arrangement.
I would suggest you file a bug report with a link to this thread
Done - Thanks. I’ve noticed a couple other recent posts about missing assets, so you never know if similar path construction code could be affecting them.
I think other cases of missing assets have generally been down to newer users who are less organised and maybe added an image from the desktop and then moved it later on or something similar. Anything that makes Blocs better though is welcome.
The reason for this is because MacOS will not allow resources to be loaded into a WKWebview from other servers (drives) as it causes a CORS error.
The workaround is that the assets and the app need to be stored on the same drive. The Asset Manager and various other portions of Blocs including the main design canvas use the WKWebview to display content.
I have encountered CORS issues in the past with another app relating to server hosted fonts that would not display properly in certain browsers. It was possible to resolve this via some htaccess code on the server, but I don’t suppose something similar could work in Blocs.
I really like the way tech like you and many other reveal their findings. This was was informative. I don’t completely understand it, but it is enough for me.
I assume it would not be a good idea to clear out this folder, like we do with the Windows temp folder right?
Thanks Norm. I just saw this today, so sorry for my delay in responding.
Assuming that it doesn’t cause other permission problems, this is an easy work-around in my case. In my dev config, I maintain my home folder plus a few test users on another partition/volume using the default macOS folder structure, with a root /Users folder plus a root /Applications folder for apps that I don’t want to have to migrate each time I install another OS version. I just tested by copying Blocs to that other partition/volume into its /Applications folder and sure enough, the project opens with all asset thumbnails now visible in the asset manager and the assets showing properly in the project window.
So to clarify…
Because you pull working copies of all the project assets into your tempAssetStorage/ folder at runtime, a user can store assets on whatever volumes or NAS folders they wish and Blocs will locate them at runtime to create the working copies. A user just needs to run Blocs from the same partition/volume that their home folder is actually located on, so that the route from Blocs.app to ~/Library/Application Support/Blocs 4/tempAssetStorage/ remains on that same partition/volume. I think there’s a more concise way to phrase this, but does this sound correct?
