Image Bug Continues


#1

@norm I have a photography blog that I update often. Bloc continues to not load the current images, it looks fine in the Bloc program but when you upload the blog it shows images from past post.

Last week I even made a page templates with just image holders. Not linked to any photos. It seemed to work last week but this weeks blog post did it again. It loaded images from a few weeks ago.

This is so frustrating! I can’t even post a simple blog without spending hours trying to make Bloc load the correct images!

Here’s a link that I uploaded this outside my normal blog to show the problem. It’s suppose to be all snowy owls. But it has some bald eagles for a past blog post.

http://itsmytimephotography.com/MC/snowy-owls.html

Feeling very frustrated!

Casey


#2

When you export does the site load correctly when you run it via the desktop?

Are you duplicating a section to add new posts?


#3

Im also looking at your image names @1x-.png and @2x-.png these are not very descriptive, could it be that when you export and then try to upload to your server, these images already exist so it doesn’t replace them with the newest ones?

Actually it may also be caused by the fact the images have the same names. Let’s say you have various images in your site called @1x-.png when you export all of these images will be placed into the export images folder, it could be that blocs then prevents multiple images being copied into the same location.

I could add some logic to check for this, in future and make some changes on the fly.

Try giving the images more unique names, and re-adding them for now and see if that fixes it. I’ll test out some scenarios to see if that replicates this issue.


#4

It does the same on export with Desktop. I’m not duplicating any sections. A new blog post (page) are blank pages that I duplicate (add a new page) and they have no images just placeholders for page elements.

I think your guess that it might be the image file name could be causing the problem. I use a Lightroom preset export for @1x and @2x images. It’s suppose to add this to the original filename. It looks like it might not of added the filename.

I’ll rename the images and see what happens. Thanks for helping figure this out. I’ll let you know how it turns out.

Casey


#5

… I’m intruding …
even if I am not a technician, I can confirm that for a long time I too have gone crazy having the same problem.
I also manage with Lightroom. Then I solved giving the images unique names.


#6

That was it. I renamed the files and it’s good now. Wow, did that frustrate me.

@norm Thank You! I’ve already changed my Lightroom preset.

One quick question. Do I even have to name the files @1x @2x or does Blocs add the suffix when you choose the different size files?

Again Thank You.

Casey


#7

It’s not essential but it makes it easier for management, otherwise the images would need different names to the original.

Think of it like this, when you export your site all of the images from it go into a single img folder, file systems don’t allow files with the same name to exist within a folder, so adding the @2x means the file name is identifiable but it’s changed, and also has a reference to the res.

On a side note, I’ve added a fail safe to Blocs 2.5 beta build5 that will prevent images with the same names from being added via the asset manager, Blocs will explain why and ask you to give your duplicate asset a different name. This should help prevent this issue and frustration in future.


#8

Thank you, that will be a great addition to the asset manager.

Casey


#9

Good idea.
But what happens when you have duplicated images in the asset manager already in older projects?


#10

You’ll need to manually fix it.


#11

oh oh.
This sounds like plenty of work.
oh oh.


#12

The fact this is just coming to light now shows how rare the issue is. I don’t think it’s something most users would ever encounter and for it to require lots of work would mean someone is adding lots of images to projects all with the same name but in various locations on the file system, I don’t think that’s a common scenario.


#13

OK. Thanks Norm.
We’ll see.
I stay on the optimistic site. :relaxed: