Loading...
 
Skip to main content

Features / Usability


Articles with more than 6 images.

posts: 97

We have a number of articles with more than 6 images.
We have generally standardised on 1024 px wide and have kept the file sizes below 100kb.
After about 6 images some don't load. It is not always the last image(s) that don't appear but they are generally the same ones each time. Often F5 or failing that Ctrl F5 solves the problem. That's fine for admins but not all that good for ordinary users. We have done a lot of google searches etc on this but have not found a solution.

We can split the article with a link at the bottom to the next part, but again that is a not very flash work around.

The article we are working on at the moment has 10 images
and the file size appears to be 18,240 bytes.

The full article is likely to have 20 images or a few more.

We are using tikiwiki V11.0

We are using .jpg files re sized and web optimized with irfanview

Any help would be appreciated.


Regards

Rod

posts: 97

This article now has about 20 pictures and maps.

The problem items were 3 of these that failed to load first time randomly sometimes all 3 and sometimes one or other, sometimes all 3 would load ok.

I have used a capture program to create another version of these 3, and now they load first pop more often (but not always) in Chrome and Firefox. When they do fail to load a single F5 now seems to solve the problem.

They are still play up all the time in IE10.


posts: 97

Does no one else have this problem? It seems to be about the 5th and 6th image out of 26 now that doesn't load.
If we delete these images then the new 5 or 6th image doesn't load. Not the end of the world as people can always refresh but it does make the article look unprofessional.


posts: 1563 Germany

Hi Robuste,

sorry, that nobody answered before.

I actually have no idea what can be the cause of your problem.

You say, that all images are loaded well in IE, but not in other browsers?

Robuste wrote:
They are still play up all the time in IE10.


You work with Tiki 11.0 you say.

Did you have the same setup on a previous version and di it work over there?

How much memory_limit do you have active on your server?
Did you make sure, that you have 256MB memory_limit?

If you have an Apache Server, you can set this in the .htaccess file in the Tiki websites document root (the directory where your domain usually points to).

If so, did you remember to rename the standart _htaccess to .htaccess and uncomment the line with the memory limit?

Copy to clipboard
about line 90: # php_value memory_limit 256M to php_value memory_limit 256M


Did you clear the Tiki caches?

Copy to clipboard
http://yourdomain.com/tiki-admin_system.php?do=all


Can you try to reproduce the behaviour with one single article at
http://demo.tiki.org/11x/ ?
user: admin
pw: 12345

Are you on shared hosting or on a dedicated managed server or a dedicated root server?

I feel, that 18MB for one single article seem to be quite huge.

Maybe you want to provide a link to your website?


If you checked all this, maybe you want to file a bugreport here:

http://dev.tiki.org/tracker5
But read this before, if it is the first time:
http://dev.tiki.org/How+to+Submit+a+new+item+on+the+Wishlist

So that is it for now, looking forward to hear from you and crossing fingers, that you find a solution.

Cheers
Torsten

posts: 97

Hi there Torsten

Thanks for your reply

1 The behavior is worst when using IE10

2 I had the same problem on tikiwiki V10 but the site was very much still under development then.

3 The php memory is set to 256M and my hosting provider tells me I can raise it to 512M, though I find this a little surprising? I experimented with memory settings and the site runs and this article shows the same behavior down to 32M. It dies at 16M ๐Ÿ˜Š so i assume that my settings are at least working. I am not sure if there is an easy way I can check what memory is actually being allocated? I think tiki_check.php just checks the settings not the actual memory?

4 I am using shared hosting at www.crazydomains.co.nz

5 I have cleared the caches with no improvement.

6 I will try reproducing on the demo site tomorrow or as soon as i get a chance.

The link to the page is

http://www.mcadam.org.nz/bluebook/tiki-read_article.php?articleId=189

I have created a test / tester123 account for you to use.

Rod


posts: 97

Sorry Torsten forgot my own rules ๐Ÿ˜Š

The login is test / Tester123A

Rod


posts: 97
I found a script on line that checks memory available and that confirms 256M

posts: 1563 Germany

You could have checked the memory_limit with
/tiki-phpinfo.php -> Core



Btw: where are you storing your images and your files?

a) file-gallery or imagegallery

b) file-gallery in database or in directory

c) if directory in Tiki document root or outside Tiki document root?



I did review your site a little bit.

Most articles have one huge image, some as wide as my old 4:9 15" screen (1024px).

Only the story of JLM WWII experience has a few images, but they are mostly smaller.
(I did not dig deeper than the first ten articles)

Differently to one of my above postings, I suggest you to make a (new clean) show.tiki.org instance, reproduce the bug there and make a snapshot.

If you need assistance, I can give you a hand, but it is quite well explained in a video here:

http://dev.tiki.org/How+to+Submit+a+new+item+on+the+Wishlist

Our Tiki bugtracker and the show.tiki.org tool is a way to help users to show the false behaviour as close as possible in the users setup and thus to as much as possible to make eficient and easy bugtracking possible to the coders.

This is in context to this:

http://www.chiark.greenend.org.uk/~sgtatham/bugs.html

If you are used to bug reports, you can watch the video here (optionally) and file the bug report directly here:
http://dev.tiki.org/Make+a+wish

From there you will be guided to the new bugtracker item and to the option to create a show instance.

Please mind, that in Tiki wishes and bugs go into the same tracker, just distinguished by category.

Earlier on I suggested to reproduce on demo, which is the old way and as I just yesterday tested show.tiki.org, I must say it is a far better idea to reproduce on a clean show.tiki.org instance.

Cheers
Torsten


posts: 97

hi there Torsten

Thanks for your further reply.

1 Out images are in file galleries.

2 The file galleries are in a directory.

3 The directory is: public_html/bluebook/img/uploads
so i guess that is inside the document root?

4 Did you get the behaviour I have reported when you looked at the site?

5 Yes we have opted for 1024px images where possible in this small family site which provides both family history formation and to some extent longish term storage of that information. All recent images have been re-sized down to 1024 where appropriate and web optimized. Some earlier articles have images which are % scaled but we will replace these in due course.

6 The JLM WWII articles has I think 26 images and all but about 2 are 1024. The weird thing is that the behaviour started at about 5 or 6 images and didn't get any worse as the number of images got to 26. We replaced the 3 images that gave problems with either other images or reconstituted ones, but that didn't improve things.

Although the images are 1024px, the file size is quite small varying from 23KB to 139KB but with the majority under 50KB.

7 I will resize / resample all the images to 640px and see what that does and report back before I do anything else.

Thanks

Rod


posts: 97

hi there Thorsen

After a lot of experimentation with reduced image size and creating the articles again from scratch etc, I decided to duplicate the site on another hosting account I have with a different provider. This seems to have totally solved the problem.

The original site was with www.crazydomains.co.nz

They are cheap but unreliable. I have known that for a while, but was going to tough it out until my annual account was due. I will now give up on them entirely.

Thanks very much for all of your suggestions and help.

Regards,

Rod