Loading...
 
Skip to main content

Architecture / Installation

Forum List Topic List

Forums » Architecture / Installation » Problem with thumbnails since upgrade to 17.2/18.2
 
Thread actions
Print this page
  • Print all pages

    • Problem with thumbnails since upgrade to 17.2/18.2

    Posted by RandyH posts: 33

    I cannot get thumbnails to display in pages since upgrading to 17.2 (and even in 18.2 now). If I click on the "JPG" image icon put in place of the thumbnail (or the alternate text that has a link), I see the image just fine. If I do a direct display via the URL, I see the image just fine. Just will not appear in a page. See http://h600.org/wiki/Half+Identical and http://h600.org/wiki/B10DNA as two examples. I have other sites on the same server with the same issue.

    I have been pulling my hair out on this one. Just not sure how to debug the problem it seems. Have read other forum posts from earlier releases (e.g. see Problems with thumbnails since upgrading to 10.1) but not found anything useful. This started when I upgraded to 17.x from 12. And continues (possibly worse) with 18.2. These two upgrades are the first that forced an override on the server to use PHP 5.6 and I suspect this has something to do with it.

    All the images are stored in a gallery. Images are in the file system, by default. None in wiki_up. All in a non-accessible directory outside the WWW URL access. None have permissions to restrict access. (for the pages referenced above)

    I have cleared caches; both on the server and on the browsers. I have not re-uploaded images (or resaved them) that I am aware of. But have been trying to figure this out for months now. Using different browsers on different devices as well. When I come in anonymously on a clean browser, I see no images on either page.

    I do notice that it sometimes works slightly better when logged in than when accessing as anonymous. But it also behaves differently as I progress. Making me think it is a cache issue. Neither page referenced above used to display anything (or will on a fresh browser with cleared history / cache and using anonymous). The B10DNA page seems to display most, if not all, image thumbnails while I am logged in. Even if I clear server caches but not if I clear browser caches.

    Reads: 3114
    Posted by Bernard Sfez / Tiki Specialist posts: 8654 France

    Hi Randy,

    You have an issue with the scale parameter.

    Copy to clipboard
    <img src="dl60?display&amp;scale=0.66" style="display:block; margin-left:auto; margin-right:auto;" alt="GEDMatch comparison graph of two full siblings that are phased to highlight half-identical matching" class="regImage pluginImg60 img-responsive">


    This "&amp;scale=0.66" is killing the display.


    Posted by RandyH posts: 33

    Bernard, thanks for the response. Interesting point. The pages are 100% Wiki code (no HTML). I did use a width="66%" construct on those first three {IMG} instances to get them to display and scale properly. Instead of the default thumbnail size. If I remove the "width=", it will appear in the thumbnail size while I am logged in. It does not affect the display for anonymous users though (still does not display at all). So I suspect something else is the issue.

    Those first three images are unique. In general, I will put images in a {DIV} construct and put a width in the DIV to control the size of the displayed, embedded image. This was one of the few places I put the width on the {IMG} construct. None of the images on the second page (B10DNA) have any width constructs. Nor on most of the site. Yet they do not display as default thumbnails either. So I suspect there is something else going on that changed during the upgrade that is preventing the display.

    I tend to experiment until I figure out what gets a pleasant formatting then use it over and over. Images were always displaying (either as default or scaled) before the upgrade. This particular example of the first three images was something I had to work on extensively. In this case, it is a {DIV} with a || (table) with {IMG} constructs containing width= constructs in the table cells. The code is below:

    Copy to clipboard
    {DIV(clear="both")}{DIV}
