Image loop crashing page load

Hi there, I have some code that is looping through a set of pages, then looping through a list of images in each of those pages. For some reason, it occasionally hangs and crashes the tab:

<?php foreach($pages->find('projects')->children()->listed() as $item): ?>
      <?php

      if ($item->clickable()->toBool() === true) { ?>
        <tr data-href="<?= $item->url() ?>" class="project project--openable">
          <td class="project--name"><?= html($item->title()) ?> -  <span>Open Project</span>
          
            <div class="gallery">
                <div class="project--slider">
                 <?php
                 $images =  $item->hoverImages()->toFiles();
                 foreach($images as $image): ?>
                   <img src="<?= $image->url(); ?>" alt="">
                 <?php endforeach ?>
                </div>
            </div>
          
        </td>
...

It’s definitely the line:

<img src="<?= $image->url(); ?>" alt="">

that is crashing it. Previously I was doing some cropping on that line, which was prone to crashing the site even more. But it still occasionally happens with just that line in. Any ideas why?

UPDATE:
What makes this problem even weirder is that for me, it doesn’t crash at all, but for the client it happens a lot. When I say “crash”, I mean it kills the tab. Opening a new tab sometimes fixes, sometimes results in another crashed tab.

Hm, can’t tell, the code looks fine, However, I’d nevertheless suggest wrapping the images part in an if statement to prevent an empty div if there are no images:

<?php $images = $item->hoverImages()->toFiles(); ?>
<?php if ($images->isNotEmpty()): ?>
    <div class="gallery">
        <div class="project--slider">
        <?php foreach($images as $image): ?>
            <img src="<?= $image->url(); ?>" alt="">
        <?php endforeach ?>
        </div>
    </div>
<?php endif ?>

How do you know it’s that line? There’s probably more code? If there was an error in the PHP code, it should actually pop up in the error logs and Kirby should show the whoops error page instead of crashing a browser tab.

That’s good to know, thank you! I’ll implement that change.

I know it’s that line because if I remove it, it doesn’t crash at all.

It never actually crashes and shows the whoops error, just loads a blank page forever then eventually shows the generic “this tab crashed” Google Chrome error. I’m really struggling to get my head around it!

Check if there is anything in the console

Also, how many pages and images are there? Could it be that you are running into script run time issues on the remote server? That would probably explain why your are not experiencing this on localhost.

I think checking the php error logs and the server logs would be crucial.

Can’t access console, the entire tab crashes! Here is a short video showing the behaviour:

The page never loads, is totally dead (can’t be interacted with in any way), and eventually shows the generic Chrome error.

Fortrabbit, the host says it could be a php memory issue:

“unfortunately, Kiby did not log any errors, but most likely the issue is image/crop-related.
I renamed the /media folder to /media-backup-fr and Kirby created the /media folder on its own. Maybe SFTP messed up some (sub)folder permissions or there is a corrupted image. Honestly, idK - so far it is working.”

This was with the previous crop code in there, but it’s still crashing (albeit less) with just the above code.

Nothing in the error or server logs. And I don’t see it when testing remote, on exactly the same link as the client! Such a strange issue.

Not many images or pages. 11 pages, currently only one page with 4 images in that field.

Hm, I think this issue is somehow JavaScript related. It says

Transferring data from code.jquery.com. I’d try and load that script from your own server, not from a CDN. You might also want to consider if you really need jQuery…

Thanks, I’ll try that!

Totally with you on not needing jQuery, however budget and time constraints forced our hand here.

UPDATE: Think we have indeed pinpointed this to an unrelated bit of Javascript, thanks so much for helping debug!

shall we remove this as the problem wasn’t Kirby related?