Provided here are three graphic chart examples showing the ((autosomal)) comparison using ((GEDMatch))'s ((Chromosome)) browser.  (You can click on any image to view it full size.)
{DIV(float="left" width="100%")}||{img fileId="52" thumb="y" rel="box[g]" width="66%" imalign="center"}|{img fileId="53" thumb="y" rel="box[g]" width="66%" imalign="center"}|{img fileId="58" thumb="y" rel="box[g]" width="66%" imalign="center"}
::__Full-Identical (Green) Regions__::|::__Half-Identical (Yellow) Regions__::|::__No Matching (Red) Regions__::
....||{DIV}{DIV(clear="both")}{DIV}

    Am always open to better ways to format the page effectively. (note: this version is likely not smartphone friendly.)

    Posted by Bernard Sfez / Tiki Specialist posts: 8654 France

    And if you try with a fixed width in pixel ?

    Copy to clipboard
    width="400px"


    Just to test...

    Posted by RandyH posts: 33
    No apparent difference

    Posted by RandyH posts: 33
    Am not sure this is a real bug / configuration issue in Tiki or just some weird mix of environment issues. As mentioned, this was the first time I had to override the default PHP setting to accommodate Tiki. Last couple of months, the test environments have not been working when I wanted to replicate and report real, other bugs. Will give it a try. But I might find it easier to setup another instance on my site, replicate the issue, and give you full access (seeing as two instances there exhibit the same issue; albeit in different domains but on the same server).


    Posted by RandyH posts: 33

    Appreciate and understand. This is not appearing like one that can be easily replicated due to the fact it sometimes (partially) disappears for logged in accounts.

    Well, I seem to have finally gotten it to work on one of the installations. See http://mycuz.us/wiki/Vasilije+Gift for an example page of it working for anonymous users, reliably.

    So now to investigate how the two installations on the same physical server differ ..

    UPDATE: So after investigating, I recall how I "fixed" it on one site to work. I changed the code in the {IMG} macro from fileId="52" thumb="y" rel="box[g]" width="66%" to src="dl52" width="66%". The change allows the images to appear in the page at all times. But this removes the ability to click on the smaller version and get a full screen version pop-up. (In a few instances on the "fixed" site, I added link= construct to get the full image capability. Not as a pop-up, but a download that appears in a new program. On this broken site, I can link to the file gallery itself to get this capability but this is not as useful.)

    If I add the thumb="y" rel="box[g]" back in but retain the change to src from fileId, the pop-up action initiates but with a blank pop-up. And the image still downloads and launches in a desktop application. So not desirable either. If I change back to fileId, the behavior is as before (so repeatable).

    Will continue to experiment to find where the error is introduced with the upgrade. And see if I can replicate on an instance — to date, still, I cannot get a new instance to work.

    Posted by RandyH posts: 33

    (could not update the last post so ...)
    UPDATE: So getting closer to the original text form of fileId="52" thumb="y" rel="boxg" width="66%" that stopped working, I see that a variation to my update of before is src="dl16" thumb="zoombox" width="100px". When clicking on the thumbnail, I get a blank popup as before but now also get the file downloaded and popped-up in a local screen that displays the image (if the browser and device is setup to allow such action). Overall, it seems a pop-up or mouseover with a fileid= reference stopped working. Changing it to src="dlnnn" seems to resolve some of the problems except the thumb with pop-up function still does not work as before. I am still not able to recreate on your test site as the virtual installation does not install correctly (configuration error).


    Posted by RandyH posts: 33
    Will see if I can free up the time during your open hours session. FYI, the following are current pages before and after: http://mycuz.us/wiki/Slavic+DNA+R1a (still untouched and causing the issue), http://h600.org/wiki/B10DNA (fixed with the latest update mentioned above to get it pseudo-working). A majority of the images on H600 are setup as thumbnails with pop-up full-size meant to happen. Most on mycuz.us were simply embedded, readable photos or images that could be clicked to get a full-size and/or downloaded version. Not originally needed to be pop-up or used as thumbs. But the mentioned page above is all thumbnails.

    Posted by RandyH posts: 33

    Many thanks to Bernard Sfez during the Tiki Online Open Hour. After we got around the difference of opinion on UTC, and struggling 30 minutes to get the webmeeting software working and installed with my microphone, we progressed on trying to resolve the thumb image problem. After exploring lots of things, and even straying into other problems I have reported (e.g. default File Galleries listing in the top-bar "42" menu), we tried one more thing at the very end. The SSH approach to cleaning the caches. (This was actually to see if it helped the Menu issue.) This seems like it may have resolved the thumbnails being generated in the pages. I am going through and unwinding the fixes, patches and similar changes now. Feel pretty stupid as I thought I had done this (clear directory directly versus the web interface to clear caches) as one of the checks earlier. But maybe not since the upgrade to 17.x then 18.x Seems to have helped a lot but not 100%. Still investigating further ...
    UPDATE: took off the fixed notices, as it was not really widespread. Just the pages I was regularly checking. An example page now that has never shown the thumbnails is http://h600.org/wiki/Structure+and+ToC+editing . Beginning to work on replicating in other sites. Thinking this is a cache issue and maybe not browser or server based but in the network caches. So frustrating.



    Posted by RandyH posts: 33

    Just as another data point. Was creating a new image in a page and noticed the following. The code used is:

    Copy to clipboard
    {DIV(float="left")}||{img fileId="102" thumb="y" rel="box[g]" imalign="center" width="300px"}::__Calculating the GD from two 12 ((STR)) Marker testers__::||{DIV}

    If I set the width to 300 or less, the thumbnail appears. If I used 400 or more, it does not. The original image is 976x145 pixels. If I set the width to "100%", the image appears. If I do not use a width, I get a tiny 100 pixel wide thumbnail and the image appears. This determination was made when viewed in a preview of the edit of page http://h600.org/wiki/Genetic+Distance


    Posted by Bernard Sfez / Tiki Specialist posts: 8654 France

    Mmm...

    I have the feeling the code is over complicate for what you need.
    The div + table to have a border then center alignment for the text in bold... A div with a class would do better or trying to use the maximum of setting from the img plugin.

    Try to remove everything keep just the image.
    Check. 😊

    Posted by RandyH posts: 33

    I just had to laugh. Was in another section of the site and saw one thumbnail appearing and one not. Look at the screen capture of the page and then look at the wiki code. No {DIV}, no "width=" or any other resizing. As simple as you can get. Yet one thumbnail appears and one does not.

    (BTW, tried to upload and include screen shots. But got your Cross-site Forgery error pop-up on trying to upload. Still cannot get your demo system to install to try and replicate the issue that way either. Will never install; has errors.)

    Since cannot show a screen shot, here at least is the code where the first thumbnail will not display but the second displays just fine (and both show a pop-up, larger image just fine when clicked on):

    Copy to clipboard
    {img fileId="97" thumb="box")
{img fileId="96" thumb="box"}


    I have given up trying to debug this. Over 6 months of error. Am guessing it is an issue with caches (either in TikiWIki, in the network equipment at the hosting provider, etc) or odd CPU limitations provided by the hosting service (Hostgator) that seem to cause failures of things in odd ways. This because it behaves differently on different days for the same pages. Not consistent. It is not a browser or wider network cache issue because everyone has the issue across the world and I have tried 4 different browsers. As the Wiki needs to just work and is primary, it is time (after 10+ years) to move on from TikiWiki to simply Mediawiki and on my own servers. More control, more reliability, etc. I know it works. Too many years of things just breaking more and more now instead of working better and better with TikiWiki. Have struggled for 4 years trying to get basic tables working in the WYSIWYG editor, spreadsheets, reference system, etc. Oh well